M.7 Security association set-up procedure

33.2033G Security3GPPAccess security for IP-based servicesTS

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

M.7.0 General

The security association set-up procedure is necessary in order to decide what security services to apply and when the security services start. In the IMS authentication of users is performed during registration as specified in clause M.6.1. Subsequent signalling communications in this session will be integrity protected based on the keys derived during the authentication process.

M.7.1 Security association parameters

For protecting IMS signalling between the UE and the P‑CSCF it is necessary to agree on shared keys that are provided by IMS AKA, and a set of parameters specific to a protection method. The security mode setup (cf. clause M.7.2) is used to negotiate the SA parameters required for IPsec ESP with authentication and confidentiality, in accordance with the provisions in clauses 5.1.3, 5.1.4, M.6.2, and M.6.3.

The SA parameters that shall be negotiated between UE and P‑CSCF in the security mode set-up procedure are:

– Encryption algorithm

cf. clause 7.1

– Integrity algorithm

cf. clause 7.1

– Mode

The IPsec SA mode of operation shall depend on whether the UE is located behind a NAT device or not. If the UE is located behind a NAT device UDP encapsulated tunnel mode according to RFC 3948 [28] shall be used. Otherwise transport mode shall be used. The set-up of security associations (cf. clause M.7.2) allows the P-CSCF to detect whether the UE is located behind a NAT or not.

– SPI (Security Parameter Index)

cf. clause 7.1

The following SA parameters are not negotiated:

cf. clause 7.1

Selectors if no NAT is present:

Cf. section 7.1

Selectors if a NAT is present:

The security associations (SA) have to be bound to specific parameters (selectors) of the SIP flows between UE and P‑CSCF, i.e. source and destination IP addresses, transport protocols that share the SA, and source and destination ports.

– IP addresses are bound If a NAT is present, it is assumed that the UE is configured locally with a (e.g. private) IP address. When the UE communicates with the P-CSCF via the NAT device, the NAT allocates a binding, mapping the local IP address to two pairs of SAs, asa publicly routable IP address (called public IP address in the sequel) and perhaps also mapping the source port used in clause 6.3, as follows:the UDP or TCP packet to another port number. In the following, the term UE_IP_address always denotes the public IP address of the UE.

NOTE: The IP addresses and ports used as selectors in IPsec tunnel mode are those of the inner IP header, in accordance with RFC 4301 [53]. The inner IP addresses are always the public IP addresses. Please also note that the terminology used here may differ from that used in other scenarios, e.g. in VPN access to a corporate network, as in the latter scenario the inner IP address is not publicly routable in general.

– IP addresses:

– inbound SA at the P‑CSCF:
The source and destination IP addresses associated with the SA are identical to those in the header of the IP packet in which the initial SIP REGISTER message was received by the P‑CSCF.

– outbound SA at the P‑CSCF:
the The source IP address bound to the outbound SA equals the destination IP address bound to the inbound SA;
the destination IP address bound to the outbound SA equals the source IP address bound to the inbound SA.

NOTE: This implies that the source and destination IP addresses in the header of the inner IP packet in which the protected SIP REGISTER message was received by the P‑CSCF need to be the same as those in the header of the IP packet in which the initial SIP REGISTER message was received by the P‑CSCF.

NOTE: This further implies that the source address in the inbound SA and the destination address in the outbound SA at the P-CSCF equals the public IP address of the UE.

– outbound SA at the UE:
The source IP address bound to the outbound SA equals the public IP address of the UE. The public IP address is learned by the UE from the received parameter in the Via header in the 401 Unauthorized response to the initial unprotected REGISTER Request (cf Section M.7.2).
The destination IP address bound to the outbound SA equals the destination IP address in the header of the IP packet in which the initial SIP REGISTER was sent to the P-CSCF.

– inbound SA at the UE:
The source IP address bound to the inbound SA equals the destination IP address bound to the outbound SA;
the destination IP address bound to the inbound SA equals the source IP address bound to the outbound SA.

NOTE: For the handling of the outer IP header in UDP encapsulated tunnel mode, see section on "Data related to the use of UDP encapsulated tunnel mode" below.

– The transport protocol selector shall allow UDP and TCP.

– Ports:

1. The P‑CSCF associates two ports, called port_ps and port_pc, with each pair of security associations established in an authenticated registration. The ports port_ps and port_pc are different from the standard SIP ports 5060 and 5061. No unprotected messages shall be sent from or received on the ports port_ps and port_pc. From a security point of view, unprotected messages may be received on any port which is different from the ports port_ps and port_pc. The number of the ports port_ps and port_pc are communicated to the UE during the security mode set-up procedure, cf. clause 7.2. These ports are used with both, UDP and TCP. The use of these ports may differ for TCP and UDP, as follows:

