Sipping C. Jennings Internet-Draft Cisco Systems Expires: August 24, 2003 February 23, 2003 Certificate Discover for SIP draft-jennings-sipping-certs-00 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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 24, 2003. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract This draft describes a scheme where SIP user agents can create self signed certificates for use with the SIP S/MIME mechanism and can then store the certificate on a web server associated with the address of record (AOR) for the user. Other user agents that want to call that AOR can retrieve these certificates from the web server. With no extra expense or effort on the end users behalf, it is possible to have a reasonable degree of confidence of the identities of the parties in a SIP session. Jennings Expires August 24, 2003 [Page 1] Internet-Draft Cert Discovery February 2003 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Location . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 5. Retrieval . . . . . . . . . . . . . . . . . . . . . . . . . . 4 6. Enrolment . . . . . . . . . . . . . . . . . . . . . . . . . . 5 7. Security Analysis . . . . . . . . . . . . . . . . . . . . . . 6 8. Security Considerations . . . . . . . . . . . . . . . . . . . 8 9. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 8 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 11. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 9 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 Normative References . . . . . . . . . . . . . . . . . . . . . 9 Informational References . . . . . . . . . . . . . . . . . . . 9 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 10 Intellectual Property and Copyright Statements . . . . . . . . 11 Jennings Expires August 24, 2003 [Page 2] Internet-Draft Cert Discovery February 2003 1. Introduction SIP RFC 3261 [1] defines a S/MIME based PKI mechanism for achieving end to end security. Among other things, it allows for users to be confident that the party they are communicating with is likely to be the person they want. Like all PKI based schemes, distribution of the public keys is a hard problem. Failure to have a good and widely supported scheme for distributing public keys will result in users not using the S/MIME capabilities of SIP. Not knowing the identities of the other parties in a SIP session greatly reduces the usefulness of encrypted media such as SRTP. This document describes an approach to using and combining existing schemes to build a trustworthy way of distributing certificates for SIP. An example use case makes this easier to understand. Say Alice meets Bob at a party and Bob says "Call me some time. Here is my AOR." Then Bob writes bob@example.com on the back of a napkin and hands it to Alice. Later Alice makes a call to bob@example.com but she wants to be sure that she really is talking to the person who owns the AOR bob@example.com. In this document I will refer to Alice as the Caller, Bob as the Subscriber, and example.com as the Service. The goal is to allow Alice to be confident she is communicating with the person with the AOR bob@example.com. Some sub-goals are: o Trivial for any one to use. Does not require any extra effort from the end user. o Free - as in free like beer. o Does not require any third party to know the Subscriber's private key. o Allows the Subscriber to have more than one communication device associated with a single AOR. None of the problems in this document or ideas presented are new. This presents work going on in the PKIX, SACRED, and SIP working groups in a SIP context and describes an approach to putting the parts together for SIP. 2. Conventions 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 [3]. Jennings Expires August 24, 2003 [Page 3] Internet-Draft Cert Discovery February 2003 3. Overview The approach is broken down into Enrolment, Location, and Retrieval phases. The general architecture is that the Service not only provides a SIP registrar service for the Subscriber but also provides certificate storage. In the Enrolment phase, the Subscriber puts their public certificate somewhere that others can find it. In the Locating phase, the Caller discovers where the person they are calling has stored their certificates. Finally in the Retrieval phase, the Caller gets a copy of the Subscribers certificates. To meet the goal of being free, the certificates are assumed to be self signed. 4. Location The goal of this stage is to allow the Caller to locate where the Subscriber stores their certificates. The only thing the Caller has is an AOR such as bob@example.com. The obvious solution is to use the host portion of the AOR to find a directory to look up the user portion. The retrieval mechanism is HTTP based. This choice of HTTP is explained in Section 5. The mechanism for location is described in draft-ietf-pkix-certstore-http [2]. The approach first does a SRV lookup and if that fails, it tries a well know host formed from the AOR directly. For the AOR bob@example.com, first an SRV lookup of _certificates._tcp.example.com would be done. If this was successful and returned an address of a.example.com and a port of 7000 then the URL would be: o https://a.example.com:7000/search-cgi?email=bob%40example.com If the SRV lookup was not successful, then the URL would be formed by adding the host name "certificates" to the domain. In this case the URL would be: o https://certificates.example.com/ search-cgi?email=bob%40example.com 5. Retrieval Once a URL for the certificate is known, the Caller needs to get it. There are several potential protocols that could work for this: HTTP, LDAP, FTP, SNMP, ACAP, and others. The existing tools for making HTTP scale, tools for caching, tools for managing attacks on servers, and existing support for hardware acceleration of HTTPS make this a good choice from the server point of view. The ease of working through NATs and firewalls along with the fact that most SIP UA need to implement HTTP for other reasons makes it an good match on the client Jennings Expires August 24, 2003 [Page 4] Internet-Draft Cert Discovery February 2003 end. The MIME capability of HTTP are useful for dealing with the various types of certificates. These points led to the selection of HTTPS as defined in draft-ietf-pkix-certstore-http [2] as a mechanism for getting the certificates. Since the certificates may be self signed, the Caller needs to be sure that they were not tampered with and that they came from the Service that was authorized to provide them. This means that the Caller MUST use HTTPS to get the certificate and the Service MUST present a certificate in the TLS handshake that has a domain name in the SubjectAltName field that matches the domain name in the original AOR. In this example the original is example.com not the result of any SRV lookup. The names are considered to match if the SubjectAltName matches the host portion of the AOR using a case insensitive comparison. Sub-domains do not match. IP address do not match host names. 6. Enrolment The Subscriber must be able to authenticate to the Service and must be able to transfer the certificate in an integrity protected way to the Service. In SIP, the Service and the Subscriber already have a shared secret that is used for authentication during SIP registration or the Service knows the certificate of the Subscriber by some out of band mechanism. This shared secret can be leveraged for enrolment of the Subscribers public certificates. The Subscriber would transfer a public certificate to the Service using an HTTPS PUT with the same URL that would be used to get their certificate. This MUST happen over HTTPS so the transfer is integrity protected. The client MUST also check that the servers certificate name matches the name of the Subscribers AOR. This matching follows the same rules as matching in Section 5. The server MUST authenticate using DIGEST authentication with some shared secret. The same shared secret that is used for SIP registration SHOULD be used. This allows any Subscriber to generate a self signed certificate and store it at the Service. Note that authorization with TLS mutual authentication is not considered because in that case the Service already has the Subscriber's Certificate and there is no need to transfer it. There is an additional problem of how to allow a user that has several communication clients to associate them all with the same AOR and still get the certificates to work. There are at least two approaches to this problem. One would be to upload a different certificate for each UA associated with the AOR and just let the Caller use all of them. This is the approach that is chosen here. The Jennings Expires August 24, 2003 [Page 5] Internet-Draft Cert Discovery February 2003 other approach would be to use the work from the SACRED working group[5] which is solving the problem of security getting the same credential on all the clients. This second approach will require the user to enter some secret on all the clients that is used to encrypt the private key being transferred around. This is extra work on the part of the user and likely that many users will choose very weak keys for doing this. In the chosen approach of using many certificates for a single AOR, the Caller would first get all the certificates from the Service. It would then send an INVITE to the Subscriber and sign it with it's own certificate but would probably not include SDP in the INVITE. The reason it does not send SDP at this point is that it does not know which of the Subscribers public keys to encrypt with. (Note: encrypted SDP is needed when the SDP is being used to pass keying material for a SRTP session). Several of the Subscriber's UAs may respond, each forming a dialog that is signed and encrypted with the appropriate certificates. The caller can check the signature because they have all the Caller's certificates. Now that a secure dialog has been established, the usual Offer/Answer can be done with signed communications and confidential SDP. The Service MUST provide some other authenticated, out of band mechanism for the Subscriber to revoke certificates. A web page accessed over HTTPS with digest authentication would work fine for this. It is RECOMMENDED that the clients use fairly short lived certificates (in the order of days to months) and enroll a new certificate before the old one expires. The Caller MAY cache the certificates that they retrieved for an AOR and use them in future calls. This cached result MUST expire after some short but configurable amount of time so that certificate revocation works. It MUST be possible to configure this time to be zero. If the Caller is using cached information and receives a certificate in the SIP signaling that is not cached, the Caller MUST update the cache and check that the certificate was not recently added to the Service. When a UA registers, it SHOULD retrieve the certificates for its AOR and check that this UA's certificate is correctly enrolled. The HTTPS server MUST support a profile of TLS_RSA_WITH_AES_128_CBC_SHA as described in RFC 3268 [4] . 7. Security Analysis This whole scheme is made possible because the Subscriber has a shared secret with the Service, the Service has a certificate that is signed by a well known certificate authority, and the Caller knows Jennings Expires August 24, 2003 [Page 6] Internet-Draft Cert Discovery February 2003 how to find the Service for the Subscriber they are calling. To look at the security of this scheme one must consider the existing SIP S/MIME trust model and what the trust relationships are. If Alice tells a secret to Bob, Bob can tell anyone. If Bob signs something and sends it to Alice, Alice can only believe this signature as much as she believes that Bob has securely managed his private key and has not posted it on an IRC channel. If Bob tells Alice that his AOR is bob@example.com, that may change in the future and someone else may get that AOR. Just because Alice manages to get a valid certificate bound to the AOR bob@example.com does not mean that Alice is going to talk to the right Bob. This last point is important in understanding why the scheme presented here is not significantly less secure than the use of S/MIME certificates in SIP that are signed by a well known certificate authority. All SIP has is the AOR - SIP can check that the name in the certificate matches the AOR but it can not check other things that are likely to make the identity unique. If the Service example.com gave the AOR bob@example.com to a new Bob, they would likely give away the email address bob@example.com to the new Bob as well. Furthermore, the certificate authority, after revoking the old certificates, would probably give the new Bob a new certificate if the new Bob could read email sent to the AOR. Alice would be talking to bob@example.com - but the new Bob instead of the old Bob. The point of this is that you have to trust the person providing your AOR will not give your AOR to someone else. Bob has some ability to chose a Service he trusts. He can enforce this contractually with the Service and by choosing one worthy of trust. Alice has to trust Bob on many things including that he picked a trustworthy party to manage his AOR and that he manages his private key appropriately. If the Subscriber can trust the Service to manage the Subscribers AOR, then the Subscriber can trust the Service not to lie about certificates they store for the Subscriber. If the Service wants to subvert Bob's communications, they can likely do this by getting a certificate authority to give them a certificate masquerading as Bob. The security of this scheme relies on the Service not lying about what Bob's public certificates are. If you buy this, the rest is fairly simple. Only Bob's UAs have the shared secret to authenticate to the Service to upload a certificate. The UA will not accidentally authenticate to a rogue service because the UA checks the certificate the Service presents in TLS. The certificate is not tampered with because the HTTPS connection is integrity protected. When the Caller retrieves a certificate they know it is coming from the correct Service because the Service must have the certificate for the domain that represents Jennings Expires August 24, 2003 [Page 7] Internet-Draft Cert Discovery February 2003 the host portion of the AOR. The Caller knows the certificate was not tampered with in transit because the connection is integrity protected. Certificates can be quickly revoked because the Caller gets the certificates on each new call to the Subscriber. This side steps some thorny CRL issues. The impact of getting these each time will probably make a relevant difference on the load of the Service's servers but does not make the scheme unworkable. The Subscribers UA's can use short lived self signed certificates. In fact UAs could upload a new certificate each time they boot. This would eliminate the need for UAs to store the private keys in NVRAM which might be a security advantage. 8. Security Considerations This whole document if focused on security and must be considered from a security point of view. It is important to remember that the scheme relies upon the Subscriber choosing a Service that does not lie. The Subscriber may wish to use contractual obligations to enforce this. Still more to do here. 9. Open Issues Sort out exact TLS profiles to be used. Do a better threat model. Is a separate certificate needed for sip than the one used for email? This would require a HTTP get of o https://a.example.com:7000/search-cgi?sip=bob%40example.com before o https://a.example.com:7000/search-cgi?email=bob%40example.com was tried. This is likely needed since the email certificate may not even be a X509 certificate. 10. IANA Considerations There are no IANA considerations. Jennings Expires August 24, 2003 [Page 8] Internet-Draft Cert Discovery February 2003 11. Conclusion The procedure described in this document is easy and it can happen automatically with no extra expense or intervention from the Subscriber or Caller. It is easy for the Service to provide and does not require them to do much beyond running a normal HTTPS web service suitable for e-commerce application. It achieves about as good a job of identifying the participants of a call as the SIP S/MIME mechanism is capable of achieving. It does not require any modification of existing protocols or inventions of new ones. 12. Acknowledgements Many thanks to Rohan Mahy and Jason Fischl for comments ... and to a bunch of people who are going to straighten me out on this stuff. Eric, Jon, there is a spot reserved here for you. Normative References [1] 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. [2] Gutmann, P., "Internet X.509 Public Key Infrastructure Operational Protocols: Certificate Store Access via HTTP", draft-ietf-pkix-certstore-http-04 (work in progress), February 2003. [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [4] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites for Transport Layer Security (TLS)", RFC 3268, June 2002. Informational References [5] Nystrom, M., Just, M. and D. Gustafson, "Securely Available Credentials - Credential Framework", draft-ietf-sacred-framework-05 (work in progress), March 2003. Jennings Expires August 24, 2003 [Page 9] Internet-Draft Cert Discovery February 2003 Author's Address Cullen Jennings Cisco Systems 170 West Tasman Drive MS: SJC-21/3 San Jose, CA 95134 USA Phone: +1 408 527-9132 EMail: fluffy@cisco.com Jennings Expires August 24, 2003 [Page 10] Internet-Draft Cert Discovery February 2003 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication 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 implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION Jennings Expires August 24, 2003 [Page 11] Internet-Draft Cert Discovery February 2003 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Jennings Expires August 24, 2003 [Page 12]