draft-ietf-sip-certs-06.txt   draft-ietf-sip-certs-07.txt 
Network Working Group C. Jennings Network Working Group C. Jennings
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Expires: October 7, 2008 J. Fischl, Ed. Expires: May 7, 2009 J. Fischl, Ed.
CounterPath Corporation CounterPath Corporation
April 5, 2008 November 3, 2008
Certificate Management Service for The Session Initiation Protocol (SIP) Certificate Management Service for The Session Initiation Protocol (SIP)
draft-ietf-sip-certs-06 draft-ietf-sip-certs-07
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 35 skipping to change at page 1, line 35
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 October 7, 2008. This Internet-Draft will expire on May 7, 2009.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2008). Copyright (C) The IETF Trust (2008).
Abstract Abstract
This draft defines a Credential Service that allows Session This draft defines a Credential Service that allows Session
Initiation Protocol (SIP) User Agents (UAs) to use a SIP event Initiation Protocol (SIP) User Agents (UAs) to use a SIP event
package to discover the certificates of other users. This mechanism package to discover the certificates of other users. This mechanism
skipping to change at page 2, line 27 skipping to change at page 2, line 27
6.4. Subscription Duration . . . . . . . . . . . . . . . . . . 10 6.4. Subscription Duration . . . . . . . . . . . . . . . . . . 10
6.5. NOTIFY Bodies . . . . . . . . . . . . . . . . . . . . . . 10 6.5. NOTIFY Bodies . . . . . . . . . . . . . . . . . . . . . . 10
6.6. Subscriber Generation of SUBSCRIBE Requests . . . . . . . 11 6.6. Subscriber Generation of SUBSCRIBE Requests . . . . . . . 11
6.7. Notifier Processing of SUBSCRIBE Requests . . . . . . . . 11 6.7. Notifier Processing of SUBSCRIBE Requests . . . . . . . . 11
6.8. Notifier Generation of NOTIFY Requests . . . . . . . . . . 11 6.8. Notifier Generation of NOTIFY Requests . . . . . . . . . . 11
6.9. Subscriber Processing of NOTIFY Requests . . . . . . . . . 12 6.9. Subscriber Processing of NOTIFY Requests . . . . . . . . . 12
6.10. Handling of Forked Requests . . . . . . . . . . . . . . . 12 6.10. Handling of Forked Requests . . . . . . . . . . . . . . . 12
6.11. Rate of Notifications . . . . . . . . . . . . . . . . . . 12 6.11. Rate of Notifications . . . . . . . . . . . . . . . . . . 12
6.12. State Agents and Lists . . . . . . . . . . . . . . . . . . 12 6.12. State Agents and Lists . . . . . . . . . . . . . . . . . . 12
6.13. Behavior of a Proxy Server . . . . . . . . . . . . . . . . 12 6.13. Behavior of a Proxy Server . . . . . . . . . . . . . . . . 12
7. Event Package Formal Definition for "credential" . . . . . . . 12 7. Event Package Formal Definition for "credential" . . . . . . . 13
7.1. Event Package Name . . . . . . . . . . . . . . . . . . . . 13 7.1. Event Package Name . . . . . . . . . . . . . . . . . . . . 13
7.2. Event Package Parameters . . . . . . . . . . . . . . . . . 13 7.2. Event Package Parameters . . . . . . . . . . . . . . . . . 13
7.3. SUBSCRIBE Bodies . . . . . . . . . . . . . . . . . . . . . 13 7.3. SUBSCRIBE Bodies . . . . . . . . . . . . . . . . . . . . . 13
7.4. Subscription Duration . . . . . . . . . . . . . . . . . . 13 7.4. Subscription Duration . . . . . . . . . . . . . . . . . . 13
7.5. NOTIFY Bodies . . . . . . . . . . . . . . . . . . . . . . 13 7.5. NOTIFY Bodies . . . . . . . . . . . . . . . . . . . . . . 13
7.6. Subscriber Generation of SUBSCRIBE Requests . . . . . . . 14 7.6. Subscriber Generation of SUBSCRIBE Requests . . . . . . . 14
7.7. Notifier Processing of SUBSCRIBE Requests . . . . . . . . 14 7.7. Notifier Processing of SUBSCRIBE Requests . . . . . . . . 14
7.8. Notifier Generation of NOTIFY Requests . . . . . . . . . . 14 7.8. Notifier Generation of NOTIFY Requests . . . . . . . . . . 15
7.9. Generation of PUBLISH Requests . . . . . . . . . . . . . . 15 7.9. Generation of PUBLISH Requests . . . . . . . . . . . . . . 15
7.10. Notifier Processing of PUBLISH Requests . . . . . . . . . 15 7.10. Notifier Processing of PUBLISH Requests . . . . . . . . . 16
7.11. Subscriber Processing of NOTIFY Requests . . . . . . . . . 16 7.11. Subscriber Processing of NOTIFY Requests . . . . . . . . . 16
7.12. Handling of Forked Requests . . . . . . . . . . . . . . . 16 7.12. Handling of Forked Requests . . . . . . . . . . . . . . . 17
7.13. Rate of Notifications . . . . . . . . . . . . . . . . . . 16 7.13. Rate of Notifications . . . . . . . . . . . . . . . . . . 17
7.14. State Agents and Lists . . . . . . . . . . . . . . . . . . 16 7.14. State Agents and Lists . . . . . . . . . . . . . . . . . . 17
7.15. Behavior of a Proxy Server . . . . . . . . . . . . . . . . 16 7.15. Behavior of a Proxy Server . . . . . . . . . . . . . . . . 17
8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
8.1. Encrypted Page Mode IM Message . . . . . . . . . . . . . . 17 8.1. Encrypted Page Mode IM Message . . . . . . . . . . . . . . 17
8.2. Setting and Retrieving UA Credentials . . . . . . . . . . 18 8.2. Setting and Retrieving UA Credentials . . . . . . . . . . 18
9. Security Considerations . . . . . . . . . . . . . . . . . . . 18 9. Security Considerations . . . . . . . . . . . . . . . . . . . 19
9.1. Certificate Revocation . . . . . . . . . . . . . . . . . . 21 9.1. Certificate Revocation . . . . . . . . . . . . . . . . . . 22
9.2. Certificate Replacement . . . . . . . . . . . . . . . . . 21 9.2. Certificate Replacement . . . . . . . . . . . . . . . . . 22
9.3. Trusting the Identity of a Certificate . . . . . . . . . . 21 9.3. Trusting the Identity of a Certificate . . . . . . . . . . 22
9.4. SACRED Framework . . . . . . . . . . . . . . . . . . . . . 22 9.4. SACRED Framework . . . . . . . . . . . . . . . . . . . . . 23
9.5. Crypto Profiles . . . . . . . . . . . . . . . . . . . . . 23 9.5. Crypto Profiles . . . . . . . . . . . . . . . . . . . . . 24
9.6. User Certificate Generation . . . . . . . . . . . . . . . 23 9.6. User Certificate Generation . . . . . . . . . . . . . . . 24
9.7. Compromised Authentication Service . . . . . . . . . . . . 23 9.7. Compromised Authentication Service . . . . . . . . . . . . 24
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
10.1. Certificate Event Package . . . . . . . . . . . . . . . . 24 10.1. Certificate Event Package . . . . . . . . . . . . . . . . 25
10.2. Credential Event Package . . . . . . . . . . . . . . . . . 24 10.2. Credential Event Package . . . . . . . . . . . . . . . . . 25
10.3. PKCS#8 . . . . . . . . . . . . . . . . . . . . . . . . . . 25 10.3. PKCS#8 . . . . . . . . . . . . . . . . . . . . . . . . . . 26
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 26 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28
12.1. Normative References . . . . . . . . . . . . . . . . . . . 27 12.1. Normative References . . . . . . . . . . . . . . . . . . . 28
12.2. Informational References . . . . . . . . . . . . . . . . . 28 12.2. Informational References . . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30
Intellectual Property and Copyright Statements . . . . . . . . . . 30 Intellectual Property and Copyright Statements . . . . . . . . . . 31
1. Introduction 1. Introduction
SIP [RFC3261] provides a mechanism [RFC3853] for end-to-end [RFC3261], as ammended by [RFC3853], provides a mechanism for end-to-
encryption and integrity using S/MIME [RFC3851]. Several security end encryption and integrity using S/MIME [RFC3851]. Several
properties of SIP depend on S/MIME, and yet it has not been widely security properties of [RFC3261] depend on S/MIME, and yet it has not
deployed. One reason is the complexity of providing a reasonable been widely deployed. One reason is the complexity of providing a
certificate distribution infrastructure. This specification proposes reasonable certificate distribution infrastructure. This
a way to address discovery, retrieval, and management of certificates specification proposes a way to address discovery, retrieval, and
for SIP deployments. Combined with the SIP Identity [RFC4474] management of certificates for SIP deployments. Combined with the
specification, this specification allows users to have certificates SIP Identity [RFC4474] specification, this specification allows users
that are not signed by any well known certificate authority while to have certificates that are not signed by any well known
still strongly binding the user's identity to the certificate. certificate authority while still strongly binding the user's
identity to the certificate.
In addition, this specification provides a mechanism that allows SIP In addition, this specification provides a mechanism that allows SIP
User Agents such as IP phones to enroll and get their credentials User Agents such as IP phones to enroll and get their credentials
without any more configuration information than they commonly have without any more configuration information than they commonly have
today. The end user expends no extra effort. today. The end user expends no 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 [RFC2119]. document are to be interpreted as described in [RFC2119].
Certificate: A PKIX [RFC3280] style certificate containing a public Certificate: A PKIX [RFC5280] style certificate containing a public
key and a list of identities in the SubjectAltName that are bound key and a list of identities in the SubjectAltName that are bound
to this key. The certificates discussed in this draft are to this key. The certificates discussed in this draft are
generally self signed and use the mechanisms in the SIP Identity generally self signed and use the mechanisms in the SIP Identity
[RFC4474] specification to vouch for their validity. Certificates [RFC4474] specification to vouch for their validity. Certificates
that are signed by a certificate authority can also be used with that are signed by a certificate authority can also be used with
all the mechanisms in this draft, but it is expected that they are all the mechanisms in this draft, but it is expected that they are
used purely as a key carrier and that their validity is not used purely as a key carrier and that their validity is not
checked. checked.
Credential: For this document, credential means the combination of a Credential: For this document, credential means the combination of a
certificate and the associated private key. certificate and the associated private key.
password phrase: A password used to encrypt a PKCS#8 private key. Password Phrase: A password used to encrypt a PKCS#8 private key.
3. Overview 3. Overview
The general approach is to provide a new SIP service referred to as a The general approach is to provide a new SIP service referred to as a
"credential service" that allows SIP User Agents (UAs) to subscribe "credential service" that allows SIP User Agents (UAs) to subscribe
to other users' certificates using a new SIP event package [RFC3265]. to other users' certificates using a new SIP event package [RFC3265].
The certificate is delivered to the subscribing UA in a corresponding The certificate is delivered to the subscribing UA in a corresponding
SIP NOTIFY request. The identity of the certificate can be vouched SIP NOTIFY request. An Authentication Service as described in the
for using the Authentication Service from the SIP Identity [RFC4474] SIP Identity [RFC4474] specification can be used to vouch for the
specification, which uses the domain's certificate to sign the NOTIFY identity of the sender of the certificate by using the sender's proxy
request. The credential service can manage public certificates as domain certificate to sign the NOTIFY request. The Authentication
well as the user's private keys. Users can update their credentials, Service is vouching that the sender is allowed to populate the SIP
as stored on the credential service, using a SIP PUBLISH [RFC3903] From header field value. The sender of the message is vouching that
request. The UA authenticates to the credential service using a this is an appropriate certificate for the user identified in the SIP
shared secret when a UA is updating a credential. Typically the from header field value. The credential service can manage public
shared secret will be the same one that is used by the UA to certificates as well as the user's private keys. Users can update
authenticate a REGISTER request with the Registrar for the domain their credentials, as stored on the credential service, using a SIP
(usually with SIP Digest Authentication). PUBLISH [RFC3903] request. The UA authenticates to the credential
service using a shared secret when a UA is updating a credential.
Typically the shared secret will be the same one that is used by the
UA to authenticate a REGISTER request with the Registrar for the
domain (usually with SIP Digest Authentication).
The following figure shows Bob publishing his credentials from one of The following figure shows Bob publishing his credentials from one of
his User Agents (e.g. his laptop software client), retrieving his his User Agents (e.g. his laptop software client), retrieving his
credentials from another of his User Agents (e.g. his mobile phone), credentials from another of his User Agents (e.g. his mobile phone),
and then Alice retrieving Bob's certificate and sending a message to and then Alice retrieving Bob's certificate and sending a message to
Bob. SIP 200-class responses are omitted from the diagram to make the Bob. SIP 200-class responses are omitted from the diagram to make the
figure easier to understand. figure easier to understand.
example.com domain example.com domain
------------------ ------------------
skipping to change at page 7, line 30 skipping to change at page 7, line 30
UA receives the certificate and can use it to encrypt a message to UA receives the certificate and can use it to encrypt a message to
Bob. Bob.
It is critical to understand that the only way that Alice can trust It is critical to understand that the only way that Alice can trust
that the certificate really is the one for Bob and that the NOTIFY that the certificate really is the one for Bob and that the NOTIFY
has not been spoofed is for Alice to check that the Identity has not been spoofed is for Alice to check that the Identity
[RFC4474] header field value is correct. [RFC4474] header field value is correct.
The mechanism described in this document works for both self signed The mechanism described in this document works for both self signed
certificates and certificates signed by well known certificate certificates and certificates signed by well known certificate
authorities. However, most UAs would only use self signed authorities. In order to deploy certificates signed by well known
certificates and would use an Authentication Service as described in certificate authorities, certificate authorities would have to
[RFC4474] to provide a strong binding of an AOR to the certificates. support adding SIP URIs to the subjectAltName of the certificates
they generate. This is something which has been rarely implemented
by commercial certificate authorities. However, most UAs would only
use self signed certificates and would use an Authentication Service
as described in [RFC4474] to provide a strong binding of an AOR to
the certificates.
The mechanisms described in this draft allow for three different The mechanisms described in this draft allow for three different
styles of deployment: styles of deployment:
1. Deployments where the credential server only stores certificates 1. Deployments where the credential server only stores certificates
and does not store any private key information. If the and does not store any private key information. If the
deployment had users with multiple devices, some other scheme deployment had users with multiple devices, some other scheme
(perhaps even manual provisioning) would be used to get the right (perhaps even manual provisioning) would be used to get the right
private keys onto all the devices that a user uses. private keys onto all the devices that a user uses.
2. Deployments where the credential server stores certificates and 2. Deployments where the credential server stores certificates and
skipping to change at page 8, line 21 skipping to change at page 8, line 26
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 6 to get the certificate. While the subscription is active, Section 6 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
revoked before it expires, the Notifier will send a notification with revoked before it expires, the Notifier will send a notification with
an empty body to indicate that the certificate is no longer valid. an empty body to indicate that the certificate is no longer valid.
However, the Subscriber might not receive the notification if an If the certificate is renewed before it expires, the Notifier will
attacker blocks this traffic. The amount of time that the Subscriber send a notification with a body containing the new certificate. Note
caches a certificate SHOULD be configurable. A default of one day is that the Subscriber might not receive the notification if an attacker
blocks this traffic. The amount of time that the Subscriber caches a
certificate SHOULD be configurable. A default of one day is
RECOMMENDED. RECOMMENDED.
Note that the actual duration of the subscription is unrelated to the Note that the actual duration of the subscription is unrelated to the
caching time or validity time of the corresponding certificate. caching time or validity time of the corresponding certificate.
Allowing subscriptions to persist after a certificate is no longer Allowing subscriptions to persist after a certificate is no 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. The Notifier could return an immediate
unauthenticated subscriptions to persist. The Notifier could return notification with the certificate in response to subscribe and then
an immediate notification with the certificate in response to immediately terminate subscription, setting the reason parameter to
subscribe and then immediately terminate subscription, setting the "probation". The Subscriber will have to periodically poll the
reason parameter to "probation". The Subscriber will have to 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 437 If the UA uses a cached certificate in a request and receives a 437
(Unsupported Certificate) response, it SHOULD remove the certificate (Unsupported Certificate) response, it SHOULD remove the certificate
it used from the cache, attempt to fetch the certificate again. If it used from the cache, attempt to fetch the certificate again. If
the certificate is changed, then the UA SHOULD retry the original the certificate is changed, then the UA SHOULD retry the original
request again with the new certificate. This situation usually request again with the new certificate. This situation usually
indicates that the certificate was recently updated, and that the indicates that the certificate was recently updated, and that the
Subscriber has not received a corresponding notification. If the Subscriber has not received a corresponding notification. If the
certificate fetched is the same as the one that was previously in the certificate fetched is the same as the one that was previously in the
cache, then the UA SHOULD NOT try the request again. This situation cache, then the UA SHOULD NOT try the request again. This situation
skipping to change at page 10, line 27 skipping to change at page 10, line 31
6.2. Event Package Parameters 6.2. Event Package Parameters
This package defines the "etag" Event header parameter which is valid This package defines the "etag" Event header parameter which is valid
only in NOTIFY requests. It contains a token which represents the only in NOTIFY requests. It contains a token which represents the
SIP etag value at the time the notification was sent. Considering SIP etag value at the time the notification was sent. Considering
how infrequently credentials are updated, this hint is very likely to how infrequently credentials are updated, this hint is very likely to
be the correct etag to use in the SIP-If-Match header in a SIP be the correct etag to use in the SIP-If-Match header in a SIP
PUBLISH request to update the current credentials. PUBLISH request to update the current credentials.
etag-param = "etag" EQUAL token
6.3. SUBSCRIBE Bodies 6.3. SUBSCRIBE Bodies
This package does not define any SUBSCRIBE bodies. This package does not define any SUBSCRIBE bodies.
6.4. Subscription Duration 6.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.
skipping to change at page 14, line 19 skipping to change at page 14, line 29
for a period of hours or days and will automatically attempt to re- for a period of hours or days and will automatically attempt to re-
subscribe before the subscription has completely expired. subscribe before the subscription has completely expired.
The Subscriber SHOULD subscribe to its credentials whenever a new The Subscriber SHOULD subscribe to its credentials whenever a new
user becomes associated with the device (a new login). The user becomes associated with the device (a new login). The
subscriber SHOULD also renew its subscription immediately after a subscriber SHOULD also renew its subscription immediately after a
reboot, or when the subscriber's network connectivity has just been reboot, or when the subscriber's network connectivity has just been
re-established. re-established.
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 directly connect to the server
may be configured with a specific name for the credential service; acting as the credential service or to a server that is authoritative
for the domain of the credential service. The UA MUST NOT connect
through an intermediate proxy to the credential service. The UA may
be configured with a specific name for the credential service;
otherwise normal SIP routing is used. As described in RFC 3261, the otherwise normal SIP routing is used. As described in RFC 3261, the
TLS connection needs to present a certificate that matches the TLS connection needs to present a certificate that matches the
expected name of the server to which the connection was formed, so expected name of the server to which the connection was formed, so
that the UA knows it is talking to the correct server. Failing to do that the UA knows it is talking to the correct server. Failing to do
this may result in the UA publishing its private key information to this may result in the UA publishing its private key information to
an attacker. The credential service will authenticate the UA using an attacker. The credential service will authenticate the UA using
the usual SIP Digest mechanism, so the UA can expect to receive a SIP the usual SIP Digest mechanism, so the UA can expect to receive a SIP
challenge to the SUBSCRIBE or PUBLISH requests. challenge to the SUBSCRIBE or PUBLISH requests.
7.7. Notifier Processing of SUBSCRIBE Requests 7.7. Notifier Processing of SUBSCRIBE Requests
skipping to change at page 15, line 20 skipping to change at page 15, line 31
reason parameter of "deactivated". (This causes a Subscriber to reason parameter of "deactivated". (This causes a Subscriber to
retry the subscription immediately.) This is so that if a secret for retry the 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.
The notification MUST be sent over TLS so that it is integrity
protected and the TLS needs to be directly connected between the UA
and the credential service with no intermediaries.
7.9. Generation of PUBLISH Requests 7.9. Generation of PUBLISH Requests
A user agent SHOULD be configurable to control whether it publishes A user agent SHOULD be configurable to control whether it publishes
the credential for a user or just the user's certificate. the credential for a user or just the user's certificate.
When publishing just a certificate, the body contains an application/ When publishing just a certificate, the body contains an application/
pkix-cert. When publishing a credential, the body contains a pkix-cert. When publishing a credential, the body contains a
multipart/mixed containing both an application/pkix-cert and an multipart/mixed containing both an application/pkix-cert and an
application/pkcs8 body. application/pkcs8 body.
When the UA sends the PUBLISH [RFC3903] request, it needs to do the When the UA sends the PUBLISH [RFC3903] request, it needs to do the
following: following:
o The UA MUST use TLS to directly connect to the server acting as
the credential service or to a server that is authoritative for
the domain of the credential service. The UA MUST NOT connect
through an intermediate proxy to the credential service.
o The Expires header field value in the PUBLISH request SHOULD be o The Expires header field value in the PUBLISH request SHOULD be
set to match the time for which the certificate is valid. set to match the time for which the certificate is valid.
o If the certificate includes Basic Constraints, it SHOULD set the o If the certificate includes Basic Constraints, it SHOULD set the
CA flag to false. CA flag to false.
o The PUBLISH request SHOULD include a SIP-If-Match header field o The PUBLISH request SHOULD include a SIP-If-Match header field
with the previous etag from the subscription. This prevents with the previous etag from the subscription. This prevents
multiple User Agents for the same AOR from publishing conflicting multiple User Agents for the same AOR from publishing conflicting
credentials. Note that UAs replace credentials that are about to credentials. Note that UAs replace credentials that are about to
expire at a random time (described in Section 5), reducing the expire at a random time (described in Section 5), reducing the
chance of publishing conflicting credentials even without using chance of publishing conflicting credentials even without using
skipping to change at page 20, line 51 skipping to change at page 21, line 45
This specification requires that TLS be used for the SIP This specification requires that TLS be used for the SIP
communications to place and retrieve a UA's private key. This communications to place and retrieve a UA's private key. This
provides security in two ways: provides security in two ways:
1. Confidentiality is provided for the digest authentication 1. Confidentiality is provided for the digest authentication
exchange, thus protecting it from dictionary attacks. exchange, thus protecting it from dictionary attacks.
2. Confidentiality is provided for the private key, thus protecting 2. Confidentiality is provided for the private key, thus protecting
it from being exposed to passive attackers. it from being exposed to passive attackers.
In order to prevent man-in-the-middle attacks, TLS clients MUST check In order to prevent man-in-the-middle attacks, TLS clients MUST check
that the SubjectAltName of the certificate for the server they that the SubjectAltName of the certificate for the server they
connected to exactly matches the server they were trying to connect connected to exactly matches the server they were trying to connect
to. Failing to use TLS or selecting a poor cipher suite (such as to. The connection must be directly connected to the correct server
NULL encryption) may result in credentials, including private keys, or any intermediaries in the TLS path can compromise the certificate
being sent unencrypted over the network and will render the whole and instead provide a certificate for which the attacker knows the
system useless. private key. This may lead the UA that relies on this compromised
certificate to lose confidential information. Failing to use TLS or
selecting a poor cipher suite (such as NULL encryption) may result in
credentials, including private keys, being sent unencrypted over the
network and will render the whole system useless.
The correct checking of chained certificates as specified in TLS The correct checking of chained certificates as specified in TLS
[RFC4366] is critical for the client to authenticate the server. If [RFC4366] is critical for the client to authenticate the server. If
the client does not authenticate that it is talking to the correct the client does not authenticate that it is talking to the correct
credential service, a man in the middle attack is possible. credential service, a man in the middle attack is possible.
9.1. Certificate Revocation 9.1. Certificate Revocation
If a particular credential needs to be revoked, the new credential is If a particular credential needs to be revoked, the new credential is
simply published to the credential service. Every device with a copy simply published to the credential service. Every device with a copy
skipping to change at page 23, line 26 skipping to change at page 24, line 25
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 [RFC2898]. It is RECOMMENDED that of DES-EDE2-CBC-Pad as defined in [RFC2898]. It is RECOMMENDED that
this profile be used when using PKCS#8. A different passphrase this profile be used when using PKCS#8. A different passphrase
SHOULD be used for the PKCS#8 encryption than is used for server SHOULD be used for the PKCS#8 encryption than is used for server
authentication. authentication.
9.6. User Certificate Generation 9.6. User Certificate Generation
The certificates should be consistent with [RFC3280]. A The certificates should be consistent with [RFC5280]. A
signatureAlgorithm of sha1WithRSAEncryption MUST be implemented. The signatureAlgorithm of sha1WithRSAEncryption MUST be implemented. The
Issuers SHOULD be the same as the subject. Given the ease of issuing Issuers SHOULD be the same as the subject. Given the ease of issuing
new certificates with this system, the Validity can be relatively new certificates with this system, the Validity can be relatively
short. A Validity of one year or less is RECOMMENDED. The short. A Validity of one year or less is RECOMMENDED. The
subjectAltName must have a URI type that is set to the SIP URL subjectAltName must have a URI type that is set to the SIP URL
corresponding to the user AOR. It MAY be desirable to put some corresponding to the user AOR. It MAY be desirable to put some
randomness into the length of time for which the certificates are randomness into the length of time for which the certificates are
valid so that it does not become necessary to renew all the valid so that it does not become necessary to renew all the
certificates in the system at the same time. certificates in the system at the same time.
skipping to change at page 27, line 40 skipping to change at page 28, line 40
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002. June 2002.
[RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific [RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific
Event Notification", RFC 3265, June 2002. Event Notification", RFC 3265, June 2002.
[RFC3268] Chown, P., "Advanced Encryption Standard (AES) [RFC3268] Chown, P., "Advanced Encryption Standard (AES)
Ciphersuites for Transport Layer Security (TLS)", Ciphersuites for Transport Layer Security (TLS)",
RFC 3268, June 2002. RFC 3268, June 2002.
[RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
X.509 Public Key Infrastructure Certificate and
Certificate Revocation List (CRL) Profile", RFC 3280,
April 2002.
[RFC3903] Niemi, A., "Session Initiation Protocol (SIP) Extension [RFC3903] Niemi, A., "Session Initiation Protocol (SIP) Extension
for Event State Publication", RFC 3903, October 2004. for Event State Publication", RFC 3903, October 2004.
[RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., [RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,
and T. Wright, "Transport Layer Security (TLS) and T. Wright, "Transport Layer Security (TLS)
Extensions", RFC 4366, April 2006. Extensions", RFC 4366, April 2006.
[RFC4474] Peterson, J. and C. Jennings, "Enhancements for [RFC4474] Peterson, J. and C. Jennings, "Enhancements for
Authenticated Identity Management in the Session Authenticated Identity Management in the Session
Initiation Protocol (SIP)", RFC 4474, August 2006. Initiation Protocol (SIP)", RFC 4474, August 2006.
skipping to change at page 28, line 17 skipping to change at page 29, line 12
[RFC2898] Kaliski, B., "PKCS #5: Password-Based Cryptography [RFC2898] Kaliski, B., "PKCS #5: Password-Based Cryptography
Specification Version 2.0", RFC 2898, September 2000. Specification Version 2.0", RFC 2898, September 2000.
This reference is normative. The mechanisms used in this This reference is normative. The mechanisms used in this
specification from RFC2898 are stable and sutable for use specification from RFC2898 are stable and sutable for use
in a standards track specification. RFC2898 has been used in a standards track specification. RFC2898 has been used
as a normative reference in several prior standards track as a normative reference in several prior standards track
documents including RFC3185, RFC3370, RFC3962, and documents including RFC3185, RFC3370, RFC3962, and
RFC4656. RFC4656.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, May 2008.
12.2. Informational References 12.2. Informational References
[RFC3760] Gustafson, D., Just, M., and M. Nystrom, "Securely [RFC3760] Gustafson, D., Just, M., and M. Nystrom, "Securely
Available Credentials (SACRED) - Credential Server Available Credentials (SACRED) - Credential Server
Framework", RFC 3760, April 2004. Framework", RFC 3760, April 2004.
[RFC3851] Ramsdell, B., "Secure/Multipurpose Internet Mail [RFC3851] Ramsdell, B., "Secure/Multipurpose Internet Mail
Extensions (S/MIME) Version 3.1 Message Specification", Extensions (S/MIME) Version 3.1 Message Specification",
RFC 3851, July 2004. RFC 3851, July 2004.
 End of changes. 24 change blocks. 
76 lines changed or deleted 105 lines changed or added

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