UDP case: the P‑CSCF receives requests and responses protected with ESP from any UE on the port port_ps (the"protected server port"). The P‑CSCF sends requests and responses protected with ESP to a UE on the port port_pc (the "protected client port").

TCP case: the P﷓-CSCF, if it does not have a TCP connection towards the UE yet, shall set up a TCP connection from its port_pc to the port port_us of the UE before sending a request to it..

NOTE: Both the UE and the P‑CSCF may set up a TCP connection from their client port to the other end’s server port on demand. An already existing TCP connection may be reused by both the P‑CSCF or the UE; but it is not mandatory.

NOTE: The protected server port port_ps stays fixed for a UE until all IMPUs from this UE are de‑registered. It may be fixed for a particular P‑CSCF over all UEs, but there is no need to fix the same protected server port for different P‑CSCFs.

NOTE: The distinction between the UDP and the TCP case reflects the different behaviour of SIP over UDP and TCP, as specified in section 18 of RFC 3261 [6].

NOTE: The handling of the protected ports is the same, irrespective of whether transport or UDP encapsulated tunnel mode is used.

2. The UE associates two ports, called port_us and port_uc, with each pair of security associations established in an authenticated registration. The ports port_us and port_uc are different from the standard SIP ports 5060 and 5061. No unprotected messages shall be sent from or received on the ports port_us and port_uc. From a security point of view, unprotected messages may be received on any port which is different from the ports port_us and port_uc. The number of the ports port_us and port_uc are communicated to the P-CSCF during the security mode set-up procedure, cf. clause 7.2. These ports are used with both, UDP and TCP. The use of these ports may differ for TCP and UDP, as follows:

UDP case: the UE receives requests and responses protected with ESP on the port port_us (the"protected server port"). The UE sends requests and responses protected with ESP on the port port_uc (the "protected client port").

TCP case: the UE, if it does not have a TCP connection towards the P‑CSCF yet, shall set up a TCP connection to the port port_ps of the P‑CSCF before sending a request to it.

NOTE: The protected server port port_us stays fixed for a UE until all IMPUs from this UE are de-registered.

NOTE: The distinction between the UDP and the TCP case reflects the different behaviour of SIP over UDP and TCP, as specified in section 18 of RFC 3261 [6]

NOTE: The handling of the protected ports is the same, irrespective of whether transport or UDP encapsulated tunnel mode is used.

3. The P‑CSCF is allowed to receive only REGISTER messages, messages relating to emergency services in accordance with TS 23.167 [31] and TS 24.229 [8], and error messages related to unprotected messages on unprotected ports. All other messages not arriving on a protected port shall be either discarded or rejected by the P‑CSCF.

4. The UE is allowed to receive only the following messages on an unprotected port:

– responses to unprotected REGISTER messages;

– messages relating to emergency services in accordance with TS 23.167 [31] and TS 24.229 [8];

– error messages related to unprotected messages.

All other messages not arriving on a protected port shall be rejected or silently discarded by the UE.

Data related to the use of UDP encapsulated tunnel mode

– Tunnel endpoint addresses and header construction for tunnel mode:

In case UDP encapsulated tunnel mode is selected, an "outer" IP header is added to protected packets exchanged between UE and P-CSCF, following the rules of tunnel mode processing according to RFC 4301 53 []. While the IP addresses of the inner IP header are as specified above in the section about "Selectors", the IP addresses of the outer IP header shall be selected as follows:

– P-CSCF:
For the outbound SA at the P-CSCF the source address shall be the IP address of the P-CSCF, the destination address shall be the public IP address of the UE. For the inbound SA only the destination address of the outer IP header is used to identify the SA at the P-CSCF, together with the SPI. This address is the IP address of the P-CSCF.

– UE:
For the outbound SA at the UE the source address shall be the local IP address of the UE, the destination address shall be the address of the P-CSCF as in the destination address of the IP header of the initial unprotected REGISTER message. For the inbound SA only the destination address of the outer IP header is used to identify the SA at the UE. This address is the local IP address of the UE.

Other data of the outer IP header (apart from IP addresses) shall be constructed as specified in RFC 4301 [53].

– Ports used in the encapsulating UDP header:

In case UDP encapsulated tunnel mode is selected, an encapsulating UDP header is inserted after the outer IP header. With respect to the ports used in the UDP header, the following rules shall be applied in accordance with standard IETF RFC 3948 [28]:

