Internet Key Exchange version 2 IKEv2 protocol

1
Internet Key Exchangeversion 2(IKEv2)protocol

• Kyesang Lee
• ksl_at_dongeui.ac.kr
• Dept. of Information Communications Eng.,
• Dongeui University,
• Busan, Korea

2
Outlines

• Introduction
• IPSEC protocols
• Security associations
• IKE protocol and its problem
• IKEv2 protocol
• Functions and features

3

• Introduction
• IPSEC protocols
• Security association

4
IPSEC Protocols

• Provide security services packet by packet
• Security protocols (network layer)
• AH (Authentication Header)
• ESP (Encapsulating Security Payload)
• Key Management protocol (application layer)
• IKE (Internet Key Exchange)

5
AH protocol

• By Using Authentication algorithms
• HMAC-MD5, HMAC-SHA-1
• Provides data integrity and data origin
  authentication security services

Authentication coverage
IP header
AH header
TCP, UDP,
Next Header (8)
Payload Length(8)
Reserved (16)
SPI (Security Parameters Index) (32)
Sequence Number (32)
Authentication Data (ICV) (32n for IPv4, 64n
for IPv6)
6
ESP protocol

• By using encryption and authentication algorithms
  such as
• DES-CBC, Null, 3DES, AES
• HMAC-MD5, HMAC-SHA-1, Null
• Provides data confidentiality security service
• Provides data integrity and data origin
  authentication security services

7
ESP Header
IP header
ESP header
TCP, Payload
ESP Trailer
ESP Auth.
SPI (Security Parameters Index) (32)
Authentication coverage
Sequence Number (32)
Encryption coverage
Variable-length Payload Data
Pad Length (8)
Padding (0 - 255 Byte)
Next Header (8)
Authentication Data (32 n)
8
Security Association

• SA should be setup before the secure
  communication takes place
• SA is the agreed state between two communicating
  peers

SA
SA
AH or ESP and its mode
AH or ESP and its mode
Alg. and Key
Alg. and Key
Host/ Security Gateway
Host/ Security Gateway
9
BASIC scenarios for SA usage

• Scenario 1
• providing end-to-end security between two hosts
• These hosts may lie behind the NAT.

Internet/ Intranet
Host
Host
10
BASIC scenarios for SA usage

• Scenario 2
• Simple VPN support

Host
Host
SG
SG
Internet
11
BASIC scenarios for SA usage

• Scenario 3
• Remote (mobile) host reaches its home network
• Remote user authentication and machine
  configuration may be needed.
• Remote host may lie behind the NAT

Case 1
Case 2
Host
Host
SG
Internet
12
SA Management

• IPSEC mandates both manual and automated SA and
  cryptographic key management
• Manual Techniques
• simplest
• human intervention
• practical in small, static environment
• but, do not scale well
• often employ statically configured, symmetric keys

13
SA Management

• Widespread deployment and use of IPSEC requires
  an standard, scalable, automated SA management
  protocol
• Automated Technique
• IKE (Internet Key Exchange) default protocol

14
IKE Protocol and its problems
15
IKE Protocol

• Automated SA and Key Management Protocol
• IKE
• Creates the first secure and authenticated
  channel between two communicating entities (IKE
  SA)
• Creates and manages child SAs (IPSEC SA)
• IKE operates in two phases

16
Phases of IKE Protocol

• Phase I
• Establishment of first secure and authenticated
  communication channel (IKE SA) and authenticated
  keys
• 4 Authentication methods
• Preshared keys
• Digital signature
• Public key encryption
• Revised public key encryption
• 2 modes (Main and aggressive modes)
• Phase II
• Establishment of IPSEC SA under the protection of
  the IKE SA
• 1 Quick mode

17
Phase IMain Mode with Signatures

• Initiator Responder
• HDR, SA
• HDR, SA
• HDR, KE, Ni
• HDR, KE, Nr
• HDR, IDii, CERT, SIG-I
• HDR, IDir, CERT, SIG-R

HDR ISAKMP Header SA Security Association
proposal KE DH Key Exchange N Nonce CERT
Certificate SIG Signature ID Identity i
Initiator r Responder means encrypted
18
Phase II Quick Mode

• 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
19
Problems of IKE protocol

• Complexity
• Specified in 3 documents IKE (RFC2409) ISAKMP
  (RFC2408) DOI (RFC2407) etc
• Total 8 exchange types ( 42) in phase I
• 4 authentication methods Preshared, digital
  signature, public key encryption, revised key
  encryption
