Q.3 Strengths and boundary conditions for the use of authentication mechanisms for non-registration messages

33.2033G Security3GPPAccess security for IP-based servicesTS

– TLS:

During the set-up phase SIP Digest with TLS is somewhat weaker than IMS AKA with IPsec because the client end of the TLS tunnel is authenticated by means of the password-based Digest mechanism, and not the UICC-based AKA mechanism, and because the session keys are cryptographically tied to authentication with IMS AKA, which is not the case for SIP Digest with TLS. But once the TLS tunnel has been set up securely, the strengths of TLS and IPsec are comparable, and no attacks, except attacks on the security of endpoint platforms, seem feasible. TLS requires TCP and does not work for UDP.

– SIP Digest proxy-authentication:

This mechanism is weaker than TLS or IPsec because the message origin authentication relies on a message authentication code (the Digest response in the Proxy-Authorization header), which is not cryptographically tied to the body nor to the header of the SIP message. (Note that qop = auth-int, which would at least provide a cryptographic tie with the message body, cannot be used in the IMS context.) Therefore, certain man-in-the-middle attacks are theoretically conceivable where an attacker could “steal” a Digest response from one message and append it to another. These attacks may, however, be impractical in many deployment scenarios so that the SIP Digest proxy-authentication provides sufficient security in these scenarios. An attacker being only able to spoof source IP address and port would not be able to break SIP Digest proxy-authentication.

There would be no technical problem in using SIP Digest proxy-authentication together with TLS, but the only security advantage would be increased home control, in case the P-CSCF is in a visited network.

– IP address check:

This mechanism has two main benefits:

– One benefit of the IP address check mechanism is for operators who would otherwise rely entirely on link layer security. If only link layer security was provided then an attacker, although correctly authenticated at the link layer, could spoof SIP addresses and impersonate another IMS user. The IP address check provides the missing link between lower layers and SIP layer to prevent this kind of attack. Reasons why operators may not want to use TLS or SIP Digest proxy-authentication may include clients not supporting these mechanisms, need for server certificates (in the TLS case) or performance.

– Another benefit of the IP address check mechanism is that the existing mechanism for identity assertion in the P-CSCF can be used in the same way as for IMS AKA with IPsec, cf. above.

However, the IP address check mechanism has to fulfill additional boundary conditions to work securely. If there is uncertainty about the boundary conditions of a given environment it is recommended to use TLS or SIP Digest proxy-authentication.

– An attacker being able to spoof source IP address and port of another registered user can break this mechanism. Therefore, this mechanism can only be used in environments where IP address and port spoofing occurs neither in the public access network nor on the customer premises. In this sense, the IP address check mechanism is weaker than SIP Digest proxy-authentication.

– When the IP address check mechanism is not used in conjunction with managing of client-initiated connections as defined in RFC 5626 [32], then only the IP address is associated with the user’s identities, cf. Annex N.2. In this case, it is additionally required to ensure that two different users cannot share the same IP address. An example of when this could happen would be when a UE not fully compliant to Annex N does not use support for managing client-initiated connections, although it sits behind a NAT, and the P-CSCF does not realise that there is a NAT. Hence the requirement in Annex N.2 that “the P-CSCF should only accept a register request without support for managing client-initiated connections if it can determine that no NAT is present in the signaling path between the UE and the P-CSCF”. Another example would be two users sharing the same machine with one IP address, and not using support for managing client-initiated connections. It depends on the environment whether the additional requirement in this bullet can be fulfilled.

– It may happen that a UE loses connection without being able to deregister in the IMS, and the access network consequently re-assigns the IP address to another user, or a NAT re-assigns the port to another user. To cover such cases, Annex N states that the P-CSCF shall overwrite any existing entry in the IP address check table when a new registration with a different IMPI, but the same IP address (and port, if applicable) is successfully performed. In the absence of malicious attacks the IP address check mechanism then works correctly.

– An attacker may try to exploit IP address and port re-assignment as follows: he repeatedly attaches to the network hoping to be assigned the IP address or port of another user who dropped off without deregistering in IMS. If this indeed happens then any non-registration message sent by the attacker would be accepted by the IP address check mechanism in the P-CSCF as coming from the previous user. The attacker does not attempt to register in IMS as he would not be able to send a correct SIP Digest response. This possibility of attack seems difficult to exploit, but again, the likelihood for success depends on the environment.

Annex R (normative):
NASS-IMS-bundled authentication