– UE:
Each protected and UDP encapsulated packet shall use port 4500 as source and destination port in the encapsulating UDP header.

– P-CSCF:
When the UE sends an UDP encapsulated packet towards the P-CSCF with the ports as described in the previous paragraph, the NAT will change the source port to a port different from 4500. This port is called port_Uenc. When the P-CSCF receives the first protected and UDP encapsulated message from the UE it shall store port_Uenc (cf. Section 7.2). From then on, all protected UDP encapsulated messages from the P-CSCF to the UE shall use port 4500 as source port and port_Uenc as destination port in the encapsulating UDP header.

The following rules apply:

1. For each unidirectional SA which has been established and has not expired, the SIP application at the P‑CSCF stores at least the following data: (UE_IP_address, UE_protected_port, P-CSCF_protected_port, SPI, IMPI, IMPU1, … , IMPUn, lifetime, mode) in an "SA_table". The pair (UE_protected_port, P-CSCF_protected_port) equals either (port_uc, port_ps) or (port_us, port_pc).

NOTE: The SPI is only required when initiating and deleting SAs in the P‑CSCF. The SPI is not exchanged between IPsec and the SIP layer for incoming or outgoing SIP messages.

2. The SIP application at the P‑CSCF shall check upon receipt of a protected REGISTER message that the source IP address in the packet headers coincide with the UE’s IP address inserted in the Via header of the protected REGISTER message. If the Via header does not explicitly contain the UE’s IP address, but rather a symbolic name then the P‑CSCF shall first resolve the symbolic name by suitable means to obtain an IP address.

3. The SIP application at the P‑CSCF shall check upon receipt of an initial REGISTER message or a re-REGISTER message that the pair (UE_IP_address, UE_protected_client_port), where the UE_IP_address is the source IP address in the packet header and the protected client port is sent as part of the security mode set-up procedure (cf. clause 7.2), has not yet been associated with entries in the "SA_table". In addition, if the P-CSCF has detected that the UE is located behind a NAT (cf. Section 7.2), the P‑CSCF shall check upon receipt of an initial (unprotected) REGISTER message, or a REGISTER message protected with UDP encapsulated tunnel mode, that the pair (UE_IP_address, UE_protected_server_port) has not yet been associated with entries in the "SA_table". Here the UE_IP_address is the source IP address in the packet header, and the protected client and server ports are sent as part of the security mode set-up procedure (cf. clause 7.2).

NOTE: In case of multiple UEs behind the same NAT, the same public IP address may be assigned by the NAT to two different UEs. Therefore, the P-CSCF shall not accept registration attempts from UEs with the same address and protected server port in order to ensure unambiguous addressing of SIP messages sent towards the UE, using the protected server port.

Furthermore, the P‑CSCF shall check that, for any one IMPI, no more than six SAs per direction are stored at any one time. If these checks are unsuccessful the registration is aborted and a suitable error message is sent to the UE.

NOTE: According to clause M.7.4 on SA handling, at most six SAs per direction may exist at a P‑CSCF for one user at any one time.

4. For each incoming protected message the SIP application at the P‑CSCF shall verify that the correct inbound SA according to clause M.7.4 on SA handling has been used. The SA is identified by the triple (UE_IP_address, UE_protected_port, P‑CSCF_protected_port) in the "SA_table". The SIP application at the P‑CSCF shall further ensure that the user associated with the SA, which was used to protect the incoming message from the UE, is identical to the user who is associated at SIP level with the message sent by the P-CSCF towards the network.

NOTE: Not all SIP messages necessarily contain public or private identities, e.g. subsequent messages in a dialogue. Other information, e.g. a dialogue identifier, may be used to associate the message with a user at SIP level.

5. For each unidirectional SA which has been established and has not expired, the SIP application at the UE stores at least the following data: (UE_IP_address, UE_protected_port, P‑CSCF_protected_port, SPI, lifetime, mode) in an "SA_table". The pair (UE_protected_port, P‑CSCF_protected_port) equals either (port_uc, port_ps) or (port_us, port_pc).

NOTE: The SPI is only required to initiate and delete SAs in the UE. The SPI is not exchanged between IPsec and the SIP layer for incoming or outgoing SIP messages.

6. When establishing a new pair of SAs (cf. clause 6.3) the SIP application at the UE shall ensure that the selected numbers for the protected ports do not correspond to an entry in the "SA_table". Furthermore, the UE should select port numbers (pseudo-)randomly from a sufficiently large set of numbers not yet allocated at the UE. When the UE receives an error message indicating a collision of a pair (IP address, port), according to rule 3 above, the UE may retry the registration with differently selected port numbers.

