< draft-ietf-sipping-certs-01.txt   draft-ietf-sipping-certs-02.txt >
SIP C. Jennings SIP C. Jennings
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Expires: August 20, 2005 J. Peterson Expires: January 18, 2006 J. Peterson
NeuStar, Inc. NeuStar, Inc.
February 19, 2005 July 17, 2005
Certificate Management Service for The Session Initiation Protocol Certificate Management Service for The Session Initiation Protocol (SIP)
(SIP) draft-ietf-sipping-certs-02
draft-ietf-sipping-certs-01
Status of this Memo Status of this Memo
This document is an Internet-Draft and is subject to all provisions By submitting this Internet-Draft, each author represents that any
of section 3 of RFC 3667. By submitting this Internet-Draft, each applicable patent or other IPR claims of which he or she is aware
author represents that any applicable patent or other IPR claims of have been or will be disclosed, and any of which he or she becomes
which he or she is aware have been or will be disclosed, and any of aware will be disclosed, in accordance with Section 6 of BCP 79.
which he or she become aware will be disclosed, in accordance with
RFC 3668.
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 other groups may also distribute working documents as Internet-
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 August 20, 2005. This Internet-Draft will expire on January 18, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2005).
Abstract Abstract
This draft defines a Credential Service that allows SIP User Agents This draft defines a Credential Service that allows SIP User Agents
to use a SIP package to discover the certificates of other users. to use a SIP package to discover the certificates of other users.
This mechanism allows user agents that want to contact a given This mechanism allows user agents that want to contact a given
Address-of-Record (AOR) to retrieve that AOR's certificate by Address-of-Record (AOR) to retrieve that AOR's certificate by
subscribing to the Credential Service. The Credential Service also subscribing to the Credential Service. The Credential Service also
allows users to store and retrieve their own certificates and private allows users to store and retrieve their own certificates and private
keys. keys.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. UA Behavior with Certificates . . . . . . . . . . . . . . . 6 4. UA Behavior with Certificates . . . . . . . . . . . . . . . 7
5. UA Behavior with Credentials . . . . . . . . . . . . . . . . 7 5. UA Behavior with Credentials . . . . . . . . . . . . . . . . 8
6. Credential Service Behavior . . . . . . . . . . . . . . . . 8 6. Credential Service Behavior . . . . . . . . . . . . . . . . 9
7. Event Package Formal Definition for "certificate" . . . . . 8 7. Event Package Formal Definition for "certificate" . . . . . 9
7.1 Event Package Name . . . . . . . . . . . . . . . . . . . . 8 7.1 Event Package Name . . . . . . . . . . . . . . . . . . . . 9
7.2 Event Package Parameters . . . . . . . . . . . . . . . . . 8 7.2 Event Package Parameters . . . . . . . . . . . . . . . . . 9
7.3 SUBSCRIBE Bodies . . . . . . . . . . . . . . . . . . . . . 9 7.3 SUBSCRIBE Bodies . . . . . . . . . . . . . . . . . . . . . 9
7.4 Subscription Duration . . . . . . . . . . . . . . . . . . 9 7.4 Subscription Duration . . . . . . . . . . . . . . . . . . 10
7.5 NOTIFY Bodies . . . . . . . . . . . . . . . . . . . . . . 9 7.5 NOTIFY Bodies . . . . . . . . . . . . . . . . . . . . . . 10
7.6 Subscriber Generation of SUBSCRIBE Requests . . . . . . . 9 7.6 Subscriber Generation of SUBSCRIBE Requests . . . . . . . 10
7.7 Notifier Processing of SUBSCRIBE Requests . . . . . . . . 9 7.7 Notifier Processing of SUBSCRIBE Requests . . . . . . . . 10
7.8 Notifier Generation of NOTIFY Requests . . . . . . . . . . 10 7.8 Notifier Generation of NOTIFY Requests . . . . . . . . . . 11
7.9 Subscriber Processing of NOTIFY Requests . . . . . . . . . 10 7.9 Subscriber Processing of NOTIFY Requests . . . . . . . . . 11
7.10 Handling of Forked Requests . . . . . . . . . . . . . . 10 7.10 Handling of Forked Requests . . . . . . . . . . . . . . 11
7.11 Rate of Notifications . . . . . . . . . . . . . . . . . 10 7.11 Rate of Notifications . . . . . . . . . . . . . . . . . 11
7.12 State Agents and Lists . . . . . . . . . . . . . . . . . 11 7.12 State Agents and Lists . . . . . . . . . . . . . . . . . 12
7.13 Behavior of a Proxy Server . . . . . . . . . . . . . . . 11 7.13 Behavior of a Proxy Server . . . . . . . . . . . . . . . 12
8. Event Package Formal Definition for "credential" . . . . . . 11 8. Event Package Formal Definition for "credential" . . . . . . 12
8.1 Event Package Name . . . . . . . . . . . . . . . . . . . . 11 8.1 Event Package Name . . . . . . . . . . . . . . . . . . . . 12
8.2 Event Package Parameters . . . . . . . . . . . . . . . . . 11 8.2 Event Package Parameters . . . . . . . . . . . . . . . . . 12
8.3 SUBSCRIBE Bodies . . . . . . . . . . . . . . . . . . . . . 11 8.3 SUBSCRIBE Bodies . . . . . . . . . . . . . . . . . . . . . 12
8.4 Subscription Duration . . . . . . . . . . . . . . . . . . 11 8.4 Subscription Duration . . . . . . . . . . . . . . . . . . 12
8.5 NOTIFY Bodies . . . . . . . . . . . . . . . . . . . . . . 12 8.5 NOTIFY Bodies . . . . . . . . . . . . . . . . . . . . . . 13
8.6 Subscriber Generation of SUBSCRIBE Requests . . . . . . . 12 8.6 Subscriber Generation of SUBSCRIBE Requests . . . . . . . 13
8.7 Notifier Processing of SUBSCRIBE Requests . . . . . . . . 13 8.7 Notifier Processing of SUBSCRIBE Requests . . . . . . . . 14
8.8 Notifier Generation of NOTIFY Requests . . . . . . . . . . 13 8.8 Notifier Generation of NOTIFY Requests . . . . . . . . . . 14
8.9 Notifier Processing of PUBLISH Requests . . . . . . . . . 13 8.9 Generation of PUBLISH Requests . . . . . . . . . . . . . . 14
8.10 Subscriber Processing of NOTIFY Requests . . . . . . . . 14 8.10 Notifier Processing of PUBLISH Requests . . . . . . . . 15
8.11 Handling of Forked Requests . . . . . . . . . . . . . . 14 8.11 Subscriber Processing of NOTIFY Requests . . . . . . . . 15
8.12 Rate of Notifications . . . . . . . . . . . . . . . . . 14 8.12 Handling of Forked Requests . . . . . . . . . . . . . . 16
8.13 State Agents and Lists . . . . . . . . . . . . . . . . . 14 8.13 Rate of Notifications . . . . . . . . . . . . . . . . . 16
8.14 Behavior of a Proxy Server . . . . . . . . . . . . . . . 14 8.14 State Agents and Lists . . . . . . . . . . . . . . . . . 16
9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 14 8.15 Behavior of a Proxy Server . . . . . . . . . . . . . . . 16
9.1 Encrypted Page Mode IM Message . . . . . . . . . . . . . . 14 9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 16
9.2 Setting and Retrieving UA Credentials . . . . . . . . . . 15 9.1 Encrypted Page Mode IM Message . . . . . . . . . . . . . . 16
10. Security Considerations . . . . . . . . . . . . . . . . . . 16 9.2 Setting and Retrieving UA Credentials . . . . . . . . . . 17
10.1 Certificate Revocation . . . . . . . . . . . . . . . . . 18 10. Security Considerations . . . . . . . . . . . . . . . . . . 18
10.2 Certificate Replacement . . . . . . . . . . . . . . . . 19 10.1 Certificate Revocation . . . . . . . . . . . . . . . . . 20
10.3 Trusting the Identity of a Certificate . . . . . . . . . 19 10.2 Certificate Replacement . . . . . . . . . . . . . . . . 21
10.4 Conformity to the SACRED Framework . . . . . . . . . . . 20 10.3 Trusting the Identity of a Certificate . . . . . . . . . 21
10.5 Crypto Profiles . . . . . . . . . . . . . . . . . . . . 20 10.4 Conformity to the SACRED Framework . . . . . . . . . . . 22
10.6 User Certificate Generation . . . . . . . . . . . . . . 20 10.5 Crypto Profiles . . . . . . . . . . . . . . . . . . . . 22
10.7 Compromised Authentication Service . . . . . . . . . . . 20 10.6 User Certificate Generation . . . . . . . . . . . . . . 23
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . 21 10.7 Compromised Authentication Service . . . . . . . . . . . 23
11.1 Certificate Event Package . . . . . . . . . . . . . . . 21 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . 23
11.2 Credential Event Package . . . . . . . . . . . . . . . . 22 11.1 Certificate Event Package . . . . . . . . . . . . . . . 24
11.3 PKCS#8 . . . . . . . . . . . . . . . . . . . . . . . . . 22 11.2 Credential Event Package . . . . . . . . . . . . . . . . 24
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 23 11.3 PKCS#8 . . . . . . . . . . . . . . . . . . . . . . . . . 24
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 26
13.1 Normative References . . . . . . . . . . . . . . . . . . . 23 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 26
13.2 Informational References . . . . . . . . . . . . . . . . . 24 13.1 Normative References . . . . . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 25 13.2 Informational References . . . . . . . . . . . . . . . . 27
Intellectual Property and Copyright Statements . . . . . . . 26 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 28
Intellectual Property and Copyright Statements . . . . . . . 29
1. Introduction 1. Introduction
SIP [6] provides a mechanism [17] for end-to-end encryption and SIP [6] provides a mechanism [18] for end-to-end encryption and
integrity using S/MIME [16]. Several security properties of SIP integrity using S/MIME [17]. Several security properties of SIP
depend on S/MIME, and yet it has not been widely deployed. depend on S/MIME, and yet it has not been widely deployed.
Certainly, one reason is the complexity of providing a reasonable Certainly, one reason is the complexity of providing a reasonable
certificate distribution infrastructure. This specification proposes certificate distribution infrastructure. This specification proposes
a way to address discovery, retrieval, and management of certificates a way to address discovery, retrieval, and management of certificates
for SIP deployments. It follows the Sacred Framework RFC 3760 [7] for SIP deployments. It follows the Sacred Framework RFC 3760 [7]
for management of the credentials. Combined with the SIP Identity for management of the credentials. Combined with the SIP Identity
[2] specification, this specification allows users to have [2] specification, this specification allows users to have
certificates that are not signed by any well known certificate certificates that are not signed by any well known certificate
authority while still strongly binding the user's identity to the authority while still strongly binding the user's identity to the
certificate. This mechanism allows SIP User Agents such as IP phones certificate. This mechanism allows SIP User Agents such as IP phones
skipping to change at page 4, line 30 skipping to change at page 4, line 30
information than they commonly have today. The end user expends no information than they commonly have today. The end user expends no
extra effort. extra effort.
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 RFC 2119 [5].
Certificate: An X.509v3 [15] style certificate containing a public Certificate: An X.509v3 [15] style certificate containing a public
key 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. [2] specification to vouch for their validity, but certificates
that are signed by a certificate authority can also be used with
all the mechanisms in this draft.
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.
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 to "credential service" that allows SIP User Agents (UAs) to subscribe
some other user's certificate using a new SIP event package [4]. The to other users' certificates using a new SIP event package [4]. The
certificate is delivered to the subscribing UA in a corresponding SIP certificate is delivered to the subscribing UA in a corresponding SIP
NOTIFY request. The identity of the certificate can be vouched for NOTIFY request. The identity of the certificate can be vouched for
using the Authentication Service from the SIP Identity [2] using the Authentication Service from the SIP Identity [2]
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 [3] request.
The UA authenticates to the Credential Service using a shared secret The UA authenticates to the credential service using a shared secret
when a UA is updating a credential. Typically the shared secret will when a UA is updating a credential. Typically the shared secret will
be the same one that is used by the UA to authenticate a REGISTER be the same one that is used by the UA to authenticate a REGISTER
request with the Registrar for the domain (usually with SIP Digest request with the Registrar for the domain (usually with SIP Digest
Authentication). 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 (ex: his laptop software client), retrieving his his User Agents (e.g. his laptop software client), retrieving his
credentials from another of his User Agents (ex: 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 Bob. SIP 200-class responses are omitted from the diagram to make the
the figure easier to understand. figure easier to understand.
example.com domain example.com domain
------------------ ------------------
Alice Proxy Auth Cred Bob1 Bob2 Alice Proxy Auth Cred Bob1 Bob2
| | | | TLS Handshake | | | | | | TLS Handshake | |
| [ Bob generates ] |<--------------------->| | [ Bob generates ] |<--------------------->|
| [ credentials and ] | PUBLISH (credential) | | [ credentials and ] | PUBLISH (credential) |
| [ publishes them ] |<----------------------| | [ publishes them ] |<----------------------|
| | | | Digest Challenge | | | | | Digest Challenge |
| | | |---------------------->| | | | |---------------------->|
skipping to change at page 6, line 4 skipping to change at page 6, line 6
| | |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 [11] handshake with the credential server
to authenticate that the UA is connected to the correct credential to authenticate that the UA is connected to the correct credential
server. Then Bob's UA publishes his newly created or updated server. Then Bob's UA publishes his newly created or updated
credentials. The Credential server digest challenges the UA to credentials. The credential server digest challenges the UA to
authenticate that the UA knows Bob's shared secret. Once the UA is authenticate that the UA knows Bob's shared secret. Once the UA is
authenticated, the credential server stores Bob's credentials. authenticated, the credential server stores Bob's credentials.
Another one 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 [11] handshake with the credential server
to authenticate that the UA is connected to the correct credential to authenticate that the UA is connected to the correct credential
server. Then Bob's UA subscribes for the credentials. The server. Then Bob's UA subscribes for the credentials. The
Credential server digest challenges the UA to authenticate that the credential server digest challenges the UA to authenticate that the
UA knows Bob's shared secret. Once the UA is authenticated, 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. Alice's certificate so that she can send him an encrypted message or so that
UA sends a SUBSCRIBE message to Bob's AOR. The proxy in Bob's domain she can verify the signature on a message from Bob. Alice's UA sends
routes this to the credential server via an authorization service. a SUBSCRIBE message to Bob's AOR. The proxy in Bob's domain routes
The credential server returns a NOFITY that contains Bob's public this to the credential server via an authorization service. The
credential server returns a NOTIFY that contains Bob's public
certificate in the body. This is routed through an authentication certificate in the body. This is routed through an authentication
service that signs that this message really can validly claim to be service that signs that this message really can validly claim to be
from the AOR "sip:bob@example.com". Alice's UA receives the from the AOR "sip:bob@example.com". Alice's UA receives the
certificate and can use it to encrypt a message to Bob. certificate and can use it to encrypt a message to Bob.
It is critical to understand that the only way that Alice can trust
that the certificate really is the one for Bob and that the NOTIFY
has not been spoofed is for Alice to check that the Identity [2]
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, it is imagined that most UAs using this would authorities; however, it is imagined that most UAs using this would
only use self signed certificates, and would use an Authentication only use self signed certificates and would use an Authentication
Service as described in [2] to provide a strong binding of an AOR to Service as described in [2] to provide a strong binding of an AOR to
the certificates. the certificates.
The mechanisms described in this draft allow for three different
styles of deployment:
1. Deployments where the the credential server only stores
certificates and does not store any private key information. If
the deployment had users with multiple devices, some other scheme
(perhaps even manual provisioning) would be used to get the right
private keys onto all the devices that a user uses.
2. Deployments where the credential server stores certificates and
also stores encrypted version of the private keys. The
credential server would not know or need the password phrase for
decrypting the private key. The credential server would help
move the the private keys between devices but the user would need
to enter a password phrase on each device to allow that device to
decrypt (and encrypt) the private key information.
3. Deployments where the credential server stores the certificates
and private keys and also knows the password phrase for
decrypting the private keys. Deployments such as these may not
even use password phrases, in which case the private keys are not
encrypted inside the PKCS#8 objects. This style of deployments
would often have the credential server, instead of the devices,
create the credentials.
4. UA Behavior with Certificates 4. UA Behavior with Certificates
When a User Agent wishes to discover some other user's certificate it When a User Agent wishes to discover some other user's certificate it
subscribes to the "certificate" SIP event package as described in subscribes to the "certificate" SIP event package as described in
Section 7 to get the certificate. While the subscription is active, Section 7 to get the certificate. While the subscription is active,
if the certificate is updated, the Subscriber will receive the if the certificate is updated, the Subscriber will receive the
updated certificate in a notification. updated certificate in a notification.
The Subscriber needs to decide how long it is willing to trust that The Subscriber needs to decide how long it is willing to trust that
the certificate it receives is still valid. If the certificate is the certificate it receives is still valid. If the certificate is
skipping to change at page 7, line 18 skipping to change at page 7, line 49
the caching time or validity time of the corresponding certificate. the caching time or validity time of the corresponding certificate.
Allowing subscriptions to persist after a certificate is not longer Allowing subscriptions to persist after a certificate is not longer
valid ensures that Subscribers receive the replacement certificate in valid ensures that Subscribers receive the replacement certificate in
a timely fashion. In some cases, the Notifier will not allow a timely fashion. In some cases, the Notifier will not allow
unauthenticated subscriptions to persist. The Notifier could return unauthenticated subscriptions to persist. The Notifier could return
an immediate notification with the certificate in response to an immediate notification with the certificate in response to
subscribe and then immediately terminate subscription, setting the subscribe and then immediately terminate subscription, setting the
reason parameter to "probation". The Subscriber will have to reason parameter to "probation". The Subscriber will have to
periodically poll the Notifier to verify validity of the certificate. periodically poll the Notifier to verify validity of the certificate.
If the UA uses a cached certificate in a request and receives a 493 If the UA uses a cached certificate in a request and receives a 437
(Undecipherable) response, it SHOULD remove the certificate it used (Unsupported Certificate) response, it SHOULD remove the certificate
from the cache, attempt to fetch the certificate again, and retry the it used from the cache, attempt to fetch the certificate again. If
the certificate is the not the same, then the UA SHOULD retry the
original request again. This situation usually indicates that the original request again. This situation usually indicates that the
certificate was recently updated, and that the Subscriber has not certificate was recently updated, and that the Subscriber has not
received a corresponding notification. received a corresponding notification. If the certificate fetched is
the same as the one that was previously in the the cache, then the UA
SHOULD NOT try the request again. This situation can happened when
the request was retargeted to a different user than the original
request. The 437 response is defined in [2].
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
outside the scope of this specification but it is worth noting that
if 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 Charlie.
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 8. After a UA an event type of credential as described in Section 8. After a UA
registers, it SHOULD retrieve its credentials. registers, it SHOULD retrieve its credentials by subscribing to them
as described in Section 7.6.
When a UA discovers its credential, the private key information might
be encrypted with a password phrase. The UA SHOULD request that the
user enter the password phrase on the device, and the UA MAY cache
this password phrase for future use.
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 for the credential package with no o If the UA receives a NOTIFY with no body for the credential
body. package.
o If the certificate has expired. o If the certificate has expired.
o If the certificate is within ten minutes of expiring, the UA o If the certificate is within 600 seconds of expiring, the UA
SHOULD attempt to create replacement credentials. The UA does SHOULD attempt to create replacement credentials. The UA does
this by waiting a random amount of time between 0 and 600 seconds. this by waiting a random amount of time between 0 and 300 seconds.
If no new credentials was received in that time, the UA creates If no new credentials have been received in that time, the UA
new credentials to replace the expiring ones, and sends them in a creates new credentials to replace the expiring ones and sends
PUBLISH request (with a SIP-If-Match header set to the current them in a PUBLISH request (with a SIP-If-Match header set to the
entity-tag). This makes credential collisions both unlikely and current etag). This makes credential collisions both unlikely and
harmless. 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, creating a certificate as described in appropriate randomness, and then creating a certificate as described
Section 10.6, and encrypting the private key with a pass phrase in Section 10.6. The UA MAY encrypt the private key with a password
supplied by the user. Then the UA can change the user's credential phrase supplied by the user. Then the UA updates the user's
by sending the server a PUBLISH[3] with an event type of credential credential by sending a PUBLISH [3] request with the credentials or
that contains a multipart/mixed containing both an just the certificate as described in Section 8.9.
application/pkix-cert and an application/pkcs8 body. The PUBLISH
request MUST include a SIP-If-Match header field with the previous
entity-tag know to the subscriber. This prevents multiple User
Agents for the same AOR from publishing conflicting credentials.
If a UA wishes to revoke the existing certificate without publishing 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. Credential Service Behavior 6. Credential Service Behavior
The Credential Service stores credentials for users and can provide The credential service stores credentials for users and can provide
the credentials to other user agents belonging to the same user, and the credentials to other user agents belonging to the same user, and
certificates to any user agent. The credentials are indexed by a URI certificates to any user agent. The credentials are indexed by a URI
that corresponds to the AOR of the user. When a UA requests a public that corresponds to the AOR of the user. When a UA requests a public
certificate with a SUBSCRIBE, the server sends the UA the certificate certificate with a SUBSCRIBE, the server sends the UA the certificate
in a NOTIFY and sends a subsequent NOTIFY any time the certificate in a NOTIFY and sends a subsequent NOTIFY any time the certificate
changes. When a credential is requested, the Credential Service changes. When a credential is requested, the credential service
digest challenges the requesting UA to authenticate it so that the digest challenges the requesting UA to authenticate it so that the
Credential Service can verify that the UA is authorized to receive credential service can verify that the UA is authorized to receive
the requested credentials. When a credential is published, the the requested credentials. When a credential is published, the
Credential Service digest challenges the requesting UA to credential service digest challenges the requesting UA to
authenticate it so that the Credential Service can verify that the UA authenticate it so that the credential service can verify that the UA
is authorized to change the credentials. This behavior is defined in is authorized to change the credentials. This behavior is defined in
Section 7 and Section 8. Section 7 and Section 8.
7. Event Package Formal Definition for "certificate" 7. Event Package Formal Definition for "certificate"
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 RFC 3265 [4].
The event-package token name for this package is: The event-package token name for this package is:
skipping to change at page 9, line 15 skipping to change at page 10, line 11
7.3 SUBSCRIBE Bodies 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.4 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.
7.5 NOTIFY Bodies 7.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 [10]) 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". other type. The Content-Disposition MUST be set to "signal".
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.
7.6 Subscriber Generation of SUBSCRIBE Requests 7.6 Subscriber Generation of SUBSCRIBE Requests
UAs discover certificates by sending a SUBSCRIBE with an event type A UA discovers a certificate by sending a SUBSCRIBE request with an
of "certificate" to the AOR for which a certificate is desired. In event type of "certificate" to the AOR for which a certificate is
general, the UA stays subscribed to the certificate for as long as it desired. In general, the UA stays subscribed to the certificate for
plans to use and cache the certificate, so that the UA can be as long as it plans to use and cache the certificate, so that the UA
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 message with an Expires header of zero. SUBSCRIBE request with an Expires header of zero.
7.7 Notifier Processing of SUBSCRIBE Requests 7.7 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 Service receives a SUBSCRIBE for a certificate, When the credential server receives a SUBSCRIBE request for a
it first checks to see if it has credentials for the requested URI. certificate, it first checks to see if it has credentials for the
If it does not have a certificate, it returns a NOTIFY request with requested URI. If it does not have a certificate, it returns a
an empty message body. NOTIFY request with an empty message body.
7.8 Notifier Generation of NOTIFY Requests 7.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 AOR of the forms a NOTIFY with the From header field value set to the value of
resource being subscribed to. This server sending the NOTIFY needs the To header field in the SUBSCRIBE request. This server sending
either to implement an Authentication Service (as described in SIP the NOTIFY needs either to implement an Authentication Service (as
Identity [2]) or else the server needs to be set up such that the described in SIP Identity [2]) or else the server needs to be set up
NOFIFY will be sent through an Authentication Service. Sending the such that the NOFIFY request will be sent through an Authentication
NOTIFY through the the Authentication Service requires the SUBSCRIBE Service. Sending the NOTIFY request through the the Authentication
to have been routed through the Authentication Service, since the Service requires the SUBSCRIBE request to have been routed through
NOTIFY is sent within the dialog formed by the SUBSCRIBE. the Authentication Service, since the NOTIFY is sent within the
dialog formed by the subscription.
7.9 Subscriber Processing of NOTIFY Requests 7.9 Subscriber Processing of NOTIFY Requests
The resulting NOTIFY will contain an application/pkix-cert body which 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 10.3 to decide if the received certificate can procedures in Section 10.3 to decide if the received certificate can
be used. The UA needs to cache this certificate for future use. The 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 10.1 . The certificate MUST be removed from the cache if the Section 10.1. The certificate MUST be removed from the cache if the
certificate has been revoked (if a NOTIFY with an empty body is 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 [2]. 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.
7.10 Handling of Forked Requests 7.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
skipping to change at page 11, line 17 skipping to change at page 12, line 16
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 [19]
with this event type. It is not possible to make such an approach with this event type. It is not possible to make such an approach
work, because the Authentication service would have to simultaneously work, because the Authentication service would have to simultaneously
assert several different identities. assert several different identities.
7.13 Behavior of a Proxy Server 7.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 methods as required in transparently forward the SUBSCRIBE and NOTIFY requests as required
SIP. This specification describes the Proxy, Authentication service, in SIP. This specification describes the Proxy, Authentication
and Credential service as three separate services but it is certainly service, and credential service as three separate services, but it is
possible to build a single sip network element that performs all of certainly possible to build a single SIP network element that
these services at the same time. performs all of these services at the same time.
8. Event Package Formal Definition for "credential" 8. Event Package Formal Definition for "credential"
8.1 Event Package Name 8.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 RFC 3265 [4].
The event-package token name for this package is: The event-package token name for this package is:
credential credential
8.2 Event Package Parameters 8.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 entity-tag value at the time the notification was sent. SIP etag value at the time the notification was sent. Considering
Considering how infrequently credentials are updated, this hint is how infrequently credentials are updated, this hint is very likely to
very likely to be the correct entity-tag to use in the SIP-If-Match be the correct etag to use in the SIP-If-Match header in a SIP
header in a SIP PUBLISH request to update the current credentials. PUBLISH request to update the current credentials.
etag-param = "etag" EQUAL token etag-param = "etag" EQUAL token
8.3 SUBSCRIBE Bodies 8.3 SUBSCRIBE Bodies
This package does not define any SUBSCRIBE bodies. This package does not define any SUBSCRIBE bodies.
8.4 Subscription Duration 8.4 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.
skipping to change at page 12, line 4 skipping to change at page 12, line 49
etag-param = "etag" EQUAL token etag-param = "etag" EQUAL token
8.3 SUBSCRIBE Bodies 8.3 SUBSCRIBE Bodies
This package does not define any SUBSCRIBE bodies. This package does not define any SUBSCRIBE bodies.
8.4 Subscription Duration 8.4 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.
8.5 NOTIFY Bodies 8.5 NOTIFY Bodies
The NOTIFY MUST contain a multipart/mixed (see [14]) body that The NOTIFY MUST contain a multipart/mixed (see [14]) 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". to "signal" as defined in [16].
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] [10]. The application/pkcs8 body contains a DER-encoded PKCS#8 [1]
object that contains the private key. contains the private key. The object that contains the private key. The PKCS#8 objects MUST be of
PKCS#8 objects MUST be of type PrivateKeyInfo. The integrity and type PrivateKeyInfo. The integrity and confidentiality of the PKCS#8
confidentiality of the PKCS#8 objects is provided by the TLS objects is provided by the TLS transport. The transport encoding of
transport. The transport encoding of all the MIME bodies is binary. all the MIME bodies is binary.
8.6 Subscriber Generation of SUBSCRIBE Requests 8.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 for a period of hours or days and will automatically attempt to re-
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.
The UA needs to authenticate with the Credential Service for these The UA needs to authenticate with the credential service for these
operations. The UA MUST use TLS to connect to the server. The UA operations. The UA MUST use TLS to connect to the server. The UA
may be configured with a specific name for the Credential Service; may 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 messages. challenge to the SUBSCRIBE or PUBLISH requests.
8.7 Notifier Processing of SUBSCRIBE Requests 8.7 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
should be set appropriately. should be set appropriately.
8.8 Notifier Generation of NOTIFY Requests 8.8 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 message. The Notifier SHOULD include the current send a Notify request. The Notifier SHOULD include the current etag
entity-tag value in the "etag" Event package parameter in the NOTIFY value in the "etag" Event package parameter in the NOTIFY request.
request. The Authentication Service is applied to this NOTIFY The Authentication Service is applied to this NOTIFY request in the
message in the same way as the certificate subscriptions. If the same way as the certificate subscriptions. If the credential is
credential is revoked, the Credential Service MUST terminate any revoked, the credential service MUST terminate any current
current subscriptions and force the UA to re-authenticate by sending subscriptions and force the UA to re-authenticate by sending a NOTIFY
a NOTIFY with its Subscription-State header set to "terminated" and a with its Subscription-State header set to "terminated" and a reason
reason parameter of "deactivated". (This causes a Subscriber to parameter of "deactivated". (This causes a Subscriber to retry the
retry the subscription immediately.) This is so that if a secret for subscription immediately.) This is so that if a secret for
retrieving the credentials gets compromised, the rogue UA will not retrieving the credentials gets compromised, the rogue UA will not
continue to receive credentials after the compromised secret has been continue to receive credentials after the compromised secret has been
changed. 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.
8.9 Notifier Processing of PUBLISH Requests 8.9 Generation of PUBLISH Requests
When the Credential Service receives a PUBLISH to update credentials, A user agent SHOULD be configurable to control whether it publishes
the credential for a user or just the user's certificate.
When publishing just a certificate, the body contains an application/
pkix-cert. When publishing a credential, the body contains a
multipart/mixed containing both an application/pkix-cert and an
application/pkcs8 body.
When the UA sends the PUBLISH [3] request, it needs to do the
following:
o The Expires header field value in the PUBLISH request SHOULD be
set to match the time for which the certificate is valid.
o If the certificate includes Basic Constraints, it SHOULD set the
CA flag to false.
o The PUBLISH request SHOULD include a SIP-If-Match header field
with the previous etag from the subscription. This prevents
multiple User Agents for the same AOR from publishing conflicting
credentials. Note that UAs replace credentials that are about to
expire at a random time (described in Section 5), reducing the
chance of publishing conflicting credentials even without using
the etag.
8.10 Notifier Processing of PUBLISH Requests
When the credential service receives a PUBLISH to update credentials,
it MUST authenticate and authorize this request the same way as for it MUST authenticate and authorize this request the same way as for
subscriptions for credentials. If this succeeds, the Credential subscriptions for credentials. If the authorization succeeds, then
Service updates the credential for this URI, processes all the active the credential service MUST perform the following check on the the
certificate and credential subscriptions to this URI, and generates a certificate:
NOTIFY request with the new credential or certificate. If the o One of the names in the SubjectAltName of the certificate matches
Subscriber submits a PUBLISH requests with no body, this revokes the the authorized user making the request.
current credentials and causes all subscriptions to the credential o The notBefore validity time MUST NOT be in the future.
package to be deactivated as described in the previous section. o The notAfter validity time MUST be in the future.
o If an CA Basic Constraint is set in the certificate, it is set to
false.
If all of these succeed, the credential service updates the
credential for this URI, processes all the active certificates and
credential subscriptions to this URI, and generates a NOTIFY request
with the new credential or certificate.
(Note that subscriptions to the certificate package are NOT If the Subscriber submits a PUBLISH request with no body, this
terminated, each subscriber to the certificate package receives a revokes the current credentials and causes all subscriptions to the
credential package to be deactivated as described in the previous
section. (Note that subscriptions to the certificate package are NOT
terminated; each subscriber to the certificate package receives a
notification with an empty body.) notification with an empty body.)
8.10 Subscriber Processing of NOTIFY Requests 8.11 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 with the private key, it MUST send a 493 decrypt the PKCS#8 object, it MUST send a 437 (Unsupported
Undecipherable response. Later if the user provides a new pass 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 pass phrase. again and attempt to decrypt with the new password phrase.
8.11 Handling of Forked Requests 8.12 Handling of Forked Requests
This event package does not permit forked requests. This event package does not permit forked requests.
8.12 Rate of Notifications 8.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.
8.13 State Agents and Lists 8.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 [19]
with this event type. with this event type.
8.14 Behavior of a Proxy Server 8.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 7.13. subscriptions described in Section 7.13.
9. Examples 9. Examples
In all these examples, large parts of the message 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.
9.1 Encrypted Page Mode IM Message 9.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:
SUBSCRIBE sip:bob@biloxi.example.com SIP/2.0 SUBSCRIBE sip:bob@biloxi.example.com SIP/2.0
... ...
Event: certificate Event: certificate
The Credential Service responds with the certificate in a NOTIFY. The credential service responds with the certificate in a NOTIFY.
NOTIFY alice@atlanta.example.com SIP/2.0 NOTIFY alice@atlanta.example.com SIP/2.0
Subscription-State: active; expires=7200 Subscription-State: active; expires=7200
.... ....
From: <sip:bob@biloxi.example.com>;tag=1234 From: <sip:bob@biloxi.example.com>;tag=1234
Identity: "12dsfsdk2389403823cbed" Identity: "NJguAbpmYXjnlxFmlOkumMI+MZXjB2iV/NW5xsFQqzD/p4yiovrJBqhd3T
Identity-Info: sips:billoxi.example.com ZkegnsmoHryzk9gTBH7Gj/erixEFIf82o3Anmb+CIbrgdl03gGaD6ICvkp
.... VqoMXZZjdvSpycyHOhh1cmUx3b9Vr3pZuEh+cB01pbMQ8B1ch++iMjw="
Event: certificate Identity-Info: <https://atlanta.example.com/cert>;alg=rsa-sha1
Content-Type: application/pkix-cert ....
Content-Disposition: signal Event: certificate
Content-Type: application/pkix-cert
Content-Disposition: signal
< certificate data > < certificate data >
Next, Alice sends a SIP MESSAGE message to Bob and can encrypt the Next, Alice sends a SIP MESSAGE message to Bob and can encrypt the
body using Bob's public key as shown below. Although outside the body using Bob's public key as shown below. Although outside the
scope of this document, it is worth noting that instant messages scope of this document, it is worth noting that instant messages
often have common plain text like "Hi", so that setting up symmetric often have common plain text like "Hi", so that setting up symmetric
keys for extended session mode IM conversations will likely increase keys for extended session mode IM conversations will likely increase
efficiency, as well as reducing the likelihood of compromising the efficiency, as well as reducing the likelihood of compromising the
asymmetric key in the certificate. asymmetric key in the certificate.
MESSAGE sip:bob@biloxi.example.com SIP/2.0 MESSAGE sip:bob@biloxi.example.com SIP/2.0
skipping to change at page 15, line 42 skipping to change at page 17, line 40
Content-Type: application/pkcs7-mime Content-Type: application/pkcs7-mime
Content-Disposition: render Content-Disposition: render
$ Content-Type: text/plain $ Content-Type: text/plain
$ $
$ < encrypted version of "Hello" > $ < encrypted version of "Hello" >
9.2 Setting and Retrieving UA Credentials 9.2 Setting and Retrieving UA Credentials
When Alice's UA wishes to publish Alice's public and private keys to When Alice's UA wishes to publish Alice's public and private keys to
the Credential Service, it sends a PUBLISH message like the one the credential service, it sends a PUBLISH request like the one
below. This must be sent over a TLS connection in which the other below. This must be sent over a TLS connection in which the other
end of the connection presents a certificate that matches the end of the connection presents a certificate that matches the
Credential Service for Alice and digest challenges the message to credential service for Alice and digest challenges the request to
authenticate her. authenticate her.
PUBLISH sips:alice@atlanta.example.com SIP/2.0 PUBLISH sips:alice@atlanta.example.com SIP/2.0
... ...
Content-Type: multipart/mixed;boundary=boundary Content-Type: multipart/mixed;boundary=boundary
Content-Disposition: signal Content-Disposition: signal
--boundary --boundary
Content-ID: 123 Content-ID: 123
Content-Type: application/pkix-cert Content-Type: application/pkix-cert
skipping to change at page 17, line 35 skipping to change at page 19, line 35
| |----------------->| | |----------------->|
| | | |
| SUBSCRIBE | 10) Client requests certificate | SUBSCRIBE | 10) Client requests certificate
|---------->| |---------->|
| | | |
|NOTIFY+AUTH| 11) Server returns user's certificate and signs that |NOTIFY+AUTH| 11) Server returns user's certificate and signs that
|<----------| it is valid using certificate for the domain |<----------| it is valid using certificate for the domain
| | | |
When the UA, labeled Bob, first created a credential for Bob, it When the UA, labeled Bob, first created a credential for Bob, it
would store this on the the server. The UA authenticated the Server would store this on the the credential server. The UA authenticated
using the certificates from the TLS handshake while the Server the Server using the certificates from the TLS handshake. The Server
authenticated the UA using a digest style challenge with a shared authenticated the UA using a digest style challenge with a shared
secret. secret.
The UA, labeled Bob, wishes to request its credentials from the The UA, labeled Bob, wishes to request its credentials from the
server. First it forms a TLS connection to the server with provides server. First it forms a TLS connection to the Server, which
integrity and privacy protection and also authenticates the server to provides integrity and privacy protection and also authenticates the
Bob's UA. Next the UA requests its credentials using a SUBSCRIBE. server to Bob's UA. Next the UA requests its credentials using a
The Server digest challenges this to authenticate Bob's UA. The SUBSCRIBE request. The Server digest challenges this to authenticate
server and Bob's UA have a shared secret that is used for this. If Bob's UA. The server and Bob's UA have a shared secret that is used
the authentication is successful, the sever sends the credentials to for this. If the authentication is successful, the server sends the
Bob's UA. The private key in the credentials may have been encrypted credentials to Bob's UA. The private key in the credentials may have
using a shared secret that the server does not know. been encrypted using a shared secret that the server does not know.
A similar process would be used for Bob's UA to publish new A similar process would be used for Bob's UA to publish new
credentials to the server. The SUBSCRIBE would be a PUBLISH and credentials to the server. The SUBSCRIBE request would change to a
there would be no NOTIFY. When this happened, all the other UAs that PUBLISH request and there would not be an NOTIFY. When this
were subscribed to Bob's credentials would receive a new NOTIFY with happened, all the other UAs that were subscribed to Bob's credentials
the new credentials. would receive a new NOTIFY 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 NOTIFY. This does not need server. The server sends the response in NOTIFY. This does not need
to be sent over a privacy or integrity protected channel, as the to be sent over a privacy or integrity protected channel, as the
Authentication service described in [2] provides integrity protection Authentication service described in [2] provides integrity protection
of this information and signs it with the certificate for the domain. 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
avoiding deployments in which the credential servers store the
private keys, even in some encrypted form that the credential
server does not know how to decrypt. Various schemes were
considered to avoid this but they all result in either moving the
problem to some other server, which does not seem to make the
problem any better, or having a different credential for each
device. For some deployments where each user has only one device
this is fine but for deployments with multiple devices, it would
require that when Alice went to contact Bob, Alice would have to
provide messages encrypted for all of Bob's devices. The sipping
working group did consider this architecture and decided it was
not appropriate due both to the information it revealed about the
devices and users and the amount of signaling required to make it
work.
This specification requires the TLS session to be used for SIP This specification requires the TLS session to be used for SIP
communications to the Credential Service. As specified in RFC 3261, communications to the credential service. As specified in RFC 3261,
TLS clients MUST check that the SubjectAltName of the certificate for TLS clients MUST check that the SubjectAltName of the certificate for
the server they connected to exactly matches the server they were the server they connected to exactly matches the server they were
trying to connect to. Failing to use TLS or selecting a poor cipher trying to connect to. Failing to use TLS or selecting a poor cipher
suite (such as NULL encryption) will result in credentials including suite (such as NULL encryption) will result in credentials, including
private key being sent unencrypted over the network and will render private keys, being sent unencrypted over the network and will render
the whole system useless. Implementations really must use TLS or the whole system useless. Implementations really must use TLS or
there is no point in implementing any of this. there is no point in implementing any of this.
The correct checking of chained certificates as specified in TLS [11] The correct checking of chained certificates as specified in TLS [11]
is critical for the client to authenticate the server. If the client is critical for the client to authenticate the server. If the client
does not authenticate that it is talking to the correct Credential does not authenticate that it is talking to the correct credential
Service, a man in the middle attack is possible. service, a man in the middle attack is possible.
10.1 Certificate Revocation 10.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.
It is possible that an attacker could mount a DOS attack such that It is possible that an attacker could mount a DOS attack such that
the UA that had cached a certificate did not receive the NOTIFY with the UA that had cached a certificate did not receive the NOTIFY with
its revocation. To protect against this attack, the UA needs to its revocation. To protect against this attack, the UA needs to
limit how long it caches certificates. After this time, the UA would limit how long it caches certificates. After this time, the UA would
invalidate the cached information even though no NOTIFY had ever been invalidate the cached information even though no NOTIFY had ever been
received due to the attacker blocking it. received due to the attacker blocking it.
The duration of this cached information is in some ways similar to a The duration of this cached information is in some ways similar to a
device deciding how often to check a CRL list. For many device deciding how often to check a CRL list. For many
applications, a default time of 1 day is suggested, but for some applications, a default time of 1 day is suggested, but for some
applications it may be desirable to set the time to zero so that no applications it may be desirable to set the time to zero so that no
certificates are cached at all and the the the credential is checked certificates are cached at all and the credential is checked for
for validity every time the certificate is used. validity every time the certificate is used.
10.2 Certificate Replacement 10.2 Certificate Replacement
The UAs in the system replace the certificates close to the time that The UAs in the system replace the certificates close to the time that
the certificates would expire. If a UA has used the same key pair to the certificates would expire. If a UA has used the same key pair to
encrypt a very large volume of traffic, the UA MAY choose to replace encrypt a very large volume of traffic, the UA MAY choose to replace
the credential with a new one. the credential with a new one before the normal expiration.
10.3 Trusting the Identity of a Certificate 10.3 Trusting the Identity of a Certificate
When a UA wishes to discover the certificate for When a UA wishes to discover the certificate for
sip:alice@example.com, the UA subscribes to the certificate for sip:alice@example.com, the UA subscribes to the certificate for
alice@example.com and receives a certificate in the body of a SIP alice@example.com and receives a certificate in the body of a SIP
Notify message. The term original URI is used to describe the NOTIFY request. The term original URI is used to describe the URI
original URI that was subscribed to. that was in the To header field value of the SUBSCRIBE request. So
in this case the original URI would be sip:alice@example.com.
If the certificate is signed by a trusted 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 message 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 [2] specification to validate that bodies have not been tampered
with and that an Authentication Service has validated this From with and that an Authentication Service has validated this From
header. 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
identities found in the SubjectAltName list. identities found in the SubjectAltName list.
These steps result in a chain of bindings that result in a trusted These steps result in a chain of bindings that result in a trusted
binding between the original AOR that was subscribed to and a public binding between the original AOR that was subscribed to and a public
key. The Original AOR is forced to match the From. The key. The original AOR is forced to match the From. The
Authentication Service validates that this message did come from the Authentication Service validates that this request did come from the
identity claimed in the From and that the bodies and the From have identity claimed in the From header field value and that the bodies
not been tampered with. The certificate in the body contains the in the request that cary the certificate have not been tampered with.
public key for the identity. Only the UA that can authenticate as The certificate in the body contains the public key for the identity.
this AOR, or devices with access to the private key of the domain, Only the UA that can authenticate as this AOR, or devices with access
can tamper with this body. This stops other users from being able to to the private key of the domain, can tamper with this body. This
provide a false public key. This chain of assertion from original stops other users from being able to provide a false public key.
URI, to From, to body, to public key is critical to the security of This chain of assertion from original URI, to From, to body, to
the mechanism described in this specification. If any of the steps public key is critical to the security of the mechanism described in
above are not followed, this chain of security will be broken and the this specification. If any of the steps above are not followed, this
system will not work. chain of security will be broken and the system will not work.
10.4 Conformity to the SACRED Framework 10.4 Conformity to the SACRED Framework
This specification uses the security design outlined in the SACRED This specification uses the security design outlined in the SACRED
Framework [7]. Specifically, it follows the cTLS architecture Framework [7]. Specifically, it follows the cTLS architecture
described in section 4.2.2 of RFC 3760. The client authenticates the described in section 4.2.2 of RFC 3760. The client authenticates the
server using the server's TLS certificate. The server authenticates server using the server's TLS certificate. The server authenticates
the client using a SIP digest transaction inside the TLS session. 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 TLS sessions form a strong session key that is used to protect
the credentials being exchanged. the credentials being exchanged.
10.5 Crypto Profiles 10.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 RFC 3546 [8] and they MUST support a TLS profile of
TLS_RSA_WITH_AES_128_CBC_SHA as described in RFC 3268 [9] and a TLS_RSA_WITH_AES_128_CBC_SHA as described in RFC 3268 [9] and a
profile of TLS_RSA_WITH_3DES_EDE_SHA. profile 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 RFC 2898 [12]. It is RECOMMENDED
that this profile be used when using PKCS#8. that this profile be used when using PKCS#8.
10.6 User Certificate Generation 10.6 User Certificate Generation
The certificates should be consistent with RFC 3280 [13]. A The certificates should be consistent with RFC 3280 [13]. 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.
It is worth noting that a UA can discover the current time by looking
at the Date header field value in the 200 response to a REGISTER
request.
10.7 Compromised Authentication Service 10.7 Compromised Authentication Service
One of this worst attacks against this system is if the One of this worst attacks against this system would be if the
Authentication Service were compromised. This attack is somewhat Authentication Service were compromised. This attack is somewhat
analogous to a CA being compromised in traditional PKI systems. The analogous to a CA being compromised in traditional PKI systems. The
attacker could make a fake certificate for which it knows the private attacker could make a fake certificate for which it knows the private
key, use it to receive any traffic for a given use, and then key, use it to receive any traffic for a given use, and then re-
re-encrypt that traffic with the correct key and forward the encrypt that traffic with the correct key and forward the
communication to the intended receiver. The attacker would thus communication to the intended receiver. The attacker would thus
become a man in the middle in the communications. become a man in the middle in the communications.
There is not too much that can be done to protect against this. A UA There is not too much that can be done to protect against this. A UA
MAY subscribe to its own certificate under some other identity to try MAY subscribe to its own certificate under some other identity to try
to detect whether the Credential server is handing out the correct to detect whether the credential server is handing out the correct
certificates. It will be difficult to do this in a way that does not certificates. It will be difficult to do this in a way that does not
allow the Credential server to recognize the user's UA. allow the credential server to recognize the user's UA.
The UA MAY also save the fingerprints of the cached certificates and The UA MAY also save the fingerprints of the cached certificates and
warn users when the certificates change resulting in a system that warn users when the certificates change significantly before their
was secure other than an leap of faith when the certificate first expiry date.
arrives or is changed.
The UA MAY also allow the user to see the fingerprints for the cached The UA MAY also allow the user to see the fingerprints for the cached
certificates so that they can be verified by some other out of band certificates so that they can be verified by some other out of band
means. means.
11. IANA Considerations 11. IANA Considerations
This specification defines two new event packages that IANA is This specification defines two new event packages that IANA is
requested to add the registry at requested to add the registry at:
http://www.iana.org/assignments/sip-events It also defines a new mime
type that IANA is requested to add to the registry at http://www.iana.org/assignments/sip-events
http://www.iana.org/assignments/media-types/application. It also defines a new mime type that IANA is requested to add to the
registry at:
http://www.iana.org/assignments/media-types/application
11.1 Certificate Event Package 11.1 Certificate Event Package
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: certificate Package Name: certificate
Is this registration for a Template Package: No Is this registration for a Template Package: No
skipping to change at page 22, line 44 skipping to change at page 25, line 25
Encoding considerations: The PKCS#8 object inside this MIME type Encoding considerations: The PKCS#8 object inside this MIME type
MUST be DER-encoded. MUST be DER-encoded.
This MIME type was designed for use with This MIME type was designed for use with
protocols which can carry binary-encoded protocols which can carry binary-encoded
data. Protocols which do not carry binary data. Protocols which do not carry binary
data (which have line length or data (which have line length or
character-set restrictions for example) character-set restrictions for example)
MUST use a reversible transfer encoding MUST use a reversible transfer encoding
(such as base64) to carry this MIME type. (such as base64) to carry this MIME type.
Protocols which carry binary data SHOULD Protocols that carry binary data SHOULD
use a transfer encoding of "binary". use a transfer encoding of "binary".
Security considerations: Carries a cryptographic private key Security considerations: Carries a cryptographic private key
Interoperability considerations: None Interoperability considerations: None
Published specification: See reference to PKCS#8 [1]
Published specification:
RSA Laboratories, "Private-Key Information Syntax Standard,
Version 1.2", PKCS 8, November 1993.
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>
Intended usage: COMMON Intended usage: COMMON
Author/Change controller: Author/Change controller:
the IESG the IESG
12. Acknowledgments 12. Acknowledgments
Many thanks to Eric Rescorla, Jim Schaad, Rohan Mahy for significant Many thanks to Eric Rescorla, Jim Schaad, Rohan Mahy for significant
help and discussion. Many others provided useful comments, including help and discussion. Many others provided useful comments, including
Kumiko Ono, Peter Gutmann, Russ Housley, Magnus Nystrom, Paul Kumiko Ono, Peter Gutmann, Russ Housley, Yaron Pdut, Aki Niemi,
Hoffman, Dan Wing, Mike Hammer, Lyndsay Campbell, and Jason Fischl. Magnus Nystrom, Paul Hoffman, Adina Simu, Dan Wing, Mike Hammer,
Rohan Mahy and Jonathan Rosenberg provided detailed review and text. Lyndsay Campbell, and Jason Fischl. Rohan Mahy, John Elwell, and
Jonathan Rosenberg provided detailed review and text.
13. References 13. References
13.1 Normative References 13.1 Normative References
[1] RSA Laboratories, "Private-Key Information Syntax Standard, [1] RSA Laboratories, "Private-Key Information Syntax Standard,
Version 1.2", PKCS 8, November 1993. Version 1.2", PKCS 8, November 1993.
[2] Peterson, J. and C. Jennings, "Enhancements for Authenticated [2] Peterson, J. and C. Jennings, "Enhancements for Authenticated
Identity Management in the Session Initiation Protocol (SIP)", Identity Management in the Session Initiation Protocol (SIP)",
draft-ietf-sip-identity-04 (work in progress), February 2005. draft-ietf-sip-identity-05 (work in progress), May 2005.
[3] Niemi, A., "Session Initiation Protocol (SIP) Extension for [3] Niemi, A., "Session Initiation Protocol (SIP) Extension for
Event State Publication", RFC 3903, October 2004. Event State Publication", RFC 3903, October 2004.
[4] Roach, A., "Session Initiation Protocol (SIP)-Specific Event [4] Roach, A., "Session Initiation Protocol (SIP)-Specific Event
Notification", RFC 3265, June 2002. Notification", RFC 3265, June 2002.
[5] Bradner, S., "Key words for use in RFCs to Indicate Requirement [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[6] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., [6] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002. Session Initiation Protocol", RFC 3261, June 2002.
[7] Gustafson, D., Just, M. and M. Nystrom, "Securely Available [7] Gustafson, D., Just, M., and M. Nystrom, "Securely Available
Credentials (SACRED) - Credential Server Framework", RFC 3760, Credentials (SACRED) - Credential Server Framework", RFC 3760,
April 2004. April 2004.
[8] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J. and [8] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and
T. Wright, "Transport Layer Security (TLS) Extensions", RFC T. Wright, "Transport Layer Security (TLS) Extensions",
3546, June 2003. RFC 3546, June 2003.
[9] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites for [9] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites for
Transport Layer Security (TLS)", RFC 3268, June 2002. Transport Layer Security (TLS)", RFC 3268, June 2002.
[10] Housley, R. and P. Hoffman, "Internet X.509 Public Key [10] Housley, R. and P. Hoffman, "Internet X.509 Public Key
Infrastructure Operational Protocols: FTP and HTTP", RFC 2585, Infrastructure Operational Protocols: FTP and HTTP", RFC 2585,
May 1999. May 1999.
[11] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC [11] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
2246, January 1999. RFC 2246, January 1999.
[12] Kaliski, B., "PKCS #5: Password-Based Cryptography [12] Kaliski, B., "PKCS #5: Password-Based Cryptography
Specification Version 2.0", RFC 2898, September 2000. Specification Version 2.0", RFC 2898, September 2000.
[13] Housley, R., Polk, W., Ford, W. and D. Solo, "Internet X.509 [13] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509
Public Key Infrastructure Certificate and Certificate Public Key Infrastructure Certificate and Certificate
Revocation List (CRL) Profile", RFC 3280, April 2002. Revocation List (CRL) Profile", RFC 3280, April 2002.
[14] Freed, N. and N. Borenstein, "Multipurpose Internet Mail [14] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types", RFC 2046, November Extensions (MIME) Part Two: Media Types", RFC 2046,
1996. November 1996.
[15] International Telecommunications Union, "Information technology [15] International Telecommunications Union, "Information technology
- Open Systems Interconnection - The Directory: Public-key and - Open Systems Interconnection - The Directory: Public-key and
attribute certificate frameworks", ITU-T Recommendation X.509, attribute certificate frameworks", ITU-T Recommendation X.509,
ISO Standard 9594-8, March 2000. ISO Standard 9594-8, March 2000.
13.2 Informational References [16] Zimmerer, E., Peterson, J., Vemuri, A., Ong, L., Audet, F.,
Watson, M., and M. Zonoun, "MIME media types for ISUP and QSIG
Objects", RFC 3204, December 2001.
[16] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions 13.2 Informational References
(S/MIME) Version 3.1 Message Specification", RFC 3851, July
2004.
[17] Peterson, J., "S/MIME Advanced Encryption Standard (AES) [17] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions
Requirement for the Session Initiation Protocol (SIP)", RFC (S/MIME) Version 3.1 Message Specification", RFC 3851,
3853, July 2004. July 2004.
[18] Gutmann, P., "Internet X.509 Public Key Infrastructure [18] Peterson, J., "S/MIME Advanced Encryption Standard (AES)
Operational Protocols: Certificate Store Access via HTTP", Requirement for the Session Initiation Protocol (SIP)",
draft-ietf-pkix-certstore-http-08 (work in progress), August RFC 3853, July 2004.
2004.
[19] Roach, A., Rosenberg, J. and B. Campbell, "A Session Initiation [19] Roach, A., Rosenberg, J., and B. Campbell, "A Session
Protocol (SIP) Event Notification Extension for Resource Initiation Protocol (SIP) Event Notification Extension for
Lists", draft-ietf-simple-event-list-07 (work in progress), Resource Lists", draft-ietf-simple-event-list-07 (work in
January 2005. progress), January 2005.
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
USA USA
Phone: +1 408 921-9990 Phone: +1 408 421-9990
EMail: fluffy@cisco.com Email: fluffy@cisco.com
Jon Peterson Jon Peterson
NeuStar, Inc. NeuStar, Inc.
1800 Sutter St 1800 Sutter St
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/
Intellectual Property Statement Intellectual Property Statement
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
 End of changes. 122 change blocks. 
311 lines changed or deleted 413 lines changed or added

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