SIP S. Dotson Internet-Draft CableLabs Intended status: Standards Track October 22, 2006 Expires: April 25, 2007 Certificate Authentication in SIP draft-dotson-sip-certificate-auth-01.xml 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 April 25, 2007. Copyright Notice Copyright (C) The Internet Society (2006). Dotson Expires April 25, 2007 [Page 1] Internet-Draft Certificate Authentication in SIP October 2006 Abstract This document defines requirements for adding certificate authentication to the Session Initiation Protocol (SIP). It is intended that potential solutions specifying certificate authentication within SIP will use these requirements as guidelines. 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. Problem Statement . . . . . . . . . . . . . . . . . . . . 3 1.2. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 3 1.3. SIP Digest . . . . . . . . . . . . . . . . . . . . . . . . 4 1.4. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 2. General Requirements . . . . . . . . . . . . . . . . . . . . . 6 2.1. Recommendations . . . . . . . . . . . . . . . . . . . . . 6 3. Related Work . . . . . . . . . . . . . . . . . . . . . . . . . 7 4. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 9 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 7. Normative References . . . . . . . . . . . . . . . . . . . . . 12 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13 Intellectual Property and Copyright Statements . . . . . . . . . . 14 Dotson Expires April 25, 2007 [Page 2] Internet-Draft Certificate Authentication in SIP October 2006 1. Introduction This document is a requirements document for SIP authentication using certificates. It is meant to start discussion within the IETF. There is no intent to specify solution-specific details in this document. 1.1. Problem Statement Currently, SIP (RFC 3261) [RFC3261] defines procedures for Digest authentication using a username/password. Adding certificates as an option for authentication in SIP provides stronger security and allows for new deployment scenarios. Some organizations and service provicers (e.g., cable operators) may want to leverage existing Public Key Infrastructure (PKI) investments for performing user authentication in SIP. Although PKI has some constraints when attempting to solve user to user security, when the UA is authenticating to its Home Network (HN) it becomes a viable option for certain deployments. 1.2. Use Cases In regards to the entity being authenticated, there are several use cases 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). The users "behind" the device may or may not be authenticated by the device. 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). o Users may be mapped to the device certificate. The device certificate could be used to bootstrap user identity certificates. The device certificate could be associated with users through some backend system. It is for discussion whether this level of detail in the use of the certificates is within scope of the procedures and scope of the problem. For example, the validity checks for a user certificate could include validation of the CN or subjectAltName attributes in relation to the identity represented in SIP messages. However, the actual mapping of certificate to device or user or both may not need Dotson Expires April 25, 2007 [Page 3] Internet-Draft Certificate Authentication in SIP October 2006 to be defined by the methodology and could be left to local policy. 1.3. SIP Digest 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. The message flow of SIP Digest during a registration is shown in Figure 1. ------- --------- ------------- | UA | | Proxy | | Registrar | | | | | | | ------- --------- ------------- | | |----------------->|----------------->| UA sends Register message | | | | | | | | | | | | |<-----------------|<-----------------| Registrar responds with a | | | 401 Unauthorized message | | | | | | |----------------->|----------------->| UA sends Register message | | | including challenge response | | | | | | | | | |<-----------------|<-----------------| Registrar sends 200 OK | | | message | | | Figure 1 SIP Digest Message Flow 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. Dotson Expires April 25, 2007 [Page 4] Internet-Draft Certificate Authentication in SIP October 2006 SIP Digest provides authentication and replay detection. Because it is based on passwords, it suffers from the security weaknesses of password based systems. 1.4. 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]. Dotson Expires April 25, 2007 [Page 5] Internet-Draft Certificate Authentication in SIP October 2006 2. General Requirements The following are the general requirements for certificate authentication in SIP: 1. The methodology MUST utilize an entity certificate for authentication. 2. The certificate MUST represent an entity that will be authenticated. The certificate MUST contain enough information that allows the entity to be identified. Examples of an entity include device, user, etc. 3. Certificates MAY be exchanged during the authentication process, or MAY be obtained through other methods such as directories. If the certificate is not provided directly, it MUST be unambiguously referenced. 4. Relying parties MUST check the validity of certificates as defined in RFC 3280 [RFC3280]. 5. Mutual authentication MUST be supported. Client-only authentication SHOULD be supported. 6. The messaging SHOULD apply to SIP based networks. 7. The methodology MUST allow for intermediate proxies. 2.1. Recommendations 1. A mechanism MAY be necessary for the entities to agree on the authentication to be used. 2. The methodology SHOULD prevent replay attacks 3. Confidentiality MAY be required based on the contents of the certificates. Dotson Expires April 25, 2007 [Page 6] Internet-Draft Certificate Authentication in SIP October 2006 3. Related Work The following sections provide an analysis of existing work in the IETF related to the requirements presented in this document. 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 Identity does not have a mechanism to pass certificates in the SIP messages. 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 The protocol requires the use of certificates for authentication, and the UA may not contain other credentials besides certificates. o There is potentially some reuse of the identity header and cryptographic assertion. In this case, the UA could act as the authentication service and provide an identity header to the entity requesting authentication. However, 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 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. RFC 3261 does not have a means to negotiate authentication methods, as there is only one allowed method of authentication. RFC 3261 does not describe a mechanism to provide a list of trusted roots. 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 Dotson Expires April 25, 2007 [Page 7] Internet-Draft Certificate Authentication in SIP October 2006 recommended in RFC 3261. As the solution is similar to RFC 3261 S/MIME in relation to the requirements in this document, the solution does not meet all the requirements in this document as described in the previous section. Dotson Expires April 25, 2007 [Page 8] Internet-Draft Certificate Authentication in SIP October 2006 4. Open Issues 1. Does the methodology accommodate both registration authentication (UA to registrar) and end to end authentication (UA to UA)?. Dotson Expires April 25, 2007 [Page 9] Internet-Draft Certificate Authentication in SIP October 2006 5. IANA Considerations None. Dotson Expires April 25, 2007 [Page 10] Internet-Draft Certificate Authentication in SIP October 2006 6. 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. Dotson Expires April 25, 2007 [Page 11] Internet-Draft Certificate Authentication in SIP October 2006 7. 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. [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 April 25, 2007 [Page 12] Internet-Draft Certificate Authentication in SIP October 2006 Author's Address Steve Dotson CableLabs 858 Coal Creek Circle Louisville, CO 80027 US Email: s.dotson@cablelabs.com Dotson Expires April 25, 2007 [Page 13] Internet-Draft Certificate Authentication in SIP October 2006 Full Copyright Statement Copyright (C) The Internet Society (2006). 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 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 April 25, 2007 [Page 14]