1 internet key exchange rocky k. c. chang 20 march 2007

1

Internet Key Exchange

Rocky K. C. Chang20 March 2007

Rocky, K. C. Chang 2

Outline An overview of IKEv1 IKE phase 1

Main mode and aggressive mode 4 different authentication methods

IKE phase 2 Setting up IPSec SAs The quick mode

The current state of IKE


IKE Internet Key Exchange (IKE) protocol is the

default method for IPSec. IKE is an application-layer protocol using the

well-known UDP port 500. IKE is a general key exchange protocol.

IKE can be thought of as a combination of the packet formats of ISAKMP and the exchanges of OAKLEY. Also influenced by SKEME and Photuris.


IKE and ISAKMP Internet Security Association and Key

Management Protocol (ISAKMP), which defines the procedures for authenticating a communicating

peer, creation and management of Security Associations, key generation techniques, and threat mitigation (e.g. denial of service and replay

attacks) ISAKMP does not define how a particular key

exchange is done, and the attributes necessary for establishing security associations.


ISAKMP relationships +------------+ +--------+ +--------------+ ! DOI ! ! ! ! Application ! ! Definition ! <----> ! ISAKMP ! ! Process ! +------------+ --> ! ! !--------------!+--------------+ ! +--------+ ! Appl Protocol!! Key Exchange ! ! ^ ^ +--------------+! Definition !<-- ! ! ^+--------------+ ! ! ! ! ! ! !----------------! ! ! v ! ! +-------+ v v ! API ! +---------------------------------------------+ +-------+ ! Socket Layer ! ! !---------------------------------------------! v ! Transport Protocol (TCP / UDP) ! +----------+ !---------------------------------------------! ! Security ! <----> ! IP ! ! Protocol ! !---------------------------------------------! +----------+ ! Link Layer Protocol ! +---------------------------------------------+


DOI and OAKLEY An IPSec DOI is also needed to define an

IPSec-specific interpretation of certain parts of ISAKMP headers and payloads.

OAKLEY is a key management framework that describes a family of canonical key negotiation sequences, and the security properties of each.

IKE (RFC 2409)+ ISAKMP (RFC 2408) + DOI (RFC 2407)


A 2-phase IKE IKE consists of two phases.

IKE phase 1 creates an ISAKMP SA that is a secure channel (encryption and integrity check) for phase 2 negotiation.

Unlike IPSec SAs, an ISAKMP SA is bi-directional. IKE phase 1 offers two modes---main and aggressive,

and 4 authentication methods. IKE phase 2 is used to establish IPSec SAs, for

example.


Why 2 phases? Q: Why not use a single phase to establish

IPSec SAs? A1: Set up a single ISAKMP SA from which

multiple IPSec SAs and nonIPSec SAs can be established.

A2: Set up IPSec SAs for different flows. A3: It is more efficient for rekeying (or key

rollover)

9

IKE Phase 1: The Main Mode


The main mode The main mode uses three pairs of messages

(three RTTs) to establish an ISAKMP SA. 1st pair: ISAKMP SA negotiation (including an exchange

of cookies) Encryption algorithms, hash algorithms, authentication

methods, and D-H group (protection suite) 2nd pair: a D-H exchange and an exchange of nonces

Derive the necessary keys for this ISAKMP SA and for the authentication of the peer in the 3rd pair of the messages.

3rd pair: Peer authentication Four authentication methods available.


A 6-message exchange Initiator Responder----------- -----------(I) IKE option negotiation

(1) -------------------------> (2) <-------------------------

(II) D-H key exchange and derivation of keys

(3) -------------------------> (4) <-------------------------

(III) Peer authentication

(5) -------------------------> (6) <-------------------------


ISAKMP header and payloads ISAKMP header:

1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+! Initiator !! Cookie !+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+! Responder !! Cookie !+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+! Next Payload ! MjVer ! MnVer ! Exchange Type ! Flags !+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+! Message ID !+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+! Length !+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


ISAKMP header and payloads

Cookies generated by I and R. Next Payload indicates the type of the payload

after the header. Different (13 at this point) payloads are

chained together using the Next Payload field. All payloads begin with a generic header:

1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+! Next Payload ! RESERVED ! Payload Length !+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


(1) ISAKMP SA negotiation Negotiate (through the ISAKMP SA payloads)

Encryption algorithm: used for data encryption, e.g., in the peer authentication in the main mode.

Hash algorithm (PRF): used for deriving secret keys in the D-H key exchange and for authentication, e.g., HMAC-MD5.

Authentication method: select one out of four methods for peer authentication, e.g.,

Symmetric-key encryption, digital signatures, and 2 public-key encryptions.