• 2 operation Modes
• Main mode and Aggressive modes
• This led to Interoperability problem
• Vulnerable to DOS attack
• Latency until the initial IPSEC SA setup
• Should wait 9 message exchanges

20
IKEv2 Protocol
21
IKE version 2

• Has been developed as a next version of the IKE
  in the IPSEC WG of the IETF
• Simplify the existing IKE (lets say IKEv1)
• Single documented, including NAT-T and remote
  access issues.
• Replacing the 8 different initial exchanges with
  a single four message exchange
• After the initial message exchange, a child SA as
  well as the IKE SA is established.
• Reduce the latency for the IPSEC SA setup
• Increase robustness against DOS attack

22
IKEv2 phase I Initial exchange
Responder
Initiator
HDR, SAi1, KEi, Ni
HDR, SAr1, KEr, Nr, CERTREQ
HDR, IDi, CERT, CERTREQ, IDr, AUTH,
SAi2, TSi, TSr
HDR, IDr, CERT, AUTH, SAr2, TSi, TSr
Each message consists of the header (HDR) and one
or more payloads. Its format follows the ISAKMP
standard. Bracket means that the payload can
be used optional. Means that the message is
encrypted and integrity protected.
23
First round messages 1 and 2

• In message 1, the Initiator propose a IKE SA
  (SAi1) and present its DH public value (KEi) to
  the responder.
• In message 2, the responder agrees a IKE SA
  (SAr1) and present its DH value (KEr) to the
  initiator
• Prf, encryption alg., authentication alg., and DH
  group are agreed.

24
First round messages 1 and 2 (cont.)

• At this time, all necessary keys for the IKE SA
  can be calculated iteratively
• SKEYSEEDprf(Ni Nr, gir)
• SK_dprf(SKEYSEED, Ni Nr SPIi SPIr 0x01)
• SK_aiprf(SKEYSEED, SK_d Ni Nr SPIi SPIr
  0x02)
• SK_arprf(SKEYSEED, SK_ai Ni Nr SPIi SPIr
  0x03)
• SK_eiprf(SKEYSEED, SK_ar Ni Nr SPIi SPIr
  0x04)
• SK_erprf(SKEYSEED, SK_ei Ni Nr SPIi SPIr
  0x05)
• Nonces add the freshness to the key materials.
• As a result of this exchange, the IKE-SA which is
  secure but not authenticated is established

25
Second round messages 3 and 4

• The initiator and the responder authenticate each
  other and the message exchanged during the first
  round (AUTH)
• Each assert its identity (ID) and proves
  knowledge of the secret corresponding the ID
• And protects the contents of the first two
  messages
• Authentication methods
• Signature
• RSA digital signature RSA-signed
  PKCS-padded-hash
• DSS digital signature DSS-signed SHA1-hash
• Preshared key
• MAC using negotiated prf function

26
Second round messages 3 and 4 (cont.)

• Authentication by Signature
• Initiator signs the 1st message appended by Nr
  and prf(SKai, IDi) and gets AUTH
• responder signs the 2nd message appended by Ni
  and prf(SKar, IDr)
• Certificates (CERT) can be exchanged and used
  during this step
• Authentication by preshared
• AUTHprf(prf(shared secret, key pad or IKEv2),
  )

27
Second round messages 3 and 4 (cont.)

• With this exchange, the establishment of a child
  SA is piggybacked.
• In message 3, the Initiator propose a IPSEC SA
  (SAi2).
• In message 4, the responder agrees a IPSEC SA
  (SAr2)
• The traffic protected by the SA is negotiated
  through traffic selector (TSi, TSr) payloads

28
IKEv2 phase I under attack

• DOS attack
• State and CPU exhaustion
• A large number of half-open IKE SA initiation
  requests from forged IP address
• This attack can be made less effective by using
  Notify(Cookie) payload.

29
IKEv2 phase I under attack
Responder
Initiator
HDR(A,0), SAi1, KEi, Ni
HDR(A,0), N(COOKIE)
HDR(A,0), N(COOKIE), SAi1, KEi, Ni
HDR(A,B), SAr1, KEr, Nr, CERTREQ
HDR(A,B), IDi, CERT, CERTREQ, IDr, AUTH,
SAi2, TSi, TSr
HDR(A,B), IDr, CERT, AUTH, SAr2, TSi, TSr
30
IKEv2 phase I under attack

