What is authentication header AH )? How does it protect against replay attacks?

ESP

ESP provides confidentiality (in addition to authentication, integrity, and anti-replay protection) for the IP payload. ESP in transport mode does not sign the entire packet. Only the IP payload (not the IP header) is protected. ESP can be used alone or in combination with AH (in order to provide for signing of the entire packet).

NOTE

IPSec is based on machine certificates, thus authentication pertains to only the computer from which the message was sent. IPSec cannot verify that data was sent from a particular user (although there are other mechanisms for doing so).

The ESP header is placed before the IP payload, and an ESP trailer and ESP authentication trailer are placed after the IP payload. The ESP header contains the following fields:

Security Parameters Index (SPI) Used to identify which SA is used in conjunction with the security protocol and destination address. This value is used by the receiver to determine the packet identification.

Sequence Number Provides anti-replay protection for the packet. The sequence number starts at 1 and increases in 32-bit increments. It is used to indicate the packet number sent over the quick mode SA for the communication. This number cannot be repeated. If a recipient gets a number that has been repeated, it will not accept the packet.

The ESP trailer contains the following fields:

Padding Validates that byte boundaries are present on encrypted payloads. This process is required by the encryption algorithm.

Padding Length Used to show the length, in bytes, of the Padding field.

Next Header Used to identify whether the payload data is TCP or UDP.

The ESP authentication trailer contains the Authentication Data field, which holds the message authentication code, also known as the integrity check value (ICV). The ICV is used for message verification and authenticity. The ICV is calculated by the packet receiver and checked against the sender’s value for integrity verification.

Figure 10.3 illustrates how ESP affects the data. You can see that the IPSec AH header has been placed after the IP header and before the TCP header.

Basic Security in Mobility Support for IPv6

Using IPSec, the BUs and BAs include message origin authorization, integrity protection, and replay protection. For the purposes of the establishment of a symmetric key and mitigation of traffic redirection attacks, a new mechanism named return routability procedure has been integrated to mobility support in IPv6.

A CN supporting IPv6 mobility may learn the care-of address of a MN, through the reception of BUs. Hence, the CN may communicate directly with the MN without using the HA as an intermediary. The structure of a BU packet from a MN to a CN is illustrated in Figure 5-11. It consists of an IPv6 fixed header together with a mobility header. The mobility header is polymorphic. For a BU, the mobility header contains a binding update message with options, the home address option and binding authorization data. The binding update message contains a sequence number and lifetime of the binding. The binding authorization data contain a binding signature. The signature is computed using a secret binding management key kbm shared between the MN and CN. The key kbm is established using the return routability procedure. The signature is calculated over a string resulting from the concatenation of the care-of address, IP address of the CN, and mobility header. The care-of address is typically also the source IP address in the fixed IPv6 header. The care-of address together with the home address, taken from the home address option, is used by the CN to create a binding. The IP address of the CN is typically the destination address in the IPv6 header.

IPSec Core Layer 3 Protocols: ESP and AH

IPSec provides confidentiality and integrity protection for transmitted information, authentication source and destinations, and anti-replay protection. Two main network protocols, Encapsulating Security Payload (ESP) and Authentication Header (AH), are used to achieve this goal. All other parts of the IPSec standard merely implement these protocols and configure the required technical parameters. Applying AH or ESP to an IP packet may modify the data payload (not always) and may insert an AH or ESP header between the IP header and the packet contents. See Figures 5.9 and 5.10 for illustrations of how these transformations are performed.

IPsec Fundamentals

Replay Protection

SRTP packet-index determination deciphers the index of an invalid as well as a valid packet. There can be no integrity check until the authentication key is determined. SRTP replay protection is the first line of defense against packets sent by an attacker.

To counter replay attack, Rollover Counter (ROC) and sliding window are used. The 16-bit sequence number from the RTP header is added to the 32-bit SRTP ROC that is stored in the cryptographic context to get the 48-bit sequence number, which is the SRTP packet index for the particular packet. The packet index is encrypted with other parameters to generate key stream segments.

