9 IMC

33.2033G Security3GPPAccess security for IP-based servicesTS

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

This clause identifies requirements on the IMC to support IMS access security. The IMC is used to enable access using IMS AKA. The IMC may be used for IMS access by a non-3GPP-only terminal when specified in the access specific annexes of this specification. The IMC shall not used if ISIM or USIM is present.

NOTE 1: a non-3GPP-only terminal is a terminal that does not support 3GPP access technology.

This clause does not identify any data or functions that may be required on the IMC for non-security purposes. The IMC shall not be part of ISIM, USIM nor SIM.

The IMC shall include:

– The IMPI;

– At least one IMPU;

– Home Network Domain Name;

– Support for sequence number checking in the context of the IMS Domain;

– The same framework for algorithms as specified in TS 33.102 [1];

– An authentication key.

Annex A (informative):
Void

Annex B (informative):
Void

Annex C (informative):
Void

Annex D (informative):
Void

Annex E (informative):
Void

Annex F (informative):
Void

Annex G (informative):
Management of sequence numbers

The example sequence number management schemes in TS 33.102 [1] Informative Annex C can be used to ensure that the authentication failure rate due to synchronization failures to kept sufficiently low when the same sequence number mechanism and data is used for authentication in the PS/CS domains and in the IMS. This can be done by enhancing the method for the allocation of index values in the AuC/HSS so that authentication vectors distributed to different service domains shall always have different index values (i.e. separate ranges of index values are reserved for PS, CS and IMS operation). The AuC/HSS is required to obtain information about which type of service node has requested the authentication vectors. Reallocation of array elements to the IMS domain can be done in the AuC/HSS with no changes required to already deployed USIMs.

As the possibility for out of order use of authentication vectors within the IMS service domain may be quite low, the number of PS or CS array elements that need to be reallocated to the IMS domain could be quite small. This means that the ability to support out of order authentication vectors within the PS and CS domains would not be significantly affected.

Sequence number management is operator specific and for some proprietary schemes over the air updating of the UICC may be needed.

Annex H (normative):
The use of "Security Mechanism Agreement for SIP Sessions" [21] for security mode set-up

The BNF syntax of RFC 3329 [21] is defined for negotiating security associations for semi-manually keyed IPsec or TLS in the following way:

security-client = "Security-Client" HCOLON sec-mechanism *(COMMA sec-mechanism)

security-server = "Security-Server" HCOLON sec-mechanism *(COMMA sec-mechanism)

security-verify = "Security-Verify" HCOLON sec-mechanism *(COMMA sec-mechanism)

sec-mechanism = mechanism-name *(SEMI mech-parameters)

mechanism-name = "ipsec-3gpp" / "tls"

mech-parameters = ( preference / algorithm / protocol / mode / encrypt-algorithm / spi‑c / spi‑s / port‑c / port‑s )

preference = "q" EQUAL qvalue

qvalue = ( "0" [ "." 0*3DIGIT ] ) / ( "1" [ "." 0*3("0") ] )

algorithm = "alg" EQUAL ("hmac-sha-1-96" / "aes-gmac" / "null" )

protocol = "prot" EQUAL ( "ah" / "esp" )

mode = "mod" EQUAL ( "trans" / "tun" / "UDP-enc-tun" )

encrypt-algorithm = "ealg" EQUAL ("aes-cbc" / "aes-gcm" / "null" )

spi‑c = "spi‑c" EQUAL spivalue

spi‑s = "spi‑s" EQUAL spivalue

spivalue = 10DIGIT; 0 to 4294967295

port‑c = "port‑c" EQUAL port

port‑s = "port‑s" EQUAL port

port = 1*DIGIT

The changes compared to RFC 3329 [21] are:

"alg" parameter: Addition of "aes-gmac" and "null". Removal of "hmac-md5-96"

"ealg" parameter: Addition of "aes-cbc" and "aes-gcm". Removal of "des-ede3-cbc"

"mod" parameter: Addition of "UDP-enc-tun"

"Hmac-sha-1-96" and "aes-cbc" are not recommended.

The use of security association parameters is specified in clauses 7.1, 7.2, M.7.1 and M.7.2 of the present document. The parameters described by the BNF above have the following semantics:

Mechanism-name: For manually keyed IPsec, this field includes the value "ipsec-3gpp". "ipsec‑3gpp" mechanism extends the general negotiation procedure of RFC 3329 [21] in the following way:

1 The server shall store the Security-Client header received in the request before sending the response with the Security-Server header.

2 The client shall include the Security-Client header in the first protected request. In other words, the first protected request shall include both Security-Verify and Security-Client header fields.

3 The server shall check that the content of Security-Client headers received in previous steps (1 and 2) are the same.

Mech-parameters: Of the mech-parameters, only preference is relevant when the mechanism-name has the value "tls".

Preference: As defined in RFC 3329 [21].

Algorithm: Defines the authentication algorithm. The algorithm parameter is mandatory. The value "aes-gmac" refers to the authentication algorithm ENCR_NULL_AUTH_AES_GMAC defined in IETF RFC 4543 [74]. The value "null" shall only be used with encryption algorithm "aes-gcm".

Protocol: Defines the IPsec protocol. May have a value "ah" or "esp". If no Protocol parameter is present, the value will be "esp".

