From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc6072.txt | 1683 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1683 insertions(+) create mode 100644 doc/rfc/rfc6072.txt (limited to 'doc/rfc/rfc6072.txt') diff --git a/doc/rfc/rfc6072.txt b/doc/rfc/rfc6072.txt new file mode 100644 index 0000000..dd6a30e --- /dev/null +++ b/doc/rfc/rfc6072.txt @@ -0,0 +1,1683 @@ + + + + + + +Internet Engineering Task Force (IETF) C. Jennings +Request for Comments: 6072 Cisco Systems +Category: Standards Track J. Fischl, Ed. +ISSN: 2070-1721 Skype + February 2011 + + +Certificate Management Service for the Session Initiation Protocol (SIP) + +Abstract + + This document defines a credential service that allows Session + Initiation Protocol (SIP) User Agents (UAs) to use a SIP event + 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, which returns an authenticated response + containing that certificate. The credential service also allows + users to store and retrieve their own certificates and private keys. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc6072. + + + + + + + + + + + + + + + + + + +Jennings & Fischl Standards Track [Page 1] + +RFC 6072 SIP Certificates February 2011 + + +Copyright Notice + + Copyright (c) 2011 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + + This document may contain material from IETF Documents or IETF + Contributions published or made publicly available before November + 10, 2008. The person(s) controlling the copyright in some of this + material may not have granted the IETF Trust the right to allow + modifications of such material outside the IETF Standards Process. + Without obtaining an adequate license from the person(s) controlling + the copyright in such materials, this document may not be modified + outside the IETF Standards Process, and derivative works of it may + not be created outside the IETF Standards Process, except to format + it for publication as an RFC or to translate it into languages other + than English. + +Table of Contents + + 1. Introduction ....................................................3 + 2. Definitions .....................................................4 + 3. Overview ........................................................4 + 4. UA Behavior with Certificates ...................................7 + 5. UA Behavior with Credentials ....................................8 + 6. Event Package Formal Definition for "certificate" ...............9 + 6.1. Event Package Name .........................................9 + 6.2. SUBSCRIBE Bodies ...........................................9 + 6.3. Subscription Duration .....................................10 + 6.4. NOTIFY Bodies .............................................10 + 6.5. Subscriber Generation of SUBSCRIBE Requests ...............10 + 6.6. Notifier Processing of SUBSCRIBE Requests .................11 + 6.7. Notifier Generation of NOTIFY Requests ....................11 + 6.8. Subscriber Processing of NOTIFY Requests ..................11 + 6.9. Handling of Forked Requests ...............................11 + 6.10. Rate of Notifications ....................................12 + 6.11. State Agents and Lists ...................................12 + 6.12. Behavior of a Proxy Server ...............................12 + + + + +Jennings & Fischl Standards Track [Page 2] + +RFC 6072 SIP Certificates February 2011 + + + 7. Event Package Formal Definition for "credential" ...............12 + 7.1. Event Package Name ........................................12 + 7.2. SUBSCRIBE Bodies ..........................................12 + 7.3. Subscription Duration .....................................12 + 7.4. NOTIFY Bodies .............................................13 + 7.5. Subscriber Generation of SUBSCRIBE Requests ...............13 + 7.6. Notifier Processing of SUBSCRIBE Requests .................14 + 7.7. Notifier Generation of NOTIFY Requests ....................14 + 7.8. Generation of PUBLISH Requests ............................15 + 7.9. Notifier Processing of PUBLISH Requests ...................15 + 7.10. Subscriber Processing of NOTIFY Requests .................16 + 7.11. Handling of Forked Requests ..............................16 + 7.12. Rate of Notifications ....................................16 + 7.13. State Agents and Lists ...................................16 + 7.14. Behavior of a Proxy Server ...............................16 + 8. Identity Signatures ............................................16 + 9. Examples .......................................................17 + 9.1. Encrypted Page Mode Instant Message .......................17 + 9.2. Setting and Retrieving UA Credentials .....................18 + 10. Security Considerations .......................................19 + 10.1. Certificate Revocation ...................................21 + 10.2. Certificate Replacement ..................................22 + 10.3. Trusting the Identity of a Certificate ...................22 + 10.3.1. Extra Assurance ...................................23 + 10.4. SACRED Framework .........................................24 + 10.5. Crypto Profiles ..........................................24 + 10.6. User Certificate Generation ..............................25 + 10.7. Private Key Storage ......................................25 + 10.8. Compromised Authentication Service .......................26 + 11. IANA Considerations ...........................................26 + 11.1. Certificate Event Package ................................27 + 11.2. Credential Event Package .................................27 + 11.3. Identity Algorithm .......................................27 + 12. Acknowledgments ...............................................27 + 13. References ....................................................28 + 13.1. Normative References .....................................28 + 13.2. Informative References ...................................29 + +1. Introduction + + [RFC3261], as amended by [RFC3853], provides a mechanism for end-to- + end encryption and integrity using Secure/Multipurpose Internet Mail + Extensions (S/MIME) [RFC5751]. Several security properties of + [RFC3261] depend on S/MIME, and yet it has not been widely deployed. + 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. Combined with the SIP Identity [RFC4474] specification, + + + +Jennings & Fischl Standards Track [Page 3] + +RFC 6072 SIP Certificates February 2011 + + + this specification allows users to have certificates that are not + signed by any well known certification authority while still strongly + binding the user's identity to the certificate. + + In addition, this specification provides a mechanism that 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 [RFC2119]. + + Certificate: A Public Key Infrastructure using X.509 (PKIX)- + [RFC5280] 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 document are generally self-signed + and use the mechanisms in the SIP Identity [RFC4474] specification + to vouch for their validity. Certificates that are signed by a + certification authority can also be used with all the mechanisms + in this document; however, they need not be validated by the + receiver (although the receiver can validate them for extra + assurance; see Section 10.3.1). + + Credential: For this document, "credential" means the combination of + a certificate and the associated private key. + + Password Phrase: A password used to encrypt and decrypt a PKCS #8 + (Public Key Cryptographic System #8) 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 other users' certificates using a new SIP event package [RFC3265]. + The certificate is delivered to the subscribing UA in a corresponding + SIP NOTIFY request. An authentication service as described in the + SIP Identity [RFC4474] specification can be used to vouch for the + identity of the sender of the certificate by using the sender's proxy + domain certificate to sign the NOTIFY request. The authentication + service is vouching that the sender is allowed to populate the SIP + From header field value. The sender of the message is vouching that + this is an appropriate certificate for the user identified in the SIP + From header field value. 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 + + + +Jennings & Fischl Standards Track [Page 4] + +RFC 6072 SIP Certificates February 2011 + + + PUBLISH [RFC3903] 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 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 (e.g., his laptop software client), retrieving his + credentials from another of his User Agents (e.g., 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 | + |---------->|------+------+----------------->| + + + + +Jennings & Fischl Standards Track [Page 5] + +RFC 6072 SIP Certificates February 2011 + + + Bob's UA (Bob2) does a Transport Layer Security (TLS) [RFC5246] + 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 credentials. The credential server + challenges the UA using a Digest Authentication scheme to + authenticate that the UA knows Bob's shared secret. Once the UA is + authenticated, the credential server stores Bob's credentials. + + Another of Bob's User Agents (Bob1) wants to fetch its current + credentials. It does a TLS [RFC5246] 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 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 + registers 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 or so that + she can verify the signature on a message from Bob. 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 "authentication service" as + defined in [RFC4474]. The credential server returns a NOTIFY 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. + + It is critical to understand that the only way that Alice can trust + that the certificate really is the one for Bob and that the NOTIFY + has not been spoofed is for Alice to check that the Identity + [RFC4474] header field value is correct. + + The mechanism described in this document works for both self-signed + certificates and certificates signed by well known certification + authorities. In order to deploy certificates signed by well known + certification authorities, certification authorities would have to + support adding SIP URIs to the SubjectAltName of the certificates + they generate. This is something that has been rarely implemented by + commercial certification authorities. However, most UAs would only + use self-signed certificates and would use an authentication service + as described in [RFC4474] to provide a strong binding of an AOR to + the certificates. + + + +Jennings & Fischl Standards Track [Page 6] + +RFC 6072 SIP Certificates February 2011 + + + The mechanisms described in this document allow for three different + styles of deployment: + + 1. Deployments where the credential server only stores certificates + and does not store any private key information. If the + deployment had users with multiple devices, some other scheme + (perhaps even manual provisioning) would be used to get the right + private keys onto all the devices that a user employs. + + 2. Deployments where the credential server stores certificates and + also stores an encrypted version of the private keys. The + credential server would not know or need the password phrase for + decrypting the private key. The credential server would help + move the private keys between devices, but the user would need to + enter a password phrase on each device to allow that device to + decrypt (and encrypt) the private key information. + + 3. Deployments where the credential server generates and stores the + certificates and private keys. Deployments such as these may not + use password phrases. Consequently, the private keys are not + encrypted inside the PKCS #8 objects. This style of deployment + would often have the credential server, instead of the devices, + create the credentials. + +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 6 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. + If the certificate is renewed before it expires, the Notifier will + send a notification with a body containing the new certificate. Note + that the Subscriber might not receive the notification if an attacker + blocks this traffic. The amount of time that the Subscriber caches a + certificate SHOULD be configurable. A default of one day is + RECOMMENDED. + + Note that the actual duration of the subscription is unrelated to the + caching time or validity time of the corresponding certificate. + Allowing subscriptions to persist after a certificate is no longer + valid ensures that Subscribers receive the replacement certificate in + a timely fashion. The Notifier could return an immediate + + + +Jennings & Fischl Standards Track [Page 7] + +RFC 6072 SIP Certificates February 2011 + + + notification with the certificate in response to a subscribe request + and then immediately terminate subscription, setting the reason + parameter to "probation". The Subscriber will have to periodically + poll the Notifier to verify the validity of the certificate. + + If the UA uses a cached certificate in a request and receives a 437 + (Unsupported Certificate) response, it SHOULD remove the certificate + it used from the cache and attempt to fetch the certificate again. + If the certificate is changed, then the UA SHOULD retry the original + request with the new certificate. This situation usually indicates + that the certificate was recently updated, and that the Subscriber + has not received a corresponding notification. If the certificate + fetched is the same as the one that was previously in the cache, then + the UA SHOULD NOT try the request again. This situation can happen + when the request is retargeted to a different user than the original + request. The 437 response is defined in [RFC4474]. + + Note: 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. + + The details of how a UA deals with receiving encrypted messages is + outside the scope of this specification. It is worth noting that if + Charlie's User Agent Server (UAS) receives a request that is + encrypted to Bob, it would be valid and legal for that UA to send a + 302 redirecting the call to Bob. + +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 7. After a UA + registers, it SHOULD retrieve its credentials by subscribing to them + as described in Section 6.5. + + When a UA discovers its credential, the private key information might + be encrypted with a password phrase. The UA SHOULD request that the + user enter the password phrase on the device, and the UA MAY cache + this password phrase for future use. + + + + + + + + + + +Jennings & Fischl Standards Track [Page 8] + +RFC 6072 SIP Certificates February 2011 + + + There are several different cases in which a UA should generate a new + credential: + + o If the UA receives a NOTIFY with no body for the credential + package. + + o If the certificate has expired. + + o If the certificate's notAfter date is within the next 600 seconds, + the UA SHOULD attempt to create replacement credentials. The UA + does this by waiting a random amount of time between 0 and + 300 seconds. If no new credentials have been received in that + time, the UA creates new credentials to replace the expiring ones + and sends them in a PUBLISH request following the rules for + modifying event state as described in Section 4.4 of [RFC3903]. + + 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 constructing a new key pair that will + require appropriate randomness as described in [RFC4086] and then + creating a certificate as described in Section 10.6. The UA MAY + encrypt the private key with a password phrase supplied by the user + as specified in Section 10.5. Next, the UA updates the user's + credential by sending a PUBLISH [RFC3903] request with the + credentials or just the certificate as described in Section 7.8. + + 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. Event Package Formal Definition for "certificate" + +6.1. Event Package Name + + This document defines a SIP event package as defined in [RFC3265]. + The event-package token name for this package is: + + certificate + +6.2. SUBSCRIBE Bodies + + This package does not define any SUBSCRIBE bodies. + + + + + + + +Jennings & Fischl Standards Track [Page 9] + +RFC 6072 SIP Certificates February 2011 + + +6.3. 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. + +6.4. 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 [RFC2585]) that + contains the certificate, unless an Accept header field has + negotiated some other type. The Content-Disposition MUST be set to + "signal" as defined in [RFC3204]. + + A future extension MAY define other NOTIFY bodies. If no "Accept" + header field is present in the SUBSCRIBE, the body type defined in + this document MUST be assumed. + + Implementations that generate large notifications are reminded to + follow the message size restrictions for unreliable transports + articulated in Section 18.1.1 of [RFC3261]. + +6.5. Subscriber Generation of SUBSCRIBE Requests + + A UA discovers a certificate by sending a SUBSCRIBE request 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 request with an Expires header field of zero. + + + + + + + + + + +Jennings & Fischl Standards Track [Page 10] + +RFC 6072 SIP Certificates February 2011 + + +6.6. Notifier Processing of SUBSCRIBE Requests + + When a SIP credential server receives a SUBSCRIBE request with the + 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 server receives a SUBSCRIBE request 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. + +6.7. 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 value of + the To header field in the SUBSCRIBE request. This server sending + the NOTIFY needs either to implement an authentication service (as + described in SIP Identity [RFC4474]) or else the server needs to be + set up such that the NOTIFY request will be sent through an + authentication service. Sending the NOTIFY request through the + authentication service requires the SUBSCRIBE request to have been + routed through the authentication service, since the NOTIFY is sent + within the dialog formed by the subscription. + +6.8. Subscriber Processing of NOTIFY Requests + + The resulting NOTIFY will contain an application/pkix-cert body that + 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 for which it should be cached 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 [RFC4474]. 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. + +6.9. Handling of Forked Requests + + This event package does not permit forked requests. At most one + subscription to this event type is permitted per resource. + + + +Jennings & Fischl Standards Track [Page 11] + +RFC 6072 SIP Certificates February 2011 + + +6.10. Rate of Notifications + + Notifiers SHOULD NOT generate NOTIFY requests more frequently than + once per minute. + +6.11. State Agents and Lists + + The credential server described in this section that serves + certificates is a state agent as defined in [RFC3265], and + implementations of the credential server MUST be implemented as a + state agent. + + Implementers MUST NOT use the event list extension [RFC4662] 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. + +6.12. Behavior of a Proxy Server + + There are no additional requirements on a SIP proxy, other than to + transparently forward the SUBSCRIBE and NOTIFY requests 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. + +7. Event Package Formal Definition for "credential" + +7.1. Event Package Name + + This document defines a SIP event package as defined in [RFC3265]. + The event-package token name for this package is: + + credential + +7.2. SUBSCRIBE Bodies + + This package does not define any SUBSCRIBE bodies. + +7.3. Subscription Duration + + Subscriptions to this event package can range from hours to one week. + 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. + + + + +Jennings & Fischl Standards Track [Page 12] + +RFC 6072 SIP Certificates February 2011 + + +7.4. NOTIFY Bodies + + An implementation compliant to this specification MUST support the + multipart/mixed type (see [RFC2046]). This allows a notification to + contain multiple resource documents including at a minimum the + application/pkix-cert body with the certificate and an application/ + pkcs8 body that has the associated private key information for the + certificate. The application/pkcs8 media type is defined in + [RFC5958]. + + The absence of an Accept header in the SUBSCRIBE indicates support + for multipart/mixed and the content types application/pkix-cert and + application/pkcs8. If an Accept header is present, these types MUST + be included, in addition to any other types supported by the client. + + The application/pkix-cert body is a Distinguished Encoding Rules + (DER)-encoded X.509v3 certificate [RFC2585]. The application/pkcs8 + body contains a DER-encoded [RFC5958] object that contains the + private key. The PKCS #8 objects MUST be of type PrivateKeyInfo. + The integrity and confidentiality of the PKCS #8 objects are provided + by the TLS transport. The transport encoding of all the MIME bodies + is binary. + +7.5. 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 directly connect to the server + acting as the credential service or to a server that is authoritative + for the domain of the credential service. The UA MUST NOT connect + through an intermediate proxy to the credential service. 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 + + + + + + + + +Jennings & Fischl Standards Track [Page 13] + +RFC 6072 SIP Certificates February 2011 + + + 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 requests. + +7.6. 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 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 field SHOULD be set + so that it is not longer than the notAfter date in the certificate. + +7.7. 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 request. The authentication service is applied to this + NOTIFY request 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 field set to "terminated" + and a reason parameter set to "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. + + The notification MUST be sent over TLS so that it is integrity + protected, and the TLS needs to be directly connected between the UA + and the credential service with no intermediaries. + + + + + + + +Jennings & Fischl Standards Track [Page 14] + +RFC 6072 SIP Certificates February 2011 + + +7.8. Generation of PUBLISH Requests + + A User Agent SHOULD be configurable to control whether it publishes + the credential for a user or just the user's certificate. + + When publishing just a certificate, the body contains an application/ + pkix-cert. When publishing a credential, the body contains a + multipart/mixed containing both an application/pkix-cert and an + application/pkcs8 body. + + When the UA sends the PUBLISH [RFC3903] request, it needs to do the + following: + + o The UA MUST use TLS to directly connect to the server acting as + the credential service or to a server that is authoritative for + the domain of the credential service. The UA MUST NOT connect + through an intermediate proxy to the credential service. + + o The Expires header field value in the PUBLISH request SHOULD be + set to match the time for which the certificate is valid. + + o If the certificate includes Basic Constraints, it SHOULD set the + cA boolean to false. + +7.9. Notifier Processing of PUBLISH Requests + + When the credential service receives a PUBLISH request to update + credentials, it MUST authenticate and authorize this request in the + same way as for subscriptions for credentials. If the authorization + succeeds, then the credential service MUST perform the following + checks on the certificate: + + o The notBefore validity time MUST NOT be in the future. + + o The notAfter validity time MUST be in the future. + + o If a cA BasicConstraints boolean is set in the certificate, it is + set to FALSE. + + If all of these succeed, the credential service updates the + credential for this URI, processes all the active certificates and + credential subscriptions to this URI, and generates a NOTIFY request + with the new credential or certificate. Note the SubjectAltName + SHOULD NOT be checked, as that would restrict which certificates + could be used and offers no additional security guarantees. + + + + + + +Jennings & Fischl Standards Track [Page 15] + +RFC 6072 SIP Certificates February 2011 + + + If the Subscriber submits a PUBLISH request with no body and + Expires=0, this revokes the current credentials. Watchers of these + credentials will receive an update with no body, indicating that they + MUST stop any previously stored credentials. Note that subscriptions + to the certificate package are NOT terminated; each Subscriber to the + certificate package receives a notification with an empty body. + +7.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, it MUST send a 437 (Unsupported + Certificate) response. Later, if the user provides a new password + phrase for the private key, the UA can subscribe to the credentials + again and attempt to decrypt with the new password phrase. + +7.11. Handling of Forked Requests + + This event package does not permit forked requests. + +7.12. Rate of Notifications + + Notifiers SHOULD NOT generate NOTIFY requests more frequently than + once per minute. + +7.13. State Agents and Lists + + The credential server described in this section which serves + credentials is a state agent, and implementations of the credential + server MUST be implemented as a state agent. + + Implementers MUST NOT use the event list extension [RFC4662] with + this event type. + +7.14. Behavior of a Proxy Server + + The behavior is identical to behavior described for certificate + subscriptions in Section 6.12. + +8. Identity Signatures + + The [RFC4474] authentication service defined a signature algorithm + based on SHA-1 called rsa-sha1. This specification adds a signature + algorithm that is roughly the same but based on SHA-256 and called + rsa-sha256. + + + + + + +Jennings & Fischl Standards Track [Page 16] + +RFC 6072 SIP Certificates February 2011 + + + When using the rsa-sha256 algorithm, the signature MUST be computed + in exactly the same way as described in Section 9 of [RFC4474] with + the exception that instead of using sha1WithRSAEncryption, the + computation is done using sha256WithRSAEncryption as described in + [RFC5754]. + + Implementations of this specification MUST implement both rsa-sha1 + and rsa-sha256. The IANA registration for rsa-sha256 is defined in + Section 11.3. + +9. Examples + + In all of these examples, large parts of the messages are omitted to + highlight what is relevant to this document. The lines in the + examples that are prefixed by $ represent encrypted blocks of data. + +9.1. Encrypted Page Mode Instant 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 + ... + 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: ".... stuff removed ...." + Identity-Info: ;alg=rsa-sha256 + .... + Event: certificate + Content-Type: application/pkix-cert + Content-Disposition: signal + + < certificate data > + + + + + + + + + + +Jennings & Fischl Standards Track [Page 17] + +RFC 6072 SIP Certificates February 2011 + + + Next, Alice sends a SIP MESSAGE to Bob and can encrypt the body using + Bob's public key as shown below. + + 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 certificate and private key + to the credential service, it sends a PUBLISH request like the one + below. This must be sent over a TLS connection directly to the + domain of the credential service. The credential service presents a + certificate where the SubjectAltName contains an entry that matches + the domain name in the request line of the PUBLISH request and + challenges the request to authenticate her. + + PUBLISH sips:alice@atlanta.example.com SIP/2.0 + ... + Event: credential + 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 + credential service will challenge the request to authenticate her, + and the NOTIFY will include a body similar to the one in the PUBLISH + example above. + + + + + + + +Jennings & Fischl Standards Track [Page 18] + +RFC 6072 SIP Certificates February 2011 + + +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. + + In this figure, authC refers to authentication and authZ refers to + authorization. + + 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 credential server. The UA authenticated the + server using the certificates from the TLS handshake. 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, which + provides integrity and privacy protection and also authenticates the + + + +Jennings & Fischl Standards Track [Page 19] + +RFC 6072 SIP Certificates February 2011 + + + server to Bob's UA. Next, the UA requests its credentials using a + SUBSCRIBE request. The server challenges the SUBSCRIBE Request 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 + server 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. Bob's UA would send a PUBLISH request + containing the new credentials. When this happened, all the other + UAs that were subscribed to Bob's credentials would receive a 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 a NOTIFY. This does not + need to be sent over a privacy or integrity protected channel, as the + authentication service described in [RFC4474] 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. + + Note: There has been significant discussion of the topic of + avoiding deployments in which the credential servers store the + private keys, even in some encrypted form that the credential + server does not know how to decrypt. Various schemes were + considered to avoid this, but they all result in either moving the + problem to some other server, which does not seem to make the + problem any better, or having a different credential for each + device. For some deployments where each user has only one device, + this is fine, but for deployments with multiple devices, it would + require that when Alice went to contact Bob, Alice would have to + provide messages encrypted for all of Bob's devices. The SIPPING + Working Group did consider this architecture and decided it was + not appropriate due both to the information it revealed about the + devices and users, and to the amount of signaling required to make + it work. + + + + + + + + + + +Jennings & Fischl Standards Track [Page 20] + +RFC 6072 SIP Certificates February 2011 + + + This specification requires that TLS be used for the SIP + communications to place and retrieve a UA's private key. This + provides security in two ways: + + 1. Confidentiality is provided for the Digest Authentication + exchange, thus protecting it from dictionary attacks. + + 2. Confidentiality is provided for the private key, thus protecting + it from being exposed to passive attackers. + + In order to prevent man-in-the-middle attacks, 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. The TLS client must be directly connected to the correct server; + otherwise, any intermediaries in the TLS path can compromise the + certificate and instead provide a certificate for which the attacker + knows the private key. This may lead the UA that relies on this + compromised certificate to lose confidential information. Failing to + use TLS or selecting a poor cipher suite (such as NULL encryption) + may result in credentials, including private keys, being sent + unencrypted over the network and will render the whole system + useless. + + The correct checking of chained certificates as specified in TLS + [RFC5246] 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 denial-of-service (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 Certificate Revocation List + (CRL). For many applications, a default time of one day is + + + +Jennings & Fischl Standards Track [Page 21] + +RFC 6072 SIP Certificates February 2011 + + + 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 + credential is checked for validity every time the certificate is + used. + + The UA MUST NOT cache the certificates for a period longer than that + of the subscription duration. This is to avoid the UA using invalid + cached credentials when the Notifier of the new credentials has been + prevented from updating the UA. + +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 before the normal expiration. + +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 request. The term "original URI" is used to describe the URI + that was in the To header field value of the SUBSCRIBE request. So, + in this case, the original URI would be sip:alice@example.com. + + If the certificate is signed by a trusted certification authority, + 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 field in the NOTIFY request MUST match the + original URI that was subscribed to. + + o The UA MUST check the Identity header field as described in the + Identity [RFC4474] specification to validate that bodies have not + been tampered with and that an authentication service has + validated this From header field. + + 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.) + + + + + + +Jennings & Fischl Standards Track [Page 22] + +RFC 6072 SIP Certificates February 2011 + + + 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 header field. The + authentication service validates that this request did come from the + identity claimed in the From header field value and that the bodies + in the request that carry the certificate have not been tampered + with. The certificate in the body contains the 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.3.1. Extra Assurance + + Although the certificates used with this document need not be + validatable to a trust anchor via PKIX [RFC5280] procedures, + certificates that can be validated may also be distributed via this + mechanism. Such certificates potentially offer an additional level + of security because they can be used with the secure (and partially + isolated) certification authority user verification and key issuance + toolset, rather than depending on the security of generic SIP + implementations. + + When a relying party receives a certificate that is not self-signed, + it MAY attempt to validate the certificate using the rules in + Section 6 of [RFC5280]. If the certificate validates successfully + and the names correctly match the user's AOR (see Section 10.6), then + the implementation SHOULD provide some indication that the + certificate has been validated with an external authority. In + general, failure to validate a certificate via this mechanism SHOULD + NOT be used as a reason to reject the certificate. However, if the + certificate is revoked, then the implementation SHOULD reject it. + + + + + + + +Jennings & Fischl Standards Track [Page 23] + +RFC 6072 SIP Certificates February 2011 + + +10.4. SACRED Framework + + This specification includes a mechanism that allows end users to + share the same credentials across different end-user devices. This + mechanism is based on the one presented in the Securely Available + Credentials (SACRED) Framework [RFC3760]. While this mechanism is + fully described in this document, the requirements and background are + more thoroughly discussed in [RFC3760]. + + Specifically, Sections 7.5, 7.6, and 7.9 follow the TLS with Client + Authentication (cTLS) architecture described in Section 4.2.2 of + [RFC3760]. 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 [RFC4366]. As specified in [RFC5246], credential + services MUST support the TLS cipher suite + TLS_RSA_WITH_AES_128_CBC_SHA. In addition, they MUST support the TLS + cipher suite TLS_RSA_WITH_AES_128_CBC_SHA256 as specified in + [RFC5246]. If additional cipher suites are supported, then + implementations MUST NOT negotiate a cipher suite that employs NULL + encryption, integrity, or authentication algorithms. + + Implementations of TLS typically support multiple versions of the + Transport Layer Security protocol as well as the older Secure Socket + Layer (SSL) protocol. Because of known security vulnerabilities, + clients and servers MUST NOT request, offer, or use SSL 2.0. See + Appendix E.2 of [RFC5246] for further details. + + The PKCS #8 encryption in the clients MUST implement PBES2 with a key + derivation algorithm of PBKDF2 using HMAC. Clients MUST implement + this HMAC with both SHA-1 [RFC3370] and SHA-256 [RFC5754]. Clients + MUST implement an encryption algorithm of id-aes128-wrap-pad as + defined in [RFC5649]. Some pre-standard deployments of this + specification used DES-EDE2-CBC-Pad as defined in [RFC2898] so, for + some implementations, it may be desirable to also support that + algorithm. A different password SHOULD be used for the PKCS #8 + encryption than is used for authentication of the client. It is + important to choose sufficiently strong passwords. Specific advice + on the password can be found in Section 6 of [RFC5959]. + + + + + + +Jennings & Fischl Standards Track [Page 24] + +RFC 6072 SIP Certificates February 2011 + + +10.6. User Certificate Generation + + The certificates need to be consistent with [RFC5280]. The + sha1WithRSAEncryption and sha256WithRSAEncryption algorithms for the + signatureAlgorithm MUST be implemented. The Issuers SHOULD be the + same as the subject. Given the ease of issuing new certificates with + this system, the Validity field can be relatively short. A Validity + value 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. + + When creating a new key pair for a certificate, it is critical to + have appropriate randomness as described in [RFC4086]. This can be + challenging on some embedded devices, such as some IP phones, and + implementers should pay particular attention to this point. + + It is worth noting that a UA can discover the current time by looking + at the Date header field value in the 200 response to a REGISTER + request. + +10.7. Private Key Storage + + The protection afforded private keys is a critical security factor. + On a small scale, failure of devices to protect the private keys will + permit an attacker to masquerade as the user or decrypt their + personal information. As noted in the SACRED Framework, when stored + on an end-user device, such as a diskette or hard drive, credentials + SHOULD NOT be in the clear. It is RECOMMENDED that private keys be + stored securely in the device, more specifically, encrypting them + using tamper-resistant hardware encryption and exposing them only + when required: for example, the private key is decrypted when + necessary to generate a digital signature, and re-encrypted + immediately to limit exposure in the RAM to a short period of time. + Some implementations may limit access to private keys by prompting + users for a PIN prior to allowing access to the private key. + + + + + + + + + + + + + +Jennings & Fischl Standards Track [Page 25] + +RFC 6072 SIP Certificates February 2011 + + + On the server side, the protection of unencrypted PKCS #8 objects is + equally important. Failure of a server to protect the private keys + would be catastrophic, as attackers with access to unencrypted + PKCS #8 objects could masquerade as any user whose private key was + not encrypted. Therefore, it is also recommended that the private + keys be stored securely in the server, more specifically, encrypting + them using tamper-resistant hardware encryption and exposing them + only when required. + + FIPS 140-2 [FIPS-140-2] provides useful guidance on secure storage. + +10.8. Compromised Authentication Service + + One of the worst attacks against the Certificate Management Service + described in this document would be if the authentication service + were compromised. This attack is somewhat analogous to a + certification authority 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 type + of attack. 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 significantly before their + expiry date. + + The UA MAY also allow the user to see the fingerprints of 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 has added + to the "Session Initiation Protocol (SIP) Event Types Namespace" + registry. + + + + + + + + +Jennings & Fischl Standards Track [Page 26] + +RFC 6072 SIP Certificates February 2011 + + +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 + +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 + + Person & email address to contact for further information: + Cullen Jennings + +11.3. Identity Algorithm + + IANA added the following entry to the "Identity-Info Algorithm + Parameter Values" registry. + + "alg" Parameter Name Reference + ---------------------- --------- + rsa-sha256 [RFC6072] + +12. Acknowledgments + + Many thanks to Eric Rescorla, Russ Housley, Jim Schaad, Rohan Mahy, + and Sean Turner for significant help, discussion, and text. Many + others provided useful comments and text, including Kumiko Ono, Peter + Gutmann, Yaron Pdut, Aki Niemi, Magnus Nystrom, Paul Hoffman, Adina + Simu, Dan Wing, Mike Hammer, Pasi Eronen, Alexey Melnikov, Tim Polk, + John Elwell, Jonathan Rosenberg, and Lyndsay Campbell. + + + +Jennings & Fischl Standards Track [Page 27] + +RFC 6072 SIP Certificates February 2011 + + +13. References + +13.1. Normative References + + [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet + Mail Extensions (MIME) Part Two: Media Types", + RFC 2046, November 1996. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2585] Housley, R. and P. Hoffman, "Internet X.509 Public Key + Infrastructure Operational Protocols: FTP and HTTP", + RFC 2585, May 1999. + + [RFC3204] Zimmerer, E., Peterson, J., Vemuri, A., Ong, L., Audet, + F., Watson, M., and M. Zonoun, "MIME media types for + ISUP and QSIG Objects", RFC 3204, December 2001. + + [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., + Johnston, A., Peterson, J., Sparks, R., Handley, M., + and E. Schooler, "SIP: Session Initiation Protocol", + RFC 3261, June 2002. + + [RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific + Event Notification", RFC 3265, June 2002. + + [RFC3370] Housley, R., "Cryptographic Message Syntax (CMS) + Algorithms", RFC 3370, August 2002. + + [RFC3903] Niemi, A., "Session Initiation Protocol (SIP) Extension + for Event State Publication", RFC 3903, October 2004. + + [RFC4474] Peterson, J. and C. Jennings, "Enhancements for + Authenticated Identity Management in the Session + Initiation Protocol (SIP)", RFC 4474, August 2006. + + [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer + Security (TLS) Protocol Version 1.2", RFC 5246, + August 2008. + + [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., + Housley, R., and W. Polk, "Internet X.509 Public Key + Infrastructure Certificate and Certificate Revocation + List (CRL) Profile", RFC 5280, May 2008. + + + + + + +Jennings & Fischl Standards Track [Page 28] + +RFC 6072 SIP Certificates February 2011 + + + [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness + Requirements for Security", BCP 106, RFC 4086, + June 2005. + + [RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, + J., and T. Wright, "Transport Layer Security (TLS) + Extensions", RFC 4366, April 2006. + + [RFC5754] Turner, S., "Using SHA2 Algorithms with Cryptographic + Message Syntax", RFC 5754, January 2010. + + [RFC5649] Housley, R. and M. Dworkin, "Advanced Encryption + Standard (AES) Key Wrap with Padding Algorithm", + RFC 5649, September 2009. + + [RFC5958] Turner, S., "Asymmetric Key Packages", RFC 5958, + August 2010. + + [RFC5959] Turner, S., "Algorithms for Asymmetric Key Package + Content Type", RFC 5959, August 2010. + +13.2. Informative References + + [RFC2898] Kaliski, B., "PKCS #5: Password-Based Cryptography + Specification Version 2.0", RFC 2898, September 2000. + + [RFC3760] Gustafson, D., Just, M., and M. Nystrom, "Securely + Available Credentials (SACRED) - Credential Server + Framework", RFC 3760, April 2004. + + [RFC3853] Peterson, J., "S/MIME Advanced Encryption Standard + (AES) Requirement for the Session Initiation Protocol + (SIP)", RFC 3853, July 2004. + + [RFC4662] Roach, A., Campbell, B., and J. Rosenberg, "A Session + Initiation Protocol (SIP) Event Notification Extension + for Resource Lists", RFC 4662, August 2006. + + [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose + Internet Mail Extensions (S/MIME) Version 3.2 Message + Specification", RFC 5751, January 2010. + + [FIPS-140-2] NIST, "Security Requirements for Cryptographic + Modules", May 2001, . + + + + + + +Jennings & Fischl Standards Track [Page 29] + +RFC 6072 SIP Certificates February 2011 + + +Authors' Addresses + + Cullen Jennings + Cisco Systems + 170 West Tasman Drive + San Jose, CA 95134 + USA + + Phone: +1 408 421-9990 + EMail: fluffy@cisco.com + + + Jason Fischl (editor) + Skype + 3210 Porter Drive + Palo Alto, CA 94304 + USA + + Phone: +1-415-202-5192 + EMail: jason.fischl@skype.net + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Jennings & Fischl Standards Track [Page 30] + -- cgit v1.2.3