NOTE: The UE should select port numbers (pseudo-)randomly for two reasons:
1) to avoid collisions of pairs (IP address, port) at the P-CSCF, cf. rule 3 above.
2) to thwart a limited form of a Denial of Service attack. UMTS/LTE PS access link security also helps to thwart this attack.

NOTE: The (pseudo-)randomization of port numbers is meant for both initial registrations and re-registrations

7. For each incoming protected message the SIP application at the UE shall verify that the correct inbound SA according to clause M.7.4 on SA handling has been used. The SA is identified by the pair (UE_protected_port, P‑CSCF_protected_port) in the "SA table".

NOTE: If the integrity check of a received packet fails then IPsec will automatically discard the packet.

M.7.2 Set-up of security associations (successful case)

The set-up of security associations is based on RFC 3329 [21]. Annex H of this specification shows how to use RFC 3329 [21] for the set-up of security associations.

In this clause the normal case is specified i.e. when no failures occurs. Note that for simplicity some of the nodes and messages have been omitted. Hence there are gaps in the numbering of messages, as the I‑CSCF is omitted.

For the purpose of the description of the message processing in case UDP encapsulated tunnel mode is used, a conceptual functional element called "UDP encapsulation function" is used. The UDP encapsulation function handles all tasks relevant to the UDP encapsulation processing, i.e. the addition and removal of UDP headers to packets. In that sense it does not perform any IPsec processing as such. From an implementation point of view, it is immaterial whether the UDP encapsulation function and the IPsec processing are combined or kept separate. On the network side, the UDP encapsulation function may reside on the P-CSCF or in a separate device.

Relation of this Annex with the NAT traversal functionality specified in TS 24.229 [8]:

If the UE is located behind a NAT, the unprotected REGISTER message and the corresponding unprotected response (messages SM1 and SM6) shall be handled according to Annex F of TS 24.229 [8]. For SIP messages protected with UDP encapsulated tunnel mode, the P-CSCF shall rewrite only the SDP according to Annex F.3 of TS 24.229 [8], and shall not perform the rewriting of the SIP headers specified in Annex F.2 of TS 24.229 [8]. The P-CSCF recognises from the mode parameter in the SA table (cf. section 7.1) that UDP encapsulated tunnel mode is used.

Figure M.8

The UE sends a Register message towards the S‑CSCF to register the location of the UE and to set-up the security mode, cf. clause M.6.1. In order to start the security mode set-up procedure, the UE shall include a Security-setup-line in this message.

The Security-setup-line in SM1 contains the Security Parameter Index (SPI) values and the protected ports selected by the UE. The UE includes two unique ports (one client and one server port) and two unique SPIs (one associated to the client port, and one associated to the server port) in the REGISTER.It also contains a list of identifiers for the integrity and encryption algorithms, which the UE supports. It shall also contain the list of IPsec modes (i.e. transport and/or UDP encapsulated tunnel mode) supported by the UE.

SM1:

SPI_U is the symbolic name of a pair of SPI values (cf. clause 7.1) (spi_uc, spi_us) that the UE selects. spi_uc is the SPI of the inbound SA at UE’s the protected client port, and spi_us is the SPI of the inbound SA at the UE’s protected server port. The syntax of spi_uc and spi_us are defined in Annex H.

NOTE 1: The syntax defined in Annex H allows a large freedom of number of SPIs Only one pair of unique SPIs is included in the Security-setup

Port_U is the symbolic name of a pair of port numbers (port_uc, port_us) as defined in clause 7.1. The syntax of port_uc and port_us is defined in Annex H.

NOTE 2: The syntax defined in Annex H allows a large freedom of number of ports. Only one pair of unique ports is included in the Security-setup.

A Release 6 P‑CSCF shall propose SA alternatives for Release 5 and Release 6 UE’s since the UE may or may not support confidentiality protection. The P‑CSCF then selects the SPIs for the inbound SAs. The same SPI number shall be used for Release 5 and Release 6 options. The P‑CSCF shall define the SPIs such that they are unique and different from any SPIs as received in the Security-setup-line from the UE.

Upon receipt of SM1, the P‑CSCF temporarily stores the parameters received in the Security-setup–line together with the UE’s IP address from the source IP address of the IP packet header, the IMPI and IMPU.

If the source IP address of the IP packet header is different from the address contained in the top-most Via header, the P-CSCF concludes that the UE is located behind a NAT device parameter with the source IP address to the Via header and acts as described in Annex F of TS 24.229 [8]. In this case the P-CSCF concludes that the UE is located behind a NAT device. If the UE has not signalled support for UDP encapsulated tunnel mode in message SM1 the P-CSCF shall silently discard the message and stop performing any further steps.

