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 ;tag=a73kszlfl To: Bob Call-ID: 1j9FpLxk3uxtm8tn@biloxi.example.com CSeq: 1 REGISTER Contact: 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 ;tag=a73kszlfl To: Bob ;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 ;tag=ja743ks76zlflH To: Bob Call-ID: 1j9FpLxk3uxtm8tn@biloxi.example.com CSeq: 2 REGISTER Contact: 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 ;tag=ja743ks76zlflH To: Bob ;tag=37GkEhwl6 Call-ID: 1j9FpLxk3uxtm8tn@biloxi.example.com CSeq: 2 REGISTER Contact: ;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]