draft-ietf-sip-certs-09.txt   draft-ietf-sip-certs-10.txt 
Network Working Group C. Jennings Network Working Group C. Jennings
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Intended status: Standards Track J. Fischl, Ed. Intended status: Standards Track J. Fischl, Ed.
Expires: March 12, 2010 Skype Expires: September 5, 2010 Skype
September 8, 2009 March 4, 2010
Certificate Management Service for The Session Initiation Protocol (SIP) Certificate Management Service for The Session Initiation Protocol (SIP)
draft-ietf-sip-certs-09 draft-ietf-sip-certs-10
Abstract
This draft 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 Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. This document may contain material provisions of BCP 78 and BCP 79.
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.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on March 12, 2010. This Internet-Draft will expire on September 5, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents
publication of this document (http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Abstract 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 BSD License.
This draft defines a Credential Service that allows Session This document may contain material from IETF Documents or IETF
Initiation Protocol (SIP) User Agents (UAs) to use a SIP event Contributions published or made publicly available before November
package to discover the certificates of other users. This mechanism 10, 2008. The person(s) controlling the copyright in some of this
allows user agents that want to contact a given Address-of-Record material may not have granted the IETF Trust the right to allow
(AOR) to retrieve that AOR's certificate by subscribing to the modifications of such material outside the IETF Standards Process.
Credential Service, which returns an authenticated response Without obtaining an adequate license from the person(s) controlling
containing that certificate. The Credential Service also allows the copyright in such materials, this document may not be modified
users to store and retrieve their own certificates and private keys. 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 Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. UA Behavior with Certificates . . . . . . . . . . . . . . . . 9 4. UA Behavior with Certificates . . . . . . . . . . . . . . . . 8
5. UA Behavior with Credentials . . . . . . . . . . . . . . . . . 10 5. UA Behavior with Credentials . . . . . . . . . . . . . . . . . 9
6. Event Package Formal Definition for "certificate" . . . . . . 11 6. Event Package Formal Definition for "certificate" . . . . . . 10
6.1. Event Package Name . . . . . . . . . . . . . . . . . . . . 11 6.1. Event Package Name . . . . . . . . . . . . . . . . . . . . 10
6.2. Event Package Parameters . . . . . . . . . . . . . . . . . 11 6.2. SUBSCRIBE Bodies . . . . . . . . . . . . . . . . . . . . . 10
6.3. SUBSCRIBE Bodies . . . . . . . . . . . . . . . . . . . . . 11 6.3. Subscription Duration . . . . . . . . . . . . . . . . . . 10
6.4. Subscription Duration . . . . . . . . . . . . . . . . . . 11 6.4. NOTIFY Bodies . . . . . . . . . . . . . . . . . . . . . . 10
6.5. NOTIFY Bodies . . . . . . . . . . . . . . . . . . . . . . 11 6.5. Subscriber Generation of SUBSCRIBE Requests . . . . . . . 11
6.6. Subscriber Generation of SUBSCRIBE Requests . . . . . . . 12 6.6. Notifier Processing of SUBSCRIBE Requests . . . . . . . . 11
6.7. Notifier Processing of SUBSCRIBE Requests . . . . . . . . 12 6.7. Notifier Generation of NOTIFY Requests . . . . . . . . . . 11
6.8. Notifier Generation of NOTIFY Requests . . . . . . . . . . 12 6.8. Subscriber Processing of NOTIFY Requests . . . . . . . . . 12
6.9. Subscriber Processing of NOTIFY Requests . . . . . . . . . 13 6.9. Handling of Forked Requests . . . . . . . . . . . . . . . 12
6.10. Handling of Forked Requests . . . . . . . . . . . . . . . 13 6.10. Rate of Notifications . . . . . . . . . . . . . . . . . . 12
6.11. Rate of Notifications . . . . . . . . . . . . . . . . . . 13 6.11. State Agents and Lists . . . . . . . . . . . . . . . . . . 12
6.12. State Agents and Lists . . . . . . . . . . . . . . . . . . 13 6.12. Behavior of a Proxy Server . . . . . . . . . . . . . . . . 12
6.13. Behavior of a Proxy Server . . . . . . . . . . . . . . . . 13 7. Event Package Formal Definition for "credential" . . . . . . . 13
7. Event Package Formal Definition for "credential" . . . . . . . 14 7.1. Event Package Name . . . . . . . . . . . . . . . . . . . . 13
7.1. Event Package Name . . . . . . . . . . . . . . . . . . . . 14 7.2. SUBSCRIBE Bodies . . . . . . . . . . . . . . . . . . . . . 13
7.2. Event Package Parameters . . . . . . . . . . . . . . . . . 14 7.3. Subscription Duration . . . . . . . . . . . . . . . . . . 13
7.3. SUBSCRIBE Bodies . . . . . . . . . . . . . . . . . . . . . 14 7.4. NOTIFY Bodies . . . . . . . . . . . . . . . . . . . . . . 13
7.4. Subscription Duration . . . . . . . . . . . . . . . . . . 14 7.5. Subscriber Generation of SUBSCRIBE Requests . . . . . . . 13
7.5. NOTIFY Bodies . . . . . . . . . . . . . . . . . . . . . . 14 7.6. Notifier Processing of SUBSCRIBE Requests . . . . . . . . 14
7.6. Subscriber Generation of SUBSCRIBE Requests . . . . . . . 15 7.7. Notifier Generation of NOTIFY Requests . . . . . . . . . . 14
7.7. Notifier Processing of SUBSCRIBE Requests . . . . . . . . 15 7.8. Generation of PUBLISH Requests . . . . . . . . . . . . . . 15
7.8. Notifier Generation of NOTIFY Requests . . . . . . . . . . 16 7.9. Notifier Processing of PUBLISH Requests . . . . . . . . . 15
7.9. Generation of PUBLISH Requests . . . . . . . . . . . . . . 16 7.10. Subscriber Processing of NOTIFY Requests . . . . . . . . . 16
7.10. Notifier Processing of PUBLISH Requests . . . . . . . . . 17 7.11. Handling of Forked Requests . . . . . . . . . . . . . . . 16
7.11. Subscriber Processing of NOTIFY Requests . . . . . . . . . 17 7.12. Rate of Notifications . . . . . . . . . . . . . . . . . . 16
7.12. Handling of Forked Requests . . . . . . . . . . . . . . . 17 7.13. State Agents and Lists . . . . . . . . . . . . . . . . . . 16
7.13. Rate of Notifications . . . . . . . . . . . . . . . . . . 17 7.14. Behavior of a Proxy Server . . . . . . . . . . . . . . . . 16
7.14. State Agents and Lists . . . . . . . . . . . . . . . . . . 18 8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
7.15. Behavior of a Proxy Server . . . . . . . . . . . . . . . . 18 8.1. Encrypted Page Mode IM Message . . . . . . . . . . . . . . 17
8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 8.2. Setting and Retrieving UA Credentials . . . . . . . . . . 18
8.1. Encrypted Page Mode IM Message . . . . . . . . . . . . . . 18 9. Security Considerations . . . . . . . . . . . . . . . . . . . 18
8.2. Setting and Retrieving UA Credentials . . . . . . . . . . 19 9.1. Certificate Revocation . . . . . . . . . . . . . . . . . . 21
9. Security Considerations . . . . . . . . . . . . . . . . . . . 20 9.2. Certificate Replacement . . . . . . . . . . . . . . . . . 21
9.1. Certificate Revocation . . . . . . . . . . . . . . . . . . 22 9.3. Trusting the Identity of a Certificate . . . . . . . . . . 21
9.2. Certificate Replacement . . . . . . . . . . . . . . . . . 23 9.3.1. Extra Assurance . . . . . . . . . . . . . . . . . . . 22
9.3. Trusting the Identity of a Certificate . . . . . . . . . . 23 9.4. SACRED Framework . . . . . . . . . . . . . . . . . . . . . 23
9.4. SACRED Framework . . . . . . . . . . . . . . . . . . . . . 24 9.5. Crypto Profiles . . . . . . . . . . . . . . . . . . . . . 23
9.5. Crypto Profiles . . . . . . . . . . . . . . . . . . . . . 24
9.6. User Certificate Generation . . . . . . . . . . . . . . . 24 9.6. User Certificate Generation . . . . . . . . . . . . . . . 24
9.7. Compromised Authentication Service . . . . . . . . . . . . 25 9.7. Compromised Authentication Service . . . . . . . . . . . . 24
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 10.1. Certificate Event Package . . . . . . . . . . . . . . . . 25
10.1. Certificate Event Package . . . . . . . . . . . . . . . . 26 10.2. Credential Event Package . . . . . . . . . . . . . . . . . 25
10.2. Credential Event Package . . . . . . . . . . . . . . . . . 26 10.3. PKCS#8 . . . . . . . . . . . . . . . . . . . . . . . . . . 26
10.3. PKCS#8 . . . . . . . . . . . . . . . . . . . . . . . . . . 27 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 26
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 12.1. Normative References . . . . . . . . . . . . . . . . . . . 27
12.1. Normative References . . . . . . . . . . . . . . . . . . . 28 12.2. Informational References . . . . . . . . . . . . . . . . . 28
12.2. Informational References . . . . . . . . . . . . . . . . . 29 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29
1. Introduction 1. Introduction
[RFC3261], as ammended by [RFC3853], provides a mechanism for end-to- [RFC3261], as ammended by [RFC3853], provides a mechanism for end-to-
end encryption and integrity using S/MIME [RFC3851]. Several end encryption and integrity using S/MIME [RFC3851]. Several
security properties of [RFC3261] depend on S/MIME, and yet it has not security properties of [RFC3261] depend on S/MIME, and yet it has not
been widely deployed. One reason is the complexity of providing a been widely deployed. One reason is the complexity of providing a
reasonable certificate distribution infrastructure. This reasonable certificate distribution infrastructure. This
specification proposes a way to address discovery, retrieval, and specification proposes a way to address discovery, retrieval, and
management of certificates for SIP deployments. Combined with the management of certificates for SIP deployments. Combined with the
skipping to change at page 5, line 36 skipping to change at page 5, line 36
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
Certificate: A PKIX [RFC5280] style certificate containing a public Certificate: A PKIX [RFC5280] style certificate containing a public
key and a list of identities in the SubjectAltName that are bound key and a list of identities in the SubjectAltName that are bound
to this key. The certificates discussed in this draft are to this key. The certificates discussed in this draft are
generally self signed and use the mechanisms in the SIP Identity generally self signed and use the mechanisms in the SIP Identity
[RFC4474] specification to vouch for their validity. Certificates [RFC4474] specification to vouch for their validity. Certificates
that are signed by a certificate authority can also be used with that are signed by a certificate authority can also be used with
all the mechanisms in this draft, but it is expected that they are all the mechanisms in this draft, however, they need not be
used purely as a key carrier and that their validity is not validated by the receiver (although the receiver can validate them
checked. for extra assurance; see Section 9.3.1).
Credential: For this document, credential means the combination of a Credential: For this document, credential means the combination of a
certificate and the associated private key. certificate and the associated private key.
Password Phrase: A password used to encrypt a PKCS#8 private key. Password Phrase: A password used to encrypt a PKCS#8 private key.
3. Overview 3. Overview
The general approach is to provide a new SIP service referred to as a The general approach is to provide a new SIP service referred to as a
"credential service" that allows SIP User Agents (UAs) to subscribe "credential service" that allows SIP User Agents (UAs) to subscribe
to other users' certificates using a new SIP event package [RFC3265]. to other users' certificates using a new SIP event package [RFC3265].
The certificate is delivered to the subscribing UA in a corresponding The certificate is delivered to the subscribing UA in a corresponding
skipping to change at page 10, line 25 skipping to change at page 10, line 25
outside the scope of this specification. It is worth noting that if outside the scope of this specification. It is worth noting that if
Charlie's UAS receives a request that is encrypted to Bob, it would Charlie's 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 be valid and legal for that UA to send a 302 redirecting the call to
Bob. Bob.
5. UA Behavior with Credentials 5. UA Behavior with Credentials
UAs discover their own credentials by subscribing to their AOR with UAs discover their own credentials by subscribing to their AOR with
an event type of credential as described in Section 7. After a UA an event type of credential as described in Section 7. After a UA
registers, it SHOULD retrieve its credentials by subscribing to them registers, it SHOULD retrieve its credentials by subscribing to them
as described in Section 6.6. as described in Section 6.5.
When a UA discovers its credential, the private key information might When a UA discovers its credential, the private key information might
be encrypted with a password phrase. The UA SHOULD request that the 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 user enter the password phrase on the device, and the UA MAY cache
this password phrase for future use. this password phrase for future use.
There are several different cases in which a UA should generate a new There are several different cases in which a UA should generate a new
credential: credential:
o If the UA receives a NOTIFY with no body for the credential o If the UA receives a NOTIFY with no body for the credential
package. package.
o If the certificate has expired. o If the certificate has expired.
o If the certificate's notAfter date is within the next 600 seconds, o If the certificate's notAfter date is within the next 600 seconds,
the UA SHOULD attempt to create replacement credentials. The UA the UA SHOULD attempt to create replacement credentials. The UA
does this by waiting a random amount of time between 0 and 300 does this by waiting a random amount of time between 0 and 300
seconds. If no new credentials have been received in that time, seconds. If no new credentials have been received in that time,
the UA creates new credentials to replace the expiring ones and the UA creates new credentials to replace the expiring ones and
sends them in a PUBLISH request (with a SIP-If-Match header field sends them in a PUBLISH request following the rules for modifying
set to the current etag). This makes credential collisions both event state from Section 4.4 of [RFC3903].
unlikely and harmless.
o If the user of the device has indicated via the user interface 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 that they wish to revoke the current certificate and issue a new
one. one.
Credentials are created by creating a new key pair which will require Credentials are created by creating a new key pair which will require
appropriate randomness, and then creating a certificate as described appropriate randomness, [RFC4086] and then creating a certificate as
in Section 9.6. The UA MAY encrypt the private key with a password described in Section 9.6. The UA MAY encrypt the private key with a
phrase supplied by the user. Next, the UA updates the user's password phrase supplied by the user. Next, the UA updates the
credential by sending a PUBLISH [RFC3903] request with the user's credential by sending a PUBLISH [RFC3903] request with the
credentials or just the certificate as described in Section 7.9. credentials or just the certificate as described in Section 7.8.
If a UA wishes to revoke the existing certificate without publishing 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 a new one, it MUST send a PUBLISH with an empty body to the
credential server. credential server.
6. Event Package Formal Definition for "certificate" 6. Event Package Formal Definition for "certificate"
6.1. Event Package Name 6.1. Event Package Name
This document defines a SIP Event Package as defined in [RFC3265]. This document defines a SIP Event Package as defined in [RFC3265].
The event-package token name for this package is: The event-package token name for this package is:
certificate certificate
6.2. Event Package Parameters 6.2. SUBSCRIBE Bodies
This package defines the "etag" Event header parameter which is valid
only in NOTIFY requests. It contains a token which represents the
SIP etag value at the time the notification was sent. Considering
how infrequently credentials are updated, this hint is very likely to
be the correct etag to use in the SIP-If-Match header in a SIP
PUBLISH request to update the current credentials.
etag-param = "etag" EQUAL token
6.3. SUBSCRIBE Bodies
This package does not define any SUBSCRIBE bodies. This package does not define any SUBSCRIBE bodies.
6.4. Subscription Duration 6.3. Subscription Duration
Subscriptions to this event package can range from no time to weeks. Subscriptions to this event package can range from no time to weeks.
Subscriptions in days are more typical and are RECOMMENDED. The Subscriptions in days are more typical and are RECOMMENDED. The
default subscription duration for this event package is one day. default subscription duration for this event package is one day.
The credential service is encouraged to keep the subscriptions active The credential service is encouraged to keep the subscriptions active
for AORs that are communicating frequently, but the credential for AORs that are communicating frequently, but the credential
service MAY terminate the subscription at any point in time. service MAY terminate the subscription at any point in time.
6.5. NOTIFY Bodies 6.4. NOTIFY Bodies
The body of a NOTIFY request for this package MUST either be empty or 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 contain an application/pkix-cert body (as defined in [RFC2585]) that
contains the certificate, unless an Accept header field has contains the certificate, unless an Accept header field has
negotiated some other type. The Content-Disposition MUST be set to negotiated some other type. The Content-Disposition MUST be set to
"signal" as defined in [RFC3204]. "signal" as defined in [RFC3204].
A future extension MAY define other NOTIFY bodies. If no "Accept" A future extension MAY define other NOTIFY bodies. If no "Accept"
header field is present in the SUBSCRIBE, the body type defined in header field is present in the SUBSCRIBE, the body type defined in
this document MUST be assumed. this document MUST be assumed.
Implementations which generate large notifications are reminded to Implementations which generate large notifications are reminded to
follow the message size restrictions for unreliable transports follow the message size restrictions for unreliable transports
articulated in Section 18.1.1 of SIP. articulated in Section 18.1.1 of SIP.
6.6. Subscriber Generation of SUBSCRIBE Requests 6.5. Subscriber Generation of SUBSCRIBE Requests
A UA discovers a certificate by sending a SUBSCRIBE request with an A UA discovers a certificate by sending a SUBSCRIBE request with an
event type of "certificate" to the AOR for which a certificate is event type of "certificate" to the AOR for which a certificate is
desired. In general, the UA stays subscribed to the certificate for 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 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. can be notified about changes or revocations to the certificate.
Subscriber User Agents will typically subscribe to certificate Subscriber User Agents will typically subscribe to certificate
information for a period of hours or days, and automatically attempt information for a period of hours or days, and automatically attempt
to re-subscribe just before the subscription is completely expired. to re-subscribe just before the subscription is completely expired.
When a user de-registers from a device (logoff, power down of a When a user de-registers from a device (logoff, power down of a
mobile device, etc.), subscribers SHOULD unsubscribe by sending a mobile device, etc.), subscribers SHOULD unsubscribe by sending a
SUBSCRIBE request with an Expires header field of zero. SUBSCRIBE request with an Expires header field of zero.
6.7. Notifier Processing of SUBSCRIBE Requests 6.6. Notifier Processing of SUBSCRIBE Requests
When a SIP credential server receives a SUBSCRIBE request with the When a SIP credential server receives a SUBSCRIBE request with the
certificate event-type, it is not necessary to authenticate the certificate event-type, it is not necessary to authenticate the
subscription request. The Notifier MAY limit the duration of the subscription request. The Notifier MAY limit the duration of the
subscription to an administrator-defined period of time. The subscription to an administrator-defined period of time. The
duration of the subscription does not correspond in any way to the duration of the subscription does not correspond in any way to the
period for which the certificate will be valid. period for which the certificate will be valid.
When the credential server receives a SUBSCRIBE request for a When the credential server receives a SUBSCRIBE request for a
certificate, it first checks to see if it has credentials for the certificate, it first checks to see if it has credentials for the
requested URI. If it does not have a certificate, it returns a requested URI. If it does not have a certificate, it returns a
NOTIFY request with an empty message body. NOTIFY request with an empty message body.
6.8. Notifier Generation of NOTIFY Requests 6.7. Notifier Generation of NOTIFY Requests
Immediately after a subscription is accepted, the Notifier MUST send Immediately after a subscription is accepted, the Notifier MUST send
a NOTIFY with the current certificate, or an empty body if no a NOTIFY with the current certificate, or an empty body if no
certificate is available for the target user. In either case it 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 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 To header field in the SUBSCRIBE request. This server sending
the NOTIFY needs either to implement an Authentication Service (as the NOTIFY needs either to implement an Authentication Service (as
described in SIP Identity [RFC4474]) or else the server needs to be described in SIP Identity [RFC4474]) or else the server needs to be
set up such that the NOTIFY request will be sent through an set up such that the NOTIFY request will be sent through an
Authentication Service. Sending the NOTIFY request through the Authentication Service. Sending the NOTIFY request through the
Authentication Service requires the SUBSCRIBE request to have been Authentication Service requires the SUBSCRIBE request to have been
routed through the Authentication Service, since the NOTIFY is sent routed through the Authentication Service, since the NOTIFY is sent
within the dialog formed by the subscription. within the dialog formed by the subscription.
6.9. Subscriber Processing of NOTIFY Requests 6.8. Subscriber Processing of NOTIFY Requests
The resulting NOTIFY will contain an application/pkix-cert body that The resulting NOTIFY will contain an application/pkix-cert body that
contains the requested certificate. The UA MUST follow the contains the requested certificate. The UA MUST follow the
procedures in Section 9.3 to decide if the received certificate can procedures in Section 9.3 to decide if the received certificate can
be used. The UA needs to cache this certificate for future use. The 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 maximum length of time it should be cached for is discussed in
Section 9.1. The certificate MUST be removed from the cache if the Section 9.1. The certificate MUST be removed from the cache if the
certificate has been revoked (if a NOTIFY with an empty body is 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 received), or if it is updated by a subsequent NOTIFY. The UA MUST
check that the NOTIFY is correctly signed by an Authentication check that the NOTIFY is correctly signed by an Authentication
Service as described in [RFC4474]. If the identity asserted by the Service as described in [RFC4474]. If the identity asserted by the
Authentication Service does not match the AOR that the UA subscribed Authentication Service does not match the AOR that the UA subscribed
to, the certificate in the NOTIFY is discarded and MUST NOT be used. to, the certificate in the NOTIFY is discarded and MUST NOT be used.
6.10. Handling of Forked Requests 6.9. Handling of Forked Requests
This event package does not permit forked requests. At most one This event package does not permit forked requests. At most one
subscription to this event type is permitted per resource. subscription to this event type is permitted per resource.
6.11. Rate of Notifications 6.10. Rate of Notifications
Notifiers SHOULD NOT generate NOTIFY requests more frequently than Notifiers SHOULD NOT generate NOTIFY requests more frequently than
once per minute. once per minute.
6.12. State Agents and Lists 6.11. State Agents and Lists
The certificate server described in this section which serves The certificate server described in this section which serves
certificates is a state agent and implementations of the certificate certificates is a state agent as defined in [RFC3265] and
server MUST be implemented as a state agent. implementations of the certificate server MUST be implemented as a
state agent.
Implementers MUST NOT use the event list extension [RFC4662] with Implementers MUST NOT use the event list extension [RFC4662] with
this event type. It is not possible to make such an approach work, this event type. It is not possible to make such an approach work,
because the Authentication service would have to simultaneously because the Authentication service would have to simultaneously
assert several different identities. assert several different identities.
6.13. Behavior of a Proxy Server 6.12. Behavior of a Proxy Server
There are no additional requirements on a SIP Proxy, other than to There are no additional requirements on a SIP Proxy, other than to
transparently forward the SUBSCRIBE and NOTIFY requests as required transparently forward the SUBSCRIBE and NOTIFY requests as required
in SIP. This specification describes the Proxy, Authentication in SIP. This specification describes the Proxy, Authentication
service, and credential service as three separate services, but it is service, and credential service as three separate services, but it is
certainly possible to build a single SIP network element that certainly possible to build a single SIP network element that
performs all of these services at the same time. performs all of these services at the same time.
7. Event Package Formal Definition for "credential" 7. Event Package Formal Definition for "credential"
7.1. Event Package Name 7.1. Event Package Name
This document defines a SIP Event Package as defined in [RFC3265]. This document defines a SIP Event Package as defined in [RFC3265].
The event-package token name for this package is: The event-package token name for this package is:
credential credential
7.2. Event Package Parameters 7.2. SUBSCRIBE Bodies
This package defines the "etag" Event header parameter which is valid
only in NOTIFY requests. It contains a token which represents the
SIP etag value at the time the notification was sent. Considering
how infrequently credentials are updated, this hint is very likely to
be the correct etag to use in the SIP-If-Match header field in a SIP
PUBLISH request to update the current credentials.
etag-param = "etag" EQUAL token
7.3. SUBSCRIBE Bodies
This package does not define any SUBSCRIBE bodies. This package does not define any SUBSCRIBE bodies.
7.4. Subscription Duration 7.3. Subscription Duration
Subscriptions to this event package can range from hours to one week. Subscriptions to this event package can range from hours to one week.
Subscriptions in days are more typical and are RECOMMENDED. The Subscriptions in days are more typical and are RECOMMENDED. The
default subscription duration for this event package is one day. default subscription duration for this event package is one day.
The credential service SHOULD keep subscriptions active for UAs that The credential service SHOULD keep subscriptions active for UAs that
are currently registered. are currently registered.
7.5. NOTIFY Bodies 7.4. NOTIFY Bodies
The NOTIFY MUST contain a multipart/mixed (see [RFC2046]) body that An implementation compliant to this specification MUST support the
contains both an application/pkix-cert body with the certificate and multipart/mixed type (see [RFC2046]). This allows a notification to
an application/pkcs8 body that has the associated private key contain multiple resource documents including at a minimum the
information for the certificate. The Content-Disposition MUST be set application/pkix-cert body with the certificate and an application/
to "signal" as defined in [RFC3204]. pkcs8 body that has the associated private key information for the
certificate.
A future extension MAY define other NOTIFY bodies. If no "Accept" The absence of an Accept header in the SUBSCRIBE indicates support
header field is present in the SUBSCRIBE, the body type defined in for multipart/mixed and the content types application/pkix-cert and
this document MUST be assumed. application/pkcs8. If an Accept header is present, these types MUST
be included, in additional to any other types supported by the
client.
The application/pkix-cert body is a DER encoded X.509v3 certificate The application/pkix-cert body is a DER encoded X.509v3 certificate
[RFC2585]. The application/pkcs8 body contains a DER-encoded [RFC2585]. The application/pkcs8 body contains a DER-encoded
[RFC5208] object that contains the private key. The PKCS#8 objects [RFC5208] object that contains the private key. The PKCS#8 objects
MUST be of type PrivateKeyInfo. The integrity and confidentiality of MUST be of type PrivateKeyInfo. The integrity and confidentiality of
the PKCS#8 objects is provided by the TLS transport. The transport the PKCS#8 objects is provided by the TLS transport. The transport
encoding of all the MIME bodies is binary. encoding of all the MIME bodies is binary.
7.6. Subscriber Generation of SUBSCRIBE Requests 7.5. Subscriber Generation of SUBSCRIBE Requests
A Subscriber User Agent will subscribe to its credential information A Subscriber User Agent will subscribe to its credential information
for a period of hours or days and will automatically attempt to re- for a period of hours or days and will automatically attempt to re-
subscribe before the subscription has completely expired. subscribe before the subscription has completely expired.
The Subscriber SHOULD subscribe to its credentials whenever a new The Subscriber SHOULD subscribe to its credentials whenever a new
user becomes associated with the device (a new login). The user becomes associated with the device (a new login). The
subscriber SHOULD also renew its subscription immediately after a subscriber SHOULD also renew its subscription immediately after a
reboot, or when the subscriber's network connectivity has just been reboot, or when the subscriber's network connectivity has just been
re-established. re-established.
skipping to change at page 15, line 41 skipping to change at page 15, line 27
be configured with a specific name for the credential service; be configured with a specific name for the credential service;
otherwise normal SIP routing is used. As described in RFC 3261, the otherwise normal SIP routing is used. As described in RFC 3261, the
TLS connection needs to present a certificate that matches the TLS connection needs to present a certificate that matches the
expected name of the server to which the connection was formed, so 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 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 this may result in the UA publishing its private key information to
an attacker. The credential service will authenticate the UA using an attacker. The credential service will authenticate the UA using
the usual SIP Digest mechanism, so the UA can expect to receive a SIP the usual SIP Digest mechanism, so the UA can expect to receive a SIP
challenge to the SUBSCRIBE or PUBLISH requests. challenge to the SUBSCRIBE or PUBLISH requests.
7.7. Notifier Processing of SUBSCRIBE Requests 7.6. Notifier Processing of SUBSCRIBE Requests
When a credential service receives a SUBSCRIBE for a credential, the When a credential service receives a SUBSCRIBE for a credential, the
credential service has to authenticate and authorize the UA and credential service has to authenticate and authorize the UA and
validate that adequate transport security is being used. Only a UA validate that adequate transport security is being used. Only a UA
that can authenticate as being able to register as the AOR is that can authenticate as being able to register as the AOR is
authorized to receive the credentials for that AOR. The credential authorized to receive the credentials for that AOR. The credential
Service MUST digest challenge the UA to authenticate the UA and then Service MUST digest challenge the UA to authenticate the UA and then
decide if it is authorized to receive the credentials. If decide if it is authorized to receive the credentials. If
authentication is successful, the Notifier MAY limit the duration of authentication is successful, the Notifier MAY limit the duration of
the subscription to an administrator-defined period of time. The the subscription to an administrator-defined period of time. The
duration of the subscription MUST NOT be larger than the length of duration of the subscription MUST NOT be larger than the length of
time for which the certificate is still valid. The Expires header 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 field SHOULD be set so that it is not longer than the notAfter date
in the certificate. in the certificate.
7.8. Notifier Generation of NOTIFY Requests 7.7. Notifier Generation of NOTIFY Requests
Once the UA has authenticated with the credential service and the Once the UA has authenticated with the credential service and the
subscription is accepted, the credential service MUST immediately subscription is accepted, the credential service MUST immediately
send a Notify request. The Notifier SHOULD include the current etag send a Notify request. The Authentication Service is applied to this
value in the "etag" Event package parameter in the NOTIFY request. NOTIFY request in the same way as the certificate subscriptions. If
The Authentication Service is applied to this NOTIFY request in the the credential is revoked, the credential service MUST terminate any
same way as the certificate subscriptions. If the credential is current subscriptions and force the UA to re-authenticate by sending
revoked, the credential service MUST terminate any current a NOTIFY with its Subscription-State header field set to "terminated"
subscriptions and force the UA to re-authenticate by sending a NOTIFY and a reason parameter of "deactivated". (This causes a Subscriber
with its Subscription-State header field set to "terminated" and a to retry the subscription immediately.) This is so that if a secret
reason parameter of "deactivated". (This causes a Subscriber to for retrieving the credentials gets compromised, the rogue UA will
retry the subscription immediately.) This is so that if a secret for not continue to receive credentials after the compromised secret has
retrieving the credentials gets compromised, the rogue UA will not been changed.
continue to receive credentials after the compromised secret has been
changed.
Any time the credentials for this URI change, the credential service Any time the credentials for this URI change, the credential service
MUST send a new NOTIFY to any active subscriptions with the new MUST send a new NOTIFY to any active subscriptions with the new
credentials. credentials.
The notification MUST be sent over TLS so that it is integrity The notification MUST be sent over TLS so that it is integrity
protected and the TLS needs to be directly connected between the UA protected and the TLS needs to be directly connected between the UA
and the credential service with no intermediaries. and the credential service with no intermediaries.
7.9. Generation of PUBLISH Requests 7.8. Generation of PUBLISH Requests
A user agent SHOULD be configurable to control whether it publishes A user agent SHOULD be configurable to control whether it publishes
the credential for a user or just the user's certificate. the credential for a user or just the user's certificate.
When publishing just a certificate, the body contains an application/ When publishing just a certificate, the body contains an application/
pkix-cert. When publishing a credential, the body contains a pkix-cert. When publishing a credential, the body contains a
multipart/mixed containing both an application/pkix-cert and an multipart/mixed containing both an application/pkix-cert and an
application/pkcs8 body. application/pkcs8 body.
When the UA sends the PUBLISH [RFC3903] request, it needs to do the When the UA sends the PUBLISH [RFC3903] request, it needs to do the
skipping to change at page 17, line 4 skipping to change at page 16, line 34
pkix-cert. When publishing a credential, the body contains a pkix-cert. When publishing a credential, the body contains a
multipart/mixed containing both an application/pkix-cert and an multipart/mixed containing both an application/pkix-cert and an
application/pkcs8 body. application/pkcs8 body.
When the UA sends the PUBLISH [RFC3903] request, it needs to do the When the UA sends the PUBLISH [RFC3903] request, it needs to do the
following: following:
o The UA MUST use TLS to directly connect to the server acting as 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 credential service or to a server that is authoritative for
the domain of the credential service. The UA MUST NOT connect the domain of the credential service. The UA MUST NOT connect
through an intermediate proxy to the credential service. through an intermediate proxy to the credential service.
o The Expires header field value in the PUBLISH request SHOULD be o The Expires header field value in the PUBLISH request SHOULD be
set to match the time for which the certificate is valid. set to match the time for which the certificate is valid.
o If the certificate includes Basic Constraints, it SHOULD set the o If the certificate includes Basic Constraints, it SHOULD set the
CA flag to false. CA flag to false.
7.10. Notifier Processing of PUBLISH Requests 7.9. Notifier Processing of PUBLISH Requests
When the credential service receives a PUBLISH to update credentials, When the credential service receives a PUBLISH to update credentials,
it MUST authenticate and authorize this request the same way as for it MUST authenticate and authorize this request the same way as for
subscriptions for credentials. If the authorization succeeds, then subscriptions for credentials. If the authorization succeeds, then
the credential service MUST perform the following check on the the credential service MUST perform the following check on the
certificate: certificate:
o One of the names in the SubjectAltName of the certificate matches o One of the names in the SubjectAltName of the certificate matches
the authorized user making the request. the authorized user making the request.
o The notBefore validity time MUST NOT be in the future. o The notBefore validity time MUST NOT be in the future.
o The notAfter validity time MUST be in the future. o The notAfter validity time MUST be in the future.
skipping to change at page 17, line 21 skipping to change at page 17, line 4
When the credential service receives a PUBLISH to update credentials, When the credential service receives a PUBLISH to update credentials,
it MUST authenticate and authorize this request the same way as for it MUST authenticate and authorize this request the same way as for
subscriptions for credentials. If the authorization succeeds, then subscriptions for credentials. If the authorization succeeds, then
the credential service MUST perform the following check on the the credential service MUST perform the following check on the
certificate: certificate:
o One of the names in the SubjectAltName of the certificate matches o One of the names in the SubjectAltName of the certificate matches
the authorized user making the request. the authorized user making the request.
o The notBefore validity time MUST NOT be in the future. o The notBefore validity time MUST NOT be in the future.
o The notAfter validity time MUST be in the future. o The notAfter validity time MUST be in the future.
o If a CA Basic Constraint is set in the certificate, it is set to o If a CA Basic Constraint is set in the certificate, it is set to
false. false.
If all of these succeed, the credential service updates the If all of these succeed, the credential service updates the
credential for this URI, processes all the active certificates and credential for this URI, processes all the active certificates and
credential subscriptions to this URI, and generates a NOTIFY request credential subscriptions to this URI, and generates a NOTIFY request
with the new credential or certificate. with the new credential or certificate.
If the Subscriber submits a PUBLISH request with no body, this If the Subscriber submits a PUBLISH request with no body and
revokes the current credentials and causes all subscriptions to the Expires=0, this revokes the current credentials. Watchers of these
credential package to be deactivated as described in the previous credentials will receive update with no body indicating that they
section. (Note that subscriptions to the certificate package are NOT MUST stop any previously stored credentials. Note that subscriptions
terminated; each subscriber to the certificate package receives a to the certificate package are NOT terminated; each subscriber to the
notification with an empty body.) certificate package receives a notification with an empty body.
7.11. Subscriber Processing of NOTIFY Requests 7.10. Subscriber Processing of NOTIFY Requests
When the UA receives a valid NOTIFY request, it should replace its When the UA receives a valid NOTIFY request, it should replace its
existing credentials with the new received ones. If the UA cannot existing credentials with the new received ones. If the UA cannot
decrypt the PKCS#8 object, it MUST send a 437 (Unsupported decrypt the PKCS#8 object, it MUST send a 437 (Unsupported
Certificate) response. Later if the user provides a new password Certificate) response. Later if the user provides a new password
phrase for the private key, the UA can subscribe to the credentials phrase for the private key, the UA can subscribe to the credentials
again and attempt to decrypt with the new password phrase. again and attempt to decrypt with the new password phrase.
7.12. Handling of Forked Requests 7.11. Handling of Forked Requests
This event package does not permit forked requests. This event package does not permit forked requests.
7.13. Rate of Notifications 7.12. Rate of Notifications
Notifiers SHOULD NOT generate NOTIFY requests more frequently than Notifiers SHOULD NOT generate NOTIFY requests more frequently than
once per minute. once per minute.
7.14. State Agents and Lists 7.13. State Agents and Lists
The credential server described in this section which serves The credential server described in this section which serves
credentials is a state agent and implementations of the credential credentials is a state agent and implementations of the credential
server MUST be implemented as a state agent. server MUST be implemented as a state agent.
Implementers MUST NOT use the event list extension [RFC4662] with Implementers MUST NOT use the event list extension [RFC4662] with
this event type. this event type.
7.15. Behavior of a Proxy Server 7.14. Behavior of a Proxy Server
The behavior is identical to behavior described for certificate The behavior is identical to behavior described for certificate
subscriptions described in Section 6.13. subscriptions described in Section 6.12.
8. Examples 8. Examples
In all these examples, large parts of the messages are omitted to In all these examples, large parts of the messages are omitted to
highlight what is relevant to this draft. The lines in the examples highlight what is relevant to this draft. The lines in the examples
that are prefixed by $ represent encrypted blocks of data. that are prefixed by $ represent encrypted blocks of data.
8.1. Encrypted Page Mode IM Message 8.1. Encrypted Page Mode IM Message
In this example, Alice sends Bob an encrypted page mode instant In this example, Alice sends Bob an encrypted page mode instant
skipping to change at page 24, line 10 skipping to change at page 23, line 46
with. The certificate in the body contains the public key for the with. The certificate in the body contains the public key for the
identity. Only the UA that can authenticate as this AOR, or devices 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 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 body. This stops other users from being able to provide a false
public key. This chain of assertion from original URI, to From, to public key. This chain of assertion from original URI, to From, to
body, to public key is critical to the security of the mechanism body, to public key is critical to the security of the mechanism
described in this specification. If any of the steps above are not described in this specification. If any of the steps above are not
followed, this chain of security will be broken and the system will followed, this chain of security will be broken and the system will
not work. not work.
9.3.1. Extra Assurance
Although the certificates used with this document need not be
validatable to a trust anchor via PKIX [RFC5280] procedures,
certificates which 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) certificate authority user verification and key issuance
toolset, rather than depending on the security of generic SIP
implementations.
When a relying party receives a certificate which is not self-signed,
it MAY attempt to validate it using the rules in Section 6 of
[RFC5280]. If the certificate validates successfully and the names
correctly match the user's AOR (see Section 9.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.
9.4. SACRED Framework 9.4. SACRED Framework
This specification includes a mechanism that allows end users to This specification includes a mechanism that allows end users to
share the same credentials across different end-user devices. This share the same credentials across different end-user devices. This
mechanism is based on the one presented in the SACRED Framework mechanism is based on the one presented in the SACRED Framework
[RFC3760]. While this mechanism is fully described in this document, [RFC3760]. While this mechanism is fully described in this document,
the requirements and background are more thoroughly discussed in the requirements and background are more thoroughly discussed in
[RFC3760]. [RFC3760].
Specifically, Section 7.6, Section 7.7 and Section 7.10 follow the Specifically, Section 7.5, Section 7.6 and Section 7.9 follow the
cTLS architecture described in section 4.2.2 of [RFC3760]. The cTLS architecture described in section 4.2.2 of [RFC3760]. The
client authenticates the server using the server's TLS certificate. client authenticates the server using the server's TLS certificate.
The server authenticates the client using a SIP digest transaction The server authenticates the client using a SIP digest transaction
inside the TLS session. The TLS sessions form a strong session key inside the TLS session. The TLS sessions form a strong session key
that is used to protect the credentials being exchanged. that is used to protect the credentials being exchanged.
9.5. Crypto Profiles 9.5. Crypto Profiles
Credential services SHOULD implement the server name indication Credential services SHOULD implement the server name indication
extensions in [RFC5246] and they MUST support a TLS profile of extensions in [RFC5246] and they MUST support a TLS profile of
skipping to change at page 26, line 33 skipping to change at page 26, line 38
To: ietf-sip-events@iana.org To: ietf-sip-events@iana.org
Subject: Registration of new SIP event package Subject: Registration of new SIP event package
Package Name: credential Package Name: credential
Is this registration for a Template Package: No Is this registration for a Template Package: No
Published Specification(s): This document Published Specification(s): This document
New Event header parameters: "etag"
Person & email address to contact for further information: Person & email address to contact for further information:
Cullen Jennings <fluffy@cisco.com> Cullen Jennings <fluffy@cisco.com>
10.3. PKCS#8 10.3. PKCS#8
To: ietf-types@iana.org To: ietf-types@iana.org
Subject: Registration of MIME media type application/pkcs8 Subject: Registration of MIME media type application/pkcs8
MIME media type name: application MIME media type name: application
skipping to change at page 27, line 26 skipping to change at page 27, line 26
Optional parameters: None Optional parameters: None
Encoding considerations: binary Encoding considerations: binary
Security considerations: Carries a cryptographic private key Security considerations: Carries a cryptographic private key
Interoperability considerations: Interoperability considerations:
The PKCS#8 object inside this MIME type MUST be DER-encoded The PKCS#8 object inside this MIME type MUST be DER-encoded
Published specification: Published specification:
RSA Laboratories, "Private-Key Information Syntax Standard, Kaliski, B., "Public-Key Cryptography Standards (PKCS) #8:
Version 1.2", PKCS 8, November 1993. Private-Key Information Syntax Specification Version 1.2",
RFC 5208, May 2008.
Applications which use this media type: Any MIME-compliant transport Applications which use this media type: Any MIME-compliant transport
Additional information: Additional information:
Magic number(s): None Magic number(s): None
File extension(s): .p8 File extension(s): .p8
Macintosh File Type Code(s): none Macintosh File Type Code(s): none
Person & email address to contact for further information: Person & email address to contact for further information:
Cullen Jennings <fluffy@cisco.com> Cullen Jennings <fluffy@cisco.com>
skipping to change at page 29, line 5 skipping to change at page 29, line 8
RFC 5208, May 2008. RFC 5208, May 2008.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008. (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, May 2008. (CRL) Profile", RFC 5280, May 2008.
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness
Requirements for Security", BCP 106, RFC 4086, June 2005.
12.2. Informational References 12.2. Informational References
[RFC3760] Gustafson, D., Just, M., and M. Nystrom, "Securely [RFC3760] Gustafson, D., Just, M., and M. Nystrom, "Securely
Available Credentials (SACRED) - Credential Server Available Credentials (SACRED) - Credential Server
Framework", RFC 3760, April 2004. Framework", RFC 3760, April 2004.
[RFC3851] Ramsdell, B., "Secure/Multipurpose Internet Mail [RFC3851] Ramsdell, B., "Secure/Multipurpose Internet Mail
Extensions (S/MIME) Version 3.1 Message Specification", Extensions (S/MIME) Version 3.1 Message Specification",
RFC 3851, July 2004. RFC 3851, July 2004.
skipping to change at page 29, line 42 skipping to change at page 29, line 48
Phone: +1 408 421-9990 Phone: +1 408 421-9990
Email: fluffy@cisco.com Email: fluffy@cisco.com
Jason Fischl (editor) Jason Fischl (editor)
Skype Skype
2145 Hamilton Ave. 2145 Hamilton Ave.
San Jose, CA 95125 San Jose, CA 95125
USA USA
Phone: +1-415-202-5192 Phone: +1-415-202-5192
Email: jason.fischl@skypelabs.com Email: jason.fischl@skype.net
 End of changes. 51 change blocks. 
178 lines changed or deleted 184 lines changed or added

This html diff was produced by rfcdiff 1.38. The latest version is available from http://tools.ietf.org/tools/rfcdiff/