Otherwise, if the source IP address of SM1 matches the UE address in the Via header, the P-CSCF concludes that the UE is not located behind a NAT. The P-CSCF then continues with the set-up of security associations as specified in section 7.2, otherwise it continues as specified in this annex.

NOTE 3: If the top-most Via header contains a domain name the P-CSCF shall perform the appropriate DNS procedures in order to retrieve the address information to be used for the comparison, as specified in Annex F of TS 24.229 [8].

Upon receipt of SM4, the P‑CSCF adds the keys IK_IM and CK_IM received from the S‑CSCF to the temporarily stored parameters.

The P‑CSCF then selects the SPIs for the inbound SAs. The P‑CSCF shall define the SPIs such that they are unique and different from any SPIs as received in the Security-setup-line from the UE.

NOTE 4: This rule is needed since the UE and the P‑CSCF use the same key for inbound and outbound traffic.

In order to determine the integrity and encryption algorithm the P‑CSCF proceeds as follows: the P‑CSCF has a list of integrity and encryption algorithms it supports, ordered by priority, cf. Annex H. Release 6 algorithms shall have higher priority than Release 5 algorithms.The P‑CSCF selects the first algorithm combination on its own list which is also supported by the UE. If the UE did not include any confidentiality algorithm in SM1 then the P-CSCF shall either select the NULL encryption algorithm or abort the procedure, according to its policy on confidentiality.

NOTE 5: It should be noted that, if the P-CSCF policy requires confidentiality, then all UEs with no encryption support would be denied access to the IMS network. This would apply in particular to UEs, which support only a Release 5-version of this specification or only GIBA according to Annex T of this specification.

The P‑CSCF then establishes two new pairs of SAs in the local security association database.

In case the P-CSCF has discovered before that the UE is located behind a NAT, it informs the UDP encapsulation function about the IPsec SA data relevant for the UDP encapsulation process. This data consists of the IP source and destination addresses of the outer IP headers and the SPIs used in all four SAs (cf. section M.6.3) established. At this point in time the UDP encapsulation function creates a table, the "UDP encapsulation table", with the following contents:

"UDP Encapsulation Table on the network side "
	SA1	SA2	SA3	SA4
Src Addr	PCSCF	UE_pub	PCSCF	UE_pub
Dest Addr	UE_pub	PCSCF	UE_pub	PCSCF
Src Port	4500	*undef*	4500	*undef*
Dest Port	*undef*	4500	*undef*	4500
SPI	SPI_us	SPI_ps	SPI_uc	SPI_pc

The P-CSCF shall use port 4500 as the source port for UDP encapsulated packets towards the UE. The P-CSCF will also receive packets from the UE with and as the destination port 4500. This is the IPsec standard port for UDP encpasulated IPsec packets (see RFC 3948 [28]). The source port for packets received by the P-CSCF from the UE and the destination port for packets sent by the P-CSCF towards the UE is not known yet and can only be learned in a later step (see below).

NOTE 6: A corresponding table on the UE side is not required as the ports used by the UE are not affected by the NAT.

The Security-setup-line in SM6 contains the SPIs and the ports assigned by the P‑CSCF. It also contains a list of identifiers for the integrity and encryption algorithms, which the P‑CSCF supports. The only exception from this is the case that the P‑CSCF is configured to never apply confidentiality. In this case, it shall not include encryption algorithms to the Security-setup-line in SM6.

Furthermore, the P-CSCF indicates the IPsec mode of operation. In case the P-CSCF detected that the UE is behind a NAT, it indicates UDP encapsulated tunnel mode, otherwise transport mode is indicated.

NOTE 7: The P‑CSCF may be configured to never apply confidentiality, e.g. because it trusts on the encryption provided by the underlying access network. In this case, the P‑CSCF acts according to Release 5 specifications, and does not include encryption algorithms to the Security-setup-line in SM6. If the P-CSCF is configured to apply confidentiality whenever the UE supports it then the P-CSCF always includes the encryption algorithms in SM6, which it supports, even if the UE did not include encryption algorithms in SM1. This is to thwart bidding down attacks.P‑CSCF may be configured to trust on the encryption provided by the underlying access network. In this case, the P‑CSCF acts according to Release 5 specifications, and does not include encryption algorithms to the Security-setup-line in SM6.

SM6:

4xx Auth_Challenge(Security-setup = SPI_P, Port_P, P‑CSCF integrity and encryption algorithms list), IPsec mode )