NOTE 1: According to clause 6 only "esp" (RFC 4303 [54]) is allowed for use in IMS.

Mode: Defines the mode in which the IPsec protocol is used. May have a value "trans" for transport mode, and value "tun" for tunneling mode. If no Mode parameter is present, the value will be "trans".

NOTE 2: Void.

Encrypt-algorithm: If present, defines the encryption algorithm. The value "aes-cbc" refers to the algorithm defined in IETF RFC 3602 [22]. The value "aes-gcm" refers to the encryption algorithm AES-GCM with a 16 octet ICV defined in IETF RFC 4106 [73]. If no Encrypt-algorithm parameter is present, the algorithm will be "null". The value "aes-gcm" shall only be used with authentication algorithm equal to "null".

Spi‑c: Defines the SPI number of the inbound SA at the protected client port.

Spi‑s: Defines the SPI number of the inbound SA at the protected server port.

Port‑c: Defines the protected client port.

Port‑s: Defines the protected server port.

It is assumed that the underlying IPsec implementation supports selectors that allow all transport protocols supported by SIP to be protected with a single SA.

Annex I (normative):
Key expansion functions for IPsec ESP

Integrity Keys:

If the selected authentication algorithm is HMAC-SHA-1-96 then IK_ESP is obtained from IK_IM by appending 32 zero bits to the end of IK_IM to create a 160‑bit string.

If selected authentication algorithm is AES-GMAC as specified in RFC 4543 [74] with 128 bit key then IK_ESP = IK_IM.

The salt value specified in Section 3.2 of RFC 4543 [74] shall be derived using the key derivation function KDF defined in Annex B of TS 33.220 [66]. The input Key to the KDF function shall be equal to the concatenation of CK_IM and IK_IM: CK_IM || IK_IM. The input S to the KDF function shall be formed from the following parameters:

– FC = 0x58.

– P0 = "AES_GMAC_SALT" .

– L0 = length of the string “AES_GMAC_SALT” (i.e. 0x00 0x0D).

The salt value shall consist of the 32 least significant bits of the 256 bits of the KDF output.

"Hmac-sha-1-96" is not recommended.

Encryption Keys:

If selected encryption algorithm is AES‑CBC as specified in RFC 3602 [22] with 128 bit key then CK_ESP = CK_{IM .}

If selected encryption algorithm is AES‑GCM as specified in RFC 4106 [73] with 128 bit key then CK_ESP = CK_IM. The salt value specified in Section 4 of RFC 4106 [73] shall be derived using the key derivation function KDF defined in Annex B of TS 33.220 [66]. The input Key to the KDF function shall be equal to the concatenation of CK_IM and IK_IM: CK_IM || IK_IM. The input S to the KDF function shall be formed from the following parameters:

– FC = 0x59

– P0 = “AES_GCM_SALT”

– L0 = length of the string “AES_GCM_SALT” (i.e. 0x00 0x0C)

The salt value shall consist of the 32 least significant bits of the 256 bits of the KDF output.

"aes-cbc" is not recommended.

Annex J (informative):
Recommendations to protect the IMS from UEs bypassing the P‑CSCF

After the UE does a successful SIP REGISTER with the P‑CSCF, malicious UE could try to send SIP messages directly to the S‑CSCF. This could imply that the UE would be able to bypass the integrity protection provided by IPsec ESP between the UE and the P‑CSCF.

NOTE: The TS 24.229 [8] defines a trust domain that consists of the P‑CSCF, the I‑CSCF, the S‑CSCF, the BGCF, the MGCF, the MRFC and all the AS:s that are not provided by 3rd party service providers. There are nodes in the edge of the trust domain that are allowed to provide with an asserted identity header. The nodes in the trust domain will trust SIP messages with asserted identity headers. The asserted identity information is useful as long as the interfaces in an operator’s network can be trusted.

If a UE manages to bypass the P‑CSCF it presents at least the following problems:

1) The P‑CSCF is not able to generate any charging information.

2) Malicious UE could masquerade as some other user (e.g. it could potentially send INVITE or BYE messages).

The following recommendations for preventing attacks based on such misbehavior are given:

– Access to S‑CSCF entities shall be restricted to the core network entities that are required for IMS operation, only. It shall be ensured that no UE is able to directly send IP packets to IMS-entities other than the required ones, ie. assigned P‑CSCF, or HTTP servers.

– Impersonation of IMS core network entities at IP level (IP spoofing), especially impersonation of P‑CSCFs by UEs shall be prevented.

– It is desirable to have a general protection mechanism against UEs spoofing (source) IP addresses in any access network providing access to IMS services.

If the traffic is between two non‑IMS CSCFs, it is recommended to use TLS mechanisms as specified in RFC 3261 [6]. This will mitigate the problems caused by misbehaviour of the UE. TLS certificate management as outlined in TS 33.310 [24] can be used between two non-IMS CSCFs. If neither intra‑CSCF traffic nor CSCF-SEG traffic can be trusted and if this traffic is not protected by the NDS/IP, TS 33.210 [5] mechanisms, then physical protection measures or IP traffic filtering should be applied. This is anyhow not in the scope of 3GPP specification.

Annex K (informative):
Void

Annex L (normative):
Application to fixed broadband access