As Figure 9.7 depicts, a received packet index must fall within range of the sliding window, and its corresponding “Received?” bit must not be checked in order for the packet to be passed to the next processing step. If the packet does not meet the criteria, it is discarded. If an attacker chooses a sequence number at random, and the window size is 64, there is a 99.9 percent likelihood (1–64/216) that the packet will be discarded before more computationally intense message authentication is applied.

5.10.3 Principles of Network Domain Security

NDS provides services for

Data Integrity or Protection The data has not been altered in an unauthorized manner.

Data Origin Authentication The data originates from a trusted source.

Anti-replay Protection To protect against the re-use of packets with an encryption mechanism place.

Confidentiality Guaranteeing the information is not made available to unauthorized sources. However, it is limited when flow control is applied.

NDS applies to the control plane within the boundary of the service provider’s network domain. NDS does not apply to the user plane. This is in line with what we learned earlier about being able to apply IPSec to Transmission Control Protocol (TCP) and Stream Control Transmission Protocol (SCTP) traffic and not the UDP, which is the transport for the media itself. NDS utilizes the following mechanisms:

Security Policy The set of rules and mechanisms for securing interfaces and providing data protection.

Security Domain The logical or physical definition of the network domain to which a common security policy is being applied.

Security Gateway (SEG) The functional element in a security, which resides at the edge of the security domain that applies.

Security Association (SA) The secure association sets up by the SEG. These are secure IPSec associations and have been negotiated with the IKE.

Security Policy Database (SPD) This contains the set of policies that determine the rules to be applied for all inbound and outbound traffic to the SEGs.

Security Association Database (SAD) Describes the active set of all the security associations and related parameters.

The SEG enforces the inter-domain security policies. These policies apply rules for data protection, filtering, and firewall capabilities. Each SEG is responsible for establishing a security association (SA) with the peer SEG. The security association is encrypted using IPSec in a tunnel mode. The SA uses ESP for the data protection. Establishing an SA is negotiated using the IKE protocol. In order to support bidirectional traffic, the SEG sets up two SAs. One SA handles the incoming signaling and one SA for the outbound.

The SEG maintains two databases. The SEG uses the security policy database to discriminate the traffic on the SA. With the help of the SPD, it determines whether the packets flowing either on the inbound or outbound SA need to be protected by IPSec, or whether they need to be filtered. The security associations’ database is used by the SEG as a map of the current traffic set belonging to an SA. Each SA entry is maintained in terms of a security parameter index (SPI), which is an index into the database. It also holds the destination addresses for the SA.

11.6.3 WPA2

The outstanding feature of WPA2 is the use of the Advanced Encryption Standard AES. Counter mode cipher block chaining message authentication code protocol (CCMP) provides the highest level of confidentiality, integrity and replay protection available in the 802.11 standard [19]. WPA2 is shown in Fig. 11.28. It uses essentially the same key-establishment process and key hierarchy architecture as WPA (Fig. 11.26). An exception is that the same key is used for confidentiality and integrity; there are no separate encryption and MIC keys. In contrast to RC4 of WEP which is a stream cipher, AES is a block cipher, although it does use a key stream to encrypt each block. CCMP achieves confidentiality in counter mode by taking each of consecutive 128 bit blocks of packet plaintext and XORing it with a keystream formed from encryption of a counter, incremented for each block, using the temporal key. To create the MIC used to insure integrity, cipher block chaining message mode is used. Each block is XOR'ed with the ciphertext of the previous block and encrypted with the temporal key. The process is started with an initializing vector (IV) created with a counter that is incremented for each packet. MIC is 64 bits of the last ciphertext block. Because of the chaining of blocks, a change in one or more bits of the message will cause a large difference between the MIC sent with the packet and the MIC constructed at the receiver.