• The responder should when it detects DOS attack
  reject initial IKE messages unless they contain
  a valid Notify payload of type COOKIE.
• In this case, the first round is repeated one
  more time, and the number of the initial messages
  exchanged is extended to 6.
• Cookie should be generated in such a way as not
  to require any saved state to recognize its valid
  cookie when the 2nd IKE_SA_INIT message arrives
• For example, a good way is to be
  CookieHash(NiIPiSPIi)

31
Remote User Authentication

• In the scenario 3 where a remote host connects to
  its home network, remote host/ user
  authentication is needed.
• Specifically this refers to the authentication of
  the initiator (remote host/ user) to the
  responder (security GW)
• used typically in addition to a public key
  signature based authentication of the responder
  to the initiator
• resulting in asymmetric authentication in two
  directions
• Many existing legacy mechanisms which are widely
  used for remote user authentication should be
  supported
• To this end, the authentication in phase I can be
  extended using EAP protocol

32
IKEv2 phase I with extended authentication
Responder
Initiator
HDR, SAi1, KEi, Ni
HDR, SAr1, KEr, Nr, CERTREQ
HDR, IDi, CERT, CERTREQ, IDr, AUTH,
SAi2, TSi, TSr
HDR, IDr, CERT, AUTH, EAP

HDR, EAP, AUTH
HDR, EAP, AUTH, SAr2, TSi, TSr
33
Remote User Authentication

• By dropping the AUTH payload in the message 3,
  the initiator indicates the desire to use
  extended authentication
• The responder place an EAP payload in the message
  4 and
• After a few more messages exchanged, the
  initiator get authenticated.

34
Remote host configuration

• Again, in the scenario 3 where a remote host
  connects to its home network, remote host
  configuration may be needed.
• The remote host may needs the dynamic assignment
  of IP address and other network parameters used
  in the home subnetwork
• For this purpose, the IKEv2 phase I can be
  adapted to convey these information.

35
IKEv2 phase Iwith remote host configuration
Responder
Initiator
HDR, SAi1, KEi, Ni
HDR, SAr1, KEr, Nr, CERTREQ
HDR, IDi, CERT, CERTREQ, IDr, AUTH,
CP(CFG_REQUEST), SAi2, TSi, TSr
HDR, IDr, CERT, AUTH, CP(CFG_REPLY), SAr2,
TSi, TSr

• The configuration payloads (CP) are used for this
  purpose
• The CP payloads must be inserted just before SA
  payload

36
IKEv2 phase IICreate Child-SA Exchange
Responder
Initiator
HDR, N, SA, Ni, KEi, TSi, TSr
HDR, SA, Nr, KEr, TSi, TSr

• Under the protection of the IKE SA, this exchange
  creates an IPSEC SA
• An SA is proposed and agreed.
• DH values may be exchanged for the perfect
  forward secrecy
• This exchange is also used in rekeying an
  existing IPSEC SA and IKE SA (In this case, TS is
  not used)

37
IKEv2 phase IIInformational Exchange
Responder
Initiator
HDR, N, D, CP,
HDR, N, D, CP,

• Used for Controlling SAs
• SA delete(D)/ SA rekeying(create and delete),
  dead peer detection, error reporting(N), liveness
  check(HDR only)

38
NAT Traversal

• There may be a NAT device between two IPSEC
  endpoints (scenario 1,3)
• IKEv2 was designed to work friendly with NAT
  devices.
• Support of NAT-T is optional.

39
NAT Traversal

• IKEv2 Operation for NAT-T
• During the first round exchange of IKEv2 phase I,
  NAT devices are discovered.
• By Checking if the outer address of the packet
  matches Notify payload within the IKE messages.
• Notify payload, NAT-DETECTION-SOURCE(DESTINATION)-
  IP, contains the hash of the original IP address.
• No match means the existence of a NAT
• If NAT is discovered, all future IKE, ESP and AH
  packets must be tunneled over UDP port 4500
• By using UDP header encapsulation

40
Outlooks

• IKEv2 is expected to appear as a proposed
  standard, soon
• IPSEC WG level work has been done last month.
• The document was handed over for IETF wide last
  call
• IKEv2 will enhance the interoperability of the
  IPSEC VPN products
• IKEv2 will promote the wide use of the IPSEC in
  the new field (SAN, Mobile IP)

41
Thank You !Please contact at ksl_at_dongeui.ac.kr
orvisit www.ietf.orf/html.charters/ipsec-charter.
html for further information.