draft-ietf-sip-certs-02.txt   draft-ietf-sip-certs-03.txt 
Network Working Group C. Jennings Network Working Group C. Jennings
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Expires: April 25, 2007 J. Peterson Intended status: Standards Track J. Peterson
NeuStar, Inc. Expires: September 5, 2007 NeuStar, Inc.
J. Fischl, Ed. J. Fischl, Ed.
CounterPath Solutions, Inc. CounterPath Solutions, Inc.
October 22, 2006 March 4, 2007
Certificate Management Service for The Session Initiation Protocol (SIP) Certificate Management Service for The Session Initiation Protocol (SIP)
draft-ietf-sip-certs-02 draft-ietf-sip-certs-03
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
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
skipping to change at page 1, line 37 skipping to change at page 1, line 37
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 April 25, 2007. This Internet-Draft will expire on September 5, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The IETF Trust (2007).
Abstract Abstract
This draft defines a Credential Service that allows Session This draft defines a Credential Service that allows Session
Initiation Protocol (SIP) User Agents (UAs) to use a SIP package to Initiation Protocol (SIP) User Agents (UAs) to use a SIP package to
discover the certificates of other users. This mechanism allows user discover the certificates of other users. This mechanism allows user
agents that want to contact a given Address-of-Record (AOR) to agents that want to contact a given Address-of-Record (AOR) to
retrieve that AOR's certificate by subscribing to the Credential retrieve that AOR's certificate by subscribing to the Credential
Service, which returns an authenticated response containing that Service, which returns an authenticated response containing that
certificate. The Credential Service also allows users to store and certificate. The Credential Service also allows users to store and
skipping to change at page 2, line 30 skipping to change at page 2, line 30
6.5. NOTIFY Bodies . . . . . . . . . . . . . . . . . . . . . . 10 6.5. NOTIFY Bodies . . . . . . . . . . . . . . . . . . . . . . 10
6.6. Subscriber Generation of SUBSCRIBE Requests . . . . . . . 11 6.6. Subscriber Generation of SUBSCRIBE Requests . . . . . . . 11
6.7. Notifier Processing of SUBSCRIBE Requests . . . . . . . . 11 6.7. Notifier Processing of SUBSCRIBE Requests . . . . . . . . 11
6.8. Notifier Generation of NOTIFY Requests . . . . . . . . . . 11 6.8. Notifier Generation of NOTIFY Requests . . . . . . . . . . 11
6.9. Subscriber Processing of NOTIFY Requests . . . . . . . . . 12 6.9. Subscriber Processing of NOTIFY Requests . . . . . . . . . 12
6.10. Handling of Forked Requests . . . . . . . . . . . . . . . 12 6.10. Handling of Forked Requests . . . . . . . . . . . . . . . 12
6.11. Rate of Notifications . . . . . . . . . . . . . . . . . . 12 6.11. Rate of Notifications . . . . . . . . . . . . . . . . . . 12
6.12. State Agents and Lists . . . . . . . . . . . . . . . . . . 12 6.12. State Agents and Lists . . . . . . . . . . . . . . . . . . 12
6.13. Behavior of a Proxy Server . . . . . . . . . . . . . . . . 12 6.13. Behavior of a Proxy Server . . . . . . . . . . . . . . . . 12
7. Event Package Formal Definition for "credential" . . . . . . . 12 7. Event Package Formal Definition for "credential" . . . . . . . 12
7.1. Event Package Name . . . . . . . . . . . . . . . . . . . . 12 7.1. Event Package Name . . . . . . . . . . . . . . . . . . . . 13
7.2. Event Package Parameters . . . . . . . . . . . . . . . . . 13 7.2. Event Package Parameters . . . . . . . . . . . . . . . . . 13
7.3. SUBSCRIBE Bodies . . . . . . . . . . . . . . . . . . . . . 13 7.3. SUBSCRIBE Bodies . . . . . . . . . . . . . . . . . . . . . 13
7.4. Subscription Duration . . . . . . . . . . . . . . . . . . 13 7.4. Subscription Duration . . . . . . . . . . . . . . . . . . 13
7.5. NOTIFY Bodies . . . . . . . . . . . . . . . . . . . . . . 13 7.5. NOTIFY Bodies . . . . . . . . . . . . . . . . . . . . . . 13
7.6. Subscriber Generation of SUBSCRIBE Requests . . . . . . . 14 7.6. Subscriber Generation of SUBSCRIBE Requests . . . . . . . 14
7.7. Notifier Processing of SUBSCRIBE Requests . . . . . . . . 14 7.7. Notifier Processing of SUBSCRIBE Requests . . . . . . . . 14
7.8. Notifier Generation of NOTIFY Requests . . . . . . . . . . 14 7.8. Notifier Generation of NOTIFY Requests . . . . . . . . . . 14
7.9. Generation of PUBLISH Requests . . . . . . . . . . . . . . 15 7.9. Generation of PUBLISH Requests . . . . . . . . . . . . . . 15
7.10. Notifier Processing of PUBLISH Requests . . . . . . . . . 15 7.10. Notifier Processing of PUBLISH Requests . . . . . . . . . 15
7.11. Subscriber Processing of NOTIFY Requests . . . . . . . . . 16 7.11. Subscriber Processing of NOTIFY Requests . . . . . . . . . 16
7.12. Handling of Forked Requests . . . . . . . . . . . . . . . 16 7.12. Handling of Forked Requests . . . . . . . . . . . . . . . 16
7.13. Rate of Notifications . . . . . . . . . . . . . . . . . . 16 7.13. Rate of Notifications . . . . . . . . . . . . . . . . . . 16
7.14. State Agents and Lists . . . . . . . . . . . . . . . . . . 16 7.14. State Agents and Lists . . . . . . . . . . . . . . . . . . 16
7.15. Behavior of a Proxy Server . . . . . . . . . . . . . . . . 16 7.15. Behavior of a Proxy Server . . . . . . . . . . . . . . . . 16
8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
8.1. Encrypted Page Mode IM Message . . . . . . . . . . . . . . 17 8.1. Encrypted Page Mode IM Message . . . . . . . . . . . . . . 17
8.2. Setting and Retrieving UA Credentials . . . . . . . . . . 18 8.2. Setting and Retrieving UA Credentials . . . . . . . . . . 18
9. Security Considerations . . . . . . . . . . . . . . . . . . . 18 9. Security Considerations . . . . . . . . . . . . . . . . . . . 18
9.1. Certificate Revocation . . . . . . . . . . . . . . . . . . 21 9.1. Certificate Revocation . . . . . . . . . . . . . . . . . . 21
9.2. Certificate Replacement . . . . . . . . . . . . . . . . . 21 9.2. Certificate Replacement . . . . . . . . . . . . . . . . . 21
9.3. Trusting the Identity of a Certificate . . . . . . . . . . 21 9.3. Trusting the Identity of a Certificate . . . . . . . . . . 21
9.4. Conformity to the SACRED Framework . . . . . . . . . . . . 22 9.4. SACRED Framework . . . . . . . . . . . . . . . . . . . . . 22
9.5. Crypto Profiles . . . . . . . . . . . . . . . . . . . . . 22 9.5. Crypto Profiles . . . . . . . . . . . . . . . . . . . . . 23
9.6. User Certificate Generation . . . . . . . . . . . . . . . 23 9.6. User Certificate Generation . . . . . . . . . . . . . . . 23
9.7. Compromised Authentication Service . . . . . . . . . . . . 23 9.7. Compromised Authentication Service . . . . . . . . . . . . 23
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
10.1. Certificate Event Package . . . . . . . . . . . . . . . . 24 10.1. Certificate Event Package . . . . . . . . . . . . . . . . 24
10.2. Credential Event Package . . . . . . . . . . . . . . . . . 24 10.2. Credential Event Package . . . . . . . . . . . . . . . . . 24
10.3. PKCS#8 . . . . . . . . . . . . . . . . . . . . . . . . . . 25 10.3. PKCS#8 . . . . . . . . . . . . . . . . . . . . . . . . . . 25
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 26 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27
12.1. Normative References . . . . . . . . . . . . . . . . . . . 26 12.1. Normative References . . . . . . . . . . . . . . . . . . . 27
12.2. Informational References . . . . . . . . . . . . . . . . . 27 12.2. Informational References . . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28
Intellectual Property and Copyright Statements . . . . . . . . . . 29 Intellectual Property and Copyright Statements . . . . . . . . . . 30
1. Introduction 1. Introduction
SIP [6] provides a mechanism [18] for end-to-end encryption and SIP [RFC3261] provides a mechanism [RFC3853] for end-to-end
integrity using S/MIME [17]. Several security properties of SIP encryption and integrity using S/MIME [RFC3851]. Several security
depend on S/MIME, and yet it has not been widely deployed. One properties of SIP depend on S/MIME, and yet it has not been widely
reason is the complexity of providing a reasonable certificate deployed. One reason is the complexity of providing a reasonable
distribution infrastructure. This specification proposes a way to certificate distribution infrastructure. This specification proposes
address discovery, retrieval, and management of certificates for SIP a way to address discovery, retrieval, and management of certificates
deployments. Combined with the SIP Identity [2] specification, this for SIP deployments. Combined with the SIP Identity [RFC4474]
specification allows users to have certificates that are not signed specification, this specification allows users to have certificates
by any well known certificate authority while still strongly binding that are not signed by any well known certificate authority while
the user's identity to the certificate. still strongly binding the user's identity to the certificate.
In addition, this specification provides a mechanism that allows SIP In addition, this specification provides a mechanism that allows SIP
User Agents such as IP phones to enroll and get their credentials User Agents such as IP phones to enroll and get their credentials
without any more configuration information than they commonly have without any more configuration information than they commonly have
today. The end user expends no extra effort. It follows the Sacred today. The end user expends no extra effort.
Framework RFC 3760 [7] for management of the credentials.
2. Definitions 2. Definitions
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 RFC 2119 [5]. document are to be interpreted as described in [RFC2119].
Certificate: A PKIX [13] style certificate containing a public key Certificate: A PKIX [RFC3280] style certificate containing a public
and a list of identities in the SubjectAltName that are bound to key and a list of identities in the SubjectAltName that are bound
this key. The certificates discussed in this draft are generally to this key. The certificates discussed in this draft are
self signed and use the mechanisms in the SIP Identity [2] generally self signed and use the mechanisms in the SIP Identity
specification to vouch for their validity. Certificates that are [RFC4474] specification to vouch for their validity. Certificates
signed by a certificate authority can also be used with all the that are signed by a certificate authority can also be used with
mechanisms in this draft, but it is expected that they are used all the mechanisms in this draft, but it is expected that they are
purely as a key carrier and that their validity is not checked. used purely as a key carrier and that their validity is not
checked.
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 [4]. The to other users' certificates using a new SIP event package [RFC3265].
certificate is delivered to the subscribing UA in a corresponding SIP The certificate is delivered to the subscribing UA in a corresponding
NOTIFY request. The identity of the certificate can be vouched for SIP NOTIFY request. The identity of the certificate can be vouched
using the Authentication Service from the SIP Identity [2] for using the Authentication Service from the SIP Identity [RFC4474]
specification, which uses the domain's certificate to sign the NOTIFY specification, which uses the domain's certificate to sign the NOTIFY
request. The credential service can manage public certificates as request. The credential service can manage public certificates as
well as the user's private keys. Users can update their credentials, well as the user's private keys. Users can update their credentials,
as stored on the credential service, using a SIP PUBLISH [3] request. as stored on the credential service, using a SIP PUBLISH [RFC3903]
The UA authenticates to the credential service using a shared secret request. The UA authenticates to the credential service using a
when a UA is updating a credential. Typically the shared secret will shared secret when a UA is updating a credential. Typically the
be the same one that is used by the UA to authenticate a REGISTER shared secret will be the same one that is used by the UA to
request with the Registrar for the domain (usually with SIP Digest authenticate a REGISTER request with the Registrar for the domain
Authentication). (usually with SIP Digest Authentication).
The following figure shows Bob publishing his credentials from one of The following figure shows Bob publishing his credentials from one of
his User Agents (e.g. his laptop software client), retrieving his his User Agents (e.g. his laptop software client), retrieving his
credentials from another of his User Agents (e.g. his mobile phone), credentials from another of his User Agents (e.g. his mobile phone),
and then Alice retrieving Bob's certificate and sending a message to 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 Bob. SIP 200-class responses are omitted from the diagram to make the
figure easier to understand. figure easier to understand.
example.com domain example.com domain
------------------ ------------------
skipping to change at page 6, line 40 skipping to change at page 6, line 40
| | | | | | | | | |
| SUBSCRIBE (certificate) | Alice fetches | | SUBSCRIBE (certificate) | Alice fetches |
|---------->|----->|----->| Bob's cert | |---------->|----->|----->| Bob's cert |
| | |NOTIFY| | | | |NOTIFY| |
| NOTIFY+Identity |<-----| | | NOTIFY+Identity |<-----| |
|<----------+------| | Alice uses cert | |<----------+------| | Alice uses cert |
| | | | to encrypt | | | | | to encrypt |
| MESSAGE | | | message to Bob | | MESSAGE | | | message to Bob |
|---------->|------+------+----------------->| |---------->|------+------+----------------->|
Bob's UA (Bob2) does a TLS [11] handshake with the credential server Bob's UA (Bob2) does a TLS [RFC4366] handshake with the credential
to authenticate that the UA is connected to the correct credential server to authenticate that the UA is connected to the correct
server. Then Bob's UA publishes his newly created or updated credential server. Then Bob's UA publishes his newly created or
credentials. The credential server digest challenges the UA to updated credentials. The credential server digest challenges the UA
authenticate that the UA knows Bob's shared secret. Once the UA is to authenticate that the UA knows Bob's shared secret. Once the UA
authenticated, the credential server stores Bob's credentials. is authenticated, the credential server stores Bob's credentials.
Another of Bob's User Agents (Bob1) wants to fetch its current Another of Bob's User Agents (Bob1) wants to fetch its current
credentials. It does a TLS [11] handshake with the credential server credentials. It does a TLS [RFC4366] handshake with the credential
to authenticate that the UA is connected to the correct credential server to authenticate that the UA is connected to the correct
server. Then Bob's UA subscribes for the credentials. The credential server. Then Bob's UA subscribes for the credentials.
credential server digest challenges the UA to authenticate that the The credential server digest challenges the UA to authenticate that
UA knows Bob's shared secret. Once the UA is authenticated, the the UA knows Bob's shared secret. Once the UA is authenticated, the
credential server sends a NOTIFY that contains Bob's credentials. credential server sends a NOTIFY that contains Bob's credentials.
The private key portion of the credential may have been encrypted The private key portion of the credential may have been encrypted
with a secret that only Bob's UA (and not the credential server) 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 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 be ready to go. Typically Bob's UA would do this when it first
registered on the network. registered on the network.
Some time later Alice decides that she wishes to discover Bob's 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 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 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 a SUBSCRIBE message to Bob's AOR. The proxy in Bob's domain routes
this to the credential server via an "authentication service" as this to the credential server via an "authentication service" as
defined in [2]. The credential server returns a NOTIFY that contains defined in [RFC4474]. The credential server returns a NOTIFY that
Bob's public certificate in the body. This is routed through an contains Bob's public certificate in the body. This is routed
authentication service that signs that this message really can through an authentication service that signs that this message really
validly claim to be from the AOR "sip:bob@example.com". Alice's UA can validly claim to be from the AOR "sip:bob@example.com". Alice's
receives the certificate and can use it to encrypt a message to Bob. 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 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 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 [2] has not been spoofed is for Alice to check that the Identity
header field value is correct. [RFC4474] header field value is correct.
The mechanism described in this document works for both self signed The mechanism described in this document works for both self signed
certificates and certificates signed by well known certificate certificates and certificates signed by well known certificate
authorities. However, most UAs would only use self signed authorities. However, most UAs would only use self signed
certificates and would use an Authentication Service as described in certificates and would use an Authentication Service as described in
[2] to provide a strong binding of an AOR to the certificates. [RFC4474] to provide a strong binding of an AOR to the certificates.
The mechanisms described in this draft allow for three different The mechanisms described in this draft allow for three different
styles of deployment: styles of deployment:
1. Deployments where the credential server only stores certificates 1. Deployments where the credential server only stores certificates
and does not store any private key information. If the and does not store any private key information. If the
deployment had users with multiple devices, some other scheme deployment had users with multiple devices, some other scheme
(perhaps even manual provisioning) would be used to get the right (perhaps even manual provisioning) would be used to get the right
private keys onto all the devices that a user uses. private keys onto all the devices that a user uses.
2. Deployments where the credential server stores certificates and 2. Deployments where the credential server stores certificates and
skipping to change at page 8, line 46 skipping to change at page 8, line 47
If the UA uses a cached certificate in a request and receives a 437 If the UA uses a cached certificate in a request and receives a 437
(Unsupported Certificate) response, it SHOULD remove the certificate (Unsupported Certificate) response, it SHOULD remove the certificate
it used from the cache, attempt to fetch the certificate again. If it used from the cache, attempt to fetch the certificate again. If
the certificate is changed, then the UA SHOULD retry the original the certificate is changed, then the UA SHOULD retry the original
request again with the new certificate. This situation usually request again with the new certificate. This situation usually
indicates that the certificate was recently updated, and that the indicates that the certificate was recently updated, and that the
Subscriber has not received a corresponding notification. If the Subscriber has not received a corresponding notification. If the
certificate fetched is the same as the one that was previously in 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 cache, then the UA SHOULD NOT try the request again. This situation
can happened when the request was retargeted to a different user than can happened when the request was retargeted to a different user than
the original request. The 437 response is defined in [2]. the original request. The 437 response is defined in [RFC4474].
Note: A UA that has a presence list MAY want to subscribe to the 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 certificates of all the presentities in the list when the UA
subscribes to their presence, so that when the user wishes to subscribes to their presence, so that when the user wishes to
contact a presentity, the UA will already have the appropriate contact a presentity, the UA will already have the appropriate
certificate. Future specifications might consider the possibility certificate. Future specifications might consider the possibility
of retrieving the certificates along with the presence documents. of retrieving the certificates along with the presence documents.
The details of how a UA deals with receiving encrypted messages is The details of how a UA deals with receiving encrypted messages is
outside the scope of this specification. It is worth noting that if outside the scope of this specification. It is worth noting that if
skipping to change at page 9, line 46 skipping to change at page 9, line 50
sends them in a PUBLISH request (with a SIP-If-Match header set to sends them in a PUBLISH request (with a SIP-If-Match header set to
the current etag). This makes credential collisions both unlikely the current etag). This makes credential collisions both unlikely
and harmless. 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, and then creating a certificate as described
in Section 9.6. The UA MAY encrypt the private key with a password in Section 9.6. The UA MAY encrypt the private key with a password
phrase supplied by the user. Next, the UA updates the user's phrase supplied by the user. Next, the UA updates the user's
credential by sending a PUBLISH [3] request with the credentials or credential by sending a PUBLISH [RFC3903] request with the
just the certificate as described in Section 7.9. credentials or just the certificate as described in Section 7.9.
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 RFC 3265 [4]. 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. Event Package Parameters
This package defines the "etag" Event header parameter which is valid This package defines the "etag" Event header parameter which is valid
only in NOTIFY requests. It contains a token which represents the only in NOTIFY requests. It contains a token which represents the
SIP etag value at the time the notification was sent. Considering SIP etag value at the time the notification was sent. Considering
how infrequently credentials are updated, this hint is very likely to how infrequently credentials are updated, this hint is very likely to
skipping to change at page 10, line 41 skipping to change at page 10, line 44
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.5. 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 [10]) that contain an application/pkix-cert body (as defined in [RFC2585]) that
contains the certificate, unless an Accept header has negotiated some contains the certificate, unless an Accept header has negotiated some
other type. The Content-Disposition MUST be set to "signal" as other type. The Content-Disposition MUST be set to "signal" as
defined in [16]. 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 is present in the SUBSCRIBE, the body type defined in this header is present in the SUBSCRIBE, the body type defined in this
document MUST be assumed. 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.6. Subscriber Generation of SUBSCRIBE Requests
skipping to change at page 11, line 45 skipping to change at page 11, line 47
NOTIFY request with an empty message body. NOTIFY request with an empty message body.
6.8. Notifier Generation of NOTIFY Requests 6.8. 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 [2]) or else the server needs to be set up described in SIP Identity [RFC4474]) or else the server needs to be
such that the NOTIFY request will be sent through an Authentication set up such that the NOTIFY request will be sent through an
Service. Sending the NOTIFY request through the Authentication Authentication Service. Sending the NOTIFY request through the
Service requires the SUBSCRIBE request to have been routed through Authentication Service requires the SUBSCRIBE request to have been
the Authentication Service, since the NOTIFY is sent within the routed through the Authentication Service, since the NOTIFY is sent
dialog formed by the subscription. within the dialog formed by the subscription.
6.9. Subscriber Processing of NOTIFY Requests 6.9. 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 [2]. 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.10. 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.11. 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.12. State Agents and Lists
Implementers MUST NOT implement state agents for this event type. Implementers MUST NOT implement state agents for this event type.
Likewise, implementations MUST NOT use the event list extension [19] Likewise, implementations MUST NOT use the event list extension
with this event type. It is not possible to make such an approach [RFC4662] with this event type. It is not possible to make such an
work, because the Authentication service would have to simultaneously approach work, because the Authentication service would have to
assert several different identities. simultaneously assert several different identities.
6.13. Behavior of a Proxy Server 6.13. 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 RFC 3265 [4]. 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. Event Package Parameters
This package defines the "etag" Event header parameter which is valid This package defines the "etag" Event header parameter which is valid
only in NOTIFY requests. It contains a token which represents the only in NOTIFY requests. It contains a token which represents the
SIP etag value at the time the notification was sent. Considering SIP etag value at the time the notification was sent. Considering
how infrequently credentials are updated, this hint is very likely to how infrequently credentials are updated, this hint is very likely to
skipping to change at page 13, line 35 skipping to change at page 13, line 38
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.5. NOTIFY Bodies
The NOTIFY MUST contain a multipart/mixed (see [14]) body that The NOTIFY MUST contain a multipart/mixed (see [RFC2046]) body that
contains both an application/pkix-cert body with the certificate and contains both an application/pkix-cert body with the certificate and
an application/pkcs8 body that has the associated private key an application/pkcs8 body that has the associated private key
information for the certificate. The Content-Disposition MUST be set information for the certificate. The Content-Disposition MUST be set
to "signal" as defined in [16]. to "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 is present in the SUBSCRIBE, the body type defined in this header is present in the SUBSCRIBE, the body type defined in this
document MUST be assumed. document MUST be assumed.
The application/pkix-cert body is a DER encoded X.509v3 certificate The application/pkix-cert body is a DER encoded X.509v3 certificate
[10]. The application/pkcs8 body contains a DER-encoded PKCS#8 [1] [RFC2585]. The application/pkcs8 body contains a DER-encoded PKCS#8
object that contains the private key. The PKCS#8 objects MUST be of [PKCS.8.1993] object that contains the private key. The PKCS#8
type PrivateKeyInfo. The integrity and confidentiality of the PKCS#8 objects MUST be of type PrivateKeyInfo. The integrity and
objects is provided by the TLS transport. The transport encoding of confidentiality of the PKCS#8 objects is provided by the TLS
all the MIME bodies is binary. transport. The transport encoding of all the MIME bodies is binary.
7.6. Subscriber Generation of SUBSCRIBE Requests 7.6. 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
skipping to change at page 15, line 27 skipping to change at page 15, line 30
7.9. Generation of PUBLISH Requests 7.9. 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 [3] request, it needs to do the When the UA sends the PUBLISH [RFC3903] request, it needs to do the
following: following:
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.
o The PUBLISH request SHOULD include a SIP-If-Match header field o The PUBLISH request SHOULD include a SIP-If-Match header field
with the previous etag from the subscription. This prevents with the previous etag from the subscription. This prevents
multiple User Agents for the same AOR from publishing conflicting multiple User Agents for the same AOR from publishing conflicting
credentials. Note that UAs replace credentials that are about to credentials. Note that UAs replace credentials that are about to
expire at a random time (described in Section 5), reducing the expire at a random time (described in Section 5), reducing the
skipping to change at page 16, line 42 skipping to change at page 16, line 44
This event package does not permit forked requests. This event package does not permit forked requests.
7.13. Rate of Notifications 7.13. 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.14. State Agents and Lists
Implementers MUST NOT implement state agents for this event type. Implementers MUST NOT implement state agents for this event type.
Likewise, implementations MUST NOT use the event list extension [19] Likewise, implementations MUST NOT use the event list extension
with this event type. [RFC4662] with this event type.
7.15. Behavior of a Proxy Server 7.15. 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.13.
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
message. Alice does not already have Bob's public key from previous message. Alice does not already have Bob's public key from previous
communications, so she fetches Bob's public key from Bob's credential communications, so she fetches Bob's public key from Bob's credential
service: service:
skipping to change at page 20, line 10 skipping to change at page 20, line 10
A similar process would be used for Bob's UA to publish new 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 credentials to the server. Bob's UA would send a PUBLISH request
containing the new credentials. When this happened, all the other containing the new credentials. When this happened, all the other
UAs that were subscribed to Bob's credentials would receive a NOTIFY UAs that were subscribed to Bob's credentials would receive a NOTIFY
with the new credentials. with the new credentials.
Alice wishes to find Bob's certificate and sends a SUBSCRIBE to the 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 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 need to be sent over a privacy or integrity protected channel, as the
Authentication service described in [2] provides integrity protection Authentication service described in [RFC4474] provides integrity
of this information and signs it with the certificate for the domain. protection of this information and signs it with the certificate for
the domain.
This whole scheme is highly dependent on trusting the operators of This whole scheme is highly dependent on trusting the operators of
the credential service and trusting that the credential service will the credential service and trusting that the credential service will
not be compromised. The security of all the users will be not be compromised. The security of all the users will be
compromised if the credential service is compromised. compromised if the credential service is compromised.
Note: There has been significant discussion of the topic of Note: There has been significant discussion of the topic of
avoiding deployments in which the credential servers store the avoiding deployments in which the credential servers store the
private keys, even in some encrypted form that the credential private keys, even in some encrypted form that the credential
server does not know how to decrypt. Various schemes were server does not know how to decrypt. Various schemes were
skipping to change at page 20, line 49 skipping to change at page 20, line 50
2. Confidentiality is provided for the private key, thus protecting 2. Confidentiality is provided for the private key, thus protecting
it from being exposed to passive attackers. it from being exposed to passive attackers.
In order to prevent man-in-the-middle attacks, TLS clients MUST check In order to prevent man-in-the-middle attacks, TLS clients MUST check
that the SubjectAltName of the certificate for the server they that the SubjectAltName of the certificate for the server they
connected to exactly matches the server they were trying to connect connected to exactly matches the server they were trying to connect
to. Failing to use TLS or selecting a poor cipher suite (such as to. Failing to use TLS or selecting a poor cipher suite (such as
NULL encryption) may result in credentials, including private keys, NULL encryption) may result in credentials, including private keys,
being sent unencrypted over the network and will render the whole being sent unencrypted over the network and will render the whole
system useless. system useless.
The correct checking of chained certificates as specified in TLS [11] The correct checking of chained certificates as specified in TLS
is critical for the client to authenticate the server. If the client [RFC4366] is critical for the client to authenticate the server. If
does not authenticate that it is talking to the correct credential the client does not authenticate that it is talking to the correct
service, a man in the middle attack is possible. credential service, a man in the middle attack is possible.
9.1. Certificate Revocation 9.1. Certificate Revocation
If a particular credential needs to be revoked, the new credential is If a particular credential needs to be revoked, the new credential is
simply published to the credential service. Every device with a copy simply published to the credential service. Every device with a copy
of the old credential or certificate in its cache will have a of the old credential or certificate in its cache will have a
subscription and will rapidly (order of seconds) be notified and subscription and will rapidly (order of seconds) be notified and
replace its cache. Clients that are not subscribed will subscribe replace its cache. Clients that are not subscribed will subscribe
when they next need to use the certificate and will get the new when they next need to use the certificate and will get the new
certificate. certificate.
skipping to change at page 22, line 8 skipping to change at page 22, line 8
If the certificate is signed by a trusted CA, and one of the names in If the certificate is signed by a trusted CA, and one of the names in
the SubjectAltName matches the original URI, then this certificate the SubjectAltName matches the original URI, then this certificate
MAY be used but only for exactly the original URI and not for other MAY be used but only for exactly the original URI and not for other
identities found in the SubjectAltName. Otherwise, there are several identities found in the SubjectAltName. Otherwise, there are several
steps the UA MUST perform before using this certificate. steps the UA MUST perform before using this certificate.
o The From header in the NOTIFY request MUST match the original URI o The From header in the NOTIFY request MUST match the original URI
that was subscribed to. that was subscribed to.
o The UA MUST check the Identity header as described in the Identity o The UA MUST check the Identity header as described in the Identity
[2] specification to validate that bodies have not been tampered [RFC4474] specification to validate that bodies have not been
with and that an Authentication Service has validated this From tampered with and that an Authentication Service has validated
header. this From header.
o The UA MUST check the validity time of the certificate and stop o The UA MUST check the validity time of the certificate and stop
using the certificate if it is invalid. (Implementations are using the certificate if it is invalid. (Implementations are
reminded to verify both the notBefore and notAfter validity reminded to verify both the notBefore and notAfter validity
times.) times.)
o The certificate MAY have several names in the SubjectAltName but o The certificate MAY have several names in the SubjectAltName but
the UA MUST only use this certificate when it needs the the UA MUST only use this certificate when it needs the
certificate for the identity asserted by the Authentication certificate for the identity asserted by the Authentication
Service in the NOTIFY. This means that the certificate should Service in the NOTIFY. This means that the certificate should
only be indexed in the certificate cache by the AOR that the only be indexed in the certificate cache by the AOR that the
Authentication Service asserted and not by the value of all the Authentication Service asserted and not by the value of all the
skipping to change at page 22, line 38 skipping to change at page 22, line 38
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.4. Conformity to the SACRED Framework 9.4. SACRED Framework
This specification uses the security design outlined in the SACRED This specification includes a mechanism that allows end users to
Framework [7]. Specifically, it follows the cTLS architecture share the same credentials across different end-user devices. This
described in section 4.2.2 of RFC 3760. The client authenticates the mechanism is based on the one presented in the SACRED Framework
server using the server's TLS certificate. The server authenticates [RFC3760]. While this mechanism is fully described in this document,
the client using a SIP digest transaction inside the TLS session. the requirements and background are more thoroughly discussed in
The TLS sessions form a strong session key that is used to protect [RFC3760].
the credentials being exchanged.
Specifically, Section 7.6, Section 7.7 and Section 7.10 follow the
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.
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 RFC 3546 [8] and they MUST support a TLS profile of extensions in [RFC4366] and they MUST support a TLS profile of
TLS_RSA_WITH_AES_128_CBC_SHA as described in RFC 3268 [9] as a TLS_RSA_WITH_AES_128_CBC_SHA as described in [RFC3268] as a profile
profile of TLS_RSA_WITH_3DES_EDE_CBC_SHA. of TLS_RSA_WITH_3DES_EDE_CBC_SHA.
The PKCS#8 in the clients MUST implement PBES2 with a key derivation The PKCS#8 in the clients MUST implement PBES2 with a key derivation
algorithm of PBKDF2 using HMAC with SHA1 and an encryption algorithm algorithm of PBKDF2 using HMAC with SHA1 and an encryption algorithm
of DES-EDE2-CBC-Pad as defined in RFC 2898 [12]. It is RECOMMENDED of DES-EDE2-CBC-Pad as defined in [RFC2898]. It is RECOMMENDED that
that this profile be used when using PKCS#8. A different passphrase this profile be used when using PKCS#8. A different passphrase
SHOULD be used for the PKCS#8 encryption than is used for server SHOULD be used for the PKCS#8 encryption than is used for server
authentication. authentication.
9.6. User Certificate Generation 9.6. User Certificate Generation
The certificates should be consistent with RFC 3280 [13]. A The certificates should be consistent with [RFC3280]. A
signatureAlgorithm of sha1WithRSAEncryption MUST be implemented. The signatureAlgorithm of sha1WithRSAEncryption MUST be implemented. The
Issuers SHOULD be the same as the subject. Given the ease of issuing Issuers SHOULD be the same as the subject. Given the ease of issuing
new certificates with this system, the Validity can be relatively new certificates with this system, the Validity can be relatively
short. A Validity of one year or less is RECOMMENDED. The short. A Validity of one year or less is RECOMMENDED. The
subjectAltName must have a URI type that is set to the SIP URL 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 corresponding to the user AOR. It MAY be desirable to put some
randomness into the length of time for which the certificates are randomness into the length of time for which the certificates are
valid so that it does not become necessary to renew all the valid so that it does not become necessary to renew all the
certificates in the system at the same time. certificates in the system at the same time.
skipping to change at page 26, line 20 skipping to change at page 27, line 18
help and discussion. Many others provided useful comments, including help and discussion. Many others provided useful comments, including
Kumiko Ono, Peter Gutmann, Russ Housley, Yaron Pdut, Aki Niemi, Kumiko Ono, Peter Gutmann, Russ Housley, Yaron Pdut, Aki Niemi,
Magnus Nystrom, Paul Hoffman, Adina Simu, Dan Wing, Mike Hammer and Magnus Nystrom, Paul Hoffman, Adina Simu, Dan Wing, Mike Hammer and
Lyndsay Campbell. Rohan Mahy, John Elwell, and Jonathan Rosenberg Lyndsay Campbell. Rohan Mahy, John Elwell, and Jonathan Rosenberg
provided detailed review and text. provided detailed review and text.
12. References 12. References
12.1. Normative References 12.1. Normative References
[1] RSA Laboratories, "Private-Key Information Syntax Standard, [PKCS.8.1993]
Version 1.2", PKCS 8, November 1993. RSA Laboratories, "Private-Key Information Syntax
Standard, Version 1.2", PKCS 8, November 1993.
[2] Peterson, J. and C. Jennings, "Enhancements for Authenticated
Identity Management in the Session Initiation Protocol (SIP)",
RFC 4474, August 2006.
[3] Niemi, A., "Session Initiation Protocol (SIP) Extension for
Event State Publication", RFC 3903, October 2004.
[4] Roach, A., "Session Initiation Protocol (SIP)-Specific Event [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Notification", RFC 3265, June 2002. Extensions (MIME) Part Two: Media Types", RFC 2046,
November 1996.
[5] Bradner, S., "Key words for use in RFCs to Indicate Requirement [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[6] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., [RFC2585] Housley, R. and P. Hoffman, "Internet X.509 Public Key
Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Infrastructure Operational Protocols: FTP and HTTP",
Session Initiation Protocol", RFC 3261, June 2002. RFC 2585, May 1999.
[7] Gustafson, D., Just, M., and M. Nystrom, "Securely Available [RFC3204] Zimmerer, E., Peterson, J., Vemuri, A., Ong, L., Audet,
Credentials (SACRED) - Credential Server Framework", RFC 3760, F., Watson, M., and M. Zonoun, "MIME media types for ISUP
April 2004. and QSIG Objects", RFC 3204, December 2001.
[8] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
T. Wright, "Transport Layer Security (TLS) Extensions", A., Peterson, J., Sparks, R., Handley, M., and E.
RFC 3546, June 2003. Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002.
[9] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites for [RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific
Transport Layer Security (TLS)", RFC 3268, June 2002. Event Notification", RFC 3265, June 2002.
[10] Housley, R. and P. Hoffman, "Internet X.509 Public Key [RFC3268] Chown, P., "Advanced Encryption Standard (AES)
Infrastructure Operational Protocols: FTP and HTTP", RFC 2585, Ciphersuites for Transport Layer Security (TLS)",
May 1999. RFC 3268, June 2002.
[11] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
RFC 2246, January 1999. X.509 Public Key Infrastructure Certificate and
Certificate Revocation List (CRL) Profile", RFC 3280,
April 2002.
[12] Kaliski, B., "PKCS #5: Password-Based Cryptography [RFC3903] Niemi, A., "Session Initiation Protocol (SIP) Extension
Specification Version 2.0", RFC 2898, September 2000. for Event State Publication", RFC 3903, October 2004.
[13] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 [RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,
Public Key Infrastructure Certificate and Certificate and T. Wright, "Transport Layer Security (TLS)
Revocation List (CRL) Profile", RFC 3280, April 2002. Extensions", RFC 4366, April 2006.
[14] Freed, N. and N. Borenstein, "Multipurpose Internet Mail [RFC4474] Peterson, J. and C. Jennings, "Enhancements for
Extensions (MIME) Part Two: Media Types", RFC 2046, Authenticated Identity Management in the Session
November 1996. Initiation Protocol (SIP)", RFC 4474, August 2006.
[15] International Telecommunications Union, "Information technology [RFC2898] Kaliski, B., "PKCS #5: Password-Based Cryptography
- Open Systems Interconnection - The Directory: Public-key and Specification Version 2.0", RFC 2898, September 2000.
attribute certificate frameworks", ITU-T Recommendation X.509,
ISO Standard 9594-8, March 2000.
[16] Zimmerer, E., Peterson, J., Vemuri, A., Ong, L., Audet, F., This reference is informational. The mechanisms used in
Watson, M., and M. Zonoun, "MIME media types for ISUP and QSIG this specification from RFC2898 are stable and sutable for
Objects", RFC 3204, December 2001. use in a standards track specification. RFC2898 has been
used as a normative reference in several prior standards
track documents including RFC3185, RFC3370, RFC3962, and
RFC4656.
12.2. Informational References 12.2. Informational References
[17] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions [RFC3760] Gustafson, D., Just, M., and M. Nystrom, "Securely
(S/MIME) Version 3.1 Message Specification", RFC 3851, Available Credentials (SACRED) - Credential Server
July 2004. Framework", RFC 3760, April 2004.
[18] Peterson, J., "S/MIME Advanced Encryption Standard (AES) [RFC3851] Ramsdell, B., "Secure/Multipurpose Internet Mail
Extensions (S/MIME) Version 3.1 Message Specification",
RFC 3851, July 2004.
[RFC3853] Peterson, J., "S/MIME Advanced Encryption Standard (AES)
Requirement for the Session Initiation Protocol (SIP)", Requirement for the Session Initiation Protocol (SIP)",
RFC 3853, July 2004. RFC 3853, July 2004.
[19] Roach, A., Rosenberg, J., and B. Campbell, "A Session [RFC4662] Roach, A., Rosenberg, J., and B. Campbell, "A Session
Initiation Protocol (SIP) Event Notification Extension for Initiation Protocol (SIP) Event Notification Extension for
Resource Lists", RFC 4662, August 2006. Resource Lists", RFC 4662, August 2006.
Authors' Addresses Authors' Addresses
Cullen Jennings Cullen Jennings
Cisco Systems Cisco Systems
170 West Tasman Drive 170 West Tasman Drive
MS: SJC-21/2 MS: SJC-21/2
San Jose, CA 95134 San Jose, CA 95134
skipping to change at page 28, line 30 skipping to change at page 29, line 30
Suite 570 Suite 570
Concord, CA 94520 Concord, CA 94520
US US
Phone: +1 925/363-8720 Phone: +1 925/363-8720
Email: jon.peterson@neustar.biz Email: jon.peterson@neustar.biz
URI: http://www.neustar.biz/ URI: http://www.neustar.biz/
Jason Fischl (editor) Jason Fischl (editor)
CounterPath Solutions, Inc. CounterPath Solutions, Inc.
8th Floor Suite 300
100 West Pender St. One Bentall Centre
Vancouver, BC V6B 1R8 505 Burrard Street
Vancouver, BC V7X 1M3
Canada Canada
Phone: +1(604)628-1801 Phone: +1 604 320-3344
Email: jason@counterpath.com Email: jason@counterpath.com
URI: http://www.counterpath.com URI: http://www.counterpath.com
Intellectual Property Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
skipping to change at page 29, line 29 skipping to change at page 30, line 45
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is provided by the IETF
Internet Society. Administrative Support Activity (IASA).
 End of changes. 66 change blocks. 
187 lines changed or deleted 199 lines changed or added

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