N.1 SIP Digest

33.2033G Security3GPPAccess security for IP-based servicesTS

SIP Digest authentication and the requirements in this Annex shall not apply to access networks defined in 3GPP specifications. The P-CSCF can enforce this condition by identifying REGISTER requests relating to SIP Digest according to the rules in Annex P.3 of the present document and discarding them when received over an access network defined in 3GPP specifications.

The provisions in Annex N are optional for implementation. The provisions in Annex N are optional for use. However, the use of one of the authentication mechanisms in the present document is mandated.

SIP Digest shall not be used in conjunction with IPsec.

NOTE 1: The use of SIP Digest in conjunction with IPsec, as specified in the main body and in Annex N of this specification, is technically impossible because SIP Digest does not generate session keys for use with IPsec security associations.

An additional scheme for authentication is SIP Digest as specified in RFC 3261 [6]. SIP Digest achieves mutual authentication between the UE and the HN, and is based on HTTP Digest as specified in RFC 7616 [76]. The identity used for authenticating a subscriber is the private identity, IMPI, which has the form of a NAI. The HSS and the UE share a preset secret (e.g., a password) associated with the IMPI. The generation of the authentication challenge shall be done in the same way as specified in RFC 7616 [76] and the present document.

It is the policy of the HN that decides if an authentication shall take place for the registration of an additional IMPU that is not part of the already registered set of IMPUs associated with the same IMPI.

If a UE supports SIP Digest as well as further authentication methods, the UE shall proceed as follows:

– If the access network is of a type defined in 3GPP specifications then the UE shall not select SIP Digest, in accordance with the requirement at the start of this clause.

NOTE 2: The rules listed in Annex T of this specification say how a UE can select between IMS AKA and GIBA.

– If the access network is of a type not defined in 3GPP specifications then

– if both the UE and network support IMS AKA according to the main body or Annex M of this specification, as determined by the use of sip-sec-agree RFC 3329 [21], the authentication method shall be IMS AKA;

– otherwise the authentication method shall be SIP Digest as specified in Annex N of this specification.