4t Ike Bcamp
-
Upload
kuljit-kaur -
Category
Documents
-
view
229 -
download
0
Transcript of 4t Ike Bcamp
-
7/30/2019 4t Ike Bcamp
1/25
Internet Key ExchangeProtocol
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 keymanagement 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
-
7/30/2019 4t Ike Bcamp
2/25
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 IKEkey management and policy negotiation
n Describe how IKE interacts with IPsec and its security associations (SAs)
-
7/30/2019 4t Ike Bcamp
3/25
Copyright 2001, Cisco Systems, Inc. Internet Key Exchange Protocol 3
2001, Cisco Systems, Inc. Access VPNv 1.0Internet Key Exchange Protocol -5
Internet Key Exchange (IKE)Internet Key Exchange (IKE)
Internet Key Exchange (RFC 2409)
The protocol used for key management inIPsec networks
Allows for automatic negotiation andcreation 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.
-
7/30/2019 4t Ike Bcamp
4/25
4 Acces VPN v1.0 Copyright 2001, Cisco Systems, Inc.
2001, Cisco Systems, Inc. Access VPNv 1.0Internet Key Exchange Protocol -6
IKE HistoryIKE History
IKE is a hybrid protocol based on:
ISAKMP (RFC 2408), the protocol fornegotiated establishment of securityassociations
Oakley (RFC 2412), a keyagreement/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.
ISAKMPThe Internet Security Association and Key Management Protocol is aprotocol 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
OakleyA key exchange protocol that defines how to derive authenticated
keying material.
SkemeA key exchange protocol that defines how to derive authenticated keying
material, with rapid key refreshment.
-
7/30/2019 4t Ike Bcamp
5/25
Copyright 2001, Cisco Systems, Inc. Internet Key Exchange Protocol 5
2001, Cisco Systems, Inc. Access VPNv 1.0Internet Key Exchange Protocol -7
ISAKMPISAKMP
Internet Security Association and KeyManagement Protocol
Establishes a secure management sessionbetween 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.
-
7/30/2019 4t Ike Bcamp
6/25
6 Acces VPN v1.0 Copyright 2001, Cisco Systems, Inc.
2001, Cisco Systems, Inc. Access VPNv 1.0Internet Key Exchange Protocol -8
OakleyOakley
Defines the mechanisms for key exchangeover the IKE session
Determines AH/ESP keying material for eachIPsec 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 resultan 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.
-
7/30/2019 4t Ike Bcamp
7/25
Copyright 2001, Cisco Systems, Inc. Internet Key Exchange Protocol 7
2001, Cisco Systems, Inc. Access VPNv 1.0Internet Key Exchange Protocol -9
Diffie-Hellman AlgorithmDiffie-Hellman Algorithm
Algorithm for secure key exchange overinsecure channels
Based on the difficulty of finding discretelogarithms
Used to establish a shared secret betweenparties (usually the secret keys forsymmetric 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).
-
7/30/2019 4t Ike Bcamp
8/25
8 Acces VPN v1.0 Copyright 2001, Cisco Systems, Inc.
2001, Cisco Systems, Inc. Access VPN v1.0Internet Key Exchange Protocol-10
Diffie-Hellman Algorithm (cont.)Diffie-Hellman Algorithm (cont.)
The parties agree on two non-secretnumbers, 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 partygenerates a public value
Y = gXmod 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 isg(generator) and the second isp (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 ong,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=gx
mod p
wherex is the entitys secret value, and Yis the entitys 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 knowg,p, YA
and YB, 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
recoverxA orxB, they cannot obtain the shared secret.
-
7/30/2019 4t Ike Bcamp
9/25
Copyright 2001, Cisco Systems, Inc. Internet Key Exchange Protocol 9
2001, Cisco Systems, Inc. Access VPN v1.0Internet Key Exchange Protocol-11
Diffie-Hellman in ActionDiffie-Hellman in Action
Private Value, XAPublic Value,YA
Private Value, XBPublic Value,YB
(shared secret)
Al ice Bob
YB mod p = g mod p =YA mod pXBXA XB
YA
YB
YB = g mod pXBYA =g mod p
X
A
XA
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 generatorgand modulusp.
Alice chooses a random large integerx(A) and sends Bob its public value, YA.
YA=gx(A)
mod p
Bob chooses a random large integerx(B) and sends Alice his public value, YB
YB=gx(B)
mod p
Alice computes:
k=YBx(A)
mod p
Bob computes:
k=YAx(B)
mod p
Both kand kare the equal to:
gx(A)x(B)mod p
Alice and Bob now have a shared secret (k=k) and even if someone has listenedon the untrusted channel, there is no way they could compute the secret from the
captured information (assuming that computing a discrete logarithm ofYA or YB is
practically unfeasible, which is currently the case).
-
7/30/2019 4t Ike Bcamp
10/25
10 Acces VPN v1.0 Copyright 2001, Cisco Systems, Inc.
2001, Cisco Systems, Inc. Access VPN v1.0Internet Key Exchange Protocol-12
IPsec and IKE RelationshipIPsec and IKE Relationship
IPsec needs SAs to protect traffic
If no SAs are in place, IPsec will ask IKE toprovide IPsec SAs
IKE opens a management session with therelevant peer, and negotiates all SAs andkeying 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 securityparameters 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.
-
7/30/2019 4t Ike Bcamp
11/25
Copyright 2001, Cisco Systems, Inc. Internet Key Exchange Protocol 11
-
7/30/2019 4t Ike Bcamp
12/25
12 Acces VPN v1.0 Copyright 2001, Cisco Systems, Inc.
2001, Cisco Systems, Inc. Access VPN v1.0Internet Key Exchange Protocol-13
IPsec and IKE Relationship (cont.)IPsec and IKE Relationship (cont.)
IKE session
AlicesLaptop
BobsLaptop
1. Outbound packet fromAlice to Bob. No SA.
2. Alices IKE beginsnegotiation with Bobs.
3. Negotiation complete.Alice and Bob now havecomplete SAs in place.
IKE IKE
IPsec IPsecAlice Bob
4. Packet is sent from Alice toBob protected by IPsec SA.
Alice Bob
This figure shows the relationship between IPsec and IKE.
When a packet to a remote peer should be protected, and no SAs for that traffic
flow exist in the local SA database (SADB), IKE steps into action.
The sequence of events on the left IPsec peer is as follows:
n Alice wants to send a packet to Bob. Because no SAs are established for this
specification of traffic, IPsec asks IKE to provide IPsec SAs.
n Alices IKE process begins the negotiation with Bobs IKE process. This
negotiation includes the establishment of a secure IKE session, the
authentication of peers, and an exchange of keys for protection of this IKE
session.
n IKE starts negotiating IPsec SAs. When negotiation completes, IKE uses built-
in key exchange methods,such as the Diffie-Hellman algorithm, to create
keying material for new IPsec SAs and to create the SAs in the local SADB.
Alice and Bob now have complete SAs in place, as IKE provided them with a
negotiated policy and the needed keying material.
n The packet can now be securely sent to Bob since it is protected by the IPsec
SAs that are negotiated with the help of IKE.
-
7/30/2019 4t Ike Bcamp
13/25
Copyright 2001, Cisco Systems, Inc. Internet Key Exchange Protocol 13
Summary
After completing this lesson, you should 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)
Lesson Review
1. What protocols is IKE based on?
2. When does IPsec require the assistance of IKE?
3. When is IKE invoked again after IPsec SAs have been established?
-
7/30/2019 4t Ike Bcamp
14/25
14 Acces VPN v1.0 Copyright 2001, Cisco Systems, Inc.
IKE Technology Description
Objectives
Upon completing this lesson, you will be able to:
n Describe the IKE protocol
n Describe various peer authentication schemes with IKE
n Describe various phases and modes of the IKE exchange and how they relate
to IPsec policies
-
7/30/2019 4t Ike Bcamp
15/25
Copyright 2001, Cisco Systems, Inc. Internet Key Exchange Protocol 15
2001, Cisco Systems, Inc. Access VPN v1.0Internet Key Exchange Protocol-18
IKE ProtocolIKE Protocol
An IKE session runs over UDP (source anddestination port 500)
The result of IKE session establishment isthe creation of IKE SAs
IKE then establishes all requested IPsec SAson demand
An IKE session runs over the UDP protocol with source and destination ports set
to 500. When the IKE negotiation begins, IKE looks for an IKE policy that is the
same on both peers. The peer that initiates the negotiation will send all its
configured policies to the remote peer. The remote peer will try to find a match by
comparing its highest priority policy against the other peer's received policies. The
remote peer checks each of its policies in order of its priority (highest priority first)
until a match is found.
A match is made when both policies from the two peers contain the sameencryption, hash, authentication, and Diffie-Hellman parameter values, and when
the remote peer's policy specifies a lifetime less than or equal to the lifetime in the
policy being compared.
If an acceptable match is not found, IKE refuses negotiation and IPsec SAs will
not be negotiated and established.
If a match is found, IKE will complete negotiations, create a secure IKE session
based on the agreed-upon policy, and negotiate IPsec security associations over
the secure IKE session.
-
7/30/2019 4t Ike Bcamp
16/25
16 Acces VPN v1.0 Copyright 2001, Cisco Systems, Inc.
2001, Cisco Systems, Inc. Access VPN v1.0Internet Key Exchange Protocol-19
IKE Session ProtectionIKE Session Protection
IKE sessions are protected by cryptographicalgorithms/protocols
The peers need to agree exactly on a bundleof algorithms and protocols to protect theIKE session
These bundles are called IKE protectionsuites
IKE sessions are protected by cryptographic algorithms. IKE provides peer
authentication, session integrity, and session privacy for its management session.
The IKE policy defines how the IKE session should be protected, and has various
parameters that are agreed upon in the initial negotiation between peers. Since
some IKE messages are encrypted and authenticated, the peers must agree upon a
way to encrypt and authenticate messages. Since each peer must authenticate the
identity of the other, they must also agree on a way to do this. For all these
negotiated parameters, IKE defines attributes and the range of values that that
these attributes may have. The peers must agree exactly on a bundle of algorithms
and protocols to protect the IKE session.
Those bundles (encryption, hash algorithm, authentication method and Diffie -
Hellman group) are called IKEprotection suites.
-
7/30/2019 4t Ike Bcamp
17/25
Copyright 2001, Cisco Systems, Inc. Internet Key Exchange Protocol 17
2001, Cisco Systems, Inc. Access VPN v1.0Internet Key Exchange Protocol-20
IKE Session Protection (cont.)IKE Session Protection (cont.)
Protect ion sui tesdefine bundles used tosecure the IKE session
Encryption algorithm
Hashing MAC algorithm
Peer authentication procedure
DH group for initial key exchange
SA lifetime
IKEprotection suites define bundles of protection methods used to secure the
IKE session.
Those methods are:
n An encryption algorithm
n A hashing MAC (HMAC) algorithm
n A Peer authentication method
n The Diffie-Hellman group used for initial key exchange
n The IKE SA lifetime (IKE session lifetime)
-
7/30/2019 4t Ike Bcamp
18/25
18 Acces VPN v1.0 Copyright 2001, Cisco Systems, Inc.
2001, Cisco Systems, Inc. Access VPN v1.0Internet Key Exchange Protocol-21
IKE Phases and ModesIKE Phases and Modes
IKE has two phases:
IKE phase 1Uses mainoraggressivemode exchange
Negotiates IKE SA
IKE phase 2
Uses qu i ckmode exchange
Negotiates IPsec SAs
IKE protocol has two phases of operation, each of which can run in a particular
mode:
n IKE phase 1
Uses a main or aggressive mode exchange. Used to negotiate the IKE
SA (establish a secure IKE session)
n IKE phase 2
Uses a quickmode exchange Negotiates IPsec SAs (negotiates and
creates IPsec protection policy)
-
7/30/2019 4t Ike Bcamp
19/25
Copyright 2001, Cisco Systems, Inc. Internet Key Exchange Protocol 19
2001, Cisco Systems, Inc. Access VPN v1.0Internet Key Exchange Protocol-22
IKE Phase 1 NegotiationIKE Phase 1 Negotiation
IKE SA negotiation
3DES, MD5, and RSA Signatures3DES, MD5, and RSA Signatures,
or
DES, SHA, and RSA Signatures,
or
3DES, SHA, and pre-shared keys
In this figure, Alice and Bob want to talk IKE. Therefore they must agree on a
common IKE protection suite. The initiator (Bob) proposes several protection
suites and the responder (Alice) chooses one of the offered protection suites. The
selection of security policy is made by the responder according to its priorities in
the configuration. In the example, Bob proposes three protection suites, and Alice
chooses the second one (based on her local policy configuration). Peers must
agree exactly on the protection suite. If they do not, no common policies exist
between peers, and the IKE session will be terminated.
-
7/30/2019 4t Ike Bcamp
20/25
20 Acces VPN v1.0 Copyright 2001, Cisco Systems, Inc.
2001, Cisco Systems, Inc. Access VPN v1.0Internet Key Exchange Protocol-23
IKE Phase 2 NegotiationIKE Phase 2 Negotiation
IKE SA in place
Lets do
ESP tunnel w/ 3DES and MD-5
For traffic between A and B,
use ESP tunnel w/ 3DES and SHA-1
or
for traffic between A and B,
use ESP tunnel w/ 3DES and MD-5
IKE phase 2 is used to negotiate and establish SAs of other protocols (IPsecs AH
and ESP, IP PCP (payload compression protocol), etc). Phase 2 needs an
established IKE SA (produced in IKE phase 1 to protect the IKE session) to
operate, and only operates in one defined mode, the quickmode.
The IKE initiator presents a list of (IPsec) policy proposals and the IKE responder
chooses an acceptable proposal according to its locally defined policy. When the
policy between peers is agreed upon, the keying material is agreed upon, and IPsec
SAs are established.
In this figure, Alice and Bob want to protect their traffic with IPsec and an IKE
SA is already established between them. The initiator (Bob) proposes several
IPsec security policies, and the responder (Alice) chooses one of the offered
policies. The selection of security policy is made by the responder according to its
priorities in the configuration. In the example Bob proposes two IPsec security
policies and Alice chooses one of them (the one that has the highest priority in her
configuration). After successful negotiation, keying material is exchanged, and the
IPsec SAs are established to protect network traffic.
-
7/30/2019 4t Ike Bcamp
21/25
Copyright 2001, Cisco Systems, Inc. Internet Key Exchange Protocol 21
2001, Cisco Systems, Inc. Access VPN v1.0Internet Key Exchange Protocol-24
IKE Peer AuthenticationIKE Peer Authentication
To establish the IKE SA, peers have toauthenticate each other (two-way)
Three defined mechanisms
Pre-shared keys
RSA encrypted nonces
RSA signatures
One of the most important factors in the IKE SA negotiation is the mutual
authentication of peers. Each peer must be sure that it is talking to the correct
peer, before negotiating traffic protection (IPsec) policies with it. This mutual
authentication is accomplished via IKEs two-way authentication methods.
IKE provides three defined methods for two-way authentication:
n Authentication using a pre-shared secret
n Authentication using RSA encrypted nonces
n Authentication using RSA signatures
The details of these authentication methods are beyond the scope of this course.
-
7/30/2019 4t Ike Bcamp
22/25
22 Acces VPN v1.0 Copyright 2001, Cisco Systems, Inc.
2001, Cisco Systems, Inc. Access VPN v1.0Internet Key Exchange Protocol-25
IKE Session EncryptionIKE Session Encryption
IKE session is encrypted by either DES or3DES
Keying material is generally derived from theinitial DH exchange
In main mode, peer identity is also encrypted
Besides peer authentication, IKE also provides privacy and integrity of the IKE
session. The IKE session can be encrypted with the use of DES or 3DES. The
keying material for encryption is generally derived from the initial Diffie-Hellman
exchange that occurs between peers at the start of the IKE session. When IKE is
negotiating in main mode, peer identity is also encrypted, whereas aggressive mode
does not hide peer identities.
-
7/30/2019 4t Ike Bcamp
23/25
Copyright 2001, Cisco Systems, Inc. Internet Key Exchange Protocol 23
2001, Cisco Systems, Inc. Access VPN v1.0Internet Key Exchange Protocol-26
IKE Session IntegrityIKE Session Integrity
IKE uses HMAC functions to guaranteesession integrity
Usually a choice between keyed SHA-1 andMD5
Keying material is generally derived from theinitial DH exchange
IKE uses the HMAC functions to guarantee the integrity of an IKE session.
Usually, a choice between keyed SHA-1 and MD5 is available. The keying
material for HMAC functions is also generally derived from the initial Diffie-
Hellman exchange.
IKE initially performs an ephemeral Diffie-Hellman exchange at the start of the
IKE session. From that exchange, peers get shared keying material, which is then
used for IKE encryption and integrity functions. The strength of that keying
material can be traded off for faster performance, by choosing lower key sizes forDiffie-Hellman exchanges. The key length (strength) of Diffie-Hellman exchanges
can be changed with the use of different DHgroups.
When an IKE sessions lifetime expires, a new Diffie-Hellman exchange is
performed between peers and the IKE SA is re-established.
-
7/30/2019 4t Ike Bcamp
24/25
24 Acces VPN v1.0 Copyright 2001, Cisco Systems, Inc.
Summary
After completing this lesson, you should be able to:
n Describe the IKE protocol
n Describe various peer authentication schemes with IKE
n Describe various phases and modes of the IKE exchange and how they relate
to IPsec policies
Lesson Review
1. What does the IKE protocol look like on the network (transport, ports)?
2. How is the IKE protocol protected against intruders?
-
7/30/2019 4t Ike Bcamp
25/25
Summary
After completing this module, you should be able to:
n Identify the main purposes of the IKE protocol
n Explain how IKE interacts with IPsec