SIP S. Dotson
Internet-Draft CableLabs
Intended status: Standards Track February 4, 2007
Expires: August 8, 2007
SIP Certificate Authentication Solution
draft-dotson-sip-certificate-auth-sol-00.txt
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 August 8, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Dotson Expires August 8, 2007 [Page 1]
Internet-Draft SIP Certificate Authentication Solution February 2007
Abstract
This document specifies SIP Certificate Authentication (SCA), a
challenge-response mechanism that uses public key cryptography to
perform certificate-based authentication in Session Initiation
Protocol (SIP) based architectures. Performing authentication in SIP
with certificates will provide stronger authentication capabilities
and increase possible deployment scenarios in SIP networks. The
scope is limited to the authentication of the SIP UA to the SIP
Service Provider's network. It does not include UA to UA
authentication within its scope.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. SIP Certificate Authentication Requirements . . . . . . . . . 5
3.1. Overall Operation . . . . . . . . . . . . . . . . . . . . 5
4. Specification of SCA Headers . . . . . . . . . . . . . . . . . 6
4.1. WWW-Authenticate Response Header . . . . . . . . . . . . . 6
5. SCA Operation . . . . . . . . . . . . . . . . . . . . . . . . 7
5.1. Client Authentication . . . . . . . . . . . . . . . . . . 7
5.2. Mutual Authentication . . . . . . . . . . . . . . . . . . 8
5.3. Creating a Challenge Response . . . . . . . . . . . . . . 8
6. Security Protocol Negotiation . . . . . . . . . . . . . . . . 10
7. Certificates . . . . . . . . . . . . . . . . . . . . . . . . . 11
7.1. Certificate Validation . . . . . . . . . . . . . . . . . . 11
7.2. Certificate Profile . . . . . . . . . . . . . . . . . . . 11
8. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
9. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 14
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
11. Security Considerations . . . . . . . . . . . . . . . . . . . 16
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
13. Normative References . . . . . . . . . . . . . . . . . . . . . 18
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 19
Intellectual Property and Copyright Statements . . . . . . . . . . 20
Dotson Expires August 8, 2007 [Page 2]
Internet-Draft SIP Certificate Authentication Solution February 2007
1. Introduction
SIP enables many next generation multimedia 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
additional credential types, specifically certificate based
credentials, is restricting certain deployment scenarios and the
advantages that can be realized by them.
Certificate based credentials offer relatively stronger
authentication, for example, when compared to username and passwords
(as used commonly). They are currently in successful use within
various deployment scenarios (such as cable) where each client is
pre-configured with certificates that are used for identification,
authentication and establishing secure communications. While this
offers many advantages, the most prominent is the ability to
authenticate certificates without pre-configuration of each
certificate in the Service Provider's network (for example, by using
Public Key Infrastructure).
Currently, SIP RFC 3261 [RFC3261] defines procedures for Digest
authentication using a username/password. Digest Authentication is
vulnerable to dictionary attacks and requires a shared secret be
distributed to the endpoint and the authenticating device.
This document defines a technical solution for adding certificate
authentication to the Session Initiation Protocol (SIP). This
solution addresses requirements for SIP UA authentication to a SIP
network and does not address any authentication requirements between
SIP UAs.
Dotson Expires August 8, 2007 [Page 3]
Internet-Draft SIP Certificate Authentication Solution February 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].
This document borrows SIP related terminology as specified in RFC
3261 [RFC3261].
certificate - electronic binding of an identity to a public key which
is contained in the certificate.
certificate authority - A trusted entity responsible for issuing
certificates that bind identities to the public and private keys of
an end entity.
digital signature - Digital signatures utilize public key
cryptography and one-way hash functions to produce a signature of the
data that can be authenticated, and is difficult to forge or
repudiate.
public key cryptography - A class of cryptographic techniques
employing two-key ciphers. Messages encrypted with the public key
can only be decrypted with the associated private key. Conversely,
messages signed with the private key can be verified with the public
key.
Dotson Expires August 8, 2007 [Page 4]
Internet-Draft SIP Certificate Authentication Solution February 2007
3. SIP Certificate Authentication Requirements
3.1. Overall Operation
SCA is based on a challenge-response paradigm. Upon being
challenged, the UAC must prove its identity to the SIP Service
Provider entity, (e.g., registrar), and if mutual authentication is
desired, the SIP Service Provider entity must prove its identity to
the UAC. Each element will have public/private key pairs and a
certificate binding the public key to an identity.
1. The client and server each establish public/private key pairs and
digital certificates signed by a trusted party.
2. The client sends a request to the server.
3. The server sends an authentication request to the client. The
request includes a random challenge, as well as data the client
can use to determine whether it has the server's certificate and
other certificates if the Public Key Infrastructure (PKI) is
employed.
4. The client uses the data sent from the server as well as data
created by the client to generate a challenge response.
5. The client sends the challenge response and client generated data
to the server.
6. The server authenticates the client by generating its own
challenge response using the server and client generated data and
compares its result with that sent in the challenge response by
the client. If the two match, the client has been authenticated.
7. If the client is successfully authenticated, a message is sent to
the client informing the client. If mutual authentication is
configured on the server, the server will also include a
challenge response of its own to prove its identity to the
client.
NOTE: ladder diagram would be helpful
Dotson Expires August 8, 2007 [Page 5]
Internet-Draft SIP Certificate Authentication Solution February 2007
4. Specification of SCA Headers
SCA is similar to that of HTTP Digest in order to minimize changes to
SIP Digest clients and sessions. The formats of the modified WWW-
Authenticate header line, the Authorization header line, and the
Authentication-Info header line are specified below.
4.1. WWW-Authenticate Response Header
If a SIP registrar requiring authentication receives a REGISTER
request and an acceptable Authorization header is not sent, the
registrar responds with a "401 Unauthorized" status code, and a WWW-
Authenticate header as per the framework defined above.
algorithm
A string indicating the algorithm used to produce the challenge
response. This specification only defines one value: 'rsa-sha1'.
qop-options
This directive is mandatory. It is a string of one or more tokens
indicating the "quality of protection" values supported by the
server. The value "auth" indicates authentication; the value "auth-
int" indicates authentication with integrity protection; see the
descriptions in a later section for calculating the response
directive value for the application of this choice. Unrecognized
options MUST be ignored.
NOTE: should we use shorter names like rsa-sha1 as used in Identity?
NOTE: For now, just including the parameters that are different from
RFC 2617
Dotson Expires August 8, 2007 [Page 6]
Internet-Draft SIP Certificate Authentication Solution February 2007
5. SCA Operation
In order to harmonize with existing solutions for SIP authentication
defined in RFC 2617 [RFC2617] and RFC 3310 [RFC3310], SCA follows the
challenge response paradigm. Instead of shared secrets, SCA relies
on certificates for authentication, and thus the creation of the
challenge response is based on public key cryptography.
5.1. Client Authentication
During the registration process, the client generates Authorization
headers as defined in RFC 3261 and thus RFC 2617 to prove its
identity to the server. It includes the username, realm, and nonce
parameters in the Authorization header. When the client receives a
challenge in the form of a "401 Unauthorized" status code and a WWW-
Authenticate header as defined in RFC 2617 with the additional
requirements in clause 4.1. The client extracts the nonce and qop
values from the WWW-Authenticate header provided by the server. The
client creates a response to the challenge as specified in a later
section. The resulting response is used as the value of the request-
digest parameter in the Authorization header sent to the server in
response to the challenge.
Upon receiving the Authorization header, the server may check the
validity of the certificate used for the response calculation. Then,
the server must perform the same cryptographic operation performed by
the client, and compare the result to the response provided by the
client. A client should remember the username, nonce, nonce count,
opaque values and server certificate associated with the registration
session in order to construct the Authorization header in future
registrations.
The Authorization header may be included preemptively in order to
improve efficiency and avoid extra round trips for authentication
challenges. Based on the servers policy for nonce generation and
management, the use of nextnonce allows the client to preemptively
generate an Authorization header with the correct request-digest
value. If the server receives old Authorization data, the server may
choose to accept it even though the nonce value might not be fresh.
Alternatively, the server may return a 401 response with a new nonce
value, causing the client to retry the request through the use of the
stale parameter. By sending the stale parameter with a value of TRUE
with the response, the client is instructed to retry with the new
nonce, but without prompting for a new username and password.
Dotson Expires August 8, 2007 [Page 7]
Internet-Draft SIP Certificate Authentication Solution February 2007
5.2. Mutual Authentication
Mutual authentication is provided by the "response-auth" directive in
the Authentication-Info header of Digest. The server proves its
identity to the client in a similar manner as client authentication.
The server uses its private key to sign and hash a string of data
made up of parameters present in the authentication session. With
qop=auth-int, it also provides integrity protection of the response.
The "response-digest" value is calculated as for the "request-digest"
in the Authorization header for client authentication, except if
"qop=auth", A2 is
A2 = ":" digest-uri-value
and if "qop=auth-int", then A2 is
A2 = ":" digest-uri-value ":" H(entity-body)
where "digest-uri-value" is the value of the "Request-URI" directive
(as defined in RFC 3261) on the Authorization header in the request.
The "cnonce-value" and "nc-value" MUST be the ones for the client
request to which this message is the response. The "response-auth",
"cnonce", and "nonce-count" directives MUST be present.
5.3. Creating a Challenge Response
The value of request-digest is calculated by creating a string of
data that is then digitally signed using the specified algorithm. In
this document, in order to remain consistent with RFC 2617, the
string obtained by applying the algorithm to the data "data" will be
denoted by KD(data)and the string obtained by applying the hash
algorithm to the data "data" will be denoted H(data). The notation
unq(X) means the value of the quoted-string X without the surrounding
quotes.
request-digest = <"> < KD ( unq(username-value)
":" unq(realm-value)
":" unq(nonce-value)
":" nc-value
":" unq(cnonce-value)
":" unq(qop-value)
Dotson Expires August 8, 2007 [Page 8]
Internet-Draft SIP Certificate Authentication Solution February 2007
":" H(A2) ) > <">
If the "qop" directive's value is "auth" or is unspecified, then A2
is:
A2 = Method ":" digest-uri-value
If the "qop" directive's value is "auth-int", then A2 is:
A2 = Method ":" digest-uri-value ":" H(entity-body)
The requirements related to the parameters used in SCA follow those
defined in RFC 2617 with the differences defined in RFC 3261.
Once the data string is formed, it MUST be hashed and signed with
private key of the client. The algorithm used for hashing and
signing is specified in the WWW-Authenticate header. This document
defines only one "algorithm" value: 'rsa-sha1';. All implementations
of this specification MUST support 'rsa-sha1'. When the 'rsa-sha1'
algorithm is specified in the "algorithm" parameter of WWW-
Authenticate, the request-digest value MUST be generated as follows:
compute the results of signing the string of data with
sha1WithRSAEncryption as described in [RFC3370] and base64 encode the
results as specified in [RFC3548]. A 1024-bit or longer RSA key MUST
be used. The result is placed in the request-digest field of the
Authorization header.
Dotson Expires August 8, 2007 [Page 9]
Internet-Draft SIP Certificate Authentication Solution February 2007
6. Security Protocol Negotiation
Because an additional authentication scheme is being added to SIP,
the server must know which security scheme a client supports. Each
username must only be associated to one credential. Clients
supporting multiple credentials must send the appropriate username in
the Authorization header for the desired credential. In this manner,
the registrar knows which type of authentication to utilize and there
is no signaling required.
Dotson Expires August 8, 2007 [Page 10]
Internet-Draft SIP Certificate Authentication Solution February 2007
7. Certificates
This implementation utilizes X509v3 certificates as defined in
[RFC3280]. The IETF PKIX working group [RFC3280] also defines
certificate profiles and key and cryptographic formats. Certificates
MUST be obtained from trusted Certificate Authorities. The means for
requesting certificates is out of the scope of this document.
7.1. Certificate Validation
Certificates MUST be validated as per the path validation rules
described in RFC 3280 [RFC3280]. These procedures include verifying
the certificate has not expired, it has not been revoked, and it
chains back up to a trusted Certificate Authority.
7.2. Certificate Profile
When a key usage extension is present, the digtalSignature and
keyEncipherment bits MUST be set. Other certificate profile details
are left to implementations.
Dotson Expires August 8, 2007 [Page 11]
Internet-Draft SIP Certificate Authentication Solution February 2007
8. Example
NOTE: needs more work
The following example shows a REGISTER dialogue between a UAC and a
Registrar using a certificate to authenticate the UAC.
The UAC sends a REGISTER request to the Registar:
REGISTER sips:ss2.biloxi.example.com SIP/2.0
Via: SIP/2.0/TLS client.biloxi.example.com:5061;branch=z9hG4bKnashds7
Max-Forwards: 70
From: Bob <sips:bob@biloxi.example.com>;tag=a73kszlfl
To: Bob <sips:bob@biloxi.example.com>
Call-ID: 1j9FpLxk3uxtm8tn@biloxi.example.com
CSeq: 1 REGISTER
Contact: <sips:bob@client.biloxi.example.com>
Content-Length: 0
SIP/2.0 401 Unauthorized Via: SIP/2.0/TLS client.biloxi.example.com:
5061;branch=z9hG4bKnashds7;received=192.0.2.201
From: Bob <sips:bob@biloxi.example.com>;tag=a73kszlfl
To: Bob <sips:bob@biloxi.example.com>;tag=1410948204
Call-ID: 1j9FpLxk3uxtm8tn@biloxi.example.com
CSeq: 1 REGISTER
WWW-Authenticate: Digest realm="atlanta.example.com", qop=auth,
nonce="ea9c8e88df84f1cec4341ae6cbe5a359",
opaque="", stale=FALSE, algorithm=rsa-sha1
Content-Length: 0
REGISTER sips:ss2.biloxi.example.com SIP/2.0
Via: SIP/2.0/TLS client.biloxi.example.com:5061;branch=z9hG4bKnashd92
Max-Forwards: 70
From: Bob <sips:bob@biloxi.example.com>;tag=ja743ks76zlflH
To: Bob <sips:bob@biloxi.example.com>
Call-ID: 1j9FpLxk3uxtm8tn@biloxi.example.com
CSeq: 2 REGISTER
Contact: <sips:bob@client.biloxi.example.com>
Authorization: Digest username="bob", realm="atlanta.example.com"
nonce="ea9c8e88df84f1cec4341ae6cbe5a359", opaque="", qop=auth,
uri="sips:ss2.biloxi.example.com", algorithm=rsa-sha1,
cnonce="ea9c8e88df84f1cec4341ae6cbe5a359",
response="dfe56131d1958046689d83306477ecc"
Content-Length: 0
SIP/2.0 200 OK
Via: SIP/2.0/TLS client.biloxi.example.com:
5061;branch=z9hG4bKnashd92;received=192.0.2.201
Dotson Expires August 8, 2007 [Page 12]
Internet-Draft SIP Certificate Authentication Solution February 2007
From: Bob <sips:bob@biloxi.example.com>;tag=ja743ks76zlflH
To: Bob <sips:bob@biloxi.example.com>;tag=37GkEhwl6
Call-ID: 1j9FpLxk3uxtm8tn@biloxi.example.com
CSeq: 2 REGISTER
Contact: <sips:bob@client.biloxi.example.com>;expires=3600
Authentication-Info: Digest qop=auth,
response-digest="dfe56131d1958046689d83306477ecc",
cnonce="ea9c8e88df84f1cec4341ae6cbe5a359"
Content-Length: 0
Dotson Expires August 8, 2007 [Page 13]
Internet-Draft SIP Certificate Authentication Solution February 2007
9. Open Issues
o Should we be doing "HTTP Authentication with Certificates" vs.
SIP, since SIP relies so heavily on the procedures in RFC 2617?
o Certificates section - may need more detail on different sections
o Security considerations section development
o Decide if how endpoints obtain necessary certificates for
validation is in scope or not, and if so, develop solution (in-
band, out-of-band, both, etc.) There appear to be a couple of
options and available methods for ensuring other end has certs
needed for validation:
* Both client and server are provisioned with necessary
certificates.
* Complete certificate chain is sent from client to server each
time, and cert-hint from server to client results in some
action at the client to retrieve cert if it doesn't have it.
* URI of cert is provided by client and server
* SIP has mechanism for passing certs for S/MIME
* SIP certs
o Instead of doing H(A2) as per Digest for message integrity, should
we instead use optional encryption in addition to the signing
o TLS section?
o Error Codes
o Name and acronym for solution
Dotson Expires August 8, 2007 [Page 14]
Internet-Draft SIP Certificate Authentication Solution February 2007
10. IANA Considerations
None.
Dotson Expires August 8, 2007 [Page 15]
Internet-Draft SIP Certificate Authentication Solution February 2007
11. Security Considerations
To be filled in (nonce creation/mgt., private key protection,
prevention of standard attacks, something on trust, availability of a
UI for certificate mgt., etc.)
Dotson Expires August 8, 2007 [Page 16]
Internet-Draft SIP Certificate Authentication Solution February 2007
12. Acknowledgements
Many thanks to Dan Wing for early feedback and text for the signing
section.
Dotson Expires August 8, 2007 [Page 17]
Internet-Draft SIP Certificate Authentication Solution February 2007
13. 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.
[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.
[RFC3310] Niemi, A., Arkko, J., and V. Torvinen, "Hypertext Transfer
Protocol (HTTP) Digest Authentication Using Authentication
and Key Agreement (AKA)", RFC 3310, September 2002.
[RFC3370] Housley, R., "Cryptographic Message Syntax (CMS)
Algorithms", RFC 3370, August 2002.
[RFC3548] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 3548, July 2003.
[RFC3852] Housley, R., "Cryptographic Message Syntax (CMS)",
RFC 3852, July 2004.
[RFC3893] Peterson, J., "Session Initiation Protocol (SIP)
Authenticated Identity Body (AIB) Format", RFC 3893,
September 2004.
[RFC4474] Peterson, J. and C. Jennings, "Enhancements for
Authenticated Identity Management in the Session
Initiation Protocol (SIP)", RFC 4474, August 2006.
Dotson Expires August 8, 2007 [Page 18]
Internet-Draft SIP Certificate Authentication Solution February 2007
Author's Address
Steve Dotson
CableLabs
858 Coal Creek Circle
Louisville, CO 80027
US
Email: s.dotson@cablelabs.com
Dotson Expires August 8, 2007 [Page 19]
Internet-Draft SIP Certificate Authentication Solution February 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 August 8, 2007 [Page 20]