IPSEC 표준화 동향 이 계 상 정보통신공학과 동의대학교 ksl@dongeui.ac.kr

IPSEC 표준화 동향

이 계 상정보통신공학과

동의대학교ksl@dongeui.ac.kr

Outline

• IPSEC 관련 IETF WGs

• IPSEC WG

• IPSRA WG

• IPSP WG

IPSEC 관련 IETF WGs

• IPSEC WG– 1993 년 발족– IP security protocols and algorithms 표준화

• IPSRA WG– 2000.3 월 1st WG meeting– Remote access issue

• IPSP WG– 2000.3 월 1st WG meeting– Policy issue

IPSEC WG

WG Goals

• 네트워크 계층에서– 보안 프로토콜과– 암호 알고리즘 표준을 개발하여– cryptographic security service 제공 :

• Authentication• Integrity• Confidentiality• Access Control

• 응용계층에서 – 네트워크 보안 프로토콜 및 키 관리 지원 프로토콜

IPSEC Protocols

• 네트워크 계층 보안 프로토콜– AH (Authentication Header)– ESP (Encapsulating Security Payload)

• 응용계층 키 관리 프로토콜– IKE (Internet Key Exchange)

AH protocol

• Authentication 알고리즘 이용• Integrity, Data Origin Authentication 서비스 제공

Next Header (8) Payload Length(8) Reserved (16)

SPI (Security Parameters Index) (32)

Sequence Number (32)

Authentication Data (32* n)

IP header AH header TCP, ….

ESP protocol• Encryption 과 Authentication 알고리즘 이용• Integrity, Data Origin Authentication 및 Confidentiality 서비스

제공

Pad Length (8)Padding (0 - 255 Byte)

SPI (Security Parameters Index) (32)

Sequence Number (32)

Payload Data

Next Header (8)

Authentication Data (32* n)

Encry

ptio

nA

uth

entica

tion

IP header ESP header TCP, … Payload ESP Trailer ESP Auth.

Security Association

• Simplex connection between two end-points • Affords security services to the traffic carried by it

AH or

ESP

SA

알고

리즘

AH or

ESP

SA

알고

리즘

Host or Security Gateway Host or Security Gateway

Security Association (cont.)• 트래픽이 양방향이면 , 두개의 SA 필요• Flexible granularity

– 두 SG 간 모든 트래픽에 하나의 Encrypted Tunnel 을 이용 . 또는 , 두 SG 를 경유하는 각 Host 쌍 트래픽 마다 하나씩 여러 Encrypted Tunnel 을 이용

• Two modes– Transport mode SA: 호스트 간에만 적용– Tunnel mode SA: IP tunnel 에 적용

• SA Combination– 트래픽 스트림이 원하는 보안 서비스가 하나의 SA 로는 충족될 수

없을 때 , 두 개이상의 SA 를 결합– 4 가지 기본 결합 방식지원을 의무화

IKE Protocol

• SA and Key Management Protocol– SA 협상 , 생성 , 관리– Key 생성 , 분배 , 갱신

• A hybrid protocol of – ISAKMP : framework, message format, phases– Oakley : key exchange modes– SKEME : public key encryption

Phases of IKE Protocol• Phase I

– Establishment of secure and authenticated communication channel (IKE SA) and authenticated keys

– 4 Authentication methods• Preshared keys• Digital signature• Public key encryption• Revised public key encryption

– Main and aggressive modes

• Phase II– Establishment of IPSEC SA– Quick mode

Main Mode with Signatures

Initiator Responder

HDR, SAHDR, SA

HDR, KE, NiHDR, KE, Nr

HDR*, IDii, [CERT,] SIG-I HDR*, IDir, [CERT,]

SIG-RHDR: Header SA: Security Association KE: Key Exchange

N: Nonce CERT: Certificate SIG: Signature

ID: Identity i: Initiator r: Responder

Aggressive Mode with Signatures

Initiator Responder

HDR, SA, KE, Ni, IDiiHDR, SA, KE, Nr, IDir,

