UNIT- 3 (Part-II)

INTERNET PROTOCOL SECURITY ARCHITECTURE

IP SECURITY OVERVIEW
In 1994, the Internet Architecture Board (IAB) issued a report titled “Security in the Internet
Architecture” (RFC 1636). The report identified key areas for security mechanisms. Among these
were the need to secure the network infrastructure from unauthorized monitoring and control of
network traffic and the need to secure end-user-to-end-user traffic using authentication and
encryption mechanisms.
To provide security, the IAB included authentication and encryption as necessary security features
in the next-generation IP, which has been issued as IPv6. Fortunately, these security capabilities
were designed to be usable both with the current IPv4 and the future IPv6. This means that vendors
can begin offering these features now, and many vendors now do have some IPsec capabil- ity in
their products. The IPsec specification now exists as a set of Internet standards.
APPLICATIONS OF IPSEC
IPsec provides the capability to secure communications across a LAN, across private
and public WANs, andacross the Internet. Examples of its use include:

 Secure branch office connectivity over the Internet

 Secure remote access over the Internet:
 Establishing extranet and intranet connectivity with partners
 Enhancing electronic commerce security:

Figure 1 is a typical scenario of IPsec usage.

BENEFITS OF IPSEC
Some of the benefits of IPsec:

• When IPsec is implemented in a firewall or router, it provides strong security.

• IPsec in a firewall is resistant to bypass if all traffic from the outside must use IP and the
firewall is the only means of entrance from the Internet into the organization.
• IPsec is below the transport layer (TCP, UDP) and so is transparent to applications.
• IPsec can be transparent to end users.
• IPsec can provide security for individual users if needed.

ROUTING APPLICATIONS

In addition to supporting end users and protecting premises systems and networks, IPsec can play a
vital role in the routing architecture required for internetworking. IPsec can assure that

o A router advertisement (a new router advertises its presence) comes from an authorized router.
o A neighbor advertisement (a router seeks to establish or maintain a neighbor relationship with a
router in another routing domain) comes from an autho- rized router.
o A redirect message comes from the router to which the initial IP packet was sent.
o A routing update is not forged.

IP SECURITY ARCHITECTURE
Ipsec documents
The documents can becategorized into the following groups.
• Architecture: Covers the general concepts, security requirements, definitions, and
mechanisms defining IPsec technology.
• Authentication Header (AH): AH is an extension header to provide message
authentication.
• Encapsulating Security Payload (ESP): ESP consists of an encapsulating header and
trailer used to provide encryption or combined encryption/authentication.
• Internet Key Exchange (IKE): This is a collection of documents describing the key
management schemes for use with IPsec.
• Cryptographic algorithms: This category encompasses a large set of docu ments that
define and describe cryptographic algorithms for encryption, mes-sage authentication,
pseudorandom functions (PRFs), and cryptographic key exchange.
• Other: There are a variety of other IPsec-related RFCs, including those deal- ing with
security policy and management information base (MIB) content.
 IPsec Services
IPsec provides security services at the IP layer by enabling a system to select required security
protocols, determine the algorithm(s) to use for the service(s), and put in place any cryptographic
keys required to provide the requested services. Two protocols are used to provide security: an
authentication protocol designated by the header of the protocol, Authentication Header (AH); and
a combined encryption/ authentication protocol designated by the format of the packet for that
protocol. Encapsulating SecurityPayload (ESP). lists the following services:

• Access control
• Connectionless integrity
• Data origin authentication
• Rejection of replayed packets (a form of partial sequence integrity)
• Confidentiality (encryption)
• Limited traffic flow confidentiality

Transport and Tunnel Modes

Both AH and ESP support two modes of use: transport and tunnel mode.
Transport mode
Transport mode provides protection primarily for upper-layer protocols. That is, transport mode
protection extends to the payload of an IP packet.
ESP in transport mode encrypts and optionally authenticates the IP payload but not the IP header.
AH in transport mode authenticates the IP payload and selected portions of the IP header.
Tunnel mode
Tunnel mode provides protection to the entire IP packet. To achieve this, after the AH or ESP
fields are added to the IP packet, the entire packet plus security fields is treated as the payload
of new outer IP packet with a new outer IP header.
Table 19.1 summarizes transport and tunnel mode functionality.
 IP security policy
