SIP S. Dotson Internet-Draft CableLabs Intended status: Standards Track November 11, 2007 Expires: May 14, 2008 Proxy Mutual Authentication in SIP draft-dotson-sip-mutual-auth-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on May 14, 2008. Copyright Notice Copyright (C) The IETF Trust (2007). Dotson Expires May 14, 2008 [Page 1] Internet-Draft Proxy Mutual Authentication in SIP November 2007 Abstract This document defines updates to the Session Initiation Protocol (SIP) to add mutual authentication to proxy authentication. The Proxy-Authentication-Info header, which allows a UA to authenticate a proxy when challenged, is not defined in SIP ([RFC 3261]). Supporting mutual proxy authentication in SIP would mitigate certain risks in using SIP Digest proxy authentication. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 5 4. Changes Required . . . . . . . . . . . . . . . . . . . . . . . 6 4.1. Section 20 . . . . . . . . . . . . . . . . . . . . . . . . 6 4.1.1. Table 3 . . . . . . . . . . . . . . . . . . . . . . . 6 4.1.2. New Subsection . . . . . . . . . . . . . . . . . . . . 6 4.1.3. 22.4 Last Paragraph . . . . . . . . . . . . . . . . . 6 4.1.4. 25.1 . . . . . . . . . . . . . . . . . . . . . . . . . 6 4.1.5. 25.1 . . . . . . . . . . . . . . . . . . . . . . . . . 7 5. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 8 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 6.1. Registration of new SIP header fields . . . . . . . . . . 9 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 9. Normative References . . . . . . . . . . . . . . . . . . . . . 12 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13 Intellectual Property and Copyright Statements . . . . . . . . . . 14 Dotson Expires May 14, 2008 [Page 2] Internet-Draft Proxy Mutual Authentication in SIP November 2007 1. Introduction Using the process defined in [I-D.drage-sip-essential-correction], this document describes a correction to the Session Initiation Protocol (SIP), defined in [RFC3261]. 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. Dotson Expires May 14, 2008 [Page 3] Internet-Draft Proxy Mutual Authentication in SIP November 2007 2. Terminology 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 [RFC2119]. Dotson Expires May 14, 2008 [Page 4] Internet-Draft Proxy Mutual Authentication in SIP November 2007 3. Problem Statement Currently, [RFC3261] defines procedures for performing SIP Digest authentication using usernames and passwords. SIP Digest, based on HTTP Digest [RFC2617], 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 [RFC2617] defines the following headers used during proxy authentication: o Proxy-Authenticate header: used by the proxy to challenge the user o Proxy-Authorization header: used by the user to send a challenge response to the proxy in order for the proxy to authenticate the user o 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 [RFC2617], 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 [RFC3261], however the Proxy-Authentication-Info header was not defined. Dotson Expires May 14, 2008 [Page 5] Internet-Draft Proxy Mutual Authentication in SIP November 2007 4. Changes Required 4.1. Section 20 4.1.1. Table 3 Table 3 needs to be updated to add a row for the new header: Proxy-Authentication-Info 2xx ar - o - o o o 4.1.2. New Subsection 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" 4.1.3. 22.4 Last Paragraph 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. 4.1.4. 25.1 In the "message header" section of BNF, the following line needs to be added between the "Proxy-Authenticate" header and the "Proxy- Authorization" header: Dotson Expires May 14, 2008 [Page 6] Internet-Draft Proxy Mutual Authentication in SIP November 2007 / Proxy-Authentication-Info 4.1.5. 25.1 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: Proxy-Authentication-Info = "Proxy-Authentication-Info" HCOLON painfo *(COMMA painfo) painfo = nextnonce / message-qop / response-auth / cnonce / nonce-count nextnonce = "nextnonce" EQUAL nonce-value response-auth = "rspauth" EQUAL response-digest response-digest = LDQUOT *LHEX RDQUOT Dotson Expires May 14, 2008 [Page 7] Internet-Draft Proxy Mutual Authentication in SIP November 2007 5. Open Issues 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. Dotson Expires May 14, 2008 [Page 8] Internet-Draft Proxy Mutual Authentication in SIP November 2007 6. IANA Considerations 6.1. Registration of new SIP header fields 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 Dotson Expires May 14, 2008 [Page 9] Internet-Draft Proxy Mutual Authentication in SIP November 2007 7. Security Considerations 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. Dotson Expires May 14, 2008 [Page 10] Internet-Draft Proxy Mutual Authentication in SIP November 2007 8. Acknowledgements 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. Dotson Expires May 14, 2008 [Page 11] Internet-Draft Proxy Mutual Authentication in SIP November 2007 9. Normative References [I-D.drage-sip-essential-correction] Drage, K., "A Process for Handling Essential Corrections to the Session Initiation Protocol (SIP)", draft-drage-sip-essential-correction-01 (work in progress), I-D Status expired, March 2007. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and L. Stewart, "HTTP Authentication: Basic and Digest Access Authentication", RFC 2617, June 1999. [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. Dotson Expires May 14, 2008 [Page 12] Internet-Draft Proxy Mutual Authentication in SIP November 2007 Author's Address Steve Dotson CableLabs 858 Coal Creek Circle Louisville, CO 80027 US Email: s.dotson@cablelabs.com Dotson Expires May 14, 2008 [Page 13] Internet-Draft Proxy Mutual Authentication in SIP November 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Dotson Expires May 14, 2008 [Page 14]