[CERT,] SIG-R HDR, [CERT,] SIG-I

HDR: Header SA: Security Association KE: Key Exchange

N: Nonce CERT: Certificate SIG: Signature

ID: Identity i: Initiator r: Responder

Quick Mode in Phase II

Initiator Responder

HDR*, HASH(1), SA, Ni

[, KE] [, IDci, IDcr]HDR*, HASH(2), SA, Nr

[, KE] [, IDci, IDcr] HDR*, HASH(3) HDR: Header SA: Security Association KE: Key Exchange

N: Nonce ID: Identity

i: Initiator r: Responder

IPSEC and NAT

• Traditional NAT (Network Address Translation)– Home network, SOHO network, etc.

• private addresses vs. globally unique addresses

– Basic NAT :

• one group of IP addresses --> another

– NAPT (Network Address Port Translation) :

• many network addresses/ ports --> single net. Addr/

ports

NAT operation - example

Stub router w/NAT Stub router w/NAT

Regional router

Stub A Stub B

WAN

s = 198.76.29.7

d = 198.76.28.4

LAN

10.33.96.5

s = 10.33.96.5

d = 198.76.28.4

LAN

10.81.13.22

s = 198.76.29.7

d = 10.81.13.22

s = 198.76.29.7

d = 198.76.28.4

WAN

NAPT operation - example

Stub router w/NAPT

Service Provider router

Stub A

WAN

s = 138.76.28.4, sport = 1024

d = 138.76.29.7, dport = 23

LAN

10.0.0.10

s = 10.0.0.10, sport=3017

d = 138.76.29.7, dport = 23

10.0.0.2

s = 138.76.29.7, sport = 23

d = 138.76.28.4, dport = 1024

10.0.0.1

s = 138.76.29.7, sport = 23

d = 10.0.0.10, dport = 3017

Incompatibilities between NAT and IPSEC

• between IPSEC AH and NAT

• between checksums and NAT

• between IKE address identifiers and NAT

• between fixed IKE destination ports and NAPT

• between overlapping SPD entries and NAT

• between IPSEC SPI selection and NAT

• between embedded IP addresses and NAT

Alternative Proposals

• UDP encapsulation– IKE and IPSEC packets are encapsulated in

UDP prior to being sent

• RSIP (Realm Specific IP)– addresses issues of IPSEC SPI demultiplexing

and SPD overlap

• IKE and checksum processing changes

IPSRA WG

Background

• Typical remote access in recent past– dial-up users via PSTN to network access server– PPP-based protocol – access control, authorization, and accounting functions

• RADIUS, TACACS, etc.

• Growing internet access via ISP • Advent of IPSEC• Remote access in future

– IPsec-based

Problems to be solved• User authentication requires human interaction• IPSEC IKE supports authentication methods based on

public- key technology• Public key infrastructure for authentication of individual

human users will take longer time to be deployed• Legacy authentication systems will continue to exist for

a while– OTP, username/password, H/W authentication token, etc

• And remote host configuration and security access control issues must be solved

WG Goals

• To define requirements and architecture– as an informational RFC

• To define user authentication mechanism– running IKE using legacy authentication mechanisms– standard track

• To define remote host configuration mechanism– standard track

• To define access control mechanism– security policy configuration– standard track

Past Meetings

• 1st BOF• 2nd BOF

– Washington, 1999.11

• 1st WG meeting– 47th IETF, Adelaide, Australia, 2000.3

• 2nd WG meeting– 48th IETF, Pittsburgh, USA, 2000.8

• Next WG meeting– San Diego, next week

Drafts

• No RFC• 3 WG drafts• Requirements draft (1)• Authentication drafts (2)

• Configuration draft (IPSEC WG draft)

• Some other drafts

Requirement draft

• Currently, 02 version (2000.11)• Understanding requirements in a number of differing remote

scenarios– Some shared and some unique requirements

• Requirement categories– Endpoint Authentication– Remote host configuration– Security Policy configuration– Auditing– Intermediary Traversal

Reference picture

Remote Access Client (IRAC)

