SIP S. Dotson Internet-Draft CableLabs Expires: December 20, 2006 June 18, 2006 Certificate Authentication in SIP draft-dotson-sip-certificate-auth-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 December 20, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document defines requirements for adding certificate authentication to the Session Initiation Protocol (SIP) [2]. 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. Dotson Expires December 20, 2006 [Page 1] Internet-Draft Certificate Authentication in SIP June 2006 1. Introduction 1.1. Problem Statement Currently, SIP (RFC 3261) [2] only defines procedures for Digest authentication using a username/password. Some organizations and service provicers may want to leverage existing Public Key Infrastructure (PKI) investments for performing user authentication in SIP. Adding certificates as an option for authentication in SIP provides stronger security and allows for new deployment scenarios. 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. SIP Digest RFC 3261 [2] defines procedures for performing SIP Digest authentication using usernames and passwords. It is based heavily on RFC 2617 [3]. SIP Digest is a challenge based mechanism for authentictaion. 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. Dotson Expires December 20, 2006 [Page 2] Internet-Draft Certificate Authentication in SIP June 2006 ------- --------------- | UA | | 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 mechansism 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. 1.3. Related Work Although this document does not attempt to define a solution, related work exists in the IETF. SIP Identity [5] provides a mechanism to cryptographically assure the identity of originators of SIP messages. It uses a private key and certificate associated with the domain indicated in the From header URI. An authentication service authenticates the UAC and then inserts an Identity header and an Identity-Info header in the forwarded the request. The Authentication Service is typically located at the outbound proxy and Dotson Expires December 20, 2006 [Page 3] Internet-Draft Certificate Authentication in SIP June 2006 may authenticate the UAC using digest authentication or an existing TLS session. The current SIP Identity solution does not meet all requirements as described in a later section, including the ability to pass certificates. Dotson Expires December 20, 2006 [Page 4] Internet-Draft Certificate Authentication in SIP June 2006 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 [1]. This document borrows SIP related terminology as specified in RFC 3261 [2]. Dotson Expires December 20, 2006 [Page 5] Internet-Draft Certificate Authentication in SIP June 2006 3. General Requirements The following are the general requirements for certificate authentication in SIP: 1. The messaging SHOULD conform to RFC 3261 [2]. 2. A mechanism MUST exist for the endpoints to agree on the authentication to be used. 3. The protocol MUST prevent replay attacks, and the anti-replay mechansism MUST NOT rely on synchronized clocks. 4. Confidentiality MAY be required based on the contents of the certificates. 5. Relying parties MUST check the validity of certificates as defined in RFC 3280 [4]. 6. The certificate MUST authenticate the endpoint. There MUST be a mapping between the user and the certificate. The certificate MUST contain enough data to allow this mapping. 7. The endpoint being authenticated SHOULD provide to the authenticator a list of roots it trusts. 8. The authenticator SHOULD provide to the endpoint being authenticated a list of roots it trusts. 9. 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. 10. Mutual authentication MUST be supported. Client-only authentication SHOULD be supported. Dotson Expires December 20, 2006 [Page 6] Internet-Draft Certificate Authentication in SIP June 2006 4. Open Issues 1. Need to categorize requirements based on implementation/ architecture. 2. Need to consider whether new SIP response codes are necessary. 3. Need to consider references to AIB, connected-identity, etc. Dotson Expires December 20, 2006 [Page 7] Internet-Draft Certificate Authentication in SIP June 2006 5. IANA Considerations None. Dotson Expires December 20, 2006 [Page 8] Internet-Draft Certificate Authentication in SIP June 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. 7. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] 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. [3] 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. [4] 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. [5] Peterson, J., "Enhancements for Authenticated Identity Management in the Session Initiated Protocol (SIP), draft-ietf-sip-identity-06 (work in progress)", June 1999. Dotson Expires December 20, 2006 [Page 9] Internet-Draft Certificate Authentication in SIP June 2006 Author's Address Steve Dotson CableLabs 858 Coal Creek Circle Louisville, CO 80027 US Email: s.dotson@cablelabs.com Dotson Expires December 20, 2006 [Page 10] Internet-Draft Certificate Authentication in SIP June 2006 Intellectual Property Statement 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. Disclaimer of Validity 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. 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Dotson Expires December 20, 2006 [Page 11]