Proxy Mutual Authentication in SIP

The Session Initiation Protocol (SIP, ) provides a stateless, challenge-response based mechanism for authentication that is based on authentication in HTTP . A proxy or a user receiving a request can challenge the initiator of the request to obtain assurance of the originator's identity. A UAS, registrar, or redirect server can use 401 (Unauthorized), where as proxies use 407 (Proxy Authentication Required), for authentication challenges. Challenges result in a resend of the requests with the digest authentication information that can be used to verify the authenticity of the originator. The two parties share a username and password to support this authentication mechanism. Refer to for more information on Digest authentication. The SIP Digest mechanism parallels the HTTP Digest mechanism specified in . HTTP Digest also allows for mutual authentication by allowing the client to authenticate the challenging entity, such as a proxy. Mutual authentication is facilitated via two headers: Authentication-Info for mutual authentication with a server, and Proxy-Authentication-Info for authentication with a proxy. These headers may be used by the challenging entities, server or proxy, to send challenge responses for authentication by the client. SIP specifies and allows for the usage of the Authentication-Info header by a server, but does not mention the Proxy-Authentication-Info header. This document presents an extension to allow for the use of the Proxy-Authentication-Info header. The header can be sent along with 2xx responses from the proxy to the client during digest authentication. The response digest in the "response-auth" directive allows the client to authenticate the proxy, i.e., it ensures that the proxy has knowledge of the password. This provides for mutual authentication when proxies challenge clients, and provides for limited integrity protection. It also allows for the Proxy to provide additional information such as the nonce value to use for a future authentication response.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

SIP () addresses User-to-User authentication and Proxy-to-User authentication. For the UA to authenticate to a server or a proxy, specifies the Authentication and Proxy-Authentication headers, respectively. For the UA to authenticate a server specifies the Authentication-Info header, which allows for mutual authentication. For the UA to authenticate a proxy does not specify an equivalent header. TLS can be used in such cases if the UA wishes to authenticate the next-hop proxy. However, in deployments where multiple proxies are involved in the messaging path (e.g., 3GPP IMS) the UA will not be able to use TLS to authenticate proxies located beyond the first hop. To allow for deployments where there is a need for the UA to mutually authenticate with proxies other than the next-hop, this document specifies the Proxy-Authentication-Info header. In addition to mutual authentication, the header also allows for the optimization of digest authentication procedures by allowing the proxy to indicate the nonce to be used by the UA for future authentication responses.

| | | | | | 407 (Proxy Auth. Required) | | |<-------------------------- | | | | | | | | | SIP REQ (with creds) | | |--------------------------> | | | | SIP REQ (without creds)| | |----------------------> | | | SIP RESPONSE | | SIP RESPONSE (e.g. 200 OK) |<---------------------- | |<-------------------------- | | | ]]> xref target="ProxyToUserDigestAuthenticationInSIP"/> provides a sample message flow when the proxy challenges a client's request using digest authentication with SIP. As illustrated, the client sends a request that is challenged by the proxy via a 407 (Proxy Authentication Required) response. The client then uses the information provided in the challenge (refer to for details) to prepare a response (to the challenge). The client then resends the request, and this time it includes the challenge response. If the response to the challenge authenticated the client, the proxy removes the response and forwards the request to the server. When the server replies, such as with a 200 OK message, the proxy forwards that reply to the client. This allows for the proxy to authenticate the client. However, it neither allows for the proxy to send additional information regarding the successful authentication such as the nonce to use for a future authentication response, nor does it allow for a client to authenticate the proxy. This is in contrast to when the challenging entity is a server, since it can accomplish both - additional authentication information and mutual authentication - via the Authentication-Info header. This document proposes the inclusion of the Proxy-Authentication-Info header to address this deficiency in Proxy-to-User authentication scenarios. The header parallels a header of the same name for HTTP, as specified in . The header is used by the proxy during Proxy-to-User authentication to allow for mutual authentication and additional authentication information. Further, since it is possible that multiple proxies exist in the authentication signaling path a SIP proxy must preserve any Proxy-Authentication-Info header field values that are present in a downstream response message.

When this header field is included by a Proxy within the 2xx response, the requirements are the same as those of a client receiving an Authentication-Info header field from a Server, as specified in .

UAS behavior is unaffected by this specification.

A Proxy MAY include this header field in a 2xx response to a request that was successfully authenticated using digest based on the Authorization header field. Syntax and semantics follow those specified in , which also defines mechanisms for backwards compatibility using the qop attribute in the request. These mechanisms MUST be used by a proxy to determine if the client supports the new mechanisms in that were not specified in . Example: Proxy-Authentication-Info: nextnonce="47364c23432d2e131a5fb210812c The proxy SHOULD at least include the 'qop', 'cnonce', 'nc', and 'rspauth' parameters in the Proxy-Authentication-Info header field. When forwarding a response from downstream that contains one or more Proxy-Authentication-Info header fields, a proxy MUST include those fields in a Proxy-Authentication-Info header in the forwarded response.

This document introduces the Proxy-Authentication-Info header that may be sent from a proxy to a client during authentication. If present, it provides an opportunity for the client to authenticate the proxy, enabling mutual authentication. A proxy that is not compliant with this specification will not include the header. However, implementors need to understand that without the specified header mutual authentication may not be possible within Proxy-to-User authentication as specified by SIP. Additionally, the presence of this header allows for the proxy to indicate the nonce to be used by the client during a future authentication response. If the nextnonce field is present the client SHOULD use it when constructing the Proxy-Authorization header for its next request. This document does not alter this requirement. However, implementers need to understand that the failure of the client to act on the nextnonce field may result in a request to re-authenticate from the proxy with the "stale=TRUE". This behavior is specified in , and is not altered by this document.

The grammar for the Proxy-Authentication-Info header is defined as follows:

is an extension to Table 3 of for the Proxy-Authentication-Info header:

This document defines a SIP message header that provides mutual authentication during proxy authentication of a UA. When challenged by a proxy or server to perform authentication (e.g., after sending an INVITE or SUBSCRIBE request), the Proxy-Authorization header provides the proxy with proof the UA knows the correct credentials for the identity being used. By adding support for the Proxy-Authentication-Info header, proxies may provide UAs with a challenge response to prove to the UA it also knows the correct credentials. The use case most affected is where the proxy/server performing the challenge is not the next-hop proxy/server of the UA. When the proxy/server is the next-hop proxy/server for the UA, TLS should be relied upon instead of this mechanism, as a malicious next-hop proxy or Man-in-The-Middle (MITM) could merely not challenge the UA, or simply not use the optional Proxy-Authorization-Info header. This header is most meaningful in environments where the UA is expecting (i.e., is configured) to perform mutual authenitication - malicious entities would be forced to prove knowledge of the UAs credentials, adding an additional layer of defense.

This document defines a new SIP header field "Proxy-Authentication-Info". Name of header: Proxy-Authentication-Info Short form: none Registrant: Sumanth Channabasappa, sumanth@cablelabs.com Normative description: RFCXXXX Note to RFC Editor: Please replace XXXX with the RFC number for this document.

The authors would like to thank Scott Lawrence from Pingtel for his feedback that lead to the support of multiple Proxy-Authentication-Info header field values. Thanks also to Wolf Dietrich Moeller from Nokia Siemens Networks and Francois Audet from Nortel. The authors are also appreciative of the assistance provided by Dean Willis and Keith Drage.