Internet Security Protocols Ch11. Internet Key Exchange(IKE) by xkv18799


									Internet Security Protocols
 Ch11. Internet Key Exchange(IKE)

                                                               11. IKE

                         IKE Basics
• 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

• 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]
                                                        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
• 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 |
• HASH_R = prf(SKEYID, g^xr | g^xi | CKY-R | CKY-I | Sai_b |
                                                        11. IKE

This section of the chapter provides examples of IKE message
• Phase one: authenticated with signatures
• Phase one: authenticated with public key encryption
• Phase one: authenticated with a revised mode of public key
• Phase one: authenticated with a pre-shared key
• Phase two: quick mode
• New group mode
                                                       11. IKE
                Phase One: Authenticated with

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
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
• 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
• 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
• 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
• 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
                                                       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
                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.

To top