Tài liệu Internet Key Exchange Protocol pdf

Internet Key Exchange
Protocol
Overview
This module introduces the IKE (Internet Key Exchange) protocol in detail and
provides an in-depth description of key management in IPsec VPNs. Detailed
protocol characteristics are discussed, as well as different protection mechanisms
and peer authentication schemes. Peer authentication schemes protect the key
management system, and are vital to the proper operation of a secure and
interoperable VPN. In order to build scalable IPsec VPNs, scalable key
management is needed. This module provides the student with a strong knowledge
of IKE, the key management and policy agreement protocol used in IPsec VPNs.
Objectives
Upon completing this module, you will be able to:
n Identify the main purposes of the IKE protocol
n Explains how IKE interacts with IPsec
2 Acces VPN v1.0 Copyright  2001, Cisco Systems, Inc.
IKE Technology Introduction
Objectives
Upon completing this lesson, you will be able to:
n Describe how IKE provides key management for IPsec
n Describe two main functions of IKE—key management and policy negotiation
n Describe how IKE interacts with IPsec and its security associations (SAs)
Copyright  2001, Cisco Systems, Inc. Internet Key Exchange Protocol 3
© 2001, Cisco Systems, Inc. Access VPN v1. 0—Internet Key Exchange Protocol -5
Internet Key Exchange (IKE)
Internet Key Exchange (IKE)
• Internet Key Exchange (RFC 2409)
• The protocol used for key management in
IPsec networks
• Allows for automatic negotiation and

creation of IPsec SAs between IPsec peers


The Internet Key Exchange (IKE) protocol, described in RFC 2409, is a key
management protocol standard which is used in conjunction with the IPsec
standard. IPsec can be configured without IKE, but IKE enhances IPsec by
providing additional features, flexibility, and ease of configuration for the IPsec
standard.
As mentioned in the T_IPsec chapter, IPsec security associations (SAs) must exist
in order for IPsec to protect network traffic. IKE manages those SAs on behalf of
IPsec, and automatically negotiates protection policies between IPsec peers.

4 Acces VPN v1.0 Copyright  2001, Cisco Systems, Inc.
© 2001, Cisco Systems, Inc. Access VPN v1. 0—Internet Key Exchange Protocol -6
IKE History
IKE History
IKE is a hybrid protocol based on:
• ISAKMP (RFC 2408), the protocol for
negotiated establishment of security
associations
• Oakley (RFC 2412), a key
agreement/exchange protocol
• SKEME, another key-exchange protocol


IKE is a hybrid protocol based on the Internet Security Association and Key
Management Protocol (ISAKMP), described in RFC 2408. The IKE protocol
implements parts of two other key management protocols–-Oakley, described in
RFC 2412, and SKEME. The protection policy within SAs is negotiated and
established with the help of the ISAKMP protocol, and keying material (session

keys for encryption and packet authentication) is agreed on and exchanged with
the use of Oakley and SKEME protocols.
ISAKMP—The Internet Security Association and Key Management Protocol is a
protocol framework that defines payload formats, the mechanics of implementing a
key exchange protocol, and the negotiation of a security association. ISAKMP is
implemented according the latest version of the "Internet Security Association and
Key Management Protocol (ISAKMP)" standard
Oakley—A key exchange protocol that defines how to derive authenticated
keying material.
Skeme—A key exchange protocol that defines how to derive authenticated keying
material, with rapid key refreshment.

Copyright  2001, Cisco Systems, Inc. Internet Key Exchange Protocol 5
© 2001, Cisco Systems, Inc. Access VPN v1. 0—Internet Key Exchange Protocol -7
ISAKMP
ISAKMP
• Internet Security Association and Key
Management Protocol
• Establishes a secure management session
between IPsec peers
• Negotiates SAs between IPsec peers


The Internet Security Association and Key Management Protocol (ISAKMP)
establishes a secure management session between IPsec peers, which is used to
negotiate IPsec SAs. ISAKMP provides the means to do the following:
n Authenticate the remote peer
n Cryptographically protect the management session
n Exchange information for key exchange
n Negotiate all traffic protection parameters using configured security policies

Therefore, the goal of ISAKMP is the establishment of an independent security
channel between authenticated peers in order to enable a secure key exchange and
the negotiation of IPsec SAs between then.

6 Acces VPN v1.0 Copyright  2001, Cisco Systems, Inc.
© 2001, Cisco Systems, Inc. Access VPN v1. 0—Internet Key Exchange Protocol -8
Oakley
Oakley
• Defines the mechanisms for key exchange
over the IKE session
• Determines AH/ESP keying material for each
IPsec SA automatically
• By default uses an authenticated Diffie-
Hellman algorithm for key exchange


Oakley is originally a free-form protocol that allows each party to proceed with the
exchange at its own speed. IKE borrowed this idea from Oakley, and defines the
mechanisms for key exchange in different modes over the IKE (ISAKMP)
session. Each protocol produces a similar result—an authenticated key exchange,
yielding trusted keying material used for IPsec SAs. Oakley, within IKE,
determines AH and ESP keying material (authentication and encryption session
keys) for each IPsec SA automatically, and by default uses an authenticated
Diffie-Hellman algorithm to accomplish this.

Copyright  2001, Cisco Systems, Inc. Internet Key Exchange Protocol 7
© 2001, Cisco Systems, Inc. Access VPN v1. 0—Internet Key Exchange Protocol -9
Diffie-Hellman Algorithm
Diffie-Hellman Algorithm
• Algorithm for secure key exchange over