SPI_P is the symbolic name of the pair of SPI values (cf. clause 7.1) (spi_pc, spi_ps) that the P‑CSCF selects. spi_pc is the SPI of the inbound SA at the P‑CSCF’s protected client port, and spi_ps is the SPI of the inbound SA at the P‑CSCF’s protected server port. The syntax of spi_pc and spi_ps is defined in Annex H.

Port_P is the symbolic name of the port numbers (port_pc, port_ps) as defined in clause 7.1. The syntax of Port_P is defined in Annex H.

Upon receipt of SM6, the UE determines the integrity and encryption algorithms as follows: the UE selects the first integrity and encryption algorithm combination on the list received from the P‑CSCF in SM 6 which is also supported by the UE.

NOTE 8: Release 5 UE will not support any encryption algorithms, and will choose the first Release 5 integrity algorithm on the list received from the P‑CSCF in SM6.

The UE shall either configure UDP encapsulated tunnel mode or determine the IPsec mode according to the mode information contained in SM6. If no mode information is included in SM6, the UE shall first check whether it is located behind a NAT by checking for the presence of a "received"-parameter in the Via header of SM6. If the UE is not located behind a NAT, the UE assumes transport mode, otherwise it aborts the communication. If transport mode is used the UE continues with the set-up of security associations as specified in section 7.2, otherwise it continues as specified in this annex.

The UE then proceeds to establish two new pairs of SAs in the local SAD.

The UE shall integrity and confidentiality protect SM7 and all following SIP messages.

Furthermore the integrity and encryption algorithms list, SPI_P, and Port_P received in SM6, and SPI_U, Port_U sent in SM1 shall be included:

SM7:

If UDP encapsulated tunnel mode is used, the UE shall use the following addresses and ports in the various headers of message SM7:

SIP header:
In the Via and Contact header the UE shall use its public IP address and protected server port. The UE learns its public IP address by inspecting the received parameter in the top-most Via header included in message SM6, in case such a parameter is present.

IP and UDP/TCP headers are used as specified in M.7.1.

If UDP encapsulated tunnel mode is applied, the UE shall start sending keep alive messages according to RFC 3948 [28]. This ensures that the NAT binding is kept alive for the duration of the registration.

When SM 7 arrives at the P-CSCF it is at first processed by the UDP encapsulation function. The UDP encapsulation function can now learn port_Uenc, which the NAT has chosen for the UDP encapsulated packet. The UDP encapsulation function inserts this port in the UDP encapsulation table, so that the table is complete.

"UDP Encapsulation Table" on the network side
	SA1	SA2	SA3	SA4
Src Addr	PCSCF	UE_pub	PCSCF	UE_pub
Dest Addr	UE_pub	PCSCF	UE_pub	PCSCF
Src Port	4500	*Port_Uenc*	4500	*Port_Uenc*
Dest Port	*Port_Uenc*	4500	*Port_Uenc*	4500
SPI	SPI_us	SPI_ps	SPI_uc	SPI_pc

The UDP encapsulation function removes the UDP header from the IP packet and hands it over to the IPsec processing.

After successful IPsec processing the SIP application in the P‑CSCF shall check whether the integrity algorithms list, SPI_P and Port_P received in SM7 is identical with the corresponding parameters sent in SM6. It further checks whether SPI_U and Port_U received in SM7 are identical with those received in SM1. If these checks are not successful the registration procedure is aborted.

The P‑CSCF shall include in SM8 information to the S‑CSCF that the received message from the UE was integrity protected as indicated in clause 6.1.5. The P‑CSCF shall add this information to all subsequent REGISTER messages received from the UE that have successfully passed the integrity check in the P‑CSCF.

SM8:

The P‑CSCF finally sends SM12 to the UE. SM12 does not contain information specific to security mode setup (i.e. a Security-setup line), but with sending SM12 not indicating an error the P‑CSCF confirms that security mode setup has been successful.

After receiving SM12 not indicating an error, the UE can assume the successful completion of the security-mode setup.

An example of how to make use of two pairs of unidirectional SAs is illustrated in figure M.9 with a set of example message exchanges protected by the respective IPsec SAs where the INVITE and following messages are assumed to be carried over TCP.

Figure M.9

M.7.3 Error cases in the set-up of security associations

M.7.3.1 Error cases related to IMS AKA

The text in clause 7.3.1 applies without changes.

M.7.3.2 Error cases related to the Security-Set-up

M.7.3.2.1 Proposal unacceptable to P‑CSCF

In this case the P‑CSCF cannot accept the proposal set sent by the UE in the Security-Set-up command of SM1. The P‑CSCF shall respond to SM1 indicating a failure, by sending an error response to the UE.

