TOC |
|
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 August 25, 2008.
This document defines the Proxy-Authentication-Info header field for the Session Initiation Protocol (SIP). When a UA is required to authenticate to a proxy using digest authentication specified in SIP this header field allows for the UA to authenticate the proxy, enabling mutual authentication. This header field can also provide integrity checks over the bodies.
1.
Introduction
2.
Terminology
3.
Overview
4.
User Agent Client (UAC) Behavior
5.
User Agent Server Behavior
6.
Proxy Behavior
7.
Extensibility Considerations
8.
Header Field Definition
9.
Security Considerations
10.
IANA Considerations
11.
Acknowledgements
12.
References
12.1.
Normative References
12.2.
Informative References
§
Authors' Addresses
§
Intellectual Property and Copyright Statements
TOC |
The Session Initiation Protocol (SIP, [RFC3261] (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.)) provides a stateless, challenge-response based mechanism for authentication that is based on authentication in HTTP [RFC2617] (Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and L. Stewart, “HTTP Authentication: Basic and Digest Access Authentication,” June 1999.). 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 [RFC3261] (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.) for more information on Digest authentication.
The SIP Digest mechanism parallels the HTTP Digest mechanism specified in [RFC2617] (Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and L. Stewart, “HTTP Authentication: Basic and Digest Access Authentication,” June 1999.). HTTP Digest [RFC2617] (Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and L. Stewart, “HTTP Authentication: Basic and Digest Access Authentication,” June 1999.) 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.
TOC |
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 (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.) [RFC2119].
TOC |
+--------+ +--------+ | UAC | | Proxy | +--------+ +--------+ | | | SIP REQ (e.g., INVITE) | |--------------------------> | | | | 407 (Proxy Auth. Required) | |<-------------------------- | | | | | | SIP REQ (with creds) | |--------------------------> | | | | 200 OK | |<-------------------------- | | |
Figure 1: Proxy-to-User Digest Authentication in SIP |
TOC |
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 [RFC3261] (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.).
TOC |
UAS behavior is unaffected by this specification.
TOC |
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 [RFC2617] (Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and L. Stewart, “HTTP Authentication: Basic and Digest Access Authentication,” June 1999.), 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 [RFC2617] (Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and L. Stewart, “HTTP Authentication: Basic and Digest Access Authentication,” June 1999.) that were not specified in [RFC2069] (Franks, J., Hallam-Baker, P., Hostetler, J., Leach, P., Luotonen, A., Sink, E., and L. Stewart, “An Extension to HTTP : Digest Access Authentication,” January 1997.).
Example:
Proxy-Authentication-Info: nextnonce="47364c23432d2e131a5fb210812c
TOC |
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 [RFC2617] (Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and L. Stewart, “HTTP Authentication: Basic and Digest Access Authentication,” June 1999.), and is not altered by this document.
TOC |
The grammar for the Proxy-Authentication-Info header is defined as follows:
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
Figure 2 (Extension to Table 3) is an extension to Table 3 of [RFC3261] (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.) for the Proxy-Authentication-Info header:
Header field where proxy ACK BYE CAN INV OPT REG Proxy-Authentication-Info 2xx o - o - o o -
Figure 2: Extension to Table 3 |
TOC |
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.
TOC |
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.
TOC |
The author would like to thank Keith Drage and Dean Willis for their assistance in the process for this change.
TOC |
TOC |
[RFC2119] | Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” BCP 14, RFC 2119, March 1997 (TXT, HTML, XML). |
[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 (TXT, HTML, XML). |
[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 (TXT). |
TOC |
[RFC2069] | Franks, J., Hallam-Baker, P., Hostetler, J., Leach, P., Luotonen, A., Sink, E., and L. Stewart, “An Extension to HTTP : Digest Access Authentication,” RFC 2069, January 1997 (TXT). |
TOC |
Steve Dotson | |
Cox | |
1400 Lake Hearn Drive | |
Atlanta, GA 30319 | |
US | |
Email: | steve.dotson@cox.com |
Stuart Hoggan | |
CableLabs | |
858 Coal Creek Circle | |
Louisville, CO 80027 | |
US | |
Email: | s.hoggan@cablelabs.com |
Sumanth Channabasappa | |
CableLabs | |
858 Coal Creek Circle | |
Louisville, CO 80027 | |
US | |
Email: | sumanth@cablelabs.com |
TOC |
Copyright © The IETF Trust (2008).
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.
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.