Security Gateway (SGW/ IRAS)

Target network

Internet

Endpoint Authentication

• Refers to verification of the identities of the communication partners – e.g., IRAC and IRAS

• Machine-level authentication• User-level authentication• Combined User/ Machine authentication

• Remote access authentication– typically asymmetric– good deal of variation in authentication requirements

for differing scenarios

Remote Host Configuration

• Refers to network-related device configuration of the client system

• Parameters– IP address, subnet mask, broadcast address, host name,

domain name servers, default routers, MTU, default TTL, etc.

• Virtual address– virtual presence on the corporate network via an IPsec

tunnel

Security Policy Configuration

• Refers to IPsec policy configuration of both the IRAC and IRAS

• For examples,– block the internet access to IRAC from outside world– For IRAS, particular user’s access could be controlled

via policies based upon the particular address (or the address from a specific pool)

Auditing

• Refers to the generation and collection of connection status information

• Some accounting information– connection start time– connection end time– incoming octets– outgoing octets

• Maintains security and integrity of the connected network

Intermediary Traversal

• Refers to the ability to pass secured traffic across intermediaries such as NAPT and firewalls

Scenarios

• Telecommuters• Corporate to remote extranet• Extranet laptop to home corporate net• Extranet desktop to home corporate net• Remote dialup laptop (Road warrior) access• Public system to corporate network

Telecommuters(Dialup/DSL/Cable modem)

IRAC

Corporate network

InternetModem ISP SGW

• Dialup/DSL/Cable modem telecommuters using their own home systems to access corporate resources

Corporate to Remote Extranet

Corporate B

Internet SGW/FW

• Extranet users using their corporate desktop systems to access the remote company network of a business partner

SGW/FW

My Corporate A

User

Extranet Laptop to Home Corporate Net

Corporate B

Internet SGW/FW

• Extranet users using their own laptop within another company’s network to access their home corporate network

SGW/FW

My Corporate A

Pop

FTP

Corp-A laptop

Extranet Desktop to Home Corporate Net

Corporate B

Internet SGW/FW

• Extranet users using a business partner’s system (on that partner’s network) to access their home corporate network

SGW/FW

My Corporate A

Pop

FTP

Corp-A desktop

Remote Dialup Laptop (Road Warrior) Acces

• Road warriors using their own laptop systems to access corporate resources via an arbitrary ISP dialup connection

• Virtually indistinguishable from the telecommuter scenario• Typically dialup is short-lived

Public System to Corporate Network

• Remote users using a borrowed system (e.g., an airport kiosk) to access corporate resources

Scenario Commonalities• User authentication is required in almost all cases• Machine authentication for IRAC is generally only useful

when combined with user authentication. Combined user and machine authentication is useful in some scenarios

• Machine authentication for IRAS is required in all scenarios

• Device configuration mechanism is required in most cases• Dynamic IRAC policy configuration is useful in several

scenarios• Most Scenarios require auditing• An intermediary traversal mechanism may be required in

any of the scenarios

Authentication drafts

• Two proposals– Pre-IKE Credential Provisioning Protocol

• PIC draft

– Client Certificate and Key Retrieval for IKE• getcert draft

PIC draft

• One of approaches of integrating legacy authentication mechanisms into IKE

• WG draft• Currently 01 version (2000.9)

– Switched from XAuth to EAP for legacy authentication

• Use simplified ISAKMP/ IKE • Use EAP (Extensible Authentication Protocol,

RFC 2284) • No modification to IKE

PIC Architecture

Client/User

Authentication Server (AS)

Legacy Authentication Server (LAS)

Security Gateway (SGW)

Optional Link

PIC Protocol• Three main stages in PIC protocol (Btw Client and AS)

– establish one-way trust relationship. A secure channel from the client to the AS is created (Server authenticated)

– Legacy authentication is performed over this channel. Use EAP tunneled within ISKMP (User authenticated)

– The AS sends the client a (typically short-term) credential which can be used in subsequent IKE exchanges

