SIP S. Dotson Internet-Draft CableLabs Intended status: Standards Track May 31, 2007 Expires: December 2, 2007 Certificate Authentication in SIP draft-dotson-sip-certificate-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 2, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Dotson Expires December 2, 2007 [Page 1] Internet-Draft Certificate Authentication in SIP May 2007 Abstract This document defines requirements for adding certificate authentication to the Session Initiation Protocol (SIP). This document is being presented with the intention of providing clear 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 . . . . . . . . . . . . . . . . . . . . . . . 5 2. Existing Work . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Requirements and Recommendations . . . . . . . . . . . . . . . 8 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 6. Normative References . . . . . . . . . . . . . . . . . . . . . 12 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13 Intellectual Property and Copyright Statements . . . . . . . . . . 14 Dotson Expires December 2, 2007 [Page 2] Internet-Draft Certificate Authentication in SIP May 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 December 2, 2007 [Page 3] Internet-Draft Certificate Authentication in SIP May 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 have end-to-end authentication 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 credentials, and is thus not involved with the authentication proxy. Dotson Expires December 2, 2007 [Page 4] Internet-Draft Certificate Authentication in SIP May 2007 If confidentiality is used, the User and Proxy 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). 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]. End entity - user of X.509 certificates and/or end user system that is represented by the certificate Dotson Expires December 2, 2007 [Page 5] Internet-Draft Certificate Authentication in SIP May 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 end-to-end 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 were able to meet all the requirements of this document. The following existing solutions were reviewed: o SIP S/MIME o AIB o SIP Identity o SIP Security Agreement Following is an analysis of existing work in the IETF related to the requirements presented in this document. 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 does not follow a challenge/response paradigm. There is no mechanism to signal that authentication is necessary, which requires a UAC to always send dialog requests S/MIME protected. o S/MIME may have issues with network intermediaries that must view or modify the bodies of SIP messages (especially SDP). Dotson Expires December 2, 2007 [Page 6] Internet-Draft Certificate Authentication in SIP May 2007 o S/MIME does not have a means to negotiate authentication methods. 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. The Authentication Service is typically located at the outbound proxy and may authenticate the UAC using digest authentication and/or a TLS session. SIP Identity does not meet all the requirements listed in this document. o Is not based on challenge/response 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. o Identity does not have a mechanism to pass certificates in the SIP messages. 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. While RFC 3329 may enable confidentiality of messaging for the solution between a client and its next-hop SIP server, it does not meet the requirement to provide end-to-end authentication of endpoints in the presence of intermediary proxies. Dotson Expires December 2, 2007 [Page 7] Internet-Draft Certificate Authentication in SIP May 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. The solution SHOULD 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. 4. The solution MUST allow for intermediate proxies within the SIP network, including when confidentiality of messaging is required. 5. The solution MUST utilize an end entity certificate for authentication. 6. A certificate MUST represent an end entity that will be authenticated. The certificate MUST contain enough information that allows the end entity to be identified. Examples of an end entity include client, user, service provider, etc. RFC 2818 [RFC2818] contains some rules on end entity authentication that may be utilized in the solution. 7. The solution MUST allow certificatess to be passed in SIP messaging. Certificates MAY be obtained through other means. 8. 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. 9. 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. Dotson Expires December 2, 2007 [Page 8] Internet-Draft Certificate Authentication in SIP May 2007 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. 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 December 2, 2007 [Page 9] Internet-Draft Certificate Authentication in SIP May 2007 4. IANA Considerations None. Dotson Expires December 2, 2007 [Page 10] Internet-Draft Certificate Authentication in SIP May 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 December 2, 2007 [Page 11] Internet-Draft Certificate Authentication in SIP May 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. [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. [RFC4474] Peterson, J. and C. Jennings, "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", RFC 4474, August 2006. Dotson Expires December 2, 2007 [Page 12] Internet-Draft Certificate Authentication in SIP May 2007 Author's Address Steve Dotson CableLabs 858 Coal Creek Circle Louisville, CO 80027 US Email: s.dotson@cablelabs.com Dotson Expires December 2, 2007 [Page 13] Internet-Draft Certificate Authentication in SIP May 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 December 2, 2007 [Page 14]