Certificate Discovery for SIP

SIP RFC 3261 defines an S/MIME based PKI mechanism for achieving end to end security. Among other things, it allows users to be confident that the party they are communicating with is likely 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. This document refers to Alice as the Caller, Bob as the Subscriber, and example.com as the Service. The overall approach is fairly simple and is illustrated in the figure below. The "store" element in the network is an HTTP web server that is run by the same administrative domain as the proxy.

+---------+ +---------+ +---+ Store A +--- --| Store B +--+ | +---------+ \ / +---------+ | | \ / | 0 | \ / | | 2 +-------+ 3 X +-------+ |0 | +--+Proxy A+------/-\---|Proxy B+-+ | | | +-------+ / \ +-------+ |4 | | | / \ | | +------+ / \ +------+ | UA A |---------/ \-------+ UA B | +------+ 1 5 +------+ The goal is for UA A to sign and encrypt a message to UA B using securely acquired self signed certificates. Both sides save their public certificates in a well known store associated with their domain and get the other's certificate from the other domain's store. There are several steps. Step 0: At some point in time, both the UA generate a self signed certificate and store it in the the Store for their domain. This is done with a PUT over HTTPS that is digest challenged with the same credentials that are used to register with the proxy in the domain. Step 1: UA A fetches the certificate for UA B from Store B. This is done using a GET over HTTPS. Step 2,3,4: UA A uses its certificate to sign and UA B's certificate to encrypt and sends a message across the proxies in steps 2,3,and 4 to UA B. This is done using the normal SIP S/MIME bodies. Step 5: UA B needs to get UA A's certificate to check the signature. It gets this from Store A using a HTTPS GET. UA B can now decrypt the message and check the signature. When one of the UA gets a certificate from a Store, the UA must check that the domain name in the AOR in the certificate matches the domain of the Store it is getting the result from. The UA knows this from the certificate presented in the TLS handshake. This one little part makes this scheme significantly different from a typical self signed certificate system. In a classical systems, such as SSH, the first time a certificate is received, there is no automatic way to validate it so the systems must make a "leap of faith" or provide manual out of bound validation which users are typically unwilling to do. This system does not require the leap of faith because the certificate in the TLS session with the store validates that the UA is getting the certificate for UA B from a trustworthy source. The scheme described in this document meets the goal of allowing Alice to be confident she is communicating with the person with the AOR bob@example.com. It also has the following very desirable properties: Trivial to use, requiring no extra effort from the part of the Caller or Subscriber. Free in that it does not require any extra expense to the Caller or Subscriber. No requirement for a third party to know the Subscriber's private key. Allows the Subscriber to have more than one communication device associated with a single AOR. Does not require the Service to deploy additional equipment with strict security requirements beyond what they are already running. None of the problems or ideas presented in this document 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.

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. The term Subscriber refers to an end user that receives calls and has an AOR in a domain that is managed by the Service. The Service provides the SIP proxy and certificate Store. The term Caller refers to the UA that is trying to call the Subscriber. The Caller is often not in the same administrative domain as the Subscriber and therefore has no pre-existing relationship with the Service.

The approach is broken down into Enrollment, 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 Enrollment 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 Subscriber's certificates. To meet the goal of being free, the certificates are assumed to be self signed.

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 mechanism for location using HTTP is described in draft-ietf-pkix-certstore-http. The approach first does a SRV lookup and if that fails, it tries a well known 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:

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:

https://certificates.example.com/search-cgi?email=bob%40example.com

An alternative scheme to locate the certificates could be based on SIP. The Caller would send an OPTIONS message to the Subscriber proxy. The reply to this would contain a content indirection body or message/external type as defined in RFC 2017 that references a MIME type of application/pkix-cert that could be retrieved using an https URL. The Caller would include a similar content indirection body pointing to their certificate in the messages sent to the Subscriber. This would avoid the need to have some well known URL for locating certificates, and each administrative domain could set up the certificates' locations as it wished.

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 and be reliable, the tools for managing attacks on servers, and the 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 UAs need to implement HTTP for other reasons make it a good match on the client end. The MIME types in 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 as a mechanism for getting the certificates. Getting the certificate with HTTP is defined in RFC 2585 and will be in a MIME type of application/pkix-cert and contain a DER encoded X509 certificate./ 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 AOR in the SubjectAltName in the retrieved certificate. 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 addresses do not match host names.

It is possible to retrieve a list of several certificates for the same AOR when there are several different UA that may receive messages for this AOR. In this case the UA sending the messages needs to use every valid certificate it received for the public key operations. A certificate Store SHOULD not provide certificates that have become invalid.