Fig. 11.28 shows the main blocks of WPA2. Note that in addition to the message data, fields of the MPDU header, notably the address fields and QoS field, formed in AAD (additional authentication data), are encrypted. The packet number counter, which is incremented on each packet is used in composing a nonce, which never repeats itself in a session. The AES CCM (Counter mode with CBC-MAC) block includes both the counter and cipher block chaining message modes for confidentiality and integrity. The CCMP header and the MAC header which are transmitted in the clear, let the receiver compose the IV which it needs to check integrity and to make the counter used for decryption. The fact that addresses are encrypted from AAD assures that diversion of packets caused by hostile change of packet header addresses can be detected in the receiver.

WPA2 gives similar protection as WPA with TKIP. It gives superior security, however, by using the AES security standard, which is stronger than RC4 for encryption and gives better integrity protection than MICHAEL used in WPA.

The Wi-Fi Alliance announced that new capabilities under WPA3 are available from 2018. Among them are protection of users who choose weak passwords, simplification of the configuration process for devices with limited display interfaces such as sensors and IoT modules, improved privacy on open networks, and stronger security for government, defense and industrial networks through new protocols using a 192 bit security suite [20].

8.3.4.2 Access security overview

Access security in 5GS consists of different components:

Mutual authentication between UE and network.

Key derivation to establish separate keys for ciphering and integrity protection, with strong key separation.

Ciphering, integrity, and replay protection of NAS signaling between UE and AMF.

Ciphering, integrity, and replay protection of Control Plane signaling between UE and the network. For 3GPP access, the RRC signaling is protected between UE and gNB. For untrusted non-3GPP access, IKEv2 and IPSec is used between UE and N3IWF.

Ciphering and integrity of the User Plane. For 3GPP access the User Plane can be ciphered and integrity protected between UE and gNB. For untrusted non-3GPP access, the User Plane can be ciphered, and integrity protected between UE and N3IWF.

Privacy protection to avoid sending the permanent user identity (SUPI) over the radio link.

Fig. 8.3 illustrates some of these components in the network.

We discuss in further detail below how each of these components have been facilitated.

7.3.1 Access Security in E-UTRAN

It was clear from the start of the standardization process that E-UTRAN should provide a security level at least as high as that of UTRAN. Access security in E-UTRAN therefore consists of different components, similar to those that can be found in UTRAN:

Mutual authentication between UE and network

Key derivation to establish separate keys for ciphering and integrity protection

Ciphering, integrity, and replay protection of NAS signaling between UE and MME

Ciphering, integrity, and replay protection of RRC signaling between UE and eNB

Ciphering of the user plane. The user plane is ciphered between UE and eNB

Use of temporary identities in order to avoid sending the permanent user identity (IMSI) over the radio link.

Figure 7.2 illustrates some of these components in the network.

Below we will discuss in detail how each of these components has been facilitated.

The authentication procedure in E-UTRAN is in many ways similar to the authentication procedure in GERAN and UTRAN, but there are also differences. To understand the reason behind these differences, it is useful to first briefly look at the security features of GERAN and UTRAN systems. As with all security features in communication systems, what was considered sufficiently secure at one point in time may not turn out to be sufficient years later when attack methods and computing power have developed further. This is also true for 3GPP radio accesses. When GERAN was developed, some limitations were purposely accepted. For example, mutual authentication is not performed in GERAN where it is only the network that authenticates the terminal. It was thought that there was no need for the UE to authenticate the network, since it was unlikely that anyone would be able to set up a rogue GERAN network. When UTRAN/UMTS was developed, enhancements were made to avoid some of the limitations of GERAN. For example, mutual authentication was introduced. These new security procedures are one reason why a new type of SIM card was needed for UMTS: the so-called UMTS SIM (or USIM for short). With the introduction of E-UTRAN, further improvement is taking place. One important aspect is, however, that it has been agreed that the use of USIM in the terminal will be sufficient to access E-UTRAN – that is, no new type of SIM card is needed. The new features are instead supported by software in the terminal and the network.