insecure channels
• Based on the difficulty of finding discrete
logarithms
• Used to establish a shared secret between
parties (usually the secret keys for
symmetric encryption or HMACs)


Diffie-Hellman algorithm was discovered in 1976 by Whitfield Diffie and Martin
Hellman. It gets its security from the difficulty of calculating the discrete
logarithms of very large numbers. The Diffie-Hellman algorithm is used for secure
key exchange over insecure channels and is used a lot in modern key management
to provide keying material for other symmetric algorithms, such as DES or keyed-
MD5 (HMAC).

8 Acces VPN v1.0 Copyright  2001, Cisco Systems, Inc.
© 2001, Cisco Systems, Inc. Access VPN v1.0—Internet Key Exchange Protocol-10
Diffie-Hellman Algorithm (cont.)
Diffie-Hellman Algorithm (cont.)
• The parties agree on two non-secret
numbers, g (generator), and p (modulus)
–g is small (e.g. 2), p is very large
• Each party generates a random secret X
• Based on g, p, and the secret, each party
generates a public value
–Y = g
X
mod p
• Peers exchange public values

In order to start a Diffie-Hellman exchange the two parties must agree on two
non-secret numbers. The first is g (generator) and the second is p (modulus).
Those numbers can be made public and are usually chosen from a table of known
values. The generator is usually a very small number (for example, 2, 3,…), and p
is a very large prime number. Every party then generates its own secret value.
Then, based on g, p and the secret value of each party, each party calculates its
public value. The public value is computed according to the following formula:
Y=g
x
mod p
where x is the entity’s secret value, and Y is the entity’s public value. After that,
the two parties exchange their public values. Each party then exponentiates the
received public value to its secret value to compute a common shared secret.
When the algorithm completes, both parties have the same shared secret which
they have computed from their secret value and the public value of the other party.
No one listening on the channel can compute that value, as they only know g, p, Y
A

and Y
B
, and at least one secret value is needed to calculate that shared secret.
Unless the attacker can compute the discrete algorithm of the above equation to
recover x
A
or x
B
, they cannot obtain the shared secret.

Copyright  2001, Cisco Systems, Inc. Internet Key Exchange Protocol 9

© 2001, Cisco Systems, Inc. Access VPN v1.0—Internet Key Exchange Protocol-11
Diffie-Hellman in Action
Diffie-Hellman in Action
Private Value, X
A
Public Value, Y
A
Private Value, X
B
Public Value, Y
B
(shared secret)
Alice Bob
Y
B
mod p = g mod p = Y
A
mod p
X
B
X
A
X
B
Y
A
Y
B
Y
B

= g mod p
X
B
Y
A
=g mod p
X
A
X
A


To follow through the algorithm in steps, here is a sequential description of the
calculations involved in a Diffie-Hellman exchange:
Alice and Bob agree on generator g and modulus p.
Alice chooses a random large integer x(A) and sends Bob its public value, Y
A.

Y
A
=g
x(A)
mod p
Bob chooses a random large integer x(B) and sends Alice his public value, Y
B

Y
B
=g
x(B)

mod p
Alice computes:
k=Y
B
x(A)
mod p
Bob computes:
k’=Y
A
x(B)
mod p
Both k and k’ are the equal to:
g
x(A)x(B)
mod p
Alice and Bob now have a shared secret (k=k’) and even if someone has listened
on the untrusted channel, there is no way they could compute the secret from the
captured information (assuming that computing a discrete logarithm of Y
A
or Y
B
is
practically unfeasible, which is currently the case).

10 Acces VPN v1.0 Copyright  2001, Cisco Systems, Inc.
© 2001, Cisco Systems, Inc. Access VPN v1.0—Internet Key Exchange Protocol-12
IPsec and IKE Relationship
IPsec and IKE Relationship
• IPsec needs SAs to protect traffic
• If no SAs are in place, IPsec will ask IKE to

provide IPsec SAs
• IKE opens a management session with the
relevant peer, and negotiates all SAs and
keying material for IPsec
• IPsec starts protecting traffic


To properly protect network traffic, the IPsec process needs established security
associations (SAs). If no SAs are present for a certain destination peer, IPsec will
ask IKE to negotiate and create IPsec SAs on its behalf.
In order to negotiate and create IPsec SAs, the two IKE processes on both peers
must first establish a secure IKE key-management session over which they will
negotiate and instantiate IPsec protection policy.Because IKE negotiations must be
protected, each IKE negotiation begins by each peer agreeing on a common
(shared) IKE protection policy. This IKE protection policy states which security
parameters will be used to protect subsequent IKE negotiations.
After the two peers agree upon an IKE protection policy, the security parameters
of the policy are identified by an IKE security association (IKE SA) established at
each peer. These IKE security associations apply to all subsequent IKE traffic
during the negotiation.
In this protected session, IPsec SAs are then negotiated and established.. With a
traffic protection (IPsec SAs) policy established and proper keying material
exchanged using the Diffie-Hellman method, IPsec can start to protect the
network traffic. After the IPsec SAs’ lifetime expires, IKE is invoked again, and
fresh IPsec SAs are created.
It is important to differentiate between the two kinds of protection policies used in
IKE/IPsec networks:
n The IKE protection policy resulting in IKE SAs, defines the protection of the
IKE key management session only.
The IPsec protection policy resulting in IPsec SAs, defines the protection of

network traffic. These IPsec SAs are usually negotiated over IKE sessions.