Both the Caller and Subscriber UA need to retrieve the other's certificate from the appropriate Store. This is done with the following steps: Determine the AOR of the certificate that is needed - for example, alice@example.com. Do a DNS SRV lookup for the service _certificates with a protocol of _tcp in the domain of the AOR. (In this example this would result in a DNS SRV query in the domain example.com). If this is found, form a URL using the hostname and port returned. If not, form the URL by using the default port for HTTPS and a hostname of certificates prepended to the the domain from the AOR. (In this example this would result in a hostname of certificates.example.com) Use the host and port found in the previous step to form a URL of the form "https:://host:port/serach-cgi?email=aor" where the "aor" is replaced with an appropriately escaped version of the AOR. For this example, this would become "https://certificates.example.com/search-cgi?email=alice%40example.com" Open a TLS connection to this URL. TLS extended hellos to indicate the requested domain SHOULD be used. The server MUST return a certificate with a SubjectAltName that matches the domain portion of the original AOR (example.com in this example). The UA MUST check this matches and if it does not, it must close the connection and not proceed. The UA then performs an HTTP GET on the URL. The Store returns the one or more bodies or an error if it has no certificates for this Subscriber. Each certificate is in an DER encoded X509 certificate and is in a body of type application/pkix-cert. A transfer encoding of binary is used. The UA MUST check that all the SubjectAltNames in all the certificates have a user and host portion that matches the original AOR. Schemes other than SIP are acceptable. In this example, a SubjectAltName that contained two URIs, "im:alice@example.com" and "sip:alice@example.com" would be acceptable. Any certificates that do not match MUST be discarded. The UA MUST check the expiry dates on the certificates. Any expired certificates MUST be discarded. The UA now has a usable list of certificates for the AOR. If the UA is using them to decrypt, it uses the serial number and issuer to find the certificate it needs to decrypt the information. If it is using the certificates to encrypt some information, it must encrypt the CEK with each of the certificates so that the a UA in possession of the private key from any one of the certificates can decrypt the material.

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 enrollment of the Subscriber's public certificates. The Subscriber would transfer acertificate 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 server's certificate name matches the name of the Subscriber's AOR. This matching follows the same rules as matching in retrieval of certificates. The client MUST authenticate to the server 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 other approach would be to use the work from the SACRED working group which is solving the problem of security getting the same credential on all the clients. 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 its own certificate and encrypt the SDP (or whatever part of the messages was being encrypted) with each of the certificates retrieved. No matter which of the Subscribers UA's received the message, that UA would be able to decrypt the information. 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. A HTTPS DELETE with digest could work but there needs to be a way to tell which certificate needs to be deleted when the AOR has multiple certificates. 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 or a profile of TLS_RSA_WITH_3DES_CBC_SHA .

The Subscriber UA needs to generate a self signed certificate and save it in the store. This is performed in the following steps: When the UA starts up, it needs to fetch its own certificate and check that it matches the certificate stored on the UA. If it does not, it should warn the user and generate a new certificate. The UA should check the expiration and arrange to generate a new certificate before the old one expires. TODO: Describe details of generating a self signed certificate. The UA forms a URL in the same way as locating a certificate but using its own AOR. The UA opens a a TLS connection and verifies the certificate returned in the TLS the same way as retrieving a certificate. The UA then does a HTTPS PUT of the certificate. The server MUST digest challenge this request. The UA computes the response to this digest and MAY use the same username and password as it would use to register with the proxy in this domain. The server must check that, for each URI in the SubjectAltName in the certificate, the user portion matches the username used in the digest authentication and the host portion matches the domain used for the TLS connection. When the certificate is close to expiring, the UA should create and store a new certificate. At this point the UA has successfully stored its certificate in the Store. The Store may discard any certificates that have expired.

If the Subscriber or Caller wishes to use an authentication service to insert and verify S/MIME bodies on their behalf, they can do so by using content indirection to specify URLs for the S/MIME bodies that can be filled in by the authentication service. TODO - This needs significantly more detail if it is to be used

This whole document is 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.

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 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 that the person providing your AOR will not give your AOR to someone else. Bob has some ability to choose 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 Subscriber's 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 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 Subscriber's UAs 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.

Is there a need for a SIP response code that indicates that a bad certificate was used and that the user should flush this certificate from their cache and try again? It is likely that SIP requires a certificate separate from the one used for email. This would require an HTTP get of: https://a.example.com:7000/search-cgi?sip=bob%40example.com This is likely needed.

The ietf-sip-identity draft is about allowing the Service to assert the identity of a Subscriber to others. It does not deal with signing or encrypting messages from one user to another which is the focus of this draft. It does make the same primary assumption that the Service is trusted by the Subscriber and that the service is trustworthy enough to adequately authenticate the Subscribers.

There are no IANA considerations.

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 the invention of any new ones.

Many thanks to Eric Rescorla, Peter Gutmann, Rohan Mahy and Jason Fischl for comments.