Fundamental to the operation of IPsec is the concept of a security policy applied to each IP packet
that transits from a source to a destination. IPsec policy is determined primarily by the interaction
of two databases, the security association database (SAD) and the security policy database (SPD).
Security Associations
A key concept that appears in both the authentication and confidentiality mecha- nisms for IP is the
security association (SA). An association is a one-way logical connection between a sender and a
receiver that affords security services to the traffic carried on it. If a peer relationship is needed for
two-way secure exchange, then two security associations are required. Security services are
afforded to an SA for the use of AH or ESP, but not both.

A security association is uniquely identified by three parameters.

• Security Parameters Index (SPI):
• IP Destination Address:
• Security Protocol Identifier:

Security Association Parameters

A security association is normally defined by the following parameters in an SAD entry.

• Security Parameter Index:

• Sequence Number Counter:
• Sequence Counter Overflow:
• Anti-Replay Window:
• AH Information:
• ESP Information
• Lifetime of this Security Association:
• I Psec Protocol Mode: Tunnel, transport, or wildcard.
• Path MTU:
AUTHENTICATION HEADER
The Authentication Header provides support for data integrity and authentication of IP packets. The
data integrity feature ensures that undetected modification to a packet's content in transit is not
possible. The authentication feature enables an end system or network device to authenticate the
user or application and filter traffic accordingly; it also prevents the address spoofing attacks
observed in today's Internet. The AH also guards against the replay attack. Authentication is based
on the use of a message authentication code (MAC), hence the two parties must share a secret key.
The Authentication Header consists of the following fields:

• Next Header (8 bits): Identifies the type of header immediately following this header.
• Payload Length (8 bits): Length of Authentication Header in 32-bit words, minus 2.
• Reserved (16 bits): For future use.
• Security Parameters Index (32 bits): Identifies a security association.
• Sequence Number (32 bits): A monotonically increasing counter value, discussed later.
• Authentication Data (variable): A variable-length field (must be an integral number of
32-bit words) that contains the Integrity Check Value (ICV), or MAC, for this packet.
Anti-Replay Service
Anti-replay service is designed to overcome the problems faced due to replay attacks in which an
intruder intervenes the packet being transferred, make one or more duplicate copies of that
authenticated packet and then sends the packets to the desired destination, thereby causing
inconvenient processing at the destination node. The Sequence Number field is designed to thwart
such attacks.
When a new SA is established, the sender initializes a sequence number counter to 0. Each time that
a packet is sent on this SA, the sender increments the counter and places the value in the Sequence
Number field. Thus, the first value to be used is 1. This value goes on increasing with respect to the
number of packets being transmitted. The sequence number field in each packet represents the value
of this counter. The maximum value of the sequence number field can go up to 232-1. If the limit of
232-1 is reached, the sender should terminate this SA and negotiate a new SA with a new key.
The IPSec authentication document dictates that the receiver should implement a window of size
W, with a default of W = 64. The right edge of the window represents the highest sequence number,
N, so far received for a valid packet. For any packet with a sequence number in the range from N-
W+1 to N that has been correctly received (i.e., properly authenticated), the corresponding slot in
the window is marked as shown. Inbound processing proceeds as follows when a packet is received:

Integrity Check Value

ICV is the value present in the authenticated data field of ESP/AH, which is used to determine any
undesired modifications made to the data during its transit. ICV can also be referred as MAC or part
of MAC algorithm. MD5 hash code and SHA-1 hash code are implemented along with HMAC
algorithms i.e.,
• HMAC-MD5-96
• HMAC-SHA-1-96
Transport and Tunnel Modes
The following figure shows typical IPv4 and IPv6 packets. In this case, the IP payload is a
TCP segment; it could also be a data unit for any other protocol that uses IP, such as UDP or ICMP.
ENCAPSULATING SECURITY PAYLOAD
ESP can be used to provide confidentiality, data origin authentication, connection- less integrity, an
anti-replay service (a form of partial sequence integrity), and (limited) traffic flow confidentiality.
The set of services provided depends on options selected at the time of Security Association (SA)
establishment and on the location of the implementation in a network topology.ESP can work with
a variety of encryption and authentication algorithms, including authenticated encryption
algorithms such as GCM.
ESP Format
Figure 19.5a shows the top-level format of an ESP packet. It contains the following fields.