Mutual authentication in E-UTRAN is based on the fact that both the USIM card and the network have access to the same secret key K. This is a permanent key that is stored on the USIM and in the HSS/AuC in the home operator’s network. Once configured, the key K never leaves the USIM or the HSS/AuC. The key K is thus not used directly to protect any traffic and it is also not visible to the end-user or even the terminal. During the authentication procedure, other keys are generated from the key K in the terminal and in the network that are used for ciphering and integrity protection of user-plane and control-plane traffic. For example, one of the derived keys is used to protect the user plane, while another key is used to protect NAS signaling. One reason why several keys are produced like this is to provide key separation and to protect the underlying shared secret K. In UTRAN and GERAN, the same keys are used for ciphering of control signaling and user traffic, and hence this is also an enhancement compared to these earlier standards. This is, however, not the only key management enhancement, as will be discussed below.

The mechanism for authentication as well as session key generation in E-UTRAN is called EPS Authentication and Key Agreement (EPS AKA). Mutual authentication with EPS AKA is done in the same manner as for UMTS AKA, but as we will see when we go through the procedure, there are a few differences when it comes to key derivation.

EPS AKA is performed when the user attaches to EPS via E-UTRAN access. Once the MME knows the user’s IMSI, the MME can request an EPS authentication vector (AV) from the HSS/AuC, as shown in Figure 7.3. Based on the IMSI, the HSS/AuC looks up the key K and a sequence number (SQN) associated with that IMSI. The AuC increases the SQN and generates a random challenge (RAND). Taking these parameters and the master key K as input to cryptographic functions, the HSS/AuC generates the UMTS AV. This AV consists of five parameters: an expected result (XRES), a network authentication token (AUTN), two keys (CK and IK), and the RAND. This is illustrated in Figure 7.3. Readers familiar with UMTS will recognize this Authentication Vector as the parameter that the HSS/AuC would send to the SGSN for access authentication in UTRAN. For E-UTRAN, however, the CK and IK are not sent to the MME. Instead, the HSS/AuC generates a new key, KASME, based on the CK and IK and other parameters such as the serving network identity (SN ID). The SN ID includes the Mobile Country Code (MCC) and Mobile Network Code (MNC) of the serving network. A reason for including SN ID is to provide a better key separation between different serving networks to prevent a key derived for one serving network being (mis)used in a different serving network. Key separation is illustrated in Figure 7.4.

KASME, together with XRES, AUTN, and RAND, constitutes the EPS AV that is sent to the MME. The CK and IK never leave the HSS/AuC when E-UTRAN is used. In order to distinguish the different AVs, the AUTN contains a special bit called the “separation bit” indicating whether the AV will be used for E-UTRAN or for UTRAN/GERAN. A reason for going through this extra step with the new key KASME, instead of using CK and IK for ciphering and integrity protection as in UTRAN, is to provide strong key separation for legacy GERAN/UTRAN systems. For more details on the generation of the EPS AV, see 3GPP TS 33.401.

Mutual authentication in E-UTRAN is performed using the parameters RAND, AUTN, and XRES. The MME keeps KASME and XRES but forwards RAND and AUTN to the terminal shown in Figure 7.5. Both RAND and AUTN are sent to the USIM. AUTN is a parameter calculated by the HSS/AuC based on the secret key K and the SQN. The USIM now calculates its own version of AUTN using its own key K and SQN, and compares it with the AUTN received from the MME. If they are consistent, the USIM authenticates the network. Then the USIM calculates a response RES using cryptographic functions with the key K and the challenge RAND as input parameters. The USIM also computes CK and IK in the same way as when UTRAN is used (it is, after all, a regular UMTS SIM card). When the terminal receives RES, CK, and IK from the USIM, it sends the RES back to the MME. The MME authenticates the terminal by verifying that the RES is equal to XRES. This completes the mutual authentication. The UE then uses the CK and IK to compute KASME in the same way as HSS/AuC did. If everything has worked out, the UE and network have authenticated each other and both UE and MME now have the same key KASME (note that none of the keys K, CK, IK, or KASME was ever sent between UE and the network).

