SIP C. Jennings Internet-Draft Cisco Systems Expires: August 20, 2005 J. Peterson NeuStar, Inc. February 19, 2005 Certificate Management Service for The Session Initiation Protocol (SIP) draft-ietf-sipping-certs-01 Status of this Memo This document is an Internet-Draft and is subject to all provisions of section 3 of RFC 3667. 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 become aware will be disclosed, in accordance with RFC 3668. 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 20, 2005. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This draft defines a Credential Service that allows SIP User Agents to use a SIP package to discover the certificates of other users. This mechanism allows user agents that want to contact a given Address-of-Record (AOR) to retrieve that AOR's certificate by subscribing to the Credential Service. The Credential Service also Jennings & Peterson Expires August 20, 2005 [Page 1] Internet-Draft SIP Certificates February 2005 allows users to store and retrieve their own certificates and private keys. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. UA Behavior with Certificates . . . . . . . . . . . . . . . 6 5. UA Behavior with Credentials . . . . . . . . . . . . . . . . 7 6. Credential Service Behavior . . . . . . . . . . . . . . . . 8 7. Event Package Formal Definition for "certificate" . . . . . 8 7.1 Event Package Name . . . . . . . . . . . . . . . . . . . . 8 7.2 Event Package Parameters . . . . . . . . . . . . . . . . . 8 7.3 SUBSCRIBE Bodies . . . . . . . . . . . . . . . . . . . . . 9 7.4 Subscription Duration . . . . . . . . . . . . . . . . . . 9 7.5 NOTIFY Bodies . . . . . . . . . . . . . . . . . . . . . . 9 7.6 Subscriber Generation of SUBSCRIBE Requests . . . . . . . 9 7.7 Notifier Processing of SUBSCRIBE Requests . . . . . . . . 9 7.8 Notifier Generation of NOTIFY Requests . . . . . . . . . . 10 7.9 Subscriber Processing of NOTIFY Requests . . . . . . . . . 10 7.10 Handling of Forked Requests . . . . . . . . . . . . . . 10 7.11 Rate of Notifications . . . . . . . . . . . . . . . . . 10 7.12 State Agents and Lists . . . . . . . . . . . . . . . . . 11 7.13 Behavior of a Proxy Server . . . . . . . . . . . . . . . 11 8. Event Package Formal Definition for "credential" . . . . . . 11 8.1 Event Package Name . . . . . . . . . . . . . . . . . . . . 11 8.2 Event Package Parameters . . . . . . . . . . . . . . . . . 11 8.3 SUBSCRIBE Bodies . . . . . . . . . . . . . . . . . . . . . 11 8.4 Subscription Duration . . . . . . . . . . . . . . . . . . 11 8.5 NOTIFY Bodies . . . . . . . . . . . . . . . . . . . . . . 12 8.6 Subscriber Generation of SUBSCRIBE Requests . . . . . . . 12 8.7 Notifier Processing of SUBSCRIBE Requests . . . . . . . . 13 8.8 Notifier Generation of NOTIFY Requests . . . . . . . . . . 13 8.9 Notifier Processing of PUBLISH Requests . . . . . . . . . 13 8.10 Subscriber Processing of NOTIFY Requests . . . . . . . . 14 8.11 Handling of Forked Requests . . . . . . . . . . . . . . 14 8.12 Rate of Notifications . . . . . . . . . . . . . . . . . 14 8.13 State Agents and Lists . . . . . . . . . . . . . . . . . 14 8.14 Behavior of a Proxy Server . . . . . . . . . . . . . . . 14 9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 14 9.1 Encrypted Page Mode IM Message . . . . . . . . . . . . . . 14 9.2 Setting and Retrieving UA Credentials . . . . . . . . . . 15 10. Security Considerations . . . . . . . . . . . . . . . . . . 16 10.1 Certificate Revocation . . . . . . . . . . . . . . . . . 18 10.2 Certificate Replacement . . . . . . . . . . . . . . . . 19 10.3 Trusting the Identity of a Certificate . . . . . . . . . 19 10.4 Conformity to the SACRED Framework . . . . . . . . . . . 20 Jennings & Peterson Expires August 20, 2005 [Page 2] Internet-Draft SIP Certificates February 2005 10.5 Crypto Profiles . . . . . . . . . . . . . . . . . . . . 20 10.6 User Certificate Generation . . . . . . . . . . . . . . 20 10.7 Compromised Authentication Service . . . . . . . . . . . 20 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . 21 11.1 Certificate Event Package . . . . . . . . . . . . . . . 21 11.2 Credential Event Package . . . . . . . . . . . . . . . . 22 11.3 PKCS#8 . . . . . . . . . . . . . . . . . . . . . . . . . 22 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 23 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 13.1 Normative References . . . . . . . . . . . . . . . . . . . 23 13.2 Informational References . . . . . . . . . . . . . . . . . 24 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 25 Intellectual Property and Copyright Statements . . . . . . . 26 Jennings & Peterson Expires August 20, 2005 [Page 3] Internet-Draft SIP Certificates February 2005 1. Introduction SIP [6] provides a mechanism [17] for end-to-end encryption and integrity using S/MIME [16]. Several security properties of SIP depend on S/MIME, and yet it has not been widely deployed. Certainly, one reason is the complexity of providing a reasonable certificate distribution infrastructure. This specification proposes a way to address discovery, retrieval, and management of certificates for SIP deployments. It follows the Sacred Framework RFC 3760 [7] for management of the credentials. Combined with the SIP Identity [2] specification, this specification allows users to have certificates that are not signed by any well known certificate authority while still strongly binding the user's identity to the certificate. This mechanism allows SIP User Agents such as IP phones to enroll and get their credentials without any more configuration information than they commonly have today. The end user expends no extra effort. 2. Definitions 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 [5]. Certificate: An X.509v3 [15] style certificate containing a public key and a list of identities in the SubjectAltName that are bound to this key. The certificates discussed in this draft are generally self signed and use the mechanisms in the SIP Identity [2] specification to vouch for their validity. Credential: For this document, credential means the combination of a certificate and the associated private key. 3. Overview The general approach is to provide a new SIP service referred to as a Credential Service that allows SIP User Agents (UAs) to subscribe to some other user's certificate using a new SIP event package [4]. The certificate is delivered to the subscribing UA in a corresponding SIP NOTIFY request. The identity of the certificate can be vouched for using the Authentication Service from the SIP Identity [2] specification, which uses the domain's certificate to sign the NOTIFY request. The Credential Service can manage public certificates as well as the user's private keys. Users can update their credentials, as stored on the Credential Service, using a SIP PUBLISH [3] request. The UA authenticates to the Credential Service using a shared secret when a UA is updating a credential. Typically the shared secret will be the same one that is used by the UA to authenticate a REGISTER Jennings & Peterson Expires August 20, 2005 [Page 4] Internet-Draft SIP Certificates February 2005 request with the Registrar for the domain (usually with SIP Digest Authentication). The following figure shows Bob publishing his credentials from one of his User Agents (ex: his laptop software client), retrieving his credentials from another of his User Agents (ex: his mobile phone), and then Alice retrieving Bob's certificate and sending a message to Bob. SIP 200-class responses are omitted from the diagram to make the figure easier to understand. example.com domain ------------------ Alice Proxy Auth Cred Bob1 Bob2 | | | | TLS Handshake | | | [ Bob generates ] |<--------------------->| | [ credentials and ] | PUBLISH (credential) | | [ publishes them ] |<----------------------| | | | | Digest Challenge | | | | |---------------------->| | | | | PUBLISH + Digest | | | | |<----------------------| | | | | | | | | | time passes... | | | | | | | | | | TLS Handshake | | [ Bob later gets ] |<---------------->| | [ back his own ] | SUBSCRIBE | | [ credentials ] | (credential) | | [ at another ] |<-----------------| | [ User Agent ] | SUBSCRIBE+Digest | | | | |<-----------------| | | | | NOTIFY | | | | |----------------->| | | | | Bob Decrypts key | | | | | | | | | | | | SUBSCRIBE (certificate) | Alice fetches | |---------->|----->|----->| Bob's cert | | | |NOTIFY| | | NOTIFY+Identity |<-----| | |<----------+------| | Alice uses cert | | | | | to encrypt | | MESSAGE | | | message to Bob | |---------->|------+------+----------------->| Bob's UA (Bob2) does a TLS [11] handshake with the credential server to authenticate that the UA is connected to the correct credential server. Then Bob's UA publishes his newly created or updated Jennings & Peterson Expires August 20, 2005 [Page 5] Internet-Draft SIP Certificates February 2005 credentials. The Credential server digest challenges the UA to authenticate that the UA knows Bob's shared secret. Once the UA is authenticated, the credential server stores Bob's credentials. Another one of Bob's User Agents (Bob1) wants to fetch its current credentials. It does a TLS [11] handshake with the credential server to authenticate that the UA is connected to the correct credential server. Then Bob's UA subscribes for the credentials. The Credential server digest challenges the UA to authenticate that the UA knows Bob's shared secret. Once the UA is authenticated, the credential server sends a NOTIFY that contains Bob's credentials. The private key portion of the credential may have been encrypted with a secret that only Bob's UA (and not the credential server) knows. In this case, once Bob's UA decrypts the private key it will be ready to go. Typically Bob's UA would do this when it first registered on the network. Some time later Alice decides that she wishes to discover Bob's certificate so that she can send him an encrypted message. Alice's UA sends a SUBSCRIBE message to Bob's AOR. The proxy in Bob's domain routes this to the credential server via an authorization service. The credential server returns a NOFITY that contains Bob's public certificate in the body. This is routed through an authentication service that signs that this message really can validly claim to be from the AOR "sip:bob@example.com". Alice's UA receives the certificate and can use it to encrypt a message to Bob. The mechanism described in this document works for both self signed certificates and certificates signed by well known certificate authorities; however, it is imagined that most UAs using this would only use self signed certificates, and would use an Authentication Service as described in [2] to provide a strong binding of an AOR to the certificates. 4. UA Behavior with Certificates When a User Agent wishes to discover some other user's certificate it subscribes to the "certificate" SIP event package as described in Section 7 to get the certificate. While the subscription is active, if the certificate is updated, the Subscriber will receive the updated certificate in a notification. The Subscriber needs to decide how long it is willing to trust that the certificate it receives is still valid. If the certificate is revoked before it expires, the Notifier will send a notification with an empty body to indicate that the certificate is no longer valid. However, the Subscriber might not receive the notification if an attacker blocks this traffic. The amount of time that the Subscriber Jennings & Peterson Expires August 20, 2005 [Page 6] Internet-Draft SIP Certificates February 2005 caches a certificate SHOULD be configurable. A default of one day is RECOMMENDED. Note that the actual duration of the subscription is orthogonal to the caching time or validity time of the corresponding certificate. Allowing subscriptions to persist after a certificate is not longer valid ensures that Subscribers receive the replacement certificate in a timely fashion. In some cases, the Notifier will not allow unauthenticated subscriptions to persist. The Notifier could return an immediate notification with the certificate in response to subscribe and then immediately terminate subscription, setting the reason parameter to "probation". The Subscriber will have to periodically poll the Notifier to verify validity of the certificate. If the UA uses a cached certificate in a request and receives a 493 (Undecipherable) response, it SHOULD remove the certificate it used from the cache, attempt to fetch the certificate again, and retry the original request again. This situation usually indicates that the certificate was recently updated, and that the Subscriber has not received a corresponding notification. A UA that has a presence list MAY want to subscribe to the certificates of all the presentities in the list when the UA subscribes to their presence, so that when the user wishes to contact a presentity, the UA will already have the appropriate certificate. Future specifications might consider the possibility of retrieving the certificates along with the presence documents. 5. UA Behavior with Credentials UAs discover their own credentials by subscribing to their AOR with an event type of credential as described in Section 8. After a UA registers, it SHOULD retrieve its credentials. There are several different cases in which a UA should generate a new credential: o If the UA receives a NOTIFY for the credential package with no body. o If the certificate has expired. o If the certificate is within ten minutes of expiring, the UA SHOULD attempt to create replacement credentials. The UA does this by waiting a random amount of time between 0 and 600 seconds. If no new credentials was received in that time, the UA creates new credentials to replace the expiring ones, and sends them in a PUBLISH request (with a SIP-If-Match header set to the current entity-tag). This makes credential collisions both unlikely and harmless. Jennings & Peterson Expires August 20, 2005 [Page 7] Internet-Draft SIP Certificates February 2005 o If the user of the device has indicated via the user interface that they wish to revoke the current certificate and issue a new one. Credentials are created by creating a new key pair which will require appropriate randomness, creating a certificate as described in Section 10.6, and encrypting the private key with a pass phrase supplied by the user. Then the UA can change the user's credential by sending the server a PUBLISH[3] with an event type of credential that contains a multipart/mixed containing both an application/pkix-cert and an application/pkcs8 body. The PUBLISH request MUST include a SIP-If-Match header field with the previous entity-tag know to the subscriber. This prevents multiple User Agents for the same AOR from publishing conflicting credentials. If a UA wishes to revoke the existing certificate without publishing a new one, it MUST send a PUBLISH with an empty body to the credential server. 6. Credential Service Behavior The Credential Service stores credentials for users and can provide the credentials to other user agents belonging to the same user, and certificates to any user agent. The credentials are indexed by a URI that corresponds to the AOR of the user. When a UA requests a public certificate with a SUBSCRIBE, the server sends the UA the certificate in a NOTIFY and sends a subsequent NOTIFY any time the certificate changes. When a credential is requested, the Credential Service digest challenges the requesting UA to authenticate it so that the Credential Service can verify that the UA is authorized to receive the requested credentials. When a credential is published, the Credential Service digest challenges the requesting UA to authenticate it so that the Credential Service can verify that the UA is authorized to change the credentials. This behavior is defined in Section 7 and Section 8. 7. Event Package Formal Definition for "certificate" 7.1 Event Package Name This document defines a SIP Event Package as defined in RFC 3265 [4]. The event-package token name for this package is: certificate 7.2 Event Package Parameters This package does not define any event package parameters. Jennings & Peterson Expires August 20, 2005 [Page 8] Internet-Draft SIP Certificates February 2005 7.3 SUBSCRIBE Bodies This package does not define any SUBSCRIBE bodies. 7.4 Subscription Duration Subscriptions to this event package can range from no time to weeks. Subscriptions in days are more typical and are RECOMMENDED. The default subscription duration for this event package is one day. The Credential Service is encouraged to keep the subscriptions active for AORs that are communicating frequently, but the Credential Service MAY terminate the subscription at any point in time. 7.5 NOTIFY Bodies The body of a NOTIFY request for this package MUST either be empty or contain an application/pkix-cert body (as defined in [10]) that contains the certificate, unless an Accept header has negotiated some other type. The Content-Disposition MUST be set to "signal". A future extension MAY define other NOTIFY bodies. If no "Accept" header is present in the SUBSCRIBE, the body type defined in this document MUST be assumed. Implementations which generate large notifications are reminded to follow the message size restrictions for unreliable transports articulated in Section 18.1.1 of SIP. 7.6 Subscriber Generation of SUBSCRIBE Requests UAs discover certificates by sending a SUBSCRIBE with an event type of "certificate" to the AOR for which a certificate is desired. In general, the UA stays subscribed to the certificate for as long as it plans to use and cache the certificate, so that the UA can be notified about changes or revocations to the certificate. Subscriber User Agents will typically SUBSCRIBE to certificate information for a period of hours or days, and automatically attempt to re-SUBSCRIBE just before the subscription is completely expired. When a user de-registers from a device (logoff, power down of a mobile device, etc.), subscribers SHOULD unsubscribe by sending a SUBSCRIBE message with an Expires header of zero. 7.7 Notifier Processing of SUBSCRIBE Requests When a SIP Credential Server receives a SUBSCRIBE request with the Jennings & Peterson Expires August 20, 2005 [Page 9] Internet-Draft SIP Certificates February 2005 certificate event-type, it is not necessary to authenticate the subscription request. The Notifier MAY limit the duration of the subscription to an administrator-defined period of time. The duration of the subscription does not correspond in any way to the period for which the certificate will be valid. When the Credential Service receives a SUBSCRIBE for a certificate, it first checks to see if it has credentials for the requested URI. If it does not have a certificate, it returns a NOTIFY request with an empty message body. 7.8 Notifier Generation of NOTIFY Requests Immediately after a subscription is accepted, the Notifier MUST send a NOTIFY with the current certificate, or an empty body if no certificate is available for the target user. In either case it forms a NOTIFY with the From header field value set to the AOR of the resource being subscribed to. This server sending the NOTIFY needs either to implement an Authentication Service (as described in SIP Identity [2]) or else the server needs to be set up such that the NOFIFY will be sent through an Authentication Service. Sending the NOTIFY through the the Authentication Service requires the SUBSCRIBE to have been routed through the Authentication Service, since the NOTIFY is sent within the dialog formed by the SUBSCRIBE. 7.9 Subscriber Processing of NOTIFY Requests The resulting NOTIFY will contain an application/pkix-cert body which contains the requested certificate. The UA MUST follow the procedures in Section 10.3 to decide if the received certificate can be used. The UA needs to cache this certificate for future use. The maximum length of time it should be cached for is discussed in Section 10.1 . The certificate MUST be removed from the cache if the certificate has been revoked (if a NOTIFY with an empty body is received), or if it is updated by a subsequent NOTIFY. The UA MUST check that the NOTIFY is correctly signed by an Authentication Service as described in [2]. If the identity asserted by the Authentication Service does not match the AOR that the UA subscribed to, the certificate in the NOTIFY is discarded and MUST NOT be used. 7.10 Handling of Forked Requests This event package does not permit forked requests. At most one subscription to this event type is permitted per resource. 7.11 Rate of Notifications Notifiers SHOULD NOT generate NOTIFY requests more frequently than Jennings & Peterson Expires August 20, 2005 [Page 10] Internet-Draft SIP Certificates February 2005 once per minute. 7.12 State Agents and Lists Implementers MUST NOT implement state agents for this event type. Likewise, implementations MUST NOT use the event list extension [19] with this event type. It is not possible to make such an approach work, because the Authentication service would have to simultaneously assert several different identities. 7.13 Behavior of a Proxy Server There are no additional requirements on a SIP Proxy, other than to transparently forward the SUBSCRIBE and NOTIFY methods as required in SIP. This specification describes the Proxy, Authentication service, and Credential service as three separate services but it is certainly possible to build a single sip network element that performs all of these services at the same time. 8. Event Package Formal Definition for "credential" 8.1 Event Package Name This document defines a SIP Event Package as defined in RFC 3265 [4]. The event-package token name for this package is: credential 8.2 Event Package Parameters This package defines the "etag" Event header parameter which is valid only in NOTIFY requests. It contains a token which represents the SIP entity-tag value at the time the notification was sent. Considering how infrequently credentials are updated, this hint is very likely to be the correct entity-tag to use in the SIP-If-Match header in a SIP PUBLISH request to update the current credentials. etag-param = "etag" EQUAL token 8.3 SUBSCRIBE Bodies This package does not define any SUBSCRIBE bodies. 8.4 Subscription Duration Subscriptions to this event package can range from hours to one week. Jennings & Peterson Expires August 20, 2005 [Page 11] Internet-Draft SIP Certificates February 2005 Subscriptions in days are more typical and are RECOMMENDED. The default subscription duration for this event package is one day. The Credential Service SHOULD keep subscriptions active for UAs that are currently registered. 8.5 NOTIFY Bodies The NOTIFY MUST contain a multipart/mixed (see [14]) body that contains both an application/pkix-cert body with the certificate and an application/pkcs8 body that has the associated private key information for the certificate. The Content-Disposition MUST be set to "signal". A future extension MAY define other NOTIFY bodies. If no "Accept" header is present in the SUBSCRIBE, the body type defined in this document MUST be assumed. The application/pkix-cert body is a DER encoded X.509v3 certificate [10]. The application/pkcs8 body contains a DER-encoded PKCS#8 [1] object that contains the private key. contains the private key. The PKCS#8 objects MUST be of type PrivateKeyInfo. The integrity and confidentiality of the PKCS#8 objects is provided by the TLS transport. The transport encoding of all the MIME bodies is binary. 8.6 Subscriber Generation of SUBSCRIBE Requests A Subscriber User Agent will SUBSCRIBE to its credential information for a period of hours or days and will automatically attempt to re-SUBSCRIBE before the subscription has completely expired. The Subscriber SHOULD SUBSCRIBE to its credentials whenever a new user becomes associated with the device (a new login). The subscriber SHOULD also renew its subscription immediately after a reboot, or when the subscriber's network connectivity has just been re-established. The UA needs to authenticate with the Credential Service for these operations. The UA MUST use TLS to connect to the server. The UA may be configured with a specific name for the Credential Service; otherwise normal SIP routing is used. As described in RFC 3261, the TLS connection needs to present a certificate that matches the expected name of the server to which the connection was formed, so that the UA knows it is talking to the correct server. Failing to do this may result in the UA publishing its private key information to an attacker. The Credential Service will authenticate the UA using the usual SIP Digest mechanism, so the UA can expect to receive a SIP challenge to the SUBSCRIBE or PUBLISH messages. Jennings & Peterson Expires August 20, 2005 [Page 12] Internet-Draft SIP Certificates February 2005 8.7 Notifier Processing of SUBSCRIBE Requests When a Credential Service receives a SUBSCRIBE for a credential, the Credential Service has to authenticate and authorize the UA and validate that adequate transport security is being used. Only a UA that can authenticate as being able to register as the AOR is authorized to receive the credentials for that AOR. The Credential Service MUST digest challenge the UA to authenticate the UA and then decide if it is authorized to receive the credentials. If authentication is successful, the Notifier MAY limit the duration of the subscription to an administrator-defined period of time. The duration of the subscription MUST not be larger than the length of time for which the certificate is still valid. The Expires header should be set appropriately. 8.8 Notifier Generation of NOTIFY Requests Once the UA has authenticated with the Credential Service and the subscription is accepted, the Credential Service MUST immediately send a Notify message. The Notifier SHOULD include the current entity-tag value in the "etag" Event package parameter in the NOTIFY request. The Authentication Service is applied to this NOTIFY message in the same way as the certificate subscriptions. If the credential is revoked, the Credential Service MUST terminate any current subscriptions and force the UA to re-authenticate by sending a NOTIFY with its Subscription-State header set to "terminated" and a reason parameter of "deactivated". (This causes a Subscriber to retry the subscription immediately.) This is so that if a secret for retrieving the credentials gets compromised, the rogue UA will not continue to receive credentials after the compromised secret has been changed. Any time the credentials for this URI change, the Credential Service MUST send a new NOTIFY to any active subscriptions with the new credentials. 8.9 Notifier Processing of PUBLISH Requests When the Credential Service receives a PUBLISH to update credentials, it MUST authenticate and authorize this request the same way as for subscriptions for credentials. If this succeeds, the Credential Service updates the credential for this URI, processes all the active certificate and credential subscriptions to this URI, and generates a NOTIFY request with the new credential or certificate. If the Subscriber submits a PUBLISH requests with no body, this revokes the current credentials and causes all subscriptions to the credential package to be deactivated as described in the previous section. Jennings & Peterson Expires August 20, 2005 [Page 13] Internet-Draft SIP Certificates February 2005 (Note that subscriptions to the certificate package are NOT terminated, each subscriber to the certificate package receives a notification with an empty body.) 8.10 Subscriber Processing of NOTIFY Requests When the UA receives a valid NOTIFY request, it should replace its existing credentials with the new received ones. If the UA cannot decrypt the PKCS#8 object with the private key, it MUST send a 493 Undecipherable response. Later if the user provides a new pass phrase for the private key, the UA can subscribe to the credentials again and attempt to decrypt with the new pass phrase. 8.11 Handling of Forked Requests This event package does not permit forked requests. 8.12 Rate of Notifications Notifiers SHOULD NOT generate NOTIFY requests more frequently than once per minute. 8.13 State Agents and Lists Implementers MUST NOT implement state agents for this event type. Likewise, implementations MUST NOT use the event list extension [19] with this event type. 8.14 Behavior of a Proxy Server The behavior is identical to behavior described for certificate subscriptions described in Section 7.13. 9. Examples In all these examples, large parts of the message are omitted to highlight what is relevant to this draft. The lines in the examples that are prefixed by $ represent encrypted blocks of data. 9.1 Encrypted Page Mode IM Message In this example, Alice sends Bob an encrypted page mode instant message. Alice does not already have Bob's public key from previous communications, so she fetches Bob's public key from Bob's Credential Service: SUBSCRIBE sip:bob@biloxi.example.com SIP/2.0 Jennings & Peterson Expires August 20, 2005 [Page 14] Internet-Draft SIP Certificates February 2005 ... Event: certificate The Credential Service responds with the certificate in a NOTIFY. NOTIFY alice@atlanta.example.com SIP/2.0 Subscription-State: active; expires=7200 .... From: ;tag=1234 Identity: "12dsfsdk2389403823cbed" Identity-Info: sips:billoxi.example.com .... Event: certificate Content-Type: application/pkix-cert Content-Disposition: signal < certificate data > Next, Alice sends a SIP MESSAGE message to Bob and can encrypt the body using Bob's public key as shown below. Although outside the scope of this document, it is worth noting that instant messages often have common plain text like "Hi", so that setting up symmetric keys for extended session mode IM conversations will likely increase efficiency, as well as reducing the likelihood of compromising the asymmetric key in the certificate. MESSAGE sip:bob@biloxi.example.com SIP/2.0 ... Content-Type: application/pkcs7-mime Content-Disposition: render $ Content-Type: text/plain $ $ < encrypted version of "Hello" > 9.2 Setting and Retrieving UA Credentials When Alice's UA wishes to publish Alice's public and private keys to the Credential Service, it sends a PUBLISH message like the one below. This must be sent over a TLS connection in which the other end of the connection presents a certificate that matches the Credential Service for Alice and digest challenges the message to authenticate her. Jennings & Peterson Expires August 20, 2005 [Page 15] Internet-Draft SIP Certificates February 2005 PUBLISH sips:alice@atlanta.example.com SIP/2.0 ... Content-Type: multipart/mixed;boundary=boundary Content-Disposition: signal --boundary Content-ID: 123 Content-Type: application/pkix-cert < Public certificate for Alice > --boundary Content-ID: 456 Content-Type: application/pkcs8 < Private Key for Alice > --boundary If one of Alice's UAs subscribes to the credential event, the UA will be digest challenged, and the NOTIFY will include a body similar to the one in the PUBLISH section above. 10. Security Considerations The high level message flow from a security point of view is summarized in the following figure. The 200 responses are removed from the figure as they do not have much to do with the overall security. Jennings & Peterson Expires August 20, 2005 [Page 16] Internet-Draft SIP Certificates February 2005 Alice Server Bob UA | | TLS Handshake | 1) Client authC/Z server | |<---------------->| | | PUBLISH | 2) Client sends request | |<-----------------| (write credential) | | Digest Challenge | 3) Server challenges client | |----------------->| | | PUBLISH + Digest | 4) Server authC/Z client | |<-----------------| | | time... | | | | | | TLS Handshake | 5) Client authC/Z server | |<---------------->| | | SUBSCRIBE | 6) Client sends request | |<-----------------| (read credential) | | Digest Challenge | 7) Server challenges client | |----------------->| | | SUBSCRIBE+Digest | 8) Server authC/Z client | |<-----------------| | | NOTIFY | 9) Server returns credential | |----------------->| | | | SUBSCRIBE | 10) Client requests certificate |---------->| | | |NOTIFY+AUTH| 11) Server returns user's certificate and signs that |<----------| it is valid using certificate for the domain | | When the UA, labeled Bob, first created a credential for Bob, it would store this on the the server. The UA authenticated the Server using the certificates from the TLS handshake while the Server authenticated the UA using a digest style challenge with a shared secret. The UA, labeled Bob, wishes to request its credentials from the server. First it forms a TLS connection to the server with provides integrity and privacy protection and also authenticates the server to Bob's UA. Next the UA requests its credentials using a SUBSCRIBE. The Server digest challenges this to authenticate Bob's UA. The server and Bob's UA have a shared secret that is used for this. If the authentication is successful, the sever sends the credentials to Bob's UA. The private key in the credentials may have been encrypted using a shared secret that the server does not know. A similar process would be used for Bob's UA to publish new credentials to the server. The SUBSCRIBE would be a PUBLISH and there would be no NOTIFY. When this happened, all the other UAs that Jennings & Peterson Expires August 20, 2005 [Page 17] Internet-Draft SIP Certificates February 2005 were subscribed to Bob's credentials would receive a new NOTIFY with the new credentials. Alice wishes to find Bob's certificate and sends a SUBSCRIBE to the server. The server sends the response in NOTIFY. This does not need to be sent over a privacy or integrity protected channel, as the Authentication service described in [2] provides integrity protection of this information and signs it with the certificate for the domain. This whole scheme is highly dependent on trusting the operators of the Credential Service and trusting that the Credential Service will not be compromised. The security of all the users will be compromised if the Credential Service is compromised. This specification requires the TLS session to be used for SIP communications to the Credential Service. As specified in RFC 3261, TLS clients MUST check that the SubjectAltName of the certificate for the server they connected to exactly matches the server they were trying to connect to. Failing to use TLS or selecting a poor cipher suite (such as NULL encryption) will result in credentials including private key being sent unencrypted over the network and will render the whole system useless. Implementations really must use TLS or there is no point in implementing any of this. The correct checking of chained certificates as specified in TLS [11] is critical for the client to authenticate the server. If the client does not authenticate that it is talking to the correct Credential Service, a man in the middle attack is possible. 10.1 Certificate Revocation If a particular credential needs to be revoked, the new credential is simply published to the Credential Service. Every device with a copy of the old credential or certificate in its cache will have a subscription and will rapidly (order of seconds) be notified and replace its cache. Clients that are not subscribed will subscribe when they next need to use the certificate and will get the new certificate. It is possible that an attacker could mount a DOS attack such that the UA that had cached a certificate did not receive the NOTIFY with its revocation. To protect against this attack, the UA needs to limit how long it caches certificates. After this time, the UA would invalidate the cached information even though no NOTIFY had ever been received due to the attacker blocking it. The duration of this cached information is in some ways similar to a device deciding how often to check a CRL list. For many Jennings & Peterson Expires August 20, 2005 [Page 18] Internet-Draft SIP Certificates February 2005 applications, a default time of 1 day is suggested, but for some applications it may be desirable to set the time to zero so that no certificates are cached at all and the the the credential is checked for validity every time the certificate is used. 10.2 Certificate Replacement The UAs in the system replace the certificates close to the time that the certificates would expire. If a UA has used the same key pair to encrypt a very large volume of traffic, the UA MAY choose to replace the credential with a new one. 10.3 Trusting the Identity of a Certificate When a UA wishes to discover the certificate for sip:alice@example.com, the UA subscribes to the certificate for alice@example.com and receives a certificate in the body of a SIP Notify message. The term original URI is used to describe the original URI that was subscribed to. If the certificate is signed by a trusted CA, and one of the names in the SubjectAltName matches the Original URI, then this certificate MAY be used but only for exactly the original URI and not for other identities found in the SubjectAltName. Otherwise, there are several steps the UA MUST perform before using this certificate. o The From header in the NOTIFY message MUST match the original URI that was subscribed to. o The UA MUST check the Identity header as described in the Identity [2] specification to validate that bodies have not been tampered with and that an Authentication Service has validated this From header. o The UA MUST check the validity time of the certificate, and stop using the certificate if it is invalid. (Implementations are reminded to verify both the notBefore and notAfter validity times.) o The certificate MAY have several names in the SubjectAltName but the UA MUST only use this certificate when it needs the certificate for the identity asserted by the Authentication Service in the NOTIFY. This means that the certificate should only be indexed in the certificate cache by the AOR that the Authentication Service asserted and not by the value of all the identities found in the SubjectAltName list. These steps result in a chain of bindings that result in a trusted binding between the original AOR that was subscribed to and a public key. The Original AOR is forced to match the From. The Authentication Service validates that this message did come from the identity claimed in the From and that the bodies and the From have not been tampered with. The certificate in the body contains the Jennings & Peterson Expires August 20, 2005 [Page 19] Internet-Draft SIP Certificates February 2005 public key for the identity. Only the UA that can authenticate as this AOR, or devices with access to the private key of the domain, can tamper with this body. This stops other users from being able to provide a false public key. This chain of assertion from original URI, to From, to body, to public key is critical to the security of the mechanism described in this specification. If any of the steps above are not followed, this chain of security will be broken and the system will not work. 10.4 Conformity to the SACRED Framework This specification uses the security design outlined in the SACRED Framework [7]. Specifically, it follows the cTLS architecture described in section 4.2.2 of RFC 3760. The client authenticates the server using the server's TLS certificate. The server authenticates the client using a SIP digest transaction inside the TLS session. The TLS sessions form a strong session key that is used to protect the credentials being exchanged. 10.5 Crypto Profiles Credential Services SHOULD implement the server name indication extensions in RFC 3546 [8] and they MUST support a TLS profile of TLS_RSA_WITH_AES_128_CBC_SHA as described in RFC 3268 [9] and a profile of TLS_RSA_WITH_3DES_EDE_SHA. The PKCS#8 in the clients MUST implement PBES2 with a key derivation algorithm of PBKDF2 using HMAC with SHA1 and an encryption algorithm of DES-EDE2-CBC-Pad as defined in RFC 2898 [12]. It is RECOMMENDED that this profile be used when using PKCS#8. 10.6 User Certificate Generation The certificates should be consistent with RFC 3280 [13]. A signatureAlgorithm of sha1WithRSAEncryption MUST be implemented. The Issuers SHOULD be the same as the subject. Given the ease of issuing new certificates with this system, the Validity can be relatively short. A Validity of one year or less is RECOMMENDED. The subjectAltName must have a URI type that is set to the SIP URL corresponding to the user AOR. It MAY be desirable to put some randomness into the length of time for which the certificates are valid so that it does not become necessary to renew all the certificates in the system at the same time. 10.7 Compromised Authentication Service One of this worst attacks against this system is if the Authentication Service were compromised. This attack is somewhat Jennings & Peterson Expires August 20, 2005 [Page 20] Internet-Draft SIP Certificates February 2005 analogous to a CA being compromised in traditional PKI systems. The attacker could make a fake certificate for which it knows the private key, use it to receive any traffic for a given use, and then re-encrypt that traffic with the correct key and forward the communication to the intended receiver. The attacker would thus become a man in the middle in the communications. There is not too much that can be done to protect against this. A UA MAY subscribe to its own certificate under some other identity to try to detect whether the Credential server is handing out the correct certificates. It will be difficult to do this in a way that does not allow the Credential server to recognize the user's UA. The UA MAY also save the fingerprints of the cached certificates and warn users when the certificates change resulting in a system that was secure other than an leap of faith when the certificate first arrives or is changed. The UA MAY also allow the user to see the fingerprints for the cached certificates so that they can be verified by some other out of band means. 11. IANA Considerations This specification defines two new event packages that IANA is requested to add the registry at http://www.iana.org/assignments/sip-events It also defines a new mime type that IANA is requested to add to the registry at http://www.iana.org/assignments/media-types/application. 11.1 Certificate Event Package To: ietf-sip-events@iana.org Subject: Registration of new SIP event package Package Name: certificate Is this registration for a Template Package: No Published Specification(s): This document New Event header parameters: This package defines no new parameters Person & email address to contact for further information: Cullen Jennings Jennings & Peterson Expires August 20, 2005 [Page 21] Internet-Draft SIP Certificates February 2005 11.2 Credential Event Package To: ietf-sip-events@iana.org Subject: Registration of new SIP event package Package Name: credential Is this registration for a Template Package: No Published Specification(s): This document New Event header parameters: "etag" Person & email address to contact for further information: Cullen Jennings 11.3 PKCS#8 To: ietf-types@iana.org Subject: Registration of MIME media type application/pkcs8 MIME media type name: application MIME subtype name: pkcs8 Required parameters: None Optional parameters: None Encoding considerations: The PKCS#8 object inside this MIME type MUST be DER-encoded. This MIME type was designed for use with protocols which can carry binary-encoded data. Protocols which do not carry binary data (which have line length or character-set restrictions for example) MUST use a reversible transfer encoding (such as base64) to carry this MIME type. Protocols which carry binary data SHOULD use a transfer encoding of "binary". Security considerations: Carries a cryptographic private key Interoperability considerations: None Jennings & Peterson Expires August 20, 2005 [Page 22] Internet-Draft SIP Certificates February 2005 Published specification: See reference to PKCS#8 [1] Applications which use this media type: Any MIME-compliant transport Additional information: Magic number(s): None File extension(s): .p8 Macintosh File Type Code(s): none Person & email address to contact for further information: Cullen Jennings Intended usage: COMMON Author/Change controller: the IESG 12. Acknowledgments Many thanks to Eric Rescorla, Jim Schaad, Rohan Mahy for significant help and discussion. Many others provided useful comments, including Kumiko Ono, Peter Gutmann, Russ Housley, Magnus Nystrom, Paul Hoffman, Dan Wing, Mike Hammer, Lyndsay Campbell, and Jason Fischl. Rohan Mahy and Jonathan Rosenberg provided detailed review and text. 13. References 13.1 Normative References [1] RSA Laboratories, "Private-Key Information Syntax Standard, Version 1.2", PKCS 8, November 1993. [2] Peterson, J. and C. Jennings, "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", draft-ietf-sip-identity-04 (work in progress), February 2005. [3] Niemi, A., "Session Initiation Protocol (SIP) Extension for Event State Publication", RFC 3903, October 2004. [4] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002. [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [6] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: Jennings & Peterson Expires August 20, 2005 [Page 23] Internet-Draft SIP Certificates February 2005 Session Initiation Protocol", RFC 3261, June 2002. [7] Gustafson, D., Just, M. and M. Nystrom, "Securely Available Credentials (SACRED) - Credential Server Framework", RFC 3760, April 2004. [8] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J. and T. Wright, "Transport Layer Security (TLS) Extensions", RFC 3546, June 2003. [9] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites for Transport Layer Security (TLS)", RFC 3268, June 2002. [10] Housley, R. and P. Hoffman, "Internet X.509 Public Key Infrastructure Operational Protocols: FTP and HTTP", RFC 2585, May 1999. [11] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999. [12] Kaliski, B., "PKCS #5: Password-Based Cryptography Specification Version 2.0", RFC 2898, September 2000. [13] 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. [14] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996. [15] International Telecommunications Union, "Information technology - Open Systems Interconnection - The Directory: Public-key and attribute certificate frameworks", ITU-T Recommendation X.509, ISO Standard 9594-8, March 2000. 13.2 Informational References [16] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification", RFC 3851, July 2004. [17] Peterson, J., "S/MIME Advanced Encryption Standard (AES) Requirement for the Session Initiation Protocol (SIP)", RFC 3853, July 2004. [18] Gutmann, P., "Internet X.509 Public Key Infrastructure Operational Protocols: Certificate Store Access via HTTP", Jennings & Peterson Expires August 20, 2005 [Page 24] Internet-Draft SIP Certificates February 2005 draft-ietf-pkix-certstore-http-08 (work in progress), August 2004. [19] Roach, A., Rosenberg, J. and B. Campbell, "A Session Initiation Protocol (SIP) Event Notification Extension for Resource Lists", draft-ietf-simple-event-list-07 (work in progress), January 2005. Authors' Addresses Cullen Jennings Cisco Systems 170 West Tasman Drive MS: SJC-21/2 San Jose, CA 95134 USA Phone: +1 408 921-9990 EMail: fluffy@cisco.com Jon Peterson NeuStar, Inc. 1800 Sutter St Suite 570 Concord, CA 94520 US Phone: +1 925/363-8720 EMail: jon.peterson@neustar.biz URI: http://www.neustar.biz/ Jennings & Peterson Expires August 20, 2005 [Page 25] Internet-Draft SIP Certificates February 2005 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 (2005). 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. Jennings & Peterson Expires August 20, 2005 [Page 26]