• Security Parameters Index (32 bits): Identifies a security association.

• Sequence Number (32 bits): A monotonically increasing counter value; this
provides an anti-replay function, as discussed for AH.
• Payload Data (variable): This is a transport-level segment (transport mode) or IP packet
(tunnel mode) that is protected by encryption.
• Padding (0 – 255 bytes): The purpose of this field is discussed later.
• Pad Length (8 bits): Indicates the number of pad bytes immediately preceding this field.
• Next Header (8 bits): Identifies the type of data contained in the payload data
field by identifyingthe first header in that payload (for example, an extension
header in IPv6, or an upper-layer protocol such as TCP).
• Authetication Data (variable): A variable-length field (must be an integral number of
32-bit words) that contains the Integrity Check Value computed over the ESP packet
minus the Authentication Data field.
Encryption and Authentication Algorithms
The Payload Data, Padding, Pad Length, and Next Header fields are encrypted by the ESP service.
If the algorithm used to encrypt the payload requires crypto- graphic synchronization data, such as
an initialization vector (IV), then these data may be carried explicitly at the beginning of the
Payload Data field. If included, an IV is usually not encrypted, although it is often referred to as
being part of the ciphertext.
Padding
The Padding field serves several purposes.
Transport and Tunnel Modes
Figure 19.7 shows two ways in which the IPsec ESP service can be used. In the upper part of the
figure, encryption (and optionally authentication) is provided directly between two hosts. Figure
19.7b shows how tunnel mode operation can be used to set up a virtual private network.
The scope of ESP for the two modes. The considerations are somewhat different for IPv4 and IPv6.
We use the packet formats of Figure 19.8a as a starting point.
Transport mode ESP
Transport mode ESP is used to encrypt and optionally authenticate thedata carried by IP (e.g., a TC
P segment), as shown in Figure 19.8b.

Tunnel mode ESP

Tunnel mode ESP is used to encrypt an entire IP packet (Figure 19.8c). For this mode, the ESP
header is prefixed to the packet and then the packet plus the ESP trailer is encrypted. This method
can be used to counter traffic analysis.
Figure 19.9 shows the protocol architecture for the two modes.
COMBINING SECURITY ASSOCIATIONS
An individual SA can implement either the AH or ESP protocol but not both. Sometimes a
particular traffic flow will call for the services provided by both AH and ESP. Further, a particular
traffic flow may require IPsec services between hosts and, for that same flow, separate services
between security gateways, such as fire- walls. In all of these cases, multiple SAs must be
employed for the same traffic flow to achieve the desired IPsec services. The term security
association bundle refers to a sequence of SAs through which traffic must be processed to provide a
desired set of IPsec services. The SAs in a bundle may terminate at different endpoints or at the
same endpoints.
Security associations may be combined into bundles in two ways:

• Transport adjacency: Refers to applying more than one security protocol to the same IP
packet without invoking tunneling.
• Iterated tunneling: Refers to the application of multiple layers of security protocols
effected through IP tunneling.

The two approaches can be combined.

Authentication Plus Confidentiality
Encryption and authentication can be combined in order to transmit an IP packet that has both
confidentiality and authentication between hosts. We look at several approaches.
ESP WITH AUTHENTICATION OPTION
This approach is illustrated in Figure 19.8. In this approach, the user first applies ESP to the data to
be protected and then appends the authentication data field. There are actually two sub cases:

• Transport mode ESP: Authentication and encryption apply to the IP payload delivered to
the host, but the IP header is not protected.
• Tunnel mode ESP: Authentication applies to the entire IP packet delivered to the outer IP
destination address (e.g., a firewall), and authentication is performed at that destination. The
entire inner IP packet is protected by the privacy mechanism for delivery to the inner IP
destination.