Now all that remains is to calculate the keys to be used for protecting traffic. As mentioned above, the following type of traffic is protected between UE and E-UTRAN:

NAS signaling between UE and MME

RRC signaling between UE and eNB

User-plane traffic between UE and eNB.

Different keys are used for each set of procedures above, and also different ciphering and integrity protection keys are used. The key KASME is used by UE and MME to derive the keys for ciphering and integrity protection of NAS signaling (KNASenc and KNASint). In addition, the MME also derives a key that is sent to the eNB (the KeNB). This key is used by the eNB to derive keys for ciphering of the user plane (KUPenc) as well as ciphering and integrity protection of the RRC signaling between UE and eNB (KRRCenc and KRRCint). The UE derives the same keys as eNB. The “family tree” of keys is typically referred to as a key hierarchy. The key hierarchy of E-UTRAN in EPS is illustrated in Figure 7.6.

Once the keys have been established in the UE and the network, it is possible to start ciphering and integrity protection of the signaling and user data. The standard allows use of different cryptographic algorithms for this, and the UE and the NW need to agree on which algorithm to use for a particular connection. The EPS encryption algorithms (EEA) currently supported for NAS, RRC, and UP ciphering are shown in Table 7.1. EEA0, 128-EEA1, and 128-EEA2 are mandatory to support in the UE, eNB, and MME, while 128-EEA3 is optional to support. The EPS integrity protection algorithms (EIA) currently supported for RRC and NAS signaling integrity protection are shown in Table 7.2. The algorithms 128-EIA1 and 128-EIA2 are mandatory to support in the UE, eNB, and MME, while 128-EIA3 is optional to support. The Null integrity protection algorithm EIA0 is only used for unauthenticated emergency calls. For more details on the ciphering and integrity algorithms supported with E-UTRAN, see 3GPP TS 33.401.

Table 7.1. Ciphering Algorithms for LTE

NameAlgorithmCommentEEA0Null ciphering algorithmWhen this algorithm is selected, there is no ciphering of the messages. Supported from Release 8.128-EEA1SNOW 3G-based algorithmSupported from Release 8128-EEA2AES-based algorithmSupported from Release 8128-EEA3ZUC-based algorithmAdded in Release 11

Table 7.2. Integrity Protection Algorithms for LTE

NameAlgorithmCommentEIA0Null integrity protection algorithmWhen this algorithm is selected, there is no integrity protection of the messages. Added in 3GPP Release 9 to support unauthenticated emergency calls128-EIA1SNOW 3G-based algorithmSupported from Release 8128-EIA2AES-based algorithmSupported from Release 8128-EIA3ZUC-based algorithmAdded in Release 11

The final aspect that should be mentioned is identity protection. In order to protect the permanent subscriber identity (i.e. IMSI) from being exposed in clear text over the radio interface, temporary identities are used whenever possible in a similar way to what is done in UTRAN. See the identities section in Chapter 6 for a description on how temporary identities are used in E-UTRAN.

A main enhancement in E-UTRAN as compared to UTRAN is, as was discussed above, the strong key separation between networks and key usage. A few other enhancements are also worth briefly mentioning:

Larger key sizes. E-UTRAN supports not only 128-bit keys but can (in future deployments) also use 256-bit keys.

Additional protection against compromised base stations. Due to the flattened architecture in E-UTRAN, additional measures were added to protect against a potentially compromised “malicious” radio base station. One of the most important features is the added forward/backward security: each time the UE changes its point of attachment (due to mobility) or when the UE changes from the Idle to the Connected state, the air interface keys are updated according to a sophisticated procedure. This means that even in the unlikely event that the keys used so far have been compromised, security can be restored.

What is authentication header AH How does it protect against replay attacks?

What is authentication header AH How does it protect against replay attacks ques10?

What is meant by authentication header?

What is authentication header and how it provides the protection to IP header?