Internet DRAFT - draft-dotson-sip-certificate-auth
draft-dotson-sip-certificate-auth
SIP S. Dotson
Internet-Draft CableLabs
Intended status: Standards Track November 6, 2007
Expires: May 9, 2008
Certificate Authentication in SIP
draft-dotson-sip-certificate-auth-04
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 9, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Dotson Expires May 9, 2008 [Page 1]
Internet-Draft Certificate Authentication in SIP November 2007
Abstract
This document defines requirements for adding certificate
authentication to the Session Initiation Protocol (SIP). The use
case addressed is that of a SIP device authenticating on behalf of
configured users using a device certificate for purposes such as
registration. This document is being presented with the intention of
providing requirements to any potential solutions specifying
certificate authentication within SIP networks. Supporting
certificate authentication in SIP would provide strong authentication
and increase the types of possible deployment scenarios.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6
2. Existing Work . . . . . . . . . . . . . . . . . . . . . . . . 7
3. Requirements and Recommendations . . . . . . . . . . . . . . . 10
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
5. Security Considerations . . . . . . . . . . . . . . . . . . . 13
6. Normative References . . . . . . . . . . . . . . . . . . . . . 14
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15
Intellectual Property and Copyright Statements . . . . . . . . . . 16
Dotson Expires May 9, 2008 [Page 2]
Internet-Draft Certificate Authentication in SIP November 2007
1. Introduction
SIP enables many real-time IP communications architectures. While it
offers many advantages, it is restrictive regarding the types of
credentials supported. As of this writing, it only provides for
username and pre-shared key based credentials. The lack of stronger
credential types, specifically certificate-based credentials, is
restricting certain deployment scenarios and the advantages that can
be realized by them.
Certificates have been successfully deployed in many networks, such
as PacketCable. They offer two distinct advantages, among others,
over username and password based credentials:
o They provide relatively stronger authentication, for example, when
compared to usernames and passwords (as used commonly)
o They allow authentication in scenarios where the clients are not
pre-configured in the SIP network (using the Public Key
Infrastructure, PKI)
Thus, SIP deployments would greatly benefit from certificate-based
authentication in SIP networks. However, this requires careful
consideration. This document presents such considerations,
requirements, and recommendations. It does not present any
solutions, which are considered out-of-scope for this document.
1.1. Overview
The sections in the document mirror the work that was done to create
the document. The use cases that were the catalyst for the document
are described. The use cases in turn drove the requirements.
Existing standardized solutions were then evaluated to determine
their ability to meet the requirements.
1.2. Use Cases
The primary use case for the requirements discussed in this document
is that of a UA registering with a SIP Registrar, where the UA has
only a certificate for authentication to the network, or possibly
multiple credentials with one credential being a certificate. The
following diagram shows the message flows during a registration as
currently defined in RFC 3261 [RFC3261].
Dotson Expires May 9, 2008 [Page 3]
Internet-Draft Certificate Authentication in SIP November 2007
User SIP Server
| |
| REGISTER |
|------------------------------>|
| |
| 401 Unauthorized |
|<------------------------------|
| |
| REGISTER |
|------------------------------>|
| |
| 200 OK |
|<------------------------------|
| |
In this call flow, a user sends a SIP REGISTER request to the SIP
Server which includes the user's identity. The SIP server provides a
challenge to the user. The user uses the challenge and its
credentials to create a challenge response and sends this back to the
SIP server. The SIP server validates the user's credentials.
There may be multiple proxies between the UA and the Registrar. In
this case, the UA needs to be able to authenticate with the Registrar
using a public certificate. The following figure uses the previous
example with the addition of an intermediate proxy.
User Proxy Server SIP Server
| | |
| REGISTER | REGISTER |
|------------------------------>|--------------------------->|
| | |
| 401 Unauthorized | 401 Unauthorized |
|<------------------------------|<---------------------------|
| | |
| REGISTER | REGISTER |
|------------------------------>|--------------------------->|
| | |
| 200 OK | 200 OK |
|<------------------------------|<---------------------------|
| | |
In this example, a proxy server is situated between the User and the
SIP Server. The proxy does not have access to the user's
subscription data. If confidentiality is used, the User and Proxy
Dotson Expires May 9, 2008 [Page 4]
Internet-Draft Certificate Authentication in SIP November 2007
would terminate the confidentiality protection.
In regards to the entity being authenticated, there are several
deployment scenarios that can be readily identified.
o The entity may be a device, in which case the certificate would
contain information related to the device identity (e.g., MAC
address, FQDN, etc).
o The entity may be a user, in which case the certificate would
contain information related to the user identity (e.g., SIP URI,
etc).
For the purposes of this document, only the device certificate use
case is considered. The registrar contains information mapping the
unique device identification asserted in the certificate to
authorized SIP identities for that device. These identities can then
be mapped to users of the device, or user devices connected to the
device such as phone handsets, as shown in the following figure.
Authentication
<======================>
+--------+
| Phone | +------------+
| Alice |--------| | +-------+ +-----------+
+--------+ | | | | | |
| SIP Device |-------| Proxy |-------| Registrar |
+--------+ | | | | | |
| Phone |--------| | +-------+ +-----------+
| Bob | +------------+
+--------+
SIP Device Authentication
In this example, the SIP device would authenticate on behalf of
configured users (e.g., Alice, Bob) to the registrar using its device
certificate. The registrar would return the authorized SIP
identities for that device (e.g., alice@foo.com, bob@foo.com). These
identities could then be mapped by the SIP device to different phone
lines. The proxy would then be responsible for ensuring only
authorized SIP identities are sourced from the SIP device.
Dotson Expires May 9, 2008 [Page 5]
Internet-Draft Certificate Authentication in SIP November 2007
1.3. 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].
This document borrows SIP related terminology as specified in RFC
3261 [RFC3261].
Certificate: A PKIX [RFC3280] style certificate containing a public
key and a list of identities in the subjectAltName that are bound to
this key.
End entity: User of X.509 certificates and/or end user system that is
represented by the certificate.
Dotson Expires May 9, 2008 [Page 6]
Internet-Draft Certificate Authentication in SIP November 2007
2. Existing Work
Currently, RFC 3261 [RFC3261] defines procedures for performing SIP
Digest authentication using usernames and passwords. SIP Digest is a
challenge based mechanism for authentication. Any time a UA or proxy
server receives a request it may challenge the initiator of the
request to provide assurance of its identity.
SIP 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. Because it
is based on passwords, it suffers from the security weaknesses of
password based systems.
The genesis for this document was the lack of an existing solution
for authentication from a UA to a registrar using a public key
certificate within SIP messaging. While there are mechanisms related
to SIP and certificates, and SIP and authentication, none of these,
as currently specified, are able to meet all the requirements of this
document. The following existing solutions were reviewed:
o TLS
o SIP S/MIME
o AIB
o SIP Identity
o SIP Security Agreement
Following is an analysis of existing work in the IETF in relation to
the requirements presented in this document.
RFC 4346 [RFC4346] describes Transport Layer Security (TLS) between a
client and a server. TLS provides privacy and data integrity between
two communiticating applications. TLS is currently required to be
supported by RFC 3261 [RFC3261] proxy servers and registrars. Mutual
TLS could be performed between the UA and it's nearest proxy in order
to authenticate the UA to the proxy, and the proxy could then assert
the identity of the UA through SIP Identity [RFC4474] or RFC 4474
[RFC3325] P-Asserted-Identity headers to the registrar. In this
model, the edge proxy performing the authentication is part of the
Dotson Expires May 9, 2008 [Page 7]
Internet-Draft Certificate Authentication in SIP November 2007
operator's trusted network.
o Because device certificates contain the identity of a device
(e.g., MAC address), and the registrar contains the mapping of
device certificate to authorized identities, extra signaling from
proxy to registrar may be needed in order to convey the device
identity from the certificate to the registrar.
o RFC 3261 [RFC3261] does not define the use of client certificates
for mutual TLS and SIP.
RFC 3261 [RFC3261] discusses the use of S/MIME and certificates to
provide confidentiality, integrity and authentication of UAs. The
procedures are based on the use of the CMS content types signedData,
for signing messages, and enveloped data, for encrypting data.
o S/MIME is not based on challenge/response, requiring the UA to
always send dialog requests S/MIME protected. This is even more
of an issue where authentication of non-REGISTERs (e.g., INVITEs)
is desired.
o RFC 3261 [RFC3261] does not define the use of using S/MIME to
authenticate a UA to a registrar.
o S/MIME may have issues with network intermediaries that must view
or modify the bodies of SIP messages (especially SDP).
o S/MIME does not have a means to negotiate authentication methods
(assuming the authentication would be between the UA and
registrar, and a UA may contain multiple credential types).
RFC 3893 [RFC3893] Authenticated Identity Body (AIB) Format defines a
more specific mechansim than the S/MIME solution in RFC 3261
[RFC3261]. It changes the MIME type and reduces the number of
headers included in the cryptographic operation from those
recommended in RFC 3261. As the solution is similar to RFC 3261
S/MIME in relation to the requirements in this document, the solution
has the same deficiencies as S/MIME described in the previous
paragraph.
RFC 4474 [RFC4474] SIP Identity provides a mechanism to
cryptographically assure the identity of originators of SIP messages.
As described in Section 5, Identity uses a private key and a
certificate associated with the domain indicated in the From header.
An authentication service authenticates the UAC and then inserts an
Identity header and an Identity-Info header in the forwarded request.
Dotson Expires May 9, 2008 [Page 8]
Internet-Draft Certificate Authentication in SIP November 2007
The Authentication Service is typically located at the outbound proxy
and may authenticate the UAC using digest authentication and/or a TLS
session.
o Identity is not based on challenge/response, requiring the UA to
always send dialog requests protected. This is even more of an
issue where authentication of non-REGISTERs (e.g., INVITEs) is
desired.
o Unless the UA is directly connected to the Authentication Service,
TLS is not available to the UA to perform mutual TLS to the
Authentication Service.
o Identity requires the Authentication Service to be authoritative
for a domain, and this is typically not supported on a UA as the
UA would need to be its own domain.
RFC 3329 [RFC3329] Security Mechanism Agreement for the Session
Initiation Protocol (SIP) describes a mechanism for a user agent and
its next-hop SIP entity to negotiate security mechanisms. RFC 3329
[RFC3329] may be used to enable confidentiality of messaging for the
solution between a client and its next-hop SIP server, but it is not
a solution in itself.
Dotson Expires May 9, 2008 [Page 9]
Internet-Draft Certificate Authentication in SIP November 2007
3. Requirements and Recommendations
The following are the general requirements and recommendations for
the support of certificate based authentication in SIP networks. A
proposed solution MUST meet all the requirements stated in this
section.
1. The solution MUST utilize SIP messaging and be compliant to RFC
3261 [RFC3261].
2. Depending on the solution, it MAY need to follow a challenge/
response paradigm, to allow the network to decide the policy for
authentication (i.e., keep the client from always computing and
sending authentication data).
3. The solution MUST provide end-to-end authentication. One example
is the authentication between UAs and Registrars during a
registration that includes intermediate proxies. In this case,
the registrar must receive enough information to ensure the
authenticity of the client and the authorization of the client to
receive service.
4. A device certificate MUST represent an end entity that will be
authenticated. The certificate MUST contain enough information
that allows the end entity to be identified. RFC 2818 [RFC2818]
contains some rules on end entity authentication that may be
utilized in the solution.
5. Relying parties MUST check the validity of certificates as
defined in RFC 3280 [RFC3280].Relying parties MAY use the
additional rules of RFC 2818 [RFC2818] to validate end entity
certificates.
6. The solution MUST support client-only authentication and mutual
authentication modes. Client-only authentication modes could be
employed when mutual authentication is achieved by other means
(e.g., TLS).
The following are the recommendations that should be considered when
developing a solution that complies with this document.
1. This document RECOMMENDS that solutions consider a way for the
entities to agree on the authentication to be used. This would
allow for the coexistence and the use of multiple authentication
mechanisms. Exceptions include solutions that do not allow for
the use of multiple credentials.
Dotson Expires May 9, 2008 [Page 10]
Internet-Draft Certificate Authentication in SIP November 2007
2. The methodology SHOULD consider message size impacts and SHOULD
attempt to limit them. Bandwidth constrained environments may be
impacted.
3. The solution SHOULD re-use existing standards and solutions where
applicable.
Dotson Expires May 9, 2008 [Page 11]
Internet-Draft Certificate Authentication in SIP November 2007
4. IANA Considerations
None.
Dotson Expires May 9, 2008 [Page 12]
Internet-Draft Certificate Authentication in SIP November 2007
5. Security Considerations
This document defines the requirements for certificate-based
authentication within SIP. As such, it does not define a specific
solution or set of technologies. However, the eventual technical
architecture meeting these requirements must consider the security of
the solution.
Depending on the solution, confidentiality and integrity of messages
may be necessary. Replay protection must be provided.
Dotson Expires May 9, 2008 [Page 13]
Internet-Draft Certificate Authentication in SIP November 2007
6. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[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.
[RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
X.509 Public Key Infrastructure Certificate and
Certificate Revocation List (CRL) Profile", RFC 3280,
April 2002.
[RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private
Extensions to the Session Initiation Protocol (SIP) for
Asserted Identity within Trusted Networks", RFC 3325,
November 2002.
[RFC3329] Arkko, J., Torvinen, V., Camarillo, G., Niemi, A., and T.
Haukka, "Security Mechanism Agreement for the Session
Initiation Protocol (SIP)", RFC 3329, January 2003.
[RFC3893] Peterson, J., "Session Initiation Protocol (SIP)
Authenticated Identity Body (AIB) Format", RFC 3893,
September 2004.
[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.1", RFC 4346, April 2006.
[RFC4474] Peterson, J. and C. Jennings, "Enhancements for
Authenticated Identity Management in the Session
Initiation Protocol (SIP)", RFC 4474, August 2006.
Dotson Expires May 9, 2008 [Page 14]
Internet-Draft Certificate 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 9, 2008 [Page 15]
Internet-Draft Certificate 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 9, 2008 [Page 16]
