Proxy Mutual Authentication in SIP

Using the process defined in , this document describes a correction to the Session Initiation Protocol (SIP), defined in . The change is the addition of the Proxy-Authentication-Info header to the current list of supported SIP headers. The Proxy-Authentication-Info header provides a challenged UA with the information necessary to authenticate the proxy, enabling mutual authentication.

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.

Currently, defines procedures for performing SIP Digest authentication using usernames and passwords. SIP Digest, based on HTTP Digest , utilizes a challenge-response authentication mechanism that may be used by a server to challenge a client request and by a client to provide authentication information. The Digest scheme challenges using a nonce value. A valid response contains a checksum of the password, username, the provided nonce value, and other parameters. As a result, the password is never sent in the clear. SIP Digest provides authentication and replay detection. HTTP Digest defines the following headers used during proxy authentication: Proxy-Authenticate header: used by the proxy to challenge the user Proxy-Authorization header: used by the user to send a challenge response to the proxy in order for the proxy to authenticate the user Proxy-Authentication-Info header: used by the proxy to send a challenge response to the user in order for the user to authenticate the proxy As described in , the transactions for proxy authentication are very similar to digest authentication for server authentication, which uses the WWW-Authenticate, Authorization, and Authentication-Info headers. Upon receiving a request which requires authentication, the proxy issues a "407 Proxy Authentication Required" response with a "Proxy-Authenticate" header. The challenge used in the Proxy-Authenticate header is the same as that for the WWW-Authenticate header. The client must then re-issue the request with a Proxy-Authorization header, which is the same as that for the Authorization header. The Proxy-Authentication-Info header defined for SIP in this document, is sent along with 2xx responses from the proxy to the client during proxy authentication. The response digest in the "response-auth" directive supports mutual authentication - the proxy proves that it knows the user's secret. The Proxy-Authentication-Info header directives are calculated as those for the Authentication-Info header. The Authentication-Info header is defined for SIP digest authentication in , however the Proxy-Authentication-Info header was not defined.

Table 3 needs to be updated to add a row for the new header: Proxy-Authentication-Info 2xx ar - o - o o o

A new subsection is needed in Section 20, similar to Sections 20.27 and 20.28 to describe the header: The Proxy-Authentication-Info header field provides for mutual authentication with HTTP Digest. A UAS MAY include this header field in a 2xx response to a request that was successfully authenticated using digest based on the Proxy-Authorization field. Syntax and semantics follow those specified in RFC 2617 [17]. Example: Proxy-Authentication-Info: nextnonce="47364c23432d2e131a5fb210812c"

This paragraph is replaced entirely by RFC 2543 did not allow usage of the Authentication-Info or Proxy-Authentication-Info header fields (it effectively used RFC 2069). However, we now allow usage of these header fields, since they provide integrity checks over the bodies and provide mutual authentication. RFC 2617 [17] defines mechanisms for backwards compatibility using the qop attribute in the request. These mechanisms MUST be used by a server to determine if the client supports the new mechanisms in RFC 2617 that were not specified in RFC 2069.

In the "message header" section of BNF, the following line needs to be added between the "Proxy-Authenticate" header and the "Proxy-Authorization" header: / Proxy-Authentication-Info

In the header definition section of the BNF, the following message header BNF needs to be added for the Proxy-Authentication-Info header between the "Proxy-Authenticate" header and the "Proxy-Authorization" header:

This document contains the following open issues: Does the Proxy-Authentication-Info header need to be added to the list of headers in section 23.4.1.2, 4th paragraph.

This document defines a new SIP header field "Proxy-Authentication-Info". Name of header: Proxy-Authentication-Info Short form: none Registrant: Steve Dotson s.dotson@cablelabs.com Normative description: Section 4 of this document

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.

The author would like to thank Keith Drage and Dean Willis for their assistance in the process for this change, and Sumanth Channabasappa for review and comments.