D-H group: select a group out of five, e.g., OAKLEY group 1: Use exponentiation over a prime modulus with

p = 2768 - 2704 - 1 + 264 * { [2638 + 149686 } and g = 2 I proposes parameters for the SA, and R replies by saying

which ones are accepted.


(1) ISAKMP SA negotiation Exchange of cookies

How to generate the cookies (not specified in ISAKMP)? After the cookie exchange, the concatenation of the two

cookies identifies the SA. SAI is the entire SA payload with all protection suites offered by

I to R and SAR is the entire SA that indicates the protection suite

accepted by R.

Initiator Responder----------- ----------- (1) CI,SAI1. Generate CI -------------------------> (2) CI,CR,SAR <------------------------- 2. Generate CR


0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+~ ISAKMP Header with XCHG of Main Mode, ~~ and Next Payload of ISA_SA ~+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+! 0 ! RESERVED ! Payload Length !+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+! Domain of Interpretation !+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+! Situation !+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+! 0 ! RESERVED ! Payload Length !+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+! Proposal #1 ! PROTO_ISAKMP ! SPI size = 0 | # Transforms !+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+! ISA_TRANS ! RESERVED ! Payload Length !+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+! Transform #1 ! KEY_OAKLEY | RESERVED2 !+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+~ prefered SA attributes ~+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+! 0 ! RESERVED ! Payload Length !+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+! Transform #2 ! KEY_OAKLEY | RESERVED2 !+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+~ alternate SA attributes ~+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


Stateless cookies in IKE A cookie exchange guards against simple

flooding attacks sent with bogus IP sources addresses or UDP ports.

I generates a cookie (of length between 64 and 128 bits) CI, and sends it to R.

R then generates a cookie CR, and sends it with CI to I.

To launch a flooding attack, the attacker has to complete a cookie exchange with the victim for each

spoofed source IP address (read the cookie sent by the victim for each cookie exchange.)


Requirements for cookie generation The cookie must depend on the specific parties.

This prevents an attacker from obtaining a cookie using a real IP address and UDP port, and

then using it to swamp the victim with requests from randomly chosen IP addresses or ports.

It must not be possible for anyone other than the issuing entity to generate cookies that will be accepted by that entity. This implies that the issuing entity will use local secret

information in the generation and subsequent verification of a cookie.

It must not be possible to deduce this secret information from any particular cookie.


Requirements for cookie generation The cookie generation and verification methods

must be fast to thwart attacks intended to sabotage CPU resources.

A recommended technique is to use a hashing function, such as MD5. An incoming cookie can be verified by regenerating it

locally from values contained in the incoming datagram and the local secret random value.

For example, cookie = h(secret, source and destination IP addresses, source and destination UDP port numbers)


Initiator and responder cookies The Initiator secret value should be different for each

cookie exchange and the secret value is cached. An alternative, of course, is to cache the cookie itself instead

of the secret value. It is recommended that the cookie be computed over the

secret, source and destination IP addresses, and source and destination UDP port numbers.

The responder secret value may be the same for many different initiators. This secret value should be changed periodically. It is recommended that the cookie be computed over the

secret, the Initiator cookie, source and destination IP addresses, and UDP port numbers.


(2) The D-H exchange A secret key, k, will be generated between the

peers using the D-H key exchange. Additionally, four secret keys will be generated

between the peers: SKEYID: a string derived from secret material known

only to the peers. It is derived differently for each authentication algorithm (why?).

SKEYIDd: the keying material used to derive keys for non-ISAKMP security associations.

SKEYIDa: the keying material used by the ISAKMP SA to authenticate its messages.

SKEYIDe: the keying material used by the ISAKMP SA to protect the confidentiality of its messages.


(2) D-H exchange SKEYIDx, x = d, a, e, are derived from SKEYID and k:

SKEYIDd = PRF(SKEYID, k | CI | CR | 0) SKEYIDa = PRF(SKEYID, SKEYIDd | k | CI | CR | 1) SKEYIDe = PRF(SKEYID, SKEYIDa | k | CI | CR | 2), where PRF is the keyed pseudo-random function (often a keyed hash

function) agreed between the peers in the ISAKMP SA negotiation stage.

The principle of key separation Different cryptographic functions should use different and

cryptographically independent keys, e.g., not to use k for both encryption and authentication.

Instead, use k as a seed from which other keys are derived.


(2) D-H exchange and (3) peer authentication

Derivation of SKEYID, message contents in the D-H exchange, and peer authentication depend on the authentication method chosen.

Four authentication methods available: pre-shared keys digital signatures public key encryption with four encryption public key encryption with two encryption


Why 4 authentication methods? The pre-shared key method is simple to configure

and fast. Why 2 public-key encryption methods?

The original public-key encryption method is not efficient.

Why public-key encryption and signature? The public-key encryption method may be unusable,

because I is required to know R’s public key. Using the signature method, one has to reveal its

identity to the other first.


Pre-shared key authentication PSKEY: pre-shared key A nonce is a large pseudo-random number, 64-2048 bits in

length, adds randomness to the key negotiation process. SKEYID = PRF(PSKEY, NI | NR) ID is a unique identification of I and R, e.g. IP address,

domain name, email address, etc. Authentication:

HASHI = PRF(SKEYID, X | Y | CI | CR | SAI | IDI) HASHR = PRF(SKEYID, Y | X | CR | CI | SAI | IDR)

Messages (5) and (6) are encrypted with SKEYIDe (the ISAKMP headers are not encrypted).


Pre-shared key authentication

Initiator Responder ----------- ----------- 3. Choose (g,p) Generate x (3) CI,CR X,[g,p],NI

X = gx mod p -------------------------> 4. Validate cookie Generate y

Y = gy mod p (4) CI,CR Y,NR <------------------------- 5. Validate cookie k = Yx mod p (5*) CI,CR, IDI, HASHI -------------------------> 6. Validate cookie Validate IDI k = Xy mod p (6*) CI,CR, IDR, HASHR <------------------------- 7. Validate cookie Validate IDR


Disadv. of pre-shared key authen. When R receives message (5), he cannot view IDI

due to the encrypted ISAKMP payloads. Therefore, R could not retrieve the shared key

corresponding to IDI. As a result, IDI in this case must be based on the IP

header information (the source IP address). If I is allocated with a different IP address due to DHCP,

NAT, Mobile IP, etc, R would not be able to retrieve the correct shared key.


Public-key signature authentication In the messages (3) and (4), each peer can optionally

request a digital certificate from another side. SKEYID = PRF(NI | NR, k) HASHI and HASHR are the same as before. Each side signs its HASH value:

SIGI = PRVKEYI(HASHI) SIGR = PRVKEYR(HASHR)

The other side could verify the digital signature based on the other side’s public key obtained from the certificate.

Messages (5) and (6) are encrypted with SKEYIDe (the ISAKMP headers are not encrypted).


Public-key signature authentication

Initiator Responder ----------- ----------- 3. Choose (g,p) Generate x (3) CI,CR X,[g,p],NI,[Cert_Req]

X = gx mod p -------------------------> 4. Validate cookie Generate y

Y = gy mod p (4) CI,CR Y,NR,[Cert_Req] <------------------------- 5. Validate cookie k = Yx mod p (5*) CI,CR, IDI,[Cert],SIGI -------------------------> 6. Validate cookie Validate IDI k = Xy mod p (6*) CI,CR, IDR,[Cert],SIGR <------------------------- 7. Validate cookie Validate IDR

30

Phase 1: The Aggressive Mode


The aggressive mode Aggressive mode is an option defined for each

authentication method. Differences:

Reduce from 3 RTT to 1.5 RTT I cannot offer different D-H groups in different protection

suites. IDI and IDR are not encrypted; therefore there is no

identity protection. Unlike the pre-shared keys for the main mode,

aggressive mode allows PSKEY to be computed based on an IP address in the ID payload rather than the packet’s source IP address.


Pre-shared key authenticationInitiator Responder----------- -----------1. Generate CI Choose (g,p) Generate x X = gx mod p (1) CI,SAI,X[g,p],NI,IDI -------------------------> 2. Generate CR Generate y Y = gy mod p (2) CI,CR,SAR,Y,NR,IDR,HASHR <-------------------------

3. Validate cookieValidate IDR

k = Yx mod p (3) CI,CR HASHI

-------------------------> 4. Validate cookie Validate IDI

k = Xy mod p


Public-key signature authentication

Initiator Responder ----------- ----------- 1. Generate CI Choose (g,p) Generate x X = gx mod p (1) CI,SAI,X[g,p],NI,IDI -------------------------> 2. Generate CR Generate y Y = gy mod p (2) CI,CR,SAR,Y,NR,IDR,[Cert],SIGR <------------------------- 3. Validate cookie

Validate IDR k = Yx mod p (3) CI,CR,[Cert],SIGI

-------------------------> 4. Validate cookie Validate IDI

k = Xy mod p

34

IKE Phase 2


IKE phase 2 This second phase can be used to

negotiate for a nonISAKMP SA (quick mode), derive new keying material (new group mode), and send an unacknowledged notification message.

All phase 2 packets are protected by the ISAKMP SA established in phase 1. All payloads except for the ISAKMP header are

encrypted. A HASH payload must immediately follow the ISAKMP

header. An SA payload must immediately follow the HASH.


Setting up an IPSec SA A single SA negotiation results in two IPSec SAs:

one inbound and one outbound. I sends a set of proposals in SAI to R, and R

accepts one proposal in SAR. The values for protocol and SPI are specified in the

ISAKMP proposal payloads (SAI and SAR). protocol: PROTO_IPSEC_AH, PROTO_IPSEC_ESP (from

DOI) Each side chooses an SPI, and the IPSec SA’s SPI is

specified by the source’s SPI. The keying material of the IPSec SA is partly determined

from the destination’s SPI.


The first message in quick mode

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ISAKMP Header with XCHG of Quick Mode, ~ ~ Next Payload of ISA_HASH and the encryption bit set ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! ISA_SA ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ keyed hash of message ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! ISA_NONCE ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Domain Of Interpretation ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Situation ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! 0 ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Proposal #1 ! PROTO_IPSEC_AH! SPI size = 4 | # Transforms ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ SPI (4 octets) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! ISA_TRANS ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Transform #1 ! AH_SHA | RESERVED2 ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! other SA attributes ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! 0 ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Transform #2 ! AH_MD5 | RESERVED2 ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! other SA attributes ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! ISA_ID ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ nonce ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


Perfect forward secrecy If PFS is required, the peers could derive a new

private key using D-H exchange in the quick mode. When PFS is in effect, if a key used as part of a session is

compromised, other keys used to protect later parts of the session are not compromised.

A system would not have PFS if there was a single secret which all symmetric keys were derived.

Multiple quick mode negotiations may take place simultaneously between two participants, which are distinguished by the message identifier, MID.


The quick mode Initiator Responder----------- -----------

1. [Choose (g,p) Generate x (1*)CI,CR,MID,HASH(1),SAI,NI[X[g,p]],[IDI,IDR]

X = gx mod p] --------------------------------->Compute HASH(1) 2. Validate HASH(1) [Generate y

Y = gy mod p] Compute HASH(2) (2*)CI,CR,MID,HASH(2),SAR,NR[Y],[IDI,IDR] <---------------------------------3. Validate HASH(2) [k = Yx mod p] Compute HASH(3)

(3*)CI,CR,MID,HASH(3) -------------------------> 4. Validate HASH(3) [k = Xy mod p]


Computing the hash values HASH(1):

Without PFS: HASH(1) = PRF(SKEYIDa, MID | SAI | NI) With PFS: HASH(1) = PRF(SKEYIDa, MID | SAI | NI | X | IDI | IDR)

HASH(2) Without PFS: HASH(2) = PRF(SKEYIDa, MID | SAR | NI | NR) With PFS: HASH(2) = PRF(SKEYIDa, MID | SAR | NI | NR | Y | IDI |

IDR) HASH(3)

HASH(3) = PRF(SKEYIDa, 0 | MID | NI | NR) What is the purpose of this message?


Computing keys for IPSec SAs If PFS is not used,

KEYMAT = PRF(SKEYIDd, protocol | SPI | NI | NR) (key refreshing)

If PFS is used, KEYMAT = PRF(SKEYIDd, k | protocol | SPI | NI |

NR)


The current state of IKE Besides the complexity and unreadability of the

RFC documents, a number of flaws have been identified.

A draft on IKEv2 To define the entire IKE protocol in a single document,

replacing RFCs 2407, 2408, and 2409 …. To simplify IKE by replacing the eight different initial

exchanges with a single four message exchange …. To decrease IKE's latency in the common case by

making the initial exchange be 2 round trips (4 messages) ….

To fix cryptographic weaknesses such as the problem with symmetries in hashes used for authentication ….

Obsoleted by RFC 4306 (December 2005)!


Summary Examined how the authenticated DH

protocol is implemented in a practical key exchange protocol. Hiding the identities of the end points Denial of service protection

IKEv1’s complexity, flaws, and the lack of security objectives

A better IKE protocol (version 2)


Acknowledgements These lecture notes are based on

M. S. Borella, “Methods and Protocols for Secure Key Negotiation Using IKE,” IEEE Network, pp. 18-29, July/Aug., 2000.

N. Doraswamy and D. Harkins, IPSec, Prentice Hall, 1999. D. Maughan, M. Schertler, M. Schneider, and J. Turner,

"Internet Security Association and Key Management Protocol (ISAKMP)," RFC2408, Nov. 1998.

D. Harkins and D. Carrel, "The Internet Key Exchange (IKE)." RFC2409, Nov. 1998.

D. Piper, "The Internet IP Security Domain of Interpretation for ISAKMP," RFC2407, Nov. 1998.

1 internet key exchange rocky k. c. chang 20 march 2007

Documents