• The credential can be thought as– a certificate, – a private key generated or stored by the AS and

accompanied by a corresponding certificate, or – symmetric secret key

Getcert draft• The architecture is similar to PIC’s

– integrate legacy authentication into IKE– use the separated AS

• The differences is in the details:– use TLS and HTTP rather than EAP, ISAKMP/IKE

• Client-side certificate generation option was selected by straw poll, among 4 proposals

• approved as a WG draft in 2000.11• Currently 00 version

Configuration (DHCP) draft• Virtual presence is useful

– using virtual IP address and then tunneling

• DHCP meets requirements of a host with IPSEC tunnel mode interface

• No modification to DHCP is required• draft is stable (currently 08, 현재 WG last call 진행중 )

Virtual host

SGW/ DHCP relay

Target network

Internet

DHCP server

Remote host virtual presence

Externally visible host

Configuration Steps

• Establish IKE SA between IRAC and IRAS• Establish DHCP SA between IRAC and IRAS• Exchange DHCP messages between IRAC and

DHCP server– using IRAS as a DHCP relay

• Establish IPSEC SA and start to communicate

Topic of next week

• Requirement– report update

• PIC and getcert– no agreement yet

• DHCP– near closure

IPSP WG

Backgrounds• Rapid growth of the need to control access to

network resources(BW, routers, hosts,…)

• The scope of IPSEC IKE limits the protocol to the authenticated exchange of keying material and associated policy information between the end-points of a security association

• However, along the path of a communication, there may be administrative entities ...

WG Goals

• To specify information model and data model for supporting IP security policies

• To develop an policy specification language• To provides guidelines for the provisioning of

IPSEC policies using existing policy distribution protocols– profiles for LDAP, COPS, SNMP and FTP

• To develop a policy exchange and negotiation protocol– discovering policy servers, distributing and negotiating

policy, and resolving policy conflicts

Past Meetings

• BOF– 1999.3

• 1st WG meeting– 47th IETF, Adelaide, Australia, 2000.3

• 2nd WG meeting– 48th IETF, Pittsburgh, USA, 2000.8

Drafts

• No RFC and 7 Internet drafts

• Policy Specification Language draft• Model draft• SPP draft• Architecture draft• Requirement draft• PIB draft• Roadmap draft

Simple Scenario

• Host A wishes to communicate with Host B, using a strong encryption

• Host A needs to determine– what its local policy (w.r.t. the comm. with B) is– what B’s policy (w.r.t. the same comm.) is– what SGs if any are in between A and B– what their policies (w.r.t. that comm.) is

Host A Host BSG1 SG2

Simple Scenario (cont.)• Depending on the individual policies involved ,

Host A may establish any combination of these SAs:– SA between Host A and Host B– SA between Host A and SG1– SA between Host A and SG2 – SA between SG1 and SG2– SA between SG1 and Host B– SA between SG2 and Host B

IPSP Architecture• Use of SPP protocol for SG discovery and policy

distribution

• Use of trust management to resolve policies

• Use of language to exchange policies

• Most of the burden of discovering and processing policy is placed on the initiator.– Such as policy resolution operation

• IPsec policy is defined in terms of local policy and signed policy statements from trusted entities

Security Policy Protocol

• Protocol for discovering, accessing and processing the security policy information

Host A Host BSG1 SG2

Policy Server A

Policy Server B

Q1/R1 Q2/R2

Q2/R2

Q2/R2 Q3/R3

SPP Message• Message = header + payload

• 6 message types– Query, Reply, Policy, Policy Ack, Transfer, KeepAlive

• 3 Payload types– Query: SG, Comsec, Certificate– Record: SG, Comsec, SA, Certificate, Policy

server, Transfer– Signature: RSA, DSA

• 메시지는 전자서명으로 인증

Summary

• IPSEC 관련 IETF WG 작업 내용 요약– IPSEC WG– IPSRA WG– IPSP WG

• Remote access 는 IPSEC 구축의 중요 부분

• 자동적이고 효율적인 IPSEC Policy management 는 망 운영에 매우 중요