For both cases, authentication applies to the cipher text rather than the plaintext.
TRANSPORT ADJACENCY
Another way to apply authentication after encryption is to use two bundled transport SAs, with the
inner being an ESP SA and the outer being an AH SA.
TRANSPORT-TUNNEL BUNDLE
The use of authentication prior to encryption might be preferable for several reasons.
BASIC COMBINATION OF SECURITY ASSOCIATIONS
The IPsec Architecture document lists four examples of combinations of SAs that must be
supported by compliant IPsec hosts (e.g., workstation, server) or security gateways (e.g. firewall,
router). These areillustrated in Figure 19.10. The lower part of each case in the figure represents the
physical connectivity of the elements; the upper part represents logical connectivity via one or more
nested SAs. Each SA can be either AH or ESP. For host-to-host SAs, the mode may be either
transport or tunnel; otherwise it must be tunnel mode.
Case 1. All security is provided between end systems that implement IPsec. For any two end
systems to communicate via an SA, they must share the appropri- ate secret keys. Among the
possible combinations are

• AH in transport mode
• ESP in transport mode
• ESP followed by AH in transport mode (an ESP SA inside an AH SA)
• Any one of a, b, or c inside an AH or ESP in tunnel mode

We have already discussed how these various combinations can be used to support
authentication,encryption, authentication before encryption, and authenti- cation after encryption.
Case 2. Security is provided only between gateways (routers, firewalls, etc.) and no hosts
implement IPsec. This case illustrates simple virtual private network support. The security
architecture document specifies tha tonly a single tunnel SA is needed for this case. The tunnel
could support AH, ESP, or ESP with the authenti- cation option. Nested tunnels are not required,
because the IPsec services apply to the entire inner packet.
Case 3. This builds on case 2 by adding end-to-end security. The same combi- nations discussed for
cases 1 and 2 are allowed here. The gateway-to-gateway tunnel provides either authentication,
confidentiality, or both for all traffic between end systems. When the gateway-to-gateway tunnel is
ESP, it also provides a limited form of traffic confidentiality. Individual hosts can implement any
additional IPsec ser- vices required for given applications or given users by means of end-to-end
SAs.
Case 4. This provides support for a remote host that uses the Internet to reach an organization’s
firewall and then to gain access to some server or workstation behind the firewall. Only tunnel
mode is required between there mote host and the firewall. As in case 1, one or two SAs may be
used between the remote host and the localhost.
KEY MANAGEMENT
The key management portion of IPsec involves the determination and distribution of secret keys. A
typical requirement is four keys for communication between two applications: transmit and receive
pairs for both integrity and confidentiality. The IPsec Architecture document mandates support for
two types of key management:

• Manual: A system administrator manually configures each system with its own keys and
with the keys of other communicating systems. This is practical for small, relatively static
environments.
• Automated: An automated system enables the on-demand creation of keys for SAs and
facilitates the use of keys in a large distributed system with an evolving configuration.

The default automated key management protocol for IPsec is referred to as ISAKMP/Oakley and
consists of the following elements:

• Oakley Key Determination Protocol: Oakley is a key exchange protocol based on the
Diffie-Hellman algorithm but providing added security. Oakley is generic in that it does not
dictate specific formats.
• Internet Security Association and Key Management Protocol (ISAKMP): ISAKMP
provides aframework for Internet key management and provides the specific protocol
support, including formats, fornegotiation of security attributes.

Key Determination Protocol

OEKLEY key determination is a refinement of the Diffie-Hellman key exchange algorithm. Recall
that Diffie-Hellman involves the following interaction between users A and B. There is prior
agreement on two global parameters: q, a large prime number; and a, a primitive root of q
The Diffie-Hellman algorithm has two attractive features:

• Secret keys are created only when needed.

• The exchange requires no pre-existing infrastructure other than an agreement on the global
parameters.

However, there are a number of weaknesses to Diffie-Hellman:-