M.7.3.2.2 Proposal unacceptable to UE

If the P‑CSCF sends in the security-setup line of SM6 a proposal that is not acceptable for the UE, the UE shall abandon the registration procedure.

M.7.3.2.3 Failed consistency check of Security-Set-up lines at the P‑CSCF

The P‑CSCF shall check whether authentication and encryption algorithms list received in SM7 is identical with the authentication and encryption algorithms list sent in SM6. If this is not the case the registration procedure is aborted. (Cf. clause 7.2).

M.7.3.2.4 Missing NAT traversal capabilities in the presence of a NAT

In case the P-CSCF detects the presence of a NAT, but the UE or the P-CSCF do not support NAT traversal as specified in this annex, the P-CSCF shall abort the procedure.

M.7.4 Authenticated re-registration

M.7.4.0 General

Every registration that includes a user authentication attempt produces new security associations. If the authentication is successful, then these new security associations shall replace the previous ones. This clause describes how the UE and P‑CSCF handle this replacement and which SAs to apply to which message.

When security associations are changed in an authenticated re-registration then the protected server ports at the UE (port_us) and the P‑CSCF (port_ps) shall remain unchanged, while the protected client ports at the UE (port_uc) and the P‑CSCF (port_pc) shall change. For the definition of these ports see clause 7.1.

If the UE has an already active pair of security associations, then it shall use this to protect the REGISTER message. If the S‑CSCF is notified by the P‑CSCF that the REGISTER message from the UE was integrity-protected it may decide not to authenticate the user by means of the AKA protocol. However, the UE may send unprotected REGISTER messages at any time. In this case, the S‑CSCF shall authenticate the user by means of the AKA protocol. In particular, if the UE considers the SAs no longer active at the P‑CSCF, e.g., after receiving no response to several protected messages, then the UE should send an unprotected REGISTER message.

Security associations may be unidirectional or bi-directional. This clause assumes that security associations are unidirectional, as this is the general case. For IP layer SAs, the lifetime mentioned in the following clauses is the lifetime held at the application layer. Furthermore deleting an SA means deleting the SA from both the application and IPsec layer. The message numbers, e.g. SM1, used in the following clauses relate to the message flow given in clause 6.1.1.

M.7.4.1 Void

M.7.4.1a Management of security associations in the UE

The UE shall be involved in only one registration procedure at a time, i.e. the UE shall remove any data relating to any previous incomplete registrations or authentications, including any SAs created by an incomplete authentication.

The UE may start a registration procedure with two existing pairs of SAs. These will be referred to as the old SAs. The authentication produces two pairs of new SAs. These new SAs shall not be used to protect non-authentication traffic until noted during the authentication flow. In the same way, certain messages in the authentication shall be protected with a particular SA. If the UE receives a message protected with the incorrect SA, it shall discard the message.

A successful authentication proceeds in the following steps:

– The UE sends the SM1 message to register with the IMS. If SM1 was protected, it shall be protected with the old outbound SA.

– The UE receives an authentication challenge in a message (SM6) from the P‑CSCF. This message shall be protected with the old inbound SA if SM1 was protected and unprotected otherwise.

– If this message SM6 can be successfully processed by the UE, the UE creates the new SAs, which are derived according to clause 7.1. The lifetime of the new SAs shall be set to allow enough time to complete the registration procedure. If SM1 was protected and UDP encapsulated tunnel mode is used in the old SAs, the new SAs shall also be configured in with UDP encapsulated tunnel mode. The UE then sends its response (SM7) to the P‑CSCF, which shall be protected with the new outbound SA. Meanwhile, if SM1 was protected, the UE shall use the old SAs for messages other than those in the authentication, until a successful message of new authentication is received (SM12); if SM1 was unprotected, the UE is not allowed to use IMS service until it receives an authentication successful message (SM12).

– The UE receives an authentication successful message (SM12) from the P‑CSCF. It shall be protected with the new inbound SA.

– After the successful processing of this message by the UE, the registration is complete. The UE sets the lifetime of the new SAs such that it either equals the latest lifetime of the old SAs or it will expire shortly after the registration timer in the message, depending which gives the SAs the longer life. For further SIP messages sent from UE, the new outbound SAs are used, with the following exception: when a SIP message is part of a pending SIP transaction it may still be sent over the old SA. A SIP transaction is called pending if it was started using an old SA. When a further SIP message protected with a new inbound SA is successfully received from the P‑CSCF, then the old SAs shall be deleted as soon as either all pending SIP transactions have been completed, or have timed out. The old SAs shall be always deleted when the lifetime is expired. This completes the SA handling procedure for the UE.

