Network S. Dotson
Internet-Draft Cox
Intended status: Standards Track S. Hoggan
Expires: December 12, 2008 S. Channabasappa
CableLabs
June 10, 2008
Proxy Mutual Authentication in SIP
draft-dotson-sip-mutual-auth-03
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 December 12, 2008.
Dotson, et al. Expires December 12, 2008 [Page 1]
Internet-Draft Proxy Mutual Authentication in SIP June 2008
Abstract
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5. User Agent Client (UAC) Behavior . . . . . . . . . . . . . . . 8
6. User Agent Server Behavior . . . . . . . . . . . . . . . . . . 9
7. Proxy Behavior . . . . . . . . . . . . . . . . . . . . . . . . 10
8. Extensibility Considerations . . . . . . . . . . . . . . . . . 11
9. Header Field Definition . . . . . . . . . . . . . . . . . . . 12
10. Security Considerations . . . . . . . . . . . . . . . . . . . 13
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
13.1. Normative References . . . . . . . . . . . . . . . . . . 16
13.2. Informative References . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
Intellectual Property and Copyright Statements . . . . . . . . . . 18
Dotson, et al. Expires December 12, 2008 [Page 2]
Internet-Draft Proxy Mutual Authentication in SIP June 2008
1. Introduction
The Session Initiation Protocol (SIP, [RFC3261]) provides a
stateless, challenge-response based mechanism for authentication that
is based on authentication in HTTP [RFC2617]. 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] for more information on Digest authentication.
The SIP Digest mechanism parallels the HTTP Digest mechanism
specified in [RFC2617]. HTTP Digest [RFC2617] 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.
Dotson, et al. Expires December 12, 2008 [Page 3]
Internet-Draft Proxy Mutual Authentication in SIP June 2008
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, et al. Expires December 12, 2008 [Page 4]
Internet-Draft Proxy Mutual Authentication in SIP June 2008
3. Motivation
SIP ([RFC3261]) addresses User-to-User authentication and Proxy-to-
User authentication. For the UA to authenticate to a server or a
proxy, [RFC3261] specifies the Authentication and Proxy-
Authentication headers, respectively. For the UA to authenticate a
server [RFC3261] specifies the Authentication-Info header, which
allows for mutual authentication. For the UA to authenticate a proxy
[RFC3261] 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.
Dotson, et al. Expires December 12, 2008 [Page 5]
Internet-Draft Proxy Mutual Authentication in SIP June 2008
4. Overview
+--------+ +--------+ +--------+
| UAC | | Proxy | | Server |
+--------+ +--------+ +--------+
| | |
| SIP REQ (e.g., INVITE) | |
|--------------------------> | |
| | |
| 407 (Proxy Auth. Required) | |
|<-------------------------- | |
| | |
| | |
| SIP REQ (with creds) | |
|--------------------------> | |
| | SIP REQ (without creds)|
| |----------------------> |
| | SIP RESPONSE |
| SIP RESPONSE (e.g. 200 OK) |<---------------------- |
|<-------------------------- | |
|
Figure 1: Proxy-to-User Digest Authentication in SIP
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 [RFC3261] 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
Dotson, et al. Expires December 12, 2008 [Page 6]
Internet-Draft Proxy Mutual Authentication in SIP June 2008
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 [RFC2617]. 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.
Dotson, et al. Expires December 12, 2008 [Page 7]
Internet-Draft Proxy Mutual Authentication in SIP June 2008
5. User Agent Client (UAC) Behavior
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].
Dotson, et al. Expires December 12, 2008 [Page 8]
Internet-Draft Proxy Mutual Authentication in SIP June 2008
6. User Agent Server Behavior
UAS behavior is unaffected by this specification.
Dotson, et al. Expires December 12, 2008 [Page 9]
Internet-Draft Proxy Mutual Authentication in SIP June 2008
7. Proxy Behavior
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], 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]
that were not specified in [RFC2069].
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.
Dotson, et al. Expires December 12, 2008 [Page 10]
Internet-Draft Proxy Mutual Authentication in SIP June 2008
8. Extensibility Considerations
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], and is not
altered by this document.
Dotson, et al. Expires December 12, 2008 [Page 11]
Internet-Draft Proxy Mutual Authentication in SIP June 2008
9. Header Field Definition
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 is an extension to Table 3 of [RFC3261] 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
Dotson, et al. Expires December 12, 2008 [Page 12]
Internet-Draft Proxy Mutual Authentication in SIP June 2008
10. 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, et al. Expires December 12, 2008 [Page 13]
Internet-Draft Proxy Mutual Authentication in SIP June 2008
11. IANA Considerations
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.
Dotson, et al. Expires December 12, 2008 [Page 14]
Internet-Draft Proxy Mutual Authentication in SIP June 2008
12. Acknowledgements
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.
Dotson, et al. Expires December 12, 2008 [Page 15]
Internet-Draft Proxy Mutual Authentication in SIP June 2008
13. References
13.1. Normative References
[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.
13.2. Informative References
[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.
Dotson, et al. Expires December 12, 2008 [Page 16]
Internet-Draft Proxy Mutual Authentication in SIP June 2008
Authors' Addresses
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
Dotson, et al. Expires December 12, 2008 [Page 17]
Internet-Draft Proxy Mutual Authentication in SIP June 2008
Full Copyright Statement
Copyright (C) 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.
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.
Dotson, et al. Expires December 12, 2008 [Page 18]