• It does not provide any information about the identities of the parties.
• It is subject to a man-in-the-middle attack, in which a third party C impersonates B while
communicating with A and impersonates A while communicating with B. Both A and B end
up negotiating a key with C, which can then listen to and pass on traffic.
• It is computationally intensive.
 OEKLEY key determination is designed to retain the advantages of Diffie- Hellman, while
countering its weaknesses.

FEATURES OF OEKLEY KEY DETERMINATION

The OEKLEY key determination algorithm is characterized by five important features:

• It employs a mechanism known as cookies to thwart clogging attacks.

• It enables the two parties to negotiate a group; this, in essence, specifies the global
parameters of theDiffie-Hellman key exchange.
• It uses nonces to ensure against replay attacks.
• It enables the exchange of Diffie-Hellman public key values.
• It authenticates the Diffie-Hellman exchange to thwart man-in-the-middle attacks.

OEKLEY key determination supports the use of different groups for the Diffie- Hellman key
exchange. Each group includes the definition of the two global parameters and the identity of the
algorithm. The current specification includes the following groups.

• Modular exponentiation with a 768-bit modulus

q = 2768 - 2704 - 1 + 264 * (:2638 * p; + 149686)
a =2
• Modular exponentiation with a 1024-bit modulus
q = 21024 - 2960 - 1 + 264 * (:2894 * p; + 129093)
a =2
• Modular exponentiation with a 1536-bit modulus
o Parameters to be determined
• Elliptic curve group over 2155
o Generator (hexadecimal): X = 7B, Y = 1C8
o Elliptic curve parameters (hexadecimal): A = 0, Y = 7338F
o Elliptic curve group over 2185
o Generator (hexadecimal): X = 18, Y = D
o Elliptic curve parameters (hexadecimal): A = 0, Y = 1EE9

OEKLEY key determination employs nonces to ensure against replay attacks. Each nonce is a
locally generated pseudorandom number. Nonces appear in responses and are encrypted during
certain portions of the exchange to secure their use.
Three different authentication methods can be used with OEKLEY key determination:

• Digital signatures
• Public-key encryption
• Symmetric-key encryption:
ISAKMP
It defines procedures and packet formats to establish, negotiate, modify, and delete security
associations.As part of SA establishment, IKE defines payloads for exchanging key generation and
authentication data.
ISAKMP HEADER FORMAT
An IKE message consists of an IKE header followed by one or more payloads. All of this is carried
in a transport protocol. The specification dictates that implementations must support the use of UDP
for the transport protocol.
It consists of the following fields.

• Initiator SPI (64 bits): A value chosen by the initiator to identify a unique IKE security
association(SA).
• Responder SPI (64 bits): A value chosen by the responder to identify a unique IKE SA.
• Next Payload (8 bits): Indicates the type of the first payload in the message; payloads are
discussed in the next subsection.
• Major Version (4 bits): Indicates major version of IKE in use.
• Minor Version (4 bits): Indicates minor version in use.
• Exchange Type (8 bits): Indicates the type of exchange; these are discussed later in this
section.
• Flags (8 bits): Indicates specific options set for this IKE exchange.
• Message ID (32 bits): Used to control retransmission of lost packets and matching of
requests and responses.
• Length (32 bits): Length of total message (header plus all payloads) in octets.

IKE PAYLOAD TYPES

• Proposal: This substructure includes a proposal number, a protocol ID (AH, ESP, or

IKE), an indicator of the number of transforms, and then a transform substructure.
• Transform: Different protocols support different transform types.
• The Key Exchange payload can be used for a variety of key exchange tech- niques,
including Oakley,Diffie-Hellman, and the RSA-based key exchange used by PGP.
• The Identification payload is used to determine the identity of communicating peers and
may be used for determining authenticity of information
• The Certificate payload transfers a public-key certificate. The Certificate Encoding field
indicates the type of certificate or certificate-related information, which may include the
following:

o PKCS #7 wrapped X.509 certificate

o PGP certificate
o DNS signed key
o X.509 certificate—signature
o X.509 certificate—key exchange
o Kerberos tokens
o Certificate Revocation List (CRL)
o Authority Revocation List (ARL)
o SPKI certificate