A failure in the authentication can occur for several reasons. If the SM1 was not protected, then no protection shall be applied to the failure messages, except the user authentication failure message which shall be protected with the new SA. If SM1 was protected, the old SAs shall be used to protect the failure messages. In both cases, after processing the failure message, the UE shall delete the new SAs.

The UE shall monitor the expiry time of registrations without an authentication and if necessary increase the lifetime of the SAs created by the last successful authentication such that it will expire shortly after the registration timer in the message.

NOTE: In particular this means that the lifetime of a SA is never decreased.

The UE shall delete any SA whose lifetime is exceeded. The UE shall delete all SAs it holds once all the IMPUs are de-registered.

M.7.4.2 Void

M.7.4.2a Management of security associations in the P‑CSCF

When the S‑CSCF initiates an authentication by sending a challenge to the UE, the P‑CSCF may already contain existing SAs from previously completed authentications. It may also contain two existing pairs of SAs from an incomplete authentication. These will be referred to as the old and registration SAs respectively. The authentication produces two pairs of new SAs. These new SAs shall not be used to protect non-authentication traffic until noted during the authentication flow. Similarly certain messages in the authentication shall be protected with a particular SA. If the P‑CSCF receives a message protected with the incorrect SA, it shall discard the message.

The P‑CSCF associates the IMPI given in the registration procedure and all the successfully registered IMPUs related to that IMPI to an SA.

A successful authentication proceeds in the following steps:

– The P‑CSCF receives the SM1 message. If SM1 is protected, it shall be protected with the old inbound SA.

– The P‑CSCF forwards the message containing the challenge (SM6) to the UE. This shall be protected with the old outbound SA, if SM1 was protected and unprotected otherwise.

– The P‑CSCF then creates the new SAs, which are derived according to clause 7.1. The expiry time of the new SAs shall be set to allow enough time to complete the registration procedure. If SM1 was protected and UDP encapsulated tunnel mode is used in the old SAs, the new SAs shall also be configured with UDP encapsulated tunnel mode. The registration SAs shall be deleted if they exist.

– The P‑CSCF receives the message carrying the response (SM7) from the UE. It shall be protected using the new inbound SA. If SM1 was protected, the old SAs are used to protect messages other than those in the authentication.

– The P‑CSCF forwards the successful registration message (SM12) to the UE. It shall be protected using the new outbound SA. This completes the registration procedure for the P‑CSCF. The P‑CSCF sets the expiry time of the new SAs such that they either equals the latest lifetime of the old SAs or it will expire shortly after the registration timer in the message, depending which gives the SAs the longer life.

– After SM12 is sent, the P‑CSCF handles the UE related SAs according to following rules:

– If there are old SAs, but SM1 belonging to the same registration procedure was received unprotected, the P‑CSCF considers error cases happened, and assumes UE does not have those old SAs for use. In this case the P‑CSCF shall remove the old SAs.

– If SM1 belonging to the same registration procedure was protected with an old valid SA, the P‑CSCF keeps this inbound SA and the corresponding three SAs created during the same registration with the UE active, and continues to use them. Any other old SAs are deleted. When the old SAs have only a short time left before expiring or a further SIP message protected with a new inbound SA is successfully received from the UE, the P‑CSCF starts to use the new SAs for outbound messages with the following exception: when a SIP message is part of a pending SIP transaction it may still be sent over the old SA. A SIP transaction is called pending if it was started using an old SA. The old SAs are then deleted as soon as all pending SIP transactions have been completed, or have timed out. The old SAs are always deleted when the old SAs lifetime are expired. When the old SAs expire without a further SIP message protected by the new SAs, the new SAs are taken into use for outbound messages. This completes the SA handling procedure for the P‑CSCF.

A failure in the authentication can occur for several reasons. If the SM1 was not protected, then no protection shall be applied to the failure messages, except the user authentication failure message which shall be protected with the new SAs. If SM1 was protected, the old SAs shall be used to protect the failure messages. In both cases, after processing the failure message, the P‑CSCF shall delete the new SAs.

The P‑CSCF shall monitor the expiry time of registrations without an authentication and if necessary increase the lifetime of SAs created by the last successful authentication such that it will expire shortly after the registration timer in the message.

The P‑CSCF shall delete any SA whose lifetime is exceeded. The P-CSCF shall delete all SAs it holds that are associated with a particular IMPI once all the associated IMPUs are de-registered.

M.7.5 Rules for security association handling when the UE changes IP address

The text in clause 7.5 applies without changes.