Internet Security Protocols Ch11. Internet Key Exchange(IKE) CNET 최원창 11. IKE IKE Basics IKE • Phase one : Establishes the IKE security association • Phase one : Uses the IKE security association to then negotiate an SA for IPSec, or another protocol The full IKE exchanges are as follows • Phase-one exchange main mode aggressive mode • Phase-two exchange quick mode • Informational exchange • New group exchange 11. IKE Definitions • HDR • CERT • SA • HASH • <P>_b • prf(key, msg) • SAi_b • SKEYID • CKY-I • SKEYID_e • g^xi and g^xr • SKEYID_a • g^xy • SKEYID_d • KE • <x>y • Nx •| • IDx • [x] • SIG 11. IKE Perfect Forward Secrecy • PFS of both keying material and identities is provided by IKE. • The identities are protected by SKEYID_e from the ISAKMP SA and therefore are not protected by PFS. 11. IKE Aspects of IKE & ISAKMP • The following attributes are used by IKE and are negotiated as part of ISAKMP security association : (a) encryption algorithm (b) hash algorithm (c) authentication method (d) information about a Diffie-Hellman group 11. IKE Modes to Establish Authenticated Key Exchange • IKE defines two phase-one methods to establish an authenticated key exchange: main mode and aggressive mode. • The phase-two quick mode is implemented as a mechanism to generate fresh keying material and negotiate non-ISAKMP security services. • Main mode and aggressive mode are both phase-one exchanges and are used to setup the IKE security association. 11. IKE Main Mode Main mode is an instantiation of the ISAKMP identity protect exchange and consists of the exchange of six messages. • The first two exchange messages negotiate policy. • The next two exchange messages Diffie-Helloman public value and ancillary data (e.g., nonces) necessary for the exchange. • The last two exchange messages authenticate the Diffie- Hellman exchange. 11. IKE Aggressive Mode Aggressive mode is an instantiation of the ISAKMP aggressive exchange and consists of the exchange of three messages. • The first two messages negotiate policy, exchange Diffie- Helloman public values and ancillary data necessary for the exchange. • The second message authenticates the responder. • The third message authenticates the initiator and provides a proof of participation in the exchange. 11. IKE Quick Mode and New Group Mode • Quick mode and new group mode have no corollary in ISAKMP. • Main mode, aggressive mode, and quick mode perform security association negotiation. • Security association offers take the form of transform paylode(s) encapsulated in proposal payload(s) encapsulated in SA paylode(s). 11. IKE Four Methods Used with Main or Aggressive Mode Four different authentication methods are used with main mode or aggressive mode. (a) a Digital Signature (b and c) two forms of authentication with public key encryption (d) a pre-shared key The value SKEYID is computed separately for each authentication method, and is therefore dependent upon each method. • For signatures: SKEYID = prf(Ni_b | Nr_b, g^xy) • For public key encryption: SKEYID = prf(hash(Ni_b | Nr_b), CKY- I | CKY-R) • For pre-shared keys: SKEYID = prf(pre-shared-key, Ni_b | Nr_b) 11. IKE Four Methods Used with Main or Aggressive Mode The result of either main mode or aggressive mode is three groups of authenticated keying material. • SKEYID_d = prf(SKEYID, g^xy | CKY-I | CKY-R | 0) • SKEYID_a = prf(SKEYID, SKEYID_d | g^xy | CKY-I | CKY-R | 1) • SKEYID_e = prf(SKEYID, SKEYID_a | g^xy | CKY-I | CKY-R | 2) The hashes for this operation are computed as follows. • HASH_I = prf(SKEYID, g^xi | g^xr | CKY-I | CKY-R | Sai_b | IDii_b) • HASH_R = prf(SKEYID, g^xr | g^xi | CKY-R | CKY-I | Sai_b | IDir_b) 11. IKE EXAMPLES OF IKE MESSAGE EXCHANGES This section of the chapter provides examples of IKE message exchanges. • Phase one: authenticated with signatures • Phase one: authenticated with public key encryption • Phase one: authenticated with a revised mode of public key encryption • Phase one: authenticated with a pre-shared key • Phase two: quick mode • New group mode 11. IKE Phase One: Authenticated with Signatures Figure 11-1 • In event 1 and 2, the two peers negotiate the IKE SA and decide on the other parts of the exchange. • In event 2 and 4, the peers exchange Diffie-Hellman keys (KE, which was set up in event 1 and 2), and pseudo-random nonces (Ni and Nr). • In event 5 and 6, the encryption (by SKEYID_e) authenticating information is exchanged. 11. IKE Phase One: Authenticated with Signatures Figure 11-2 • Aggressive mode with signatures in conjunction with ISAKMP is shown. • Notice that half the number of messages are exchanged as main mode. • The trade off is that in the aggressive mode there is limitation on negotiation since the initiator must provide the Diffie-Hellman value the nonce in first message. • The initiator cannot offer different Diffie-Hellman groups in different protection suites. • However, aggressive mode may be the only way to establish the IKE SA. • In both modes, the signed data, SIG_I or SIG_R, is the result of the negotiated Digital Signature algorithm applied to HASH_I or HASH_R, respectively. 11. IKE Phase One: Authenticated with Public Key Encryption • Using public key encryption to authenticate the exchange, the ancillary information exchanged between the peers is encrypted nonces. • This operation requires that the initiator of the exchange must have the responder’s public key. • Figure 11-3 and 11-4 show main mode and aggressive mode respectively for phase one: authenticated with public key encription. • In event 2 and 3, the identification payloads (IDii and IDir) and the nonces (Ni_b and Nr_b) are encripted with each peer’s public keys. 11. IKE Phase One: Authenticated with a Revised Mode of Public Key Encryption • Authentication with public key encryption has advantages over authentication with signatures, but the operation entails four public key operations, two for encryption and two for decryption. • Figure 11-5 shows this operation for main mode (aggressive mode is not shown, and is available in RFC 2409). 11. IKE Phase One: Authenticated with Pre-Shared Key • When using pre-shared key authentication with main mode the key can only be identified by the IP address of the peers since HASH_I must be computed before the initiator has processed IDir. 11. IKE Phase two: Quick Mode • Quick mode is not a complete exchange itself. • The Quick mode messages are authenticated with the prf (key, msg) function. • The information exchanged along with quick mode is protected by the ISAKMP SA-i.e., all payloads except the ISAKMP header are encrypted. • In quick mode, a HASH payload immediately follows the ISAKMP header and an SA payload must immediately follow the HASH. 11. IKE NEW group mode • New group mode is not to be uses prior to establishment of an ISAKMP SA. • Figure 11-6 shows the exchange for this mode. • The hashes are for the above exchange are: • HASH(1) = prf(SKEYID_a, M-ID | SA) • HASH(2) = prf(SKEYID_a, M-ID | SA) 11. IKE ISAKMP information Exchanges • This protocol protects ISAKMP Informational Exchanges when possible. 11. IKE OAKLEY GROUPS • With IKE, the group in which to do the Diffie-Hellman exchange is negotiated. • These groups originated with the OAKLEY protocol and therefore called “OAKLEY Group”. 11. IKE MESSAGES FOR A COMPLETE IKE EXCHANGE • This section shows the messages exchanges to establish a secure channel between ISAKMP processes and generate key material, and then negotiate an IPSec SA. • Figure 11-7 shows the payload exchanged between the two parties during the first round trip exchange, using main mode. • The second exchange consists of payloads in Figure 11-8(a) and (b). 11. IKE Phase Two Using Quick Mode • The payloads in Figures 11-9(a) and (b) are exchanged in the first round of quick mode with ISAKMP SA negotiation. • The contents of the hash are described in Figure 11-9(a). • As a check against replay attacks, the responder waits until receipt of the message shown in Figure 11-9(b). 11. IKE IPSEC, NAT, AND IKE • Figure 11-10 shown IKE operation with the IPC-NAT gateway. • When the negotiation is complete and successful, IKE will communicate the negotiated security parameters directly to the IPC-NAT gateway engine as described in Figure 11-10. • Operation of an IPC-NAT device may be distinguished from that of an IPSec gateway that does not support NAT as follow. • IPC-NAT device has security policies administered using private realm addressing. • Element fundamental to the security model of an IPC-NAT device includes IPC-NAT address mapping in conjunction with security policies and SA attributes. • However, a NAT device capable of providing security across IPSec tunnels can continue to support Normal-NAT for packets that do not require IPC-NAT.
Pages to are hidden for
"Internet Security Protocols Ch11. Internet Key Exchange(IKE)"Please download to view full document