Transcript Chapter 6

Chapter 8
Chapter 5
Chapter 7
IKE
UDP
Figure 5.1 Relative Location of Security Facilities in the TCP/IP Protocol Stack
1
Excerpt from Rescorla “SSL and TLS”
He has described a “simple messaging system” similar to PGP, then he goes on:
The system we’ve just described works pretty well if all we’re doing is sending
simple messages around, as with e-mail, but it rapidly becomes inadequate if what
we want is to have a communications channel over which we can pass arbitrary
messages.
We’d like to be able to establish a set of secret keys that we could use for an
entire connection. This would let us avoid doing expensive public key
operations for every packet, which is especially important in interactive
applications where each keystroke might generate a packet.
A typical design for such a system is to have a handshake phase where Alice and
Bob authenticate each other and establish keys. Then they move on to a data
transfer phase where they use those keys to actually transmit the data they’re
interested in.
We’ll see this in our study of IPSec.
The handshake phase protocol is called Internet Key Exchange (IKE)
In Chapter 8 Stallings will leave the handshake phase until last.
2
Chapter 8 – IP Security
8.1 IP Security Overview
Applications of IPSec
► Secure branch office connectivity over the Internet
(“Virtual Private Network”)
► Secure remote access over the Internet
(traveling employees and telecommuters)
► Extranet and Intranet connectivity with partners
► Enhancing E-commerce security (B to B)
3
*
VPN
telecommuter
BHM
*
*
ATL
VPN
Figure 8.1 An IP Security Scenario
* We see that IPsec inserts new headers
between the IP header and the IP payload
4
Benefits of IPsec
► When IPSec implemented in firewall,
all traffic crossing boundary can be protected,
but internal traffic does not suffer overhead
of security-related processing
► IPsec in firewall is resistant to bypass
(provided firewall is only means of access)
► IPsec transparent to applications
► IPsec can be transparent to end users ("tunnel mode")
► IPsec can provide security for end users
if needed ("transport mode")
Routing Applications
Protection of routing updates (recall RIP)
5
IPsec Documents
There are three basic IPsec protocols:
► Authentication Header (AH): AH is an extension header to
provide message authentication. Because some authentication is
also (optionally) provided in ESP, AH is no longer used much and in
the 4th edition Stallings has deleted the section on AH that was in
previous editions of the book.
However, he continues to refer to AH in several places, so you need
to know that it exists.
► Encapsulating Security Payload (ESP): this provides
encryption and optional authentication of messages.
► Internet Key Exchange (IKE): This protocol governs the
preliminary handshake phase.
6
IPsec Services
► Access control
► Connectionless integrity
► Data origin authentication
► Rejection of replayed packets
► Confidentiality (encryption)
► Traffic flow confidentiality (in tunnel mode)
7
Transport and Tunnel Modes – overview
Transport Mode provides protection primarily for upper-layer
protocols – that is, for the IP datagram payload.
Transport mode is typically used in end-to-end communication
between two hosts.
Tunnel Mode extends protection to the entire datagram, by
encapsulating it in a new “outer” datagram.
Tunnel mode is typically used in communication between two routers
(must be used if a router is involved).
8
You will see this in
lab session #2
Tunnel Mode
9
Table 8.1 Tunnel Mode and Transport Mode Functionality
10
8.2 IP Security Policy
Security Associations (SA) (page 276/7) – established during handshake
► SA is a one-way relationship between a sender A and a
receiver B that specifies security services to be applied
to a subset of traffic from A to B
► if a peer relationship is desired, we need at least two SAs
► a single SA specifies authentication (AH) XOR encryption (ESP)
so we may need 4 SA’s for two-way traffic between A and B
11
Focus on an outbound IP datagram crossing the boundary
between an intranet and the Internet.
How is it decided what security processes are applied to this
datagram?
This is a policy decision by administration.
The decision for each category of traffic is entered into
a Security Policy Database.
The menu of available processes is collected into a
Security Association Database.
Adopt 2-step process - entries in the Security Policy Database point
to entries in the Security Association Database.
12
* IP destination address
* SPI
Information in the SA database has been agreed to by sender
and receiver during the preliminary handshake phase (IKE).
13
“A security association is uniquely
identified by three parameters:
► Security Parameters Index (SPI)
► IP address of destination
endpoint of SA
► IPSec protocol (AH XOR ESP)”
* IP destination address
* SPI
14
Summary of relationship between SPD, IKE, and SAD:
Note that SA must first be established between the two IKEs
15
Security Association (SA) Example: Handshaking over secure inter-IKE
channel to establish ESP SA from source BHM to destination ATL
CLT
BHM
Want
SA
IKE: negotiate algorithms,
develop keys,
authenticate participants
ATL Chooses
SPI = 1235
ATL
This SA uniquely identified by
AH XOR ESP
= ESP
ATL Chooses
SPI = 1234
SA destination = ATL
SPI
= ???
1234
SA BHM → ATL established
SPI is unique, local to
destination endpoint
of SA
16
Note that BYPASS IPsec is a possible policy for nonsensitive traffic that requires no security processing.
17
Now consider incoming traffic (page 280/1)
IP datagram arrives:
51
AH header
DATA
PROTOCOL field = 51 reveals data processed with AH
PROTOCOL field = 50 reveals data processed with ESP
We’ll see that the IPsec header includes the SPI
18
Incoming Traffic – contd.
Consider an IPsec datagram arriving at ATL over our example SA
BHM
This SA uniquely identified by
AH XOR ESP
= ESP
ATL
SA destination = ATL
ATL knows that it is ATL!
SPI
The other two parameters are
readily available to ATL in the
incoming datagram headers
= ???
1234
Search of incoming SPD is not
necessary: ATL can index into SAD
19
Index
PROTOCOL = 50 or
51
There may be incoming datagrams that were not
subjected to IPsec processing – search of incoming
SPD needed to detect intruders.
20
8.3 Encapsulating Security Payload
H
Initialization Vector
P
T
Optional Integrity Check Value (MAC)
Figure 8.5(a) ESP Packet Format
21
Anti-Replay Service
Figure 8.6 Anti-replay Mechanism
22
ESP in transport mode
Alice
End-to-end encryption
Bob
ESP in transport mode conceals what Alice is saying to Bob,
but not that Alice and Bob are communicating.
23
ESP in tunnel mode
Alice
VPN
Bob
ESP in tunnel mode over the VPN also
conceals the fact that Alice is talking to Bob
24
Alice
VPN
Bob
25
Scope of ESP encryption
and authentication
Original datagram
Protocol = 6
ESP authentication
does not extend to
the IP header
ESP in
transport mode
Protocol = 50
Next = 6
ESP in
tunnel mode
Protocol = 50
Next = 4
26
8.4 Combining Security Associations
Since a single SA is tightly focused, it may be necessary to combine more
then one to get the desired protection [the new standard, RFC 4301 drops
the term security association bundle ].
For example, the previous slide noted that ESP authentication does not
extend to the IP datagram header. AP does authenticate the “immutable”
(unchanging) fields in the datagram header, so we may need both ESP
and AH.
The SAs may terminate at different endpoints, or at the same endpoint.
There are two way to combine SAs:
► Transport adjacency
- apply more than one protocol to a given IP datagram
example: ESP, followed by AH
► tunneling (possibly iterated)
- encapsulation of one datagram inside another
27
Authentication plus
confidentiality, using
Transport Adjacency
This is simple, but undesirable, because it authenticates the ciphertext
28
Authentication plus confidentiality, using tunneling.
First, apply AH in
transport mode:
Recall ESP in
tunnel mode:
With this scheme, AH authenticates the plaintext
29
Basic Combinations of Security Associations
End-to-End Security:
Already discussed, and you will see it in lab session #2, section 9
30
Secure transmission over Internet
VPN
You will see this in lab session #2, section 5
31
End-to-End Security over VPN:
You will see this in lab session #2, section 10
32
Traveling salesperson or telecommuter communicating over Internet
33
8.5 Internet Key Exchange
Although Stallings presents this at the end of Chapter 8, it actually has
to occur before data can be exchanged securely.
The default key automated key management protocol for IPSec consists of
two parts (p293):
► Oakley Key Exchange Protocol (development of Diffie-Hellman)
Discuss this next
► Internet Security Association and Key Management Protocol
provides a framework for negotiation of security attributes
Defer to page 296
34
Key Determination Protocol (Oakley)
Recall Diffie-Hellman Key Exchange Protocol:
K is the session key
that will be used for
symmetric encryption
of data transmitted.
Global public parameters q (modulus) and α (generator)
already agreed. Y is public key, X is private key.
35
Diffie-Hellman
Advantages:
► secret keys created only when needed
► exchange requires no pre-existing infrastructure
Disadvantages:
► no authentication of participants
► subject to (wo)man-in-the-middle attacks
► computationally intensive
subject to “clogging attacks” (next slide)
► vulnerable to replay attack (more later)
36
Clogging attack: Darth masquerades as A (trusted by B),
sends YA, triggering extensive computation by B.
37
Features of IKE Key Determination (p294)
1. It uses Cookies to thwart clogging attacks
2. The two parties negotiate use of a group
(the global parameters q and α)
3. It uses Nonces protect against replay attack
4. It enables Diffie-Hellman public key exchange
5. It authenticates the participants
(protects against man-in-the-middle attacks)
38
Cookie requirements (to defend against clogging attacks):
1. Cookie must depend on the two specific parties.
2. Impossible for anyone other than the issuing entity to
generate a cookie that will be accepted by that entity
(must use local non-shared secret information in
generation and verification)
3. Generation and verification methods must be fast.
Recommendation for cookies:
Perform a hash over the source and destination IP addresses,
the TCP/UDP source and destination ports, and a
locally-generated secret (not shared) value.
Note:
► cookies are not time-dependent
► IKE cookies are not the same as HTTP cookies.
39
Use of cookies:
40
Clogging attempt by Darth, from spoofed IP address of A
Darth can force B to generate ACKs,
but not to compute DH keys
41
But cookies, not being time-dependent,
do not protect against a replay attack
1
3
Darth copies messages 1 and 3
42
Replay Attack: Darth has copied message 1 and after A and B have
finished their exchange Darth re-sends message 1 to B.
1
3
B thinks this initiates a new exchange and responds as before,
sending message 2 to A; A recognizes cookA, but knows she didn’t
initiate a new exchange, so she ignores this as a delayed duplicate.
Darth has also copied message 3 and now re-sends it to B.
B recognizes his own cookie, concludes that the exchange is genuine
and computes YB and K – wasted computation.
43
A nonce is a number used only once.
1
Replay attack (replay messages 1 and 3) fails,
because B knows he has seen the nonce nA before.
44
IKE key determination refers to a group, which is essentially values
of the global parameters modulus q and generator α.
Standard groups:
► 1. modular exponentiation (MODP) with 768-bit modulus, α = 2
► 2. modular exponentiation with 1024-bit modulus, α = 2
► 5. modular exponentiation with 1536-bit modulus, α = 2
► two elliptic curve groups (omit)
45
Authentication of Participants
As usual, we have to authenticate the participants.
On page 295/6 Stallings states that three methods can be used with IKE
key determination (Oakley.)
► Digital signatures
► Public-Key encryption - encrypt with sender private key
The first two methods appear to be the same
► symmetric-key encryption – manual exchange of secret key
46
Second part of IKE/Oakley:
IKE is an application layer protocol, using UDP to carry messages.
IKE
IPsec
ISAKMP refers to Initiator and Responder, since it is controlling Layer
3, where a client-server situation does not exist. Initiator and
Responder are peers, both using UDP port 500.
I think of IKE as a puppeteer, operating above the stage, pulling
the strings that set the dials and switches at the IP layer.
47
There are now two versions of IPsec/IKE. Stallings’ pages 294300 cover IKE version 2, but since we have version 1 in the lab
we’ll substitute a handout.
Application
Layer (5)
IP Layer (3)
Although this figure refers to IKEv2 and IPsecv3,
the basic structure is correct for us.
48
We have seen that before a pair of security gateways can exchange
user data protected by IPsec, they must complete a preliminary
handshake, the Internet Key Exchange.
During the handshake they authenticate each other and establish
algorithms and keys that will be used in subsequent user data transfer.
IKE itself has two phases:
► phase 1: a secure channel, the IKE Security Association
pair is set up between the two security gateways
► phase 2: the two gateways use this channel to negotiate
safely one or more IPsec SA pairs that will be
used to protect transfer of user data between
the two intranets
Both phases must be complete before user data can flow
49
IKE provides two items:
► a collection of message formats
► standard sequences of these messages
to accomplish specific objectives
We consider these in order.
50
First Item: IKE messages consist of a header, followed
by one or more payloads
Header format (v1):
(a) IKEv1 Header
For IKE SA establishment
Exchangetype will be
Identitity Protection
Exchange (anti-Darth!)
51
First Item – continued:
IKE Payloads all begin with the generic header:
Types you will see in lab #2 are:
► Security Association payload
► Proposal payload
► Transform payload
► Key exchange payload
► Identification payload
52
Second Item: Standard sequences of messages.
Within IKE there are two phases. Here is more detail:
IKE phase 1:
The Identity Protection Exchange consists of 6 messages:
Messages (1) and (2): Peers negotiate algorithms to be used for
establishment of the secure channel between security gateways
Messages (3) and (4) generate the keys to be used
Messages (5) and (6) include authentication of the peers.
53
IKE Phase 2
The secure channel established in phase 1 is used to establish one
or more IPSec SA pairs that will subsequently be used to protect
user data. We have Darth shut out, so an abbreviated sequence
without participant authentication, Quick Mode, is normally used,
consisting of just 3 messages.
54
Back to Phase 1 – the Identity Protection Exchange
The algorithms to be offered in message (1) and selected in
message (2) are:
► the symmetric encryption algorithm
► the hash algorithm to be used in HMAC for message integrity
► the participant authentication method
► the group to be used for Diffie-Hellman/Oakley
during session key development
55
Identity Protection Exchange
#
Initiator
Direction
(1) HDR; SA
=>
(2)
<=
Responder
NOTE
Begin ISAKMP-SA
HDR; SA
Basic SA agreed upon
At this point the parties have agreed on algorithms
(3) HDR; KE; NONCE
=>
(4)
<=
Key Generated (by
Initiator and Responder)
At this point each party has used Diffie-Hellman to securely generate keys.
However, the initiator could have been a “man in the middle”
(5) HDR*; ID-I; AUTH
=>
(6)
<=
HDR; KE; NONCE
Initiator Identity
Verified by Responder
HDR*; ID-R; AUTH
Responder Identity
Verified by Initiator
* = payload encrypted
At this point the parties have authenticated themselves to each other
and the IKE Security Associations are complete.
56
IKE phase 1 finished.
We have a secure channel established
between authenticated peers.
Proceed to phase 2:
Use the secure channel to establish SAs
for user data transfer.
57
IKE Phase 2
We could go through the six-message exchange again, checking
authentication and producing totally new keys.
Instead, use Quick Mode, which takes just 3 messages.
Quick Mode accepts the choice of algorithms made in phase1.
It also accepts the DH key generated in phase 1, but hashes it
to make “new” keys (“new keys from old”)
End of Handshake.
IKE and IPSec Security Associations established.
We can proceed to transmit user data.
58
We now take a look at lab #2
In the first part of lab session #2 we want to establish a secure tunnel
through the “dangerous” network 192.168.6.0 for traffic between
192.168.5.0 and 192.168.7.0
59
Recall that IKE consist of two phases:
1. The two “peers” (the encrypting routers X2 and X3)
establish a secure, authenticated channel through which
to communicate. This is called the “IKE SA”
2. The secure channel established in phase 1 is used to
establish one or more “IPsec SAs,” each of which will be
used to protect particular subsets of user traffic
flowing between the two subnets.
60
Phase 1 uses the IKEv1 Identity Protection Exchange. According to
RFC 2409, the following items must be negotiated:
► the symmetric encryption algorithm
► the hash algorithm to be used in HMAC for message integrity
► the participant authentication method
► the group to be used for Diffie-Hellman/Oakley
during session key development
In message #1 the Initiator presents a menu of available sets of
these items, and in message #2 the Responder chooses one.
61
Message #1 – Initiator to Responder
Internet Security Association and Key Management Protocol
Initiator cookie: 0x46434F49BFDEB5A2
Responder cookie: 0x0000000000000000
Cookies
Next payload: Security Association (1)
Exchange type: Identity Protection (Main Mode) (2)
(equivalent
Security Association payload
SPI)
Next payload: Vendor ID (13)
Length: 148
Domain of interpretation: IPSEC (1)
Situation: IDENTITY (1)
Proposal payload # 0
Next payload: NONE (0)
Length: 136
Proposal number: 0
Protocol ID: ISAKMP (1)
SPI size: 0
Number of transforms: 4
Transform payload # 0
Next payload: Transform (3)
Length: 32
Transform number: 0
Transform ID: KEY_IKE (1)
Life-Type (11): Seconds (1)
Life-Duration (12): Duration-Value (3600)
Encryption-Algorithm (1): 3DES-CBC (5)
Hash-Algorithm (2): MD5 (1)
Authentication-Method (3): RSA-SIG (3)
Group-Description (4): 1536 bit MODP group (5)
Continues with Transform payloads # 1 - 3
to
62
Message #1 - continued
Proposal payload # 0
Next payload: NONE (0)
Length: 136
Proposal number: 0
Protocol ID: ISAKMP (1)
SPI size: 0
Number of transforms: 4
Transform payload # 0
Next payload: Transform (3)
Length: 32
Transform number: 0
Transform ID: KEY_IKE (1)
Life-Type (11): Seconds (1)
Life-Duration (12): Duration-Value (3600)
Encryption-Algorithm (1): 3DES-CBC (5)
Hash-Algorithm (2): MD5 (1)
Authentication-Method (3): RSA-SIG (3)
Group-Description (4): 1536 bit MODP group (5)
Transform payload # 1
Next payload: Transform (3)
Length: 32
Transform number: 1
Transform ID: KEY_IKE (1)
Life-Type (11): Seconds (1)
Life-Duration (12): Duration-Value (3600)
Encryption-Algorithm (1): 3DES-CBC (5)
Hash-Algorithm (2): SHA (2)
Authentication-Method (3): RSA-SIG (3)
Group-Description (4): 1536 bit MODP group (5)
Continues with Transform payloads # 2 & 3
63
Message #2 – Responder to Initiator
Internet Security Association and Key Management Protocol
Initiator cookie: 0x46434F49BFDEB5A2
Responder cookie: 0x78B0C0E83C7E8B8A
Next payload: Security Association (1)
Exchange type: Identity Protection (Main Mode) (2)
Security Association payload
Next payload: Vendor ID (13)
Length: 52
Domain of interpretation: IPSEC (1)
Situation: IDENTITY (1)
Proposal payload # 0
Next payload: NONE (0)
Length: 40
Proposal number: 0
Protocol ID: ISAKMP (1)
SPI size: 0
Number of transforms: 1
Transform payload # 0
Next payload: NONE (0)
Length: 32
Transform number: 0
Responder
Transform ID: KEY_IKE (1)
Life-Type (11): Seconds (1)
chooses
Life-Duration (12): Duration-Value (3600)
transform #0
Encryption-Algorithm (1): 3DES-CBC (5)
Hash-Algorithm (2): MD5 (1)
Authentication-Method (3): RSA-SIG (3)
64
Group-Description (4): 1536 bit MODP group (5)
Phase 1 – continued
In lab session #2 the responder’s choice (in message #2) is:
► symmetric encryption algorithm – 3DES-CBC
► hash algorithm – MD5
► participant authentication method – RSA-SIG
► Oakley group – group 5 (1536 bits, α = 2)
Messages #3 and #4 perform the Oakley key exchange
Messages #5 and #6 authenticate parties using RSA-SIG
End of IKE Phase 1 – secure channel established
65
Phase 2: Having set up the secure channel, we can now use it to
establish the parameters of an IPSec SA that will govern the
cryptographic processing of a particular subset of traffic between the
subnets.
As stated before, it would be possible to go through a complete new
sequence of procedures (e.g. Diffie-Hellman for key exchange), but this
is not necessary over the secure channel.
Instead, an abbreviated procedure is used, simply hashing the keys
generated in phase 1. This is called Quick Mode. The Oakley RFC
(2412) refers to this as “new keys from old.”
In Quick Mode three messages are exchanged over the secure channel.
Since these are encrypted you will not be able to investigate the in the
lab.
66
First of 3 quick Mode messages:
Internet Security Association and Key Management Protocol
Initiator cookie: 0x46434F49BFDEB5A2
Responder cookie: 0x78B0C0E83C7E8B8A
Next payload: Hash (8)
Version: 1.0
Exchange type: Quick Mode (32)
Flags
.... ...1 = Encryption
.... ..0. = No commit
.... .0.. = No authentication
Message ID: 0x6BAA1227
Length: 412
Encrypted payload (384 bytes)
67
End of material on IPsec.
68
69