Slide 1
1
Networking
IPsec
© Janice Regan, 2009-2017
© Janice Regan, 2009-2017
2
Necessary components
Both authentication and encryption are based on algorithms that require the end users to process the contents of the packets using a key known only to the sender and/or the receiver
This means that a third party, who does not have the key, will not be able to
Decrypt the packets encrypted contents to see what is in the packet
Make undetected changes to an authenticated packet, or make a packet appear to come from the authenticated sender.
© Janice Regan, 2009-2017
3
IPsec
IPsec is used to add authentication and encryption to the existing IPv4 protocol (and to IPv6)
Rather than redefining the IP header IPsec uses
an authentication header that is inserted between the IP header and the contents of the IP packet to enable authentication only (transport mode)
AND / OR
An encapsulating security payload header inserted between the IP header and the payload of the IP packet to enable authentication and encryption (transport mode)
OR
One (or rarely both) of the above headers and tunneling.
© Janice Regan, 2009-2017
4
© Janice Regan, 2009-2017
5
IPsec usage
Host to host
May use transport mode
May use tunnel mode
Security Gateway to Security Gateway
Must use tunneling
Host to/from security gateway
For traffic destined to security gateway (for example SNMP message) the gateway is operating as a host and transport mode may be used
Otherwise, if the gateway is operating as a gateway tunneling mode must be used
© Janice Regan, 2009-2017
6
IPv4 Authentication (transport mode)
authenticated
Partially authenticated
IPv4
header
TCP
header
TCP data
IPv4
header
TCP
header
TCP data
Authentication
header
IPv4 packet: no authentication
IPv4 packet: IPsec authentication
© Janice Regan, 2009-2017
7
IPv4 packet: No Authentication
IPv4 packet: Tunnel mode Authentication
IPv4 Authentication (tunnel mode)
authenticated
Partially authenticated
IPv4
header
TCP
header
TCP data
IPv4
header
TCP
header
TCP data
Authentication
header
IPv4
tunnel
header
© Janice Regan, 2009-2017
8
IPv4 Protocol Header
Protocol will have a value of 51, indicating that the next information will be an IPsec authentication header
Comer 2000: fig 7.3
© Janice Regan, 2009-2017
9
Authentication header
Next
Header
Payload
Length
Reserved
Security Parameter Index
Sequence Number
Authentication Data
0
16
32
© Janice Regan, 2009-2017
10
Authentication header fields
Next Header: The Next header field in the authentication header contains the protocol in the message (TCP, UDP, ICMP … the value that would otherwise have been in the protocol field of the IPv4 header)
Sequence number: contains a unique packet number for each packet sent. Starts at zero when a authentication method is agreed upon and a security association (SA) is established. Used to prevent replay (denial of service) attacks.
© Janice Regan, 2009-2017
11
Authentication header fields
Authentication Data: varies according to the authentication algorithm used. Most common algorithms are DESCBC (cipher Block Chaining mode of the Data Encryption Standard, default for IPv6), MD5 (Message Digest No. 5) and SHA1 (Secure Hash algorithm 1)
Payload Length: length in 32 bit words of the Sequence number and authentication data fields.
© Janice Regan, 2009-2017
12
Authentication header fields
Security parameters index: One of the three parameters used to uniquely define a security association (SA). Used to identify the appropriate SA in the security association database (SAD)
© Janice Regan, 2009-2017
13
Security Associations (1)
An SA describes one simplex connection.
If you are using both AH and ESP you need one SA for each.
For two way communication you need one SA for each direction
Three parameters used to uniquely define a security association (SA).
destination address
security protocol (AH or ESP)
Security parameters index (SPI)
© Janice Regan, 2009-2017
14
Security Association (2)
SAs are stored in a database The SAD (Security Associations Database) also includes the following information:
Mode of communication (transport or tunnel)
Sequence Number Counter
Anti-Replay Window: to determine whether an inbound AH or ESP packet is a replay.
AH Authentication algorithm type, keys, etc.
OR
ESP Encryption algorithm and / or authentication, algorithm types, keys etc.
Lifetime of this Security Association
© Janice Regan, 2009-2017
15
IPv6 packet Structure
IPv6
header
Destination
Options
header
Hop by
Hop
header
Routing
header
Fragment
header
DATA
Encapsulating
Security
header
Destination
Options
header
Authentication
header
Transport
header
© Janice Regan, 2009-2017
16
Building authenticated packets
An Authentication header is added to the payload of the IP packet
The Authentication data in the header is set to 0
The IP header is added to the front of the packet
Mutable fields in the IP header are set to 0 (see following slides)
© Janice Regan, 2009-2017
17
Building authenticated packets
The IP header, the Authentication header and payload are hashed (and possibly encrypted (signed) as well) to create authentication data
Authentication data are put into the authentication header
Fields set to zero for calculation of the Authentication data are set back the their correct values (the fields are not actually zeroed and reset, the algorithm used just treats them as zero)
© Janice Regan, 2009-2017
18
Authentication and IP header
The authentication data in the authentication header is determined using the IP header the authentication header and the data
The values in immutable or mutable and predictable fields in the IP header are used in the calculation of the authentication data.
The values in mutable fields in the IP header are set to zero for the purpose of calculating the authentication data.
© Janice Regan, 2009-2017
19
Authentication and IP header
Immutable
Version
Internet Header Length
Total Length
Identification Protocol (This should be the value for AH.)
Source Address
Destination Address
Mutable but predictable with loose or strict source routing IPv4 or with routing header IPv6
© Janice Regan, 2009-2017
20
Authentication and IP header
Mutable (zeroed prior to ICV calculation) IPv4
Header Checksum TOS — This field is excluded because some routers are known to change the value of this field, even though the IP specification does not consider TOS to be a mutable header field.
Fragment Offset — Since AH is applied only to non-fragmented IP packets, the Offset Field must always be zero, and thus it is excluded (even though it is predictable).
© Janice Regan, 2009-2017
21
Authentication and IP header
Mutable (zeroed prior to ICV calculation) IPv4
TTL — This is changed en-route as a normal course of processing by routers, and thus its value at the receiver is not predictable by the sender.
Flags — This field is excluded since an intermediate router might set the DF bit, even if the source did not select it.
Header Checksum — This will change if any of these other fields changes, and thus its value upon reception cannot be predicted by the sender.
Mutable (IPv6) Class, Flow label, Hop limit
© Janice Regan, 2009-2017
22
IPsec and fragmentation
Transport mode
A fragment will not be processed to add a transport mode AH or ESP header
A packet that has been built including a AH and/or ESP header can later be fragmented. Such a packet must be reassembled before IPsec processing at the destination can begin
Tunnel mode
AH and / or ESP can be applied to any IP packet, that packet may contain a fragment or a non fragmented IP packet.
© Janice Regan, 2009-2017
23
Encapsulating security header
Required by IPv6 to be the last optional header, (other than destination options which are only important at the destination) otherwise following option headers would be unreadable because they were encrypted.
Retrofitted to IPv4, must follow the IPv4 header so that header is not encrypted.
The next header is payload type (next higher level protocol) for both IPv4 and IPv6
Padding present for compatibility with encryption algorithms, alignment of authorization data on a 4 byte boundary, or the disguise contents of packets
Authentication is for encapsulating security protocol header, use an authentication header for general authentication
© Janice Regan, 2009-2017
24
ESP header/payload for IPv6
SEQUENCE NUMBER
SECURITY PARAMETER INDEX (SPI)
AUTHENTICATION DATA (Variable Length)
PADDING
(0-255 octets)
PAD
LENGTH
NEXT
HEADER
INITIALIZATION VECTOR
DATA
encrypted
© Janice Regan, 2009-2017
25
ESP header and trailer for IPv4
ESP Header
ESP Trailer
SEQUENCE NUMBER
SECURITY PARAMETER INDEX (SPI)
AUTHENTICATION DATA (Variable Length)
PADDING
(0-255 octets)
PAD
LENGTH
NEXT
HEADER
© Janice Regan, 2009-2017
26
Security header fields
Security Parameter Index: (SPI)
One of the three parameters used to define a security association (SA). The other two are destination address and security protocol (AH or ESP).
Sequence Number:
This unsigned 32-bit field contains a monotonically increasing counter value (sequence number).
The sender’s counter (sequence number) is initialized to 0 when an SA is established. The sequence number is incremented for each successive packet sent. If the sequence number has cycled a new SA must be established.
© Janice Regan, 2009-2017
27
Security header fields
Sequence Number: (cont)
The sender’s counter (sequence number) is initialized to 0 when an SA is established. The sender increments the Sequence Number for this SA and inserts the new value into the Sequence Number field for each packet sent. Thus the first packet sent using a given SA will have a Sequence Number of 1. The sender checks to ensure that the counter has not cycled before inserting the new value in the Sequence Number field. If the sequence number has cycled a new SA must be established.
© Janice Regan, 2009-2017
28
Security trailer fields
Padding: when is it needed?
To insure that the Payload Data, Pad Length and Next Header fields, as well as the Padding to be a multiple of some number of bytes (e. g. the block size of a block cipher). Some encryption algorithms require this condition.
To ensure that the encrypted data terminates on a 4-byte boundary. The Pad Length and Next Header fields must be right aligned within a 4-byte word, as illustrated in the ESP packet format figure above,
© Janice Regan, 2009-2017
29
Security trailer fields
Padding: (cont)
to ensure that the Authentication Data field (if present) is aligned on a 4-byte boundary.
to conceal the actual length of the payload, in support of (partial) traffic flow confidentiality.
Note that the amount of padding is recorded in the ESP trailer and is thus encrypted, therefore someone intercepting the packet cannot determine the amount of padding that has been added
Inclusion of such additional padding has adverse bandwidth implications and thus its use should be undertaken with care.
© Janice Regan, 2009-2017
30
Security trailer fields
Pad Length:
indicates the number of pad bytes immediately preceding it. The range of valid values is 0-255
Next Header:
identifies the type of data contained in the Payload Data field, e.g., an extension header in IPv6 or an upper layer protocol identifier in IPv4.
© Janice Regan, 2009-2017
31
Security trailer fields
Authentication data: variable-length, contains an Integrity Check Value (ICV) computed over the ESP packet minus the Authentication Data.
The length of the field is specified by the authentication function selected.
The Authentication Data field is optional, and is included only if the authentication service has been selected for the SA in question.
The authentication algorithm specification MUST specify the length of the ICV and the comparison rules and processing steps for validation.
© Janice Regan, 2009-2017
32
IPsec transport mode
IP header
TCP header
TCP data
TCP
header
TCP
data
IP
header
ESP
header
ESP
trailer
ESP
auth
encrypted
authenticated
Included in authentication calculation
Not encrypted or authenticated
© Janice Regan, 2009-2017
33
IPsec tunneling
IP header
TCP header
TCP data
New IP
header
TCP
header
TCP
data
IP
header
AH
ESP
header
ESP
trailer
ESP
auth
encrypted
authenticated
Included in authentication calculation
Not encrypted or authenticated
© Janice Regan, 2009-2017
34
IPsec tunneling
IP header
TCP header
TCP data
New IP
header
TCP
header
TCP
data
IP
header
ESP
header
ESP
trailer
ESP
auth
encrypted
authenticated
Included in authentication calculation
Not encrypted or authenticated
© Janice Regan, 2009-2017
35
Encapsulating Security Protocol
Add ESP trailer after payload
For transport mode add ESP header to start of payload
For tunnel mode add ESP header before original IP header
© Janice Regan, 2009-2017
36
Encapsulating Security Protocol
Encrypts the result using the key, encryption algorithm, algorithm mode indicated by the SA
For transport mode Payload Data, Padding, Pad Length, and Next Header
For tunnel mode Payload Data, Padding, Pad Length, and Next Header and original IP header
Create authentication data (ICV) from ESP header payload and trailer, and then add after encrypted IP payload
Add IP header before ESP header, protocol value (next header) should be 50
© Janice Regan, 2009-2017
37
If authentication is selected, encryption is performed first, before the authentication, and the encryption does not encompass the Authentication Data field. This order of processing facilitates rapid detection and rejection of replayed or bogus packets by the receiver, prior to decrypting the packet, hence potentially reducing the impact of denial of service attacks. It also allows for the possibility of parallel processing of packets at the receiver, i.e., decryption can take place in parallel with authentication. Note that since the Authentication Data is not protected by encryption, a keyed authentication algorithm must be employed to compute the ICV.
RFC 2406
© Janice Regan, 2009-2017
38
© Janice Regan, 2009-2017
39
IPsec usage
Host to host
May use transport mode
May use tunnel mode
Security Gateway to Security Gateway
Must use tunneling
Host to/from security gateway
For traffic destined to security gateway (for example SNMP message) the gateway is operating as a host and transport mode may be used
Otherwise, if the gateway is operating as a gateway tunneling mode must be used
© Janice Regan, 2009-2017
40
IPv4 packet: Transport mode Authentication
IPv4 packet: Tunnel mode Authentication
IPv4 AH Authentication
authenticated
Partially authenticated
IPv4
header
TCP
header
TCP data
Authentication
header
IPv4
tunnel
header
authenticated
Partially authenticated
IPv4
header
TCP
header
TCP data
Authentication
header
© Janice Regan, 2009-2017
41
AH authentication algorithms
HMAC with MD5 RFC 2403
HMAC with SHA-1 RFC 2404
© Janice Regan, 2009-2017
42
Transport Mode
Tunnel Mode
IPsec: ESP
New IP
header
TCP
header
TCP
data
IP
header
ESP
header
ESP
trailer
ESP
auth
encrypted
authenticated
Not encrypted or authenticated
TCP
header
TCP
data
IP
header
ESP
header
ESP
trailer
ESP
auth
© Janice Regan, 2009-2017
43
ESP authentication algorithms
HMAC with MD5 RFC 2403
HMAC with SHA-1 RFC 2404
Null Authentication
© Janice Regan, 2009-2017
44
ESP encryption algorithms
DES in CBC mode RFC 2405
Null Encryption
© Janice Regan, 2009-2017
45
Security Associations (1)
An SA describes one simplex connection.
If you are using both AH and ESP you need one SA for each.
For two way communication you need one SA for each direction
Three parameters used to uniquely define a security association (SA).
destination address
security protocol (AH or ESP)
Security parameters index (SPI)
© Janice Regan, 2009-2017
46
Security Association (2)
SAs are stored in a database The SAD (Security Associations Database) also includes the following information:
Mode of communication (transport or tunnel)
Sequence Number Counter
Anti-Replay Window: to determine whether an inbound AH or ESP packet is a replay.
AH Authentication algorithm type, keys, etc.
OR
ESP Encryption algorithm and / or authentication, algorithm types, keys etc.
Lifetime of this Security Association
/docProps/thumbnail.jpeg