draft-ietf-sip-certs-15.txt   rfc6072.txt 
Network Working Group C. Jennings Internet Engineering Task Force (IETF) C. Jennings
Internet-Draft Cisco Systems Request for Comments: 6072 Cisco Systems
Intended status: Standards Track J. Fischl, Ed. Category: Standards Track J. Fischl, Ed.
Expires: March 25, 2011 Skype ISSN: 2070-1721 Skype
September 21, 2010 February 2011
Certificate Management Service for The Session Initiation Protocol (SIP) Certificate Management Service for the Session Initiation Protocol (SIP)
draft-ietf-sip-certs-15
Abstract Abstract
This draft defines a Credential Service that allows Session This document 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
allows user agents that want to contact a given Address-of-Record allows User Agents that want to contact a given Address-of-Record
(AOR) to retrieve that AOR's certificate by subscribing to the (AOR) to retrieve that AOR's certificate by subscribing to the
Credential Service, which returns an authenticated response credential service, which returns an authenticated response
containing that certificate. The Credential Service also allows containing that certificate. The credential service also allows
users to store and retrieve their own certificates and private keys. users to store and retrieve their own certificates and private keys.
Status of this Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering This is an Internet Standards Track document.
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
This Internet-Draft will expire on March 25, 2011. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc6072.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 3, line 7 skipping to change at page 2, line 34
modifications of such material outside the IETF Standards Process. modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction ....................................................3
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Definitions .....................................................4
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Overview ........................................................4
4. UA Behavior with Certificates . . . . . . . . . . . . . . . . 9 4. UA Behavior with Certificates ...................................7
5. UA Behavior with Credentials . . . . . . . . . . . . . . . . . 10 5. UA Behavior with Credentials ....................................8
6. Event Package Formal Definition for "certificate" . . . . . . 11 6. Event Package Formal Definition for "certificate" ...............9
6.1. Event Package Name . . . . . . . . . . . . . . . . . . . . 11 6.1. Event Package Name .........................................9
6.2. SUBSCRIBE Bodies . . . . . . . . . . . . . . . . . . . . . 11 6.2. SUBSCRIBE Bodies ...........................................9
6.3. Subscription Duration . . . . . . . . . . . . . . . . . . 11 6.3. Subscription Duration .....................................10
6.4. NOTIFY Bodies . . . . . . . . . . . . . . . . . . . . . . 11 6.4. NOTIFY Bodies .............................................10
6.5. Subscriber Generation of SUBSCRIBE Requests . . . . . . . 12 6.5. Subscriber Generation of SUBSCRIBE Requests ...............10
6.6. Notifier Processing of SUBSCRIBE Requests . . . . . . . . 12 6.6. Notifier Processing of SUBSCRIBE Requests .................11
6.7. Notifier Generation of NOTIFY Requests . . . . . . . . . . 12 6.7. Notifier Generation of NOTIFY Requests ....................11
6.8. Subscriber Processing of NOTIFY Requests . . . . . . . . . 13 6.8. Subscriber Processing of NOTIFY Requests ..................11
6.9. Handling of Forked Requests . . . . . . . . . . . . . . . 13 6.9. Handling of Forked Requests ...............................11
6.10. Rate of Notifications . . . . . . . . . . . . . . . . . . 13 6.10. Rate of Notifications ....................................12
6.11. State Agents and Lists . . . . . . . . . . . . . . . . . . 13 6.11. State Agents and Lists ...................................12
6.12. Behavior of a Proxy Server . . . . . . . . . . . . . . . . 13 6.12. Behavior of a Proxy Server ...............................12
7. Event Package Formal Definition for "credential" . . . . . . . 14
7.1. Event Package Name . . . . . . . . . . . . . . . . . . . . 14 7. Event Package Formal Definition for "credential" ...............12
7.2. SUBSCRIBE Bodies . . . . . . . . . . . . . . . . . . . . . 14 7.1. Event Package Name ........................................12
7.3. Subscription Duration . . . . . . . . . . . . . . . . . . 14 7.2. SUBSCRIBE Bodies ..........................................12
7.4. NOTIFY Bodies . . . . . . . . . . . . . . . . . . . . . . 14 7.3. Subscription Duration .....................................12
7.5. Subscriber Generation of SUBSCRIBE Requests . . . . . . . 15 7.4. NOTIFY Bodies .............................................13
7.6. Notifier Processing of SUBSCRIBE Requests . . . . . . . . 15 7.5. Subscriber Generation of SUBSCRIBE Requests ...............13
7.7. Notifier Generation of NOTIFY Requests . . . . . . . . . . 15 7.6. Notifier Processing of SUBSCRIBE Requests .................14
7.8. Generation of PUBLISH Requests . . . . . . . . . . . . . . 16 7.7. Notifier Generation of NOTIFY Requests ....................14
7.9. Notifier Processing of PUBLISH Requests . . . . . . . . . 16 7.8. Generation of PUBLISH Requests ............................15
7.10. Subscriber Processing of NOTIFY Requests . . . . . . . . . 17 7.9. Notifier Processing of PUBLISH Requests ...................15
7.11. Handling of Forked Requests . . . . . . . . . . . . . . . 17 7.10. Subscriber Processing of NOTIFY Requests .................16
7.12. Rate of Notifications . . . . . . . . . . . . . . . . . . 17 7.11. Handling of Forked Requests ..............................16
7.13. State Agents and Lists . . . . . . . . . . . . . . . . . . 17 7.12. Rate of Notifications ....................................16
7.14. Behavior of a Proxy Server . . . . . . . . . . . . . . . . 18 7.13. State Agents and Lists ...................................16
8. Identity Signatures . . . . . . . . . . . . . . . . . . . . . 18 7.14. Behavior of a Proxy Server ...............................16
9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 8. Identity Signatures ............................................16
9.1. Encrypted Page Mode IM Message . . . . . . . . . . . . . . 18 9. Examples .......................................................17
9.2. Setting and Retrieving UA Credentials . . . . . . . . . . 19 9.1. Encrypted Page Mode Instant Message .......................17
10. Security Considerations . . . . . . . . . . . . . . . . . . . 20 9.2. Setting and Retrieving UA Credentials .....................18
10.1. Certificate Revocation . . . . . . . . . . . . . . . . . . 23 10. Security Considerations .......................................19
10.2. Certificate Replacement . . . . . . . . . . . . . . . . . 23 10.1. Certificate Revocation ...................................21
10.3. Trusting the Identity of a Certificate . . . . . . . . . . 23 10.2. Certificate Replacement ..................................22
10.3.1. Extra Assurance . . . . . . . . . . . . . . . . . . . 24 10.3. Trusting the Identity of a Certificate ...................22
10.4. SACRED Framework . . . . . . . . . . . . . . . . . . . . . 25 10.3.1. Extra Assurance ...................................23
10.5. Crypto Profiles . . . . . . . . . . . . . . . . . . . . . 25 10.4. SACRED Framework .........................................24
10.6. User Certificate Generation . . . . . . . . . . . . . . . 26 10.5. Crypto Profiles ..........................................24
10.7. Private Key Storage . . . . . . . . . . . . . . . . . . . 26 10.6. User Certificate Generation ..............................25
10.8. Compromised Authentication Service . . . . . . . . . . . . 27 10.7. Private Key Storage ......................................25
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 10.8. Compromised Authentication Service .......................26
11.1. Certificate Event Package . . . . . . . . . . . . . . . . 28 11. IANA Considerations ...........................................26
11.2. Credential Event Package . . . . . . . . . . . . . . . . . 28 11.1. Certificate Event Package ................................27
11.3. Identity Algorithm . . . . . . . . . . . . . . . . . . . . 28 11.2. Credential Event Package .................................27
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28 11.3. Identity Algorithm .......................................27
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 12. Acknowledgments ...............................................27
13.1. Normative References . . . . . . . . . . . . . . . . . . . 29 13. References ....................................................28
13.2. Informational References . . . . . . . . . . . . . . . . . 30 13.1. Normative References .....................................28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30 13.2. Informative References ...................................29
1. Introduction 1. Introduction
[RFC3261], as amended by [RFC3853], provides a mechanism for end-to- [RFC3261], as amended by [RFC3853], provides a mechanism for end-to-
end encryption and integrity using S/MIME [RFC3851]. Several end encryption and integrity using Secure/Multipurpose Internet Mail
security properties of [RFC3261] depend on S/MIME, and yet it has not Extensions (S/MIME) [RFC5751]. Several security properties of
been widely deployed. One reason is the complexity of providing a [RFC3261] depend on S/MIME, and yet it has not been widely deployed.
reasonable certificate distribution infrastructure. This One reason is the complexity of providing a reasonable certificate
specification proposes a way to address discovery, retrieval, and distribution infrastructure. This specification proposes a way to
management of certificates for SIP deployments. Combined with the address discovery, retrieval, and management of certificates for SIP
SIP Identity [RFC4474] specification, this specification allows users deployments. Combined with the SIP Identity [RFC4474] specification,
to have certificates that are not signed by any well known this specification allows users to have certificates that are not
certification authority while still strongly binding the user's signed by any well known certification authority while still strongly
identity to the certificate. 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 [RFC5280] style certificate containing a public Certificate: A Public Key Infrastructure using X.509 (PKIX)-
key and a list of identities in the SubjectAltName that are bound [RFC5280] style certificate containing a public key and a list of
to this key. The certificates discussed in this draft are identities in the SubjectAltName that are bound to this key. The
generally self-signed and use the mechanisms in the SIP Identity certificates discussed in this document are generally self-signed
[RFC4474] specification to vouch for their validity. Certificates and use the mechanisms in the SIP Identity [RFC4474] specification
that are signed by a certification authority can also be used with to vouch for their validity. Certificates that are signed by a
all the mechanisms in this draft, however, they need not be certification authority can also be used with all the mechanisms
validated by the receiver (although the receiver can validate them in this document; however, they need not be validated by the
for extra assurance; see Section 10.3.1). receiver (although the receiver can validate them for extra
Credential: For this document, credential means the combination of a assurance; see Section 10.3.1).
certificate and the associated private key.
Password Phrase: A password used to encrypt and decrypt a PKCS#8 Credential: For this document, "credential" means the combination of
private key. a certificate and the associated private key.
Password Phrase: A password used to encrypt and decrypt a PKCS #8
(Public Key Cryptographic System #8) private key.
3. Overview 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. An Authentication Service as described in the SIP NOTIFY request. An authentication service as described in the
SIP Identity [RFC4474] specification can be used to vouch for the SIP Identity [RFC4474] specification can be used to vouch for the
identity of the sender of the certificate by using the sender's proxy identity of the sender of the certificate by using the sender's proxy
domain certificate to sign the NOTIFY request. The Authentication domain certificate to sign the NOTIFY request. The authentication
Service is vouching that the sender is allowed to populate the SIP service is vouching that the sender is allowed to populate the SIP
From header field value. The sender of the message is vouching that From header field value. The sender of the message is vouching that
this is an appropriate certificate for the user identified in the SIP this is an appropriate certificate for the user identified in the SIP
from header field value. The credential service can manage public From header field value. The credential service can manage public
certificates as well as the user's private keys. Users can update certificates as well as the user's private keys. Users can update
their credentials, as stored on the credential service, using a SIP their credentials, as stored on the credential service, using a SIP
PUBLISH [RFC3903] request. The UA authenticates to the credential PUBLISH [RFC3903] request. The UA authenticates to the credential
service using a shared secret when a UA is updating a 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 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 UA to authenticate a REGISTER request with the Registrar for the
domain (usually with SIP Digest Authentication). 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
figure easier to understand. the 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 7, line 28 skipping to change at page 5, line 40
| | | | | | | | | |
| | | | TLS Handshake | | | | | TLS Handshake |
| [ Bob later gets ] |<---------------->| | [ Bob later gets ] |<---------------->|
| [ back his own ] | SUBSCRIBE | | [ back his own ] | SUBSCRIBE |
| [ credentials ] | (credential) | | [ credentials ] | (credential) |
| [ at another ] |<-----------------| | [ at another ] |<-----------------|
| [ User Agent ] | SUBSCRIBE+Digest | | [ User Agent ] | SUBSCRIBE+Digest |
| | | |<-----------------| | | | |<-----------------|
| | | | NOTIFY | | | | | NOTIFY |
| | | |----------------->| | | | |----------------->|
| | | | Bob Decrypts key | | | | | Bob decrypts key |
| | | | | | | | | |
| | | | | | | | | |
| SUBSCRIBE (certificate) | Alice fetches | | SUBSCRIBE (certificate) | Alice fetches |
|---------->|----->|----->| Bob's cert | |---------->|----->|----->| Bob's cert |
| | |NOTIFY| | | | |NOTIFY| |
| NOTIFY+Identity |<-----| | | NOTIFY+Identity |<-----| |
|<----------+------| | Alice uses cert | |<----------+------| | Alice uses cert |
| | | | to encrypt | | | | | to encrypt |
| MESSAGE | | | message to Bob | | MESSAGE | | | message to Bob |
|---------->|------+------+----------------->| |---------->|------+------+----------------->|
Bob's UA (Bob2) does a TLS [RFC5246] handshake with the credential Bob's UA (Bob2) does a Transport Layer Security (TLS) [RFC5246]
server to authenticate that the UA is connected to the correct handshake with the credential server to authenticate that the UA is
credential server. Then Bob's UA publishes his newly created or connected to the correct credential server. Then Bob's UA publishes
updated credentials. The credential server digest challenges the UA his newly created or updated credentials. The credential server
to authenticate that the UA knows Bob's shared secret. Once the UA challenges the UA using a Digest Authentication scheme to
is authenticated, the credential server stores Bob's credentials. authenticate that the UA knows Bob's shared secret. Once the UA is
authenticated, the credential server stores Bob's credentials.
Another of Bob's User Agents (Bob1) wants to fetch its current Another of Bob's User Agents (Bob1) wants to fetch its current
credentials. It does a TLS [RFC5246] handshake with the credential credentials. It does a TLS [RFC5246] handshake with the credential
server to authenticate that the UA is connected to the correct server to authenticate that the UA is connected to the correct
credential server. Then Bob's UA subscribes for the credentials. credential server. Then Bob's UA subscribes for the credentials.
The credential server digest challenges the UA to authenticate that The credential server challenges the UA to authenticate that the UA
the UA knows Bob's shared secret. Once the UA is authenticated, the 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. registers on the network.
Some time later Alice decides that she wishes to discover Bob's Some time later Alice decides that she wishes to discover Bob's
certificate so that she can send him an encrypted message or so that certificate so that she can send him an encrypted message or so that
she can verify the signature on a message from Bob. Alice's UA sends she can verify the signature on a message from Bob. Alice's UA sends
a SUBSCRIBE message to Bob's AOR. The proxy in Bob's domain routes a SUBSCRIBE message to Bob's AOR. The proxy in Bob's domain routes
this to the credential server via an "authentication service" as this to the credential server via an "authentication service" as
defined in [RFC4474]. The credential server returns a NOTIFY that defined in [RFC4474]. The credential server returns a NOTIFY that
contains Bob's public certificate in the body. This is routed contains Bob's public certificate in the body. This is routed
through an authentication service that signs that this message really through an authentication service that signs that this message really
can validly claim to be from the AOR "sip:bob@example.com". Alice's can validly claim to be from the AOR "sip:bob@example.com". Alice's
UA receives the certificate and can use it to encrypt a message to 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 certification certificates and certificates signed by well known certification
authorities. In order to deploy certificates signed by well known authorities. In order to deploy certificates signed by well known
certification authorities, certification authorities would have to certification authorities, certification authorities would have to
support adding SIP URIs to the SubjectAltName of the certificates support adding SIP URIs to the SubjectAltName of the certificates
they generate. This is something which has been rarely implemented they generate. This is something that has been rarely implemented by
by commercial certification authorities. However, most UAs would commercial certification authorities. However, most UAs would only
only use self-signed certificates and would use an Authentication use self-signed certificates and would use an authentication service
Service as described in [RFC4474] to provide a strong binding of an as described in [RFC4474] to provide a strong binding of an AOR to
AOR to the certificates. the certificates.
The mechanisms described in this draft allow for three different The mechanisms described in this document 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 employs.
2. Deployments where the credential server stores certificates and 2. Deployments where the credential server stores certificates and
also stores an encrypted version of the private keys. The also stores an encrypted version of the private keys. The
credential server would not know or need the password phrase for credential server would not know or need the password phrase for
decrypting the private key. The credential server would help decrypting the private key. The credential server would help
move the private keys between devices but the user would need to move the private keys between devices, but the user would need to
enter a password phrase on each device to allow that device to enter a password phrase on each device to allow that device to
decrypt (and encrypt) the private key information. decrypt (and encrypt) the private key information.
3. Deployments where the credential server generates and stores the 3. Deployments where the credential server generates and stores the
certificates and private keys. Deployments such as these may not certificates and private keys. Deployments such as these may not
use password phrases. Consequently, the private keys are not use password phrases. Consequently, the private keys are not
encrypted inside the PKCS#8 objects. This style of deployment encrypted inside the PKCS #8 objects. This style of deployment
would often have the credential server, instead of the devices, would often have the credential server, instead of the devices,
create the credentials. 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,
subscribes to the "certificate" SIP event package as described in it 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.
If the certificate is renewed before it expires, the Notifier will If the certificate is renewed before it expires, the Notifier will
send a notification with a body containing the new certificate. Note send a notification with a body containing the new certificate. Note
that the Subscriber might not receive the notification if an attacker that the Subscriber might not receive the notification if an attacker
blocks this traffic. The amount of time that the Subscriber caches a blocks this traffic. The amount of time that the Subscriber caches a
certificate SHOULD be configurable. A default of one day is 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. The Notifier could return an immediate a timely fashion. The Notifier could return an immediate
notification with the certificate in response to subscribe and then notification with the certificate in response to a subscribe request
immediately terminate subscription, setting the reason parameter to and then immediately terminate subscription, setting the reason
"probation". The Subscriber will have to periodically poll the parameter to "probation". The Subscriber will have to periodically
Notifier to verify validity of the certificate. poll the Notifier to verify the 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 and attempt to fetch the certificate again.
the certificate is changed, then the UA SHOULD retry the original If the certificate is changed, then the UA SHOULD retry the original
request again with the new certificate. This situation usually request with the new certificate. This situation usually indicates
indicates that the certificate was recently updated, and that the that the certificate was recently updated, and that the Subscriber
Subscriber has not received a corresponding notification. If the has not received a corresponding notification. If the certificate
certificate fetched is the same as the one that was previously in the fetched is the same as the one that was previously in the cache, then
cache, then the UA SHOULD NOT try the request again. This situation the UA SHOULD NOT try the request again. This situation can happen
can happened when the request was retargeted to a different user than when the request is retargeted to a different user than the original
the original request. The 437 response is defined in [RFC4474]. request. The 437 response is defined in [RFC4474].
Note: A UA that has a presence list MAY want to subscribe to the Note: A UA that has a presence list MAY want to subscribe to the
certificates of all the presentities in the list when the UA certificates of all the presentities in the list when the UA
subscribes to their presence, so that when the user wishes to subscribes to their presence, so that when the user wishes to
contact a presentity, the UA will already have the appropriate contact a presentity, the UA will already have the appropriate
certificate. Future specifications might consider the possibility certificate. Future specifications might consider the possibility
of retrieving the certificates along with the presence documents. of retrieving the certificates along with the presence documents.
The details of how a UA deals with receiving encrypted messages is The details of how a UA deals with receiving encrypted messages is
outside the scope of this specification. It is worth noting that if outside the scope of this specification. It is worth noting that if
Charlie's UAS receives a request that is encrypted to Bob, it would Charlie's User Agent Server (UAS) receives a request that is
be valid and legal for that UA to send a 302 redirecting the call to encrypted to Bob, it would be valid and legal for that UA to send a
Bob. 302 redirecting the call to Bob.
5. UA Behavior with Credentials 5. UA Behavior with Credentials
UAs discover their own credentials by subscribing to their AOR with UAs discover their own credentials by subscribing to their AOR with
an event type of credential as described in Section 7. After a UA an event type of "credential" as described in Section 7. After a UA
registers, it SHOULD retrieve its credentials by subscribing to them registers, it SHOULD retrieve its credentials by subscribing to them
as described in Section 6.5. as described in Section 6.5.
When a UA discovers its credential, the private key information might When a UA discovers its credential, the private key information might
be encrypted with a password phrase. The UA SHOULD request that the be encrypted with a password phrase. The UA SHOULD request that the
user enter the password phrase on the device, and the UA MAY cache user enter the password phrase on the device, and the UA MAY cache
this password phrase for future use. this password phrase for future use.
There are several different cases in which a UA should generate a new There are several different cases in which a UA should generate a new
credential: credential:
skipping to change at page 10, line 34 skipping to change at page 9, line 7
registers, it SHOULD retrieve its credentials by subscribing to them registers, it SHOULD retrieve its credentials by subscribing to them
as described in Section 6.5. as described in Section 6.5.
When a UA discovers its credential, the private key information might When a UA discovers its credential, the private key information might
be encrypted with a password phrase. The UA SHOULD request that the be encrypted with a password phrase. The UA SHOULD request that the
user enter the password phrase on the device, and the UA MAY cache user enter the password phrase on the device, and the UA MAY cache
this password phrase for future use. this password phrase for future use.
There are several different cases in which a UA should generate a new There are several different cases in which a UA should generate a new
credential: credential:
o If the UA receives a NOTIFY with no body for the credential o If the UA receives a NOTIFY with no body for the credential
package. package.
o If the certificate has expired. o If the certificate has expired.
o If the certificate's notAfter date is within the next 600 seconds, o If the certificate's notAfter date is within the next 600 seconds,
the UA SHOULD attempt to create replacement credentials. The UA the UA SHOULD attempt to create replacement credentials. The UA
does this by waiting a random amount of time between 0 and 300 does this by waiting a random amount of time between 0 and
seconds. If no new credentials have been received in that time, 300 seconds. If no new credentials have been received in that
the UA creates new credentials to replace the expiring ones and time, the UA creates new credentials to replace the expiring ones
sends them in a PUBLISH request following the rules for modifying and sends them in a PUBLISH request following the rules for
event state from Section 4.4 of [RFC3903]. modifying event state as described in Section 4.4 of [RFC3903].
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
appropriate randomness as described in [RFC4086] and then creating a Credentials are created by constructing a new key pair that will
certificate as described in Section 10.6. The UA MAY encrypt the require appropriate randomness as described in [RFC4086] and then
private key with a password phrase supplied by the user as specified creating a certificate as described in Section 10.6. The UA MAY
in Section 10.5. Next, the UA updates the user's credential by encrypt the private key with a password phrase supplied by the user
sending a PUBLISH [RFC3903] request with the credentials or just the as specified in Section 10.5. Next, the UA updates the user's
certificate as described in Section 7.8. credential by sending a PUBLISH [RFC3903] request with the
credentials or just the certificate as described in Section 7.8.
If a UA wishes to revoke the existing certificate without publishing If a UA wishes to revoke the existing certificate without publishing
a new one, it MUST send a PUBLISH with an empty body to the a new one, it MUST send a PUBLISH with an empty body to the
credential server. credential server.
6. Event Package Formal Definition for "certificate" 6. Event Package Formal Definition for "certificate"
6.1. Event Package Name 6.1. Event Package Name
This document defines a SIP Event Package as defined in [RFC3265]. This document defines a SIP event package as defined in [RFC3265].
The event-package token name for this package is: The event-package token name for this package is:
certificate certificate
6.2. SUBSCRIBE Bodies 6.2. SUBSCRIBE Bodies
This package does not define any SUBSCRIBE bodies. This package does not define any SUBSCRIBE bodies.
6.3. Subscription Duration 6.3. Subscription Duration
skipping to change at page 11, line 47 skipping to change at page 10, line 27
The body of a NOTIFY request for this package MUST either be empty or The body of a NOTIFY request for this package MUST either be empty or
contain an application/pkix-cert body (as defined in [RFC2585]) that contain an application/pkix-cert body (as defined in [RFC2585]) that
contains the certificate, unless an Accept header field has contains the certificate, unless an Accept header field has
negotiated some other type. The Content-Disposition MUST be set to negotiated some other type. The Content-Disposition MUST be set to
"signal" as defined in [RFC3204]. "signal" as defined in [RFC3204].
A future extension MAY define other NOTIFY bodies. If no "Accept" A future extension MAY define other NOTIFY bodies. If no "Accept"
header field is present in the SUBSCRIBE, the body type defined in header field is present in the SUBSCRIBE, the body type defined in
this document MUST be assumed. this document MUST be assumed.
Implementations which generate large notifications are reminded to Implementations that 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 [RFC3261].
6.5. Subscriber Generation of SUBSCRIBE Requests 6.5. Subscriber Generation of SUBSCRIBE Requests
A UA discovers a certificate by sending a SUBSCRIBE request with an A UA discovers a certificate by sending a SUBSCRIBE request with an
event type of "certificate" to the AOR for which a certificate is event type of "certificate" to the AOR for which a certificate is
desired. In general, the UA stays subscribed to the certificate for desired. In general, the UA stays subscribed to the certificate for
as long as it plans to use and cache the certificate, so that the UA as long as it plans to use and cache the certificate, so that the UA
can be notified about changes or revocations to the certificate. can be notified about changes or revocations to the certificate.
Subscriber User Agents will typically subscribe to certificate Subscriber User Agents will typically subscribe to certificate
information for a period of hours or days, and automatically attempt information for a period of hours or days, and automatically attempt
to re-subscribe just before the subscription is completely expired. to re-subscribe just before the subscription is completely expired.
When a user de-registers from a device (logoff, power down of a When a user de-registers from a device (logoff, power down of a
mobile device, etc.), subscribers SHOULD unsubscribe by sending a mobile device, etc.), Subscribers SHOULD unsubscribe by sending a
SUBSCRIBE request with an Expires header field of zero. SUBSCRIBE request with an Expires header field of zero.
6.6. Notifier Processing of SUBSCRIBE Requests 6.6. Notifier Processing of SUBSCRIBE Requests
When a SIP credential server receives a SUBSCRIBE request with the When a SIP credential server receives a SUBSCRIBE request with the
certificate event-type, it is not necessary to authenticate the certificate event-type, it is not necessary to authenticate the
subscription request. The Notifier MAY limit the duration of the subscription request. The Notifier MAY limit the duration of the
subscription to an administrator-defined period of time. The subscription to an administrator-defined period of time. The
duration of the subscription does not correspond in any way to the duration of the subscription does not correspond in any way to the
period for which the certificate will be valid. period for which the certificate will be valid.
skipping to change at page 12, line 42 skipping to change at page 11, line 26
requested URI. If it does not have a certificate, it returns a requested URI. If it does not have a certificate, it returns a
NOTIFY request with an empty message body. NOTIFY request with an empty message body.
6.7. Notifier Generation of NOTIFY Requests 6.7. Notifier Generation of NOTIFY Requests
Immediately after a subscription is accepted, the Notifier MUST send Immediately after a subscription is accepted, the Notifier MUST send
a NOTIFY with the current certificate, or an empty body if no a NOTIFY with the current certificate, or an empty body if no
certificate is available for the target user. In either case it certificate is available for the target user. In either case it
forms a NOTIFY with the From header field value set to the value of forms a NOTIFY with the From header field value set to the value of
the To header field in the SUBSCRIBE request. This server sending the To header field in the SUBSCRIBE request. This server sending
the NOTIFY needs either to implement an Authentication Service (as the NOTIFY needs either to implement an authentication service (as
described in SIP Identity [RFC4474]) or else the server needs to be described in SIP Identity [RFC4474]) or else the server needs to be
set up such that the NOTIFY request will be sent through an set up such that the NOTIFY request will be sent through an
Authentication Service. Sending the NOTIFY request through the authentication service. Sending the NOTIFY request through the
Authentication Service requires the SUBSCRIBE request to have been authentication service requires the SUBSCRIBE request to have been
routed through the Authentication Service, since the NOTIFY is sent routed through the authentication service, since the NOTIFY is sent
within the dialog formed by the subscription. within the dialog formed by the subscription.
6.8. Subscriber Processing of NOTIFY Requests 6.8. Subscriber Processing of NOTIFY Requests
The resulting NOTIFY will contain an application/pkix-cert body that The resulting NOTIFY will contain an application/pkix-cert body that
contains the requested certificate. The UA MUST follow the contains the requested certificate. The UA MUST follow the
procedures in Section 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 for which it should be cached 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 [RFC4474]. If the identity asserted by the service as described in [RFC4474]. If the identity asserted by the
Authentication Service does not match the AOR that the UA subscribed authentication service does not match the AOR that the UA subscribed
to, the certificate in the NOTIFY is discarded and MUST NOT be used. to, the certificate in the NOTIFY is discarded and MUST NOT be used.
6.9. Handling of Forked Requests 6.9. Handling of Forked Requests
This event package does not permit forked requests. At most one This event package does not permit forked requests. At most one
subscription to this event type is permitted per resource. subscription to this event type is permitted per resource.
6.10. Rate of Notifications 6.10. Rate of Notifications
Notifiers SHOULD NOT generate NOTIFY requests more frequently than Notifiers SHOULD NOT generate NOTIFY requests more frequently than
once per minute. once per minute.
6.11. State Agents and Lists 6.11. State Agents and Lists
The credential server described in this section which serves The credential server described in this section that serves
certificates is a state agent as defined in [RFC3265] and certificates is a state agent as defined in [RFC3265], and
implementations of the credential server MUST be implemented as a implementations of the credential server MUST be implemented as a
state agent. state agent.
Implementers MUST NOT use the event list extension [RFC4662] with Implementers MUST NOT use the event list extension [RFC4662] with
this event type. It is not possible to make such an approach work, this event type. It is not possible to make such an approach work,
because the Authentication service would have to simultaneously because the authentication service would have to simultaneously
assert several different identities. assert several different identities.
6.12. Behavior of a Proxy Server 6.12. Behavior of a Proxy Server
There are no additional requirements on a SIP Proxy, other than to There are no additional requirements on a SIP proxy, other than to
transparently forward the SUBSCRIBE and NOTIFY requests as required transparently forward the SUBSCRIBE and NOTIFY requests as required
in SIP. This specification describes the Proxy, Authentication in SIP. This specification describes the proxy, authentication
service, and credential service as three separate services, but it is service, and credential service as three separate services, but it is
certainly possible to build a single SIP network element that certainly possible to build a single SIP network element that
performs all of these services at the same time. performs all of these services at the same time.
7. Event Package Formal Definition for "credential" 7. Event Package Formal Definition for "credential"
7.1. Event Package Name 7.1. Event Package Name
This document defines a SIP Event Package as defined in [RFC3265]. This document defines a SIP event package as defined in [RFC3265].
The event-package token name for this package is: The event-package token name for this package is:
credential credential
7.2. SUBSCRIBE Bodies 7.2. SUBSCRIBE Bodies
This package does not define any SUBSCRIBE bodies. This package does not define any SUBSCRIBE bodies.
7.3. Subscription Duration 7.3. Subscription Duration
skipping to change at page 14, line 40 skipping to change at page 13, line 18
multipart/mixed type (see [RFC2046]). This allows a notification to multipart/mixed type (see [RFC2046]). This allows a notification to
contain multiple resource documents including at a minimum the contain multiple resource documents including at a minimum the
application/pkix-cert body with the certificate and an application/ application/pkix-cert body with the certificate and an application/
pkcs8 body that has the associated private key information for the pkcs8 body that has the associated private key information for the
certificate. The application/pkcs8 media type is defined in certificate. The application/pkcs8 media type is defined in
[RFC5958]. [RFC5958].
The absence of an Accept header in the SUBSCRIBE indicates support The absence of an Accept header in the SUBSCRIBE indicates support
for multipart/mixed and the content types application/pkix-cert and for multipart/mixed and the content types application/pkix-cert and
application/pkcs8. If an Accept header is present, these types MUST application/pkcs8. If an Accept header is present, these types MUST
be included, in additional to any other types supported by the be included, in addition to any other types supported by the client.
client.
The application/pkix-cert body is a DER encoded X.509v3 certificate The application/pkix-cert body is a Distinguished Encoding Rules
[RFC2585]. The application/pkcs8 body contains a DER-encoded (DER)-encoded X.509v3 certificate [RFC2585]. The application/pkcs8
[RFC5958] object that contains the private key. The PKCS#8 objects body contains a DER-encoded [RFC5958] object that contains the
MUST be of type PrivateKeyInfo. The integrity and confidentiality of private key. The PKCS #8 objects MUST be of type PrivateKeyInfo.
the PKCS#8 objects is provided by the TLS transport. The transport The integrity and confidentiality of the PKCS #8 objects are provided
encoding of all the MIME bodies is binary. by the TLS transport. The transport encoding of all the MIME bodies
is binary.
7.5. Subscriber Generation of SUBSCRIBE Requests 7.5. Subscriber Generation of SUBSCRIBE Requests
A Subscriber User Agent will subscribe to its credential information A Subscriber User Agent will subscribe to its credential information
for a period of hours or days and will automatically attempt to re- for a period of hours or days and will automatically attempt to
subscribe before the subscription has completely expired. re-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 directly connect to the server operations. The UA MUST use TLS to directly connect to the server
acting as the credential service or to a server that is authoritative acting as the credential service or to a server that is authoritative
for the domain of the credential service. The UA MUST NOT connect for the domain of the credential service. The UA MUST NOT connect
through an intermediate proxy to the credential service. The UA may through an intermediate proxy to the credential service. The UA may
be configured with a specific name for the credential service; be configured with a specific name for the credential service;
otherwise normal SIP routing is used. As described in RFC 3261, the otherwise, normal SIP routing is used. As described in RFC 3261, the
TLS connection needs to present a certificate that matches the TLS connection needs to present a certificate that matches the
expected name of the server to which the connection was formed, so expected name of the server to which the connection was formed, so
that the UA knows it is talking to the correct server. Failing to do that the UA knows it is talking to the correct server. Failing to do
this may result in the UA publishing its private key information to this may result in the UA publishing its private key information to
an attacker. The credential service will authenticate the UA using an attacker. The credential service will authenticate the UA using
the usual SIP Digest mechanism, so the UA can expect to receive a SIP the usual SIP Digest mechanism, so the UA can expect to receive a SIP
challenge to the SUBSCRIBE or PUBLISH requests. challenge to the SUBSCRIBE or PUBLISH requests.
7.6. Notifier Processing of SUBSCRIBE Requests 7.6. Notifier Processing of SUBSCRIBE Requests
When a credential service receives a SUBSCRIBE for a credential, the When a credential service receives a SUBSCRIBE for a credential, the
credential service has to authenticate and authorize the UA and credential service has to authenticate and authorize the UA, and
validate that adequate transport security is being used. Only a UA validate that adequate transport security is being used. Only a UA
that can authenticate as being able to register as the AOR is that can authenticate as being able to register as the AOR is
authorized to receive the credentials for that AOR. The Credential authorized to receive the credentials for that AOR. The credential
Service MUST digest challenge the UA to authenticate the UA and then service MUST challenge the UA to authenticate the UA and then decide
decide if it is authorized to receive the credentials. If if it is authorized to receive the credentials. If authentication is
authentication is successful, the Notifier MAY limit the duration of successful, the Notifier MAY limit the duration of the subscription
the subscription to an administrator-defined period of time. The to an administrator-defined period of time. The duration of the
duration of the subscription MUST NOT be larger than the length of subscription MUST NOT be larger than the length of time for which the
time for which the certificate is still valid. The Expires header certificate is still valid. The Expires header field SHOULD be set
field SHOULD be set so that it is not longer than the notAfter date so that it is not longer than the notAfter date in the certificate.
in the certificate.
7.7. Notifier Generation of NOTIFY Requests 7.7. Notifier Generation of NOTIFY Requests
Once the UA has authenticated with the credential service and the Once the UA has authenticated with the credential service and the
subscription is accepted, the credential service MUST immediately subscription is accepted, the credential service MUST immediately
send a Notify request. The Authentication Service is applied to this send a Notify request. The authentication service is applied to this
NOTIFY request in the same way as the certificate subscriptions. If NOTIFY request in the same way as the certificate subscriptions. If
the credential is revoked, the credential service MUST terminate any the credential is revoked, the credential service MUST terminate any
current subscriptions and force the UA to re-authenticate by sending current subscriptions and force the UA to re-authenticate by sending
a NOTIFY with its Subscription-State header field set to "terminated" a NOTIFY with its Subscription-State header field set to "terminated"
and a reason parameter of "deactivated". (This causes a Subscriber and a reason parameter set to "deactivated". (This causes a
to retry the subscription immediately.) This is so that if a secret Subscriber to retry the subscription immediately.) This is so that
for retrieving the credentials gets compromised, the rogue UA will if a secret for retrieving the credentials gets compromised, the
not continue to receive credentials after the compromised secret has rogue UA will not continue to receive credentials after the
been changed. compromised secret has been changed.
Any time the credentials for this URI change, the credential service Any time the credentials for this URI change, the credential service
MUST send a new NOTIFY to any active subscriptions with the new MUST send a new NOTIFY to any active subscriptions with the new
credentials. credentials.
The notification MUST be sent over TLS so that it is integrity The notification MUST be sent over TLS so that it is integrity
protected and the TLS needs to be directly connected between the UA protected, and the TLS needs to be directly connected between the UA
and the credential service with no intermediaries. and the credential service with no intermediaries.
7.8. Generation of PUBLISH Requests 7.8. Generation of PUBLISH Requests
A user agent SHOULD be configurable to control whether it publishes A User Agent SHOULD be configurable to control whether it publishes
the credential for a user or just the user's certificate. the credential for a user or just the user's certificate.
When publishing just a certificate, the body contains an application/ When publishing just a certificate, the body contains an application/
pkix-cert. When publishing a credential, the body contains a pkix-cert. When publishing a credential, the body contains a
multipart/mixed containing both an application/pkix-cert and an multipart/mixed containing both an application/pkix-cert and an
application/pkcs8 body. application/pkcs8 body.
When the UA sends the PUBLISH [RFC3903] request, it needs to do the When the UA sends the PUBLISH [RFC3903] request, it needs to do the
following: following:
o The UA MUST use TLS to directly connect to the server acting as o The UA MUST use TLS to directly connect to the server acting as
the credential service or to a server that is authoritative for the credential service or to a server that is authoritative for
the domain of the credential service. The UA MUST NOT connect the domain of the credential service. The UA MUST NOT connect
through an intermediate proxy to the credential service. through an intermediate proxy to the credential service.
o The Expires header field value in the PUBLISH request SHOULD be o The Expires header field value in the PUBLISH request SHOULD be
set to match the time for which the certificate is valid. set to match the time for which the certificate is valid.
o If the certificate includes Basic Constraints, it SHOULD set the o If the certificate includes Basic Constraints, it SHOULD set the
cA flag to false. cA boolean to false.
7.9. Notifier Processing of PUBLISH Requests 7.9. Notifier Processing of PUBLISH Requests
When the credential service receives a PUBLISH to update credentials, When the credential service receives a PUBLISH request to update
it MUST authenticate and authorize this request the same way as for credentials, it MUST authenticate and authorize this request in the
subscriptions for credentials. If the authorization succeeds, then same way as for subscriptions for credentials. If the authorization
the credential service MUST perform the following check on the succeeds, then the credential service MUST perform the following
certificate: checks on the certificate:
o The notBefore validity time MUST NOT be in the future. o The notBefore validity time MUST NOT be in the future.
o The notAfter validity time MUST be in the future. o The notAfter validity time MUST be in the future.
o If a cA Basic Constraint flag is set in the certificate, it is set
to false. o If a cA BasicConstraints boolean is set in the certificate, it is
set to FALSE.
If all of these succeed, the credential service updates the If all of these succeed, the credential service updates the
credential for this URI, processes all the active certificates and credential for this URI, processes all the active certificates and
credential subscriptions to this URI, and generates a NOTIFY request credential subscriptions to this URI, and generates a NOTIFY request
with the new credential or certificate. Note the SubjectAltName with the new credential or certificate. Note the SubjectAltName
SHOULD NOT be checked as that would restrict which certificates could SHOULD NOT be checked, as that would restrict which certificates
be used and offers no additional security guarantees. could be used and offers no additional security guarantees.
If the Subscriber submits a PUBLISH request with no body and If the Subscriber submits a PUBLISH request with no body and
Expires=0, this revokes the current credentials. Watchers of these Expires=0, this revokes the current credentials. Watchers of these
credentials will receive update with no body indicating that they credentials will receive an update with no body, indicating that they
MUST stop any previously stored credentials. Note that subscriptions MUST stop any previously stored credentials. Note that subscriptions
to the certificate package are NOT terminated; each subscriber to the to the certificate package are NOT terminated; each Subscriber to the
certificate package receives a notification with an empty body. certificate package receives a notification with an empty body.
7.10. Subscriber Processing of NOTIFY Requests 7.10. Subscriber Processing of NOTIFY Requests
When the UA receives a valid NOTIFY request, it should replace its When the UA receives a valid NOTIFY request, it should replace its
existing credentials with the new received ones. If the UA cannot existing credentials with the new received ones. If the UA cannot
decrypt the PKCS#8 object, it MUST send a 437 (Unsupported decrypt the PKCS #8 object, it MUST send a 437 (Unsupported
Certificate) response. Later if the user provides a new password Certificate) response. Later, if the user provides a new password
phrase for the private key, the UA can subscribe to the credentials phrase for the private key, the UA can subscribe to the credentials
again and attempt to decrypt with the new password phrase. again and attempt to decrypt with the new password phrase.
7.11. Handling of Forked Requests 7.11. Handling of Forked Requests
This event package does not permit forked requests. This event package does not permit forked requests.
7.12. Rate of Notifications 7.12. Rate of Notifications
Notifiers SHOULD NOT generate NOTIFY requests more frequently than Notifiers SHOULD NOT generate NOTIFY requests more frequently than
once per minute. once per minute.
7.13. State Agents and Lists 7.13. State Agents and Lists
The credential server described in this section which serves The credential server described in this section which serves
credentials is a state agent and implementations of the credential credentials is a state agent, and implementations of the credential
server MUST be implemented as a state agent. server MUST be implemented as a state agent.
Implementers MUST NOT use the event list extension [RFC4662] with Implementers MUST NOT use the event list extension [RFC4662] with
this event type. this event type.
7.14. Behavior of a Proxy Server 7.14. Behavior of a Proxy Server
The behavior is identical to behavior described for certificate The behavior is identical to behavior described for certificate
subscriptions described in Section 6.12. subscriptions in Section 6.12.
8. Identity Signatures 8. Identity Signatures
The [RFC4474] Authentication service defined an signature algorithm The [RFC4474] authentication service defined a signature algorithm
based on SHA-1 called rsa-sha1. This specification adds an signature based on SHA-1 called rsa-sha1. This specification adds a signature
algorithm that is roughly the same but based on SHA-256 and called algorithm that is roughly the same but based on SHA-256 and called
rsa-sha256. rsa-sha256.
When using the rsa-sha256 algorithm, the signature MUST be computed When using the rsa-sha256 algorithm, the signature MUST be computed
in exactly the same way as described in section 9 of [RFC4474] with in exactly the same way as described in Section 9 of [RFC4474] with
the exception that instead of using sha1WithRSAEncryption, the the exception that instead of using sha1WithRSAEncryption, the
computation is done using sha256WithRSAEncryption as described in computation is done using sha256WithRSAEncryption as described in
[RFC5754]. [RFC5754].
Implementations of this specification MUST implement both rsa-sha1 Implementations of this specification MUST implement both rsa-sha1
and rsa-sha256. The IANA registration for rsa-sha256 is defined in and rsa-sha256. The IANA registration for rsa-sha256 is defined in
Section 11.3. Section 11.3.
9. Examples 9. Examples
In all these examples, large parts of the messages are omitted to In all of 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 document. The lines in the
that are prefixed by $ represent encrypted blocks of data. examples that are prefixed by $ represent encrypted blocks of data.
9.1. Encrypted Page Mode IM Message 9.1. Encrypted Page Mode Instant 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
skipping to change at page 19, line 17 skipping to change at page 18, line 4
.... ....
From: <sip:bob@biloxi.example.com>;tag=1234 From: <sip:bob@biloxi.example.com>;tag=1234
Identity: ".... stuff removed ...." Identity: ".... stuff removed ...."
Identity-Info: <https://atlanta.example.com/cert>;alg=rsa-sha256 Identity-Info: <https://atlanta.example.com/cert>;alg=rsa-sha256
.... ....
Event: certificate Event: certificate
Content-Type: application/pkix-cert Content-Type: application/pkix-cert
Content-Disposition: signal Content-Disposition: signal
< certificate data > < certificate data >
Next, Alice sends a SIP MESSAGE to Bob and can encrypt the body using
Next, Alice sends a SIP MESSAGE message to Bob and can encrypt the Bob's public key as shown below.
body using Bob's public key as shown below.
MESSAGE sip:bob@biloxi.example.com SIP/2.0 MESSAGE sip:bob@biloxi.example.com SIP/2.0
... ...
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 certificate and private key When Alice's UA wishes to publish Alice's certificate and private key
to the credential service, it sends a PUBLISH request like the one to the credential service, it sends a PUBLISH request like the one
below. This must be sent over a TLS connection directly to the below. This must be sent over a TLS connection directly to the
domain of the credential service. The credential service presents a domain of the credential service. The credential service presents a
certificate where the SubjectAltName contains an entry that matches certificate where the SubjectAltName contains an entry that matches
the domain name in the request line of the PUBLISH request and digest the domain name in the request line of the PUBLISH request and
challenges the request to authenticate her. challenges the request to authenticate her.
PUBLISH sips:alice@atlanta.example.com SIP/2.0 PUBLISH sips:alice@atlanta.example.com SIP/2.0
... ...
Event: credential Event: credential
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
< Public certificate for Alice > < Public certificate for Alice >
--boundary --boundary
Content-ID: 456 Content-ID: 456
Content-Type: application/pkcs8 Content-Type: application/pkcs8
< Private Key for Alice > < Private Key for Alice >
--boundary --boundary
If one of Alice's UAs subscribes to the credential event, the UA will If one of Alice's UAs subscribes to the credential event, the
be digest challenged, and the NOTIFY will include a body similar to credential service will challenge the request to authenticate her,
the one in the PUBLISH section above. and the NOTIFY will include a body similar to the one in the PUBLISH
example above.
10. Security Considerations 10. Security Considerations
The high level message flow from a security point of view is The high-level message flow from a security point of view is
summarized in the following figure. The 200 responses are removed summarized in the following figure. The 200 responses are removed
from the figure as they do not have much to do with the overall from the figure, as they do not have much to do with the overall
security. security.
In this figure, authC refers to authentication and authZ refers to In this figure, authC refers to authentication and authZ refers to
authorization. authorization.
Alice Server Bob UA Alice Server Bob UA
| | TLS Handshake | 1) Client authC/Z server | | TLS Handshake | 1) Client authC/Z server
| |<---------------->| | |<---------------->|
| | PUBLISH | 2) Client sends request | | PUBLISH | 2) Client sends request
| |<-----------------| (write credential) | |<-----------------| (write credential)
skipping to change at page 21, line 36 skipping to change at page 19, line 46
| | | |
| 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 credential server. The UA authenticated the would store this on the credential server. The UA authenticated the
Server using the certificates from the TLS handshake. The Server 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, which server. First, it forms a TLS connection to the server, which
provides integrity and privacy protection and also authenticates the provides integrity and privacy protection and also authenticates the
server to Bob's UA. Next the UA requests its credentials using a server to Bob's UA. Next, the UA requests its credentials using a
SUBSCRIBE request. The Server digest challenges this to authenticate SUBSCRIBE request. The server challenges the SUBSCRIBE Request to
Bob's UA. The server and Bob's UA have a shared secret that is used authenticate Bob's UA. The server and Bob's UA have a shared secret
for this. If the authentication is successful, the server sends the that is used for this. If the authentication is successful, the
credentials to Bob's UA. The private key in the credentials may have server sends the credentials to Bob's UA. The private key in the
been encrypted using a shared secret that the server does not know. credentials may have been encrypted using a shared secret that the
server does not know.
A similar process would be used for Bob's UA to publish new A similar process would be used for Bob's UA to publish new
credentials to the server. Bob's UA would send a PUBLISH request credentials to the server. Bob's UA would send a PUBLISH request
containing the new credentials. When this happened, all the other containing the new credentials. When this happened, all the other
UAs that were subscribed to Bob's credentials would receive a NOTIFY UAs that were subscribed to Bob's credentials would receive a NOTIFY
with the new credentials. with the new credentials.
Alice wishes to find Bob's certificate and sends a SUBSCRIBE to the Alice wishes to find Bob's certificate and sends a SUBSCRIBE to the
server. The server sends the response in a NOTIFY. This does not server. The server sends the response in a NOTIFY. This does not
need to be sent over a privacy or integrity protected channel, as the need to be sent over a privacy or integrity protected channel, as the
Authentication service described in [RFC4474] provides integrity authentication service described in [RFC4474] provides integrity
protection of this information and signs it with the certificate for protection of this information and signs it with the certificate for
the domain. the domain.
This whole scheme is highly dependent on trusting the operators of This whole scheme is highly dependent on trusting the operators of
the credential service and trusting that the credential service will the credential service and trusting that the credential service will
not be compromised. The security of all the users will be not be compromised. The security of all the users will be
compromised if the credential service is compromised. compromised if the credential service is compromised.
Note: There has been significant discussion of the topic of Note: There has been significant discussion of the topic of
avoiding deployments in which the credential servers store the avoiding deployments in which the credential servers store the
private keys, even in some encrypted form that the credential private keys, even in some encrypted form that the credential
server does not know how to decrypt. Various schemes were server does not know how to decrypt. Various schemes were
considered to avoid this but they all result in either moving the 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 to some other server, which does not seem to make the
problem any better, or having a different credential for each problem any better, or having a different credential for each
device. For some deployments where each user has only one device device. For some deployments where each user has only one device,
this is fine but for deployments with multiple devices, it would this is fine, but for deployments with multiple devices, it would
require that when Alice went to contact Bob, Alice would have to require that when Alice went to contact Bob, Alice would have to
provide messages encrypted for all of Bob's devices. The sipping provide messages encrypted for all of Bob's devices. The SIPPING
working group did consider this architecture and decided it was Working Group did consider this architecture and decided it was
not appropriate due both to the information it revealed about the not appropriate due both to the information it revealed about the
devices and users and the amount of signaling required to make it devices and users, and to the amount of signaling required to make
work. it work.
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. The connection must be directly connected to the correct server to. The TLS client must be directly connected to the correct server;
or any intermediaries in the TLS path can compromise the certificate otherwise, any intermediaries in the TLS path can compromise the
and instead provide a certificate for which the attacker knows the certificate and instead provide a certificate for which the attacker
private key. This may lead the UA that relies on this compromised knows the private key. This may lead the UA that relies on this
certificate to lose confidential information. Failing to use TLS or compromised certificate to lose confidential information. Failing to
selecting a poor cipher suite (such as NULL encryption) may result in use TLS or selecting a poor cipher suite (such as NULL encryption)
credentials, including private keys, being sent unencrypted over the may result in credentials, including private keys, being sent
network and will render the whole system useless. 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
[RFC5246] is critical for the client to authenticate the server. If [RFC5246] 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.
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 denial-of-service (DoS)
the UA that had cached a certificate did not receive the NOTIFY with attack such that the UA that had cached a certificate did not receive
its revocation. To protect against this attack, the UA needs to the NOTIFY with its revocation. To protect against this attack, the
limit how long it caches certificates. After this time, the UA would UA needs to limit how long it caches certificates. After this time,
invalidate the cached information even though no NOTIFY had ever been the UA would invalidate the cached information, even though no NOTIFY
received due to the attacker blocking it. had ever been 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 Certificate Revocation List
applications, a default time of 1 day is suggested, but for some (CRL). For many applications, a default time of one day is
applications it may be desirable to set the time to zero so that no suggested, but for some applications it may be desirable to set the
certificates are cached at all and the credential is checked for time to zero so that no certificates are cached at all and the
validity every time the certificate is used. credential is checked for validity every time the certificate is
used.
The UA MUST NOT cache the certificates for a period longer than that The UA MUST NOT cache the certificates for a period longer than that
of the subscription duration. This is to avoid the UA using invalid of the subscription duration. This is to avoid the UA using invalid
cached credentials when the notifier of the new credentials has been cached credentials when the Notifier of the new credentials has been
prevented from updating the UA. prevented from updating the UA.
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 before the normal expiration. 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 request. The term original URI is used to describe the URI NOTIFY request. The term "original URI" is used to describe the URI
that was in the To header field value of the SUBSCRIBE request. So 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. in this case, the original URI would be sip:alice@example.com.
If the certificate is signed by a trusted certification authority, If the certificate is signed by a trusted certification authority,
and one of the names in the SubjectAltName matches the original URI, and one of the names in the SubjectAltName matches the original URI,
then this certificate MAY be used but only for exactly the original then this certificate MAY be used, but only for exactly the original
URI and not for other identities found in the SubjectAltName. URI and not for other identities found in the SubjectAltName.
Otherwise, there are several steps the UA MUST perform before using Otherwise, there are several steps the UA MUST perform before using
this certificate. this certificate.
o The From header field in the NOTIFY request MUST match the o The From header field in the NOTIFY request MUST match the
original URI that was subscribed to. original URI that was subscribed to.
o The UA MUST check the Identity header field as described in the o The UA MUST check the Identity header field as described in the
Identity [RFC4474] specification to validate that bodies have not Identity [RFC4474] specification to validate that bodies have not
been tampered with and that an Authentication Service has been tampered with and that an authentication service has
validated this From header field. validated this From header field.
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 header field. The
Authentication Service validates that this request did come from the authentication service validates that this request did come from the
identity claimed in the From header field value and that the bodies identity claimed in the From header field value and that the bodies
in the request that carry the certificate have not been tampered in the request that carry the certificate have not been tampered
with. The certificate in the body contains the public key for the with. The certificate in the body contains the public key for the
identity. Only the UA that can authenticate as this AOR, or devices identity. Only the UA that can authenticate as this AOR, or devices
with access to the private key of the domain, can tamper with this with access to the private key of the domain, can tamper with this
body. This stops other users from being able to provide a false body. This stops other users from being able to provide a false
public key. This chain of assertion from original URI, to From, to public key. This chain of assertion from original URI, to From, to
body, to public key is critical to the security of the mechanism body, to public key is critical to the security of the mechanism
described in this specification. If any of the steps above are not described in this specification. If any of the steps above are not
followed, this chain of security will be broken and the system will followed, this chain of security will be broken and the system will
not work. not work.
10.3.1. Extra Assurance 10.3.1. Extra Assurance
Although the certificates used with this document need not be Although the certificates used with this document need not be
validatable to a trust anchor via PKIX [RFC5280] procedures, validatable to a trust anchor via PKIX [RFC5280] procedures,
certificates which can be validated may also be distributed via this certificates that can be validated may also be distributed via this
mechanism. Such certificates potentially offer an additional level mechanism. Such certificates potentially offer an additional level
of security because they can be used with the secure (and partially of security because they can be used with the secure (and partially
isolated) certification authority user verification and key issuance isolated) certification authority user verification and key issuance
toolset, rather than depending on the security of generic SIP toolset, rather than depending on the security of generic SIP
implementations. implementations.
When a relying party receives a certificate which is not self-signed, When a relying party receives a certificate that is not self-signed,
it MAY attempt to validate it using the rules in Section 6 of it MAY attempt to validate the certificate using the rules in
[RFC5280]. If the certificate validates successfully and the names Section 6 of [RFC5280]. If the certificate validates successfully
correctly match the user's AOR (see Section 10.6), then the and the names correctly match the user's AOR (see Section 10.6), then
implementation SHOULD provide some indication that the certificate the implementation SHOULD provide some indication that the
has been validated with an external authority. In general, failure certificate has been validated with an external authority. In
to validate a certificate via this mechanism SHOULD NOT be used as a general, failure to validate a certificate via this mechanism SHOULD
reason to reject the certificate. However, if the certificate is NOT be used as a reason to reject the certificate. However, if the
revoked, then the implementation SHOULD reject it. certificate is revoked, then the implementation SHOULD reject it.
10.4. SACRED Framework 10.4. SACRED Framework
This specification includes a mechanism that allows end users to This specification includes a mechanism that allows end users to
share the same credentials across different end-user devices. This share the same credentials across different end-user devices. This
mechanism is based on the one presented in the SACRED Framework mechanism is based on the one presented in the Securely Available
[RFC3760]. While this mechanism is fully described in this document, Credentials (SACRED) Framework [RFC3760]. While this mechanism is
the requirements and background are more thoroughly discussed in fully described in this document, the requirements and background are
[RFC3760]. more thoroughly discussed in [RFC3760].
Specifically, Section 7.5, Section 7.6 and Section 7.9 follow the Specifically, Sections 7.5, 7.6, and 7.9 follow the TLS with Client
cTLS architecture described in section 4.2.2 of [RFC3760]. The Authentication (cTLS) architecture described in Section 4.2.2 of
client authenticates the server using the server's TLS certificate. [RFC3760]. The client authenticates the server using the server's
The server authenticates the client using a SIP digest transaction TLS certificate. The server authenticates the client using a SIP
inside the TLS session. The TLS sessions form a strong session key Digest transaction inside the TLS session. The TLS sessions form a
that is used to protect the credentials being exchanged. strong session key that is used to protect 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 [RFC4366]. As specified in [RFC5246], Credential extensions in [RFC4366]. As specified in [RFC5246], credential
Services MUST support the TLS cipher suite services MUST support the TLS cipher suite
TLS_RSA_WITH_AES_128_CBC_SHA. In addition, they MUST support the TLS TLS_RSA_WITH_AES_128_CBC_SHA. In addition, they MUST support the TLS
cipher suite TLS_RSA_WITH_AES_128_CBC_SHA256 as specified in cipher suite TLS_RSA_WITH_AES_128_CBC_SHA256 as specified in
[RFC5246]. If additional cipher suites are supported, then [RFC5246]. If additional cipher suites are supported, then
implementations MUST NOT negotiate a cipher suite that employs NULL implementations MUST NOT negotiate a cipher suite that employs NULL
encryption, integrity, or authentication algorithms. encryption, integrity, or authentication algorithms.
Implementations of TLS typically support multiple versions of the Implementations of TLS typically support multiple versions of the
Transport Layer Security protocol as well as the older Secure Sockets Transport Layer Security protocol as well as the older Secure Socket
Layer (SSL) protocol. Because of known security vulnerabilities, Layer (SSL) protocol. Because of known security vulnerabilities,
clients and servers MUST NOT request, offer, or use SSL 2.0. See clients and servers MUST NOT request, offer, or use SSL 2.0. See
Appendix E.2 of [RFC5246]for further details. Appendix E.2 of [RFC5246] for further details.
The PKCS#8 in the clients MUST implement PBES2 with a key derivation The PKCS #8 encryption in the clients MUST implement PBES2 with a key
algorithm of PBKDF2 using HMAC with SHA-256 [RFC5754] and an derivation algorithm of PBKDF2 using HMAC. Clients MUST implement
encryption algorithm of id-aes128-wrap-pad as defined in [RFC5649]. this HMAC with both SHA-1 [RFC3370] and SHA-256 [RFC5754]. Clients
Some pre-standard deployments of this specification used DES-EDE2- MUST implement an encryption algorithm of id-aes128-wrap-pad as
CBC-Pad as defined in [RFC2898] so, for some implementations, it may defined in [RFC5649]. Some pre-standard deployments of this
be desirable to also support that algorithm. A different passphrase specification used DES-EDE2-CBC-Pad as defined in [RFC2898] so, for
SHOULD be used for the PKCS#8 encryption than is used for some implementations, it may be desirable to also support that
authentication of the client. It is important to choose an algorithm. A different password SHOULD be used for the PKCS #8
sufficiently strong passphrases. Specific advice on the passphrase encryption than is used for authentication of the client. It is
can be found in section 6 of [RFC5958]. important to choose sufficiently strong passwords. Specific advice
on the password can be found in Section 6 of [RFC5959].
10.6. User Certificate Generation 10.6. User Certificate Generation
The certificates need to be consistent with [RFC5280]. The The certificates need to be consistent with [RFC5280]. The
sha1WithRSAEncryption and sha256WithRSAEncryption algorithm for the sha1WithRSAEncryption and sha256WithRSAEncryption algorithms for the
signatureAlgorithm MUST be implemented. The Issuers SHOULD be the signatureAlgorithm MUST be implemented. The Issuers SHOULD be the
same as the subject. Given the ease of issuing new certificates with same as the subject. Given the ease of issuing new certificates with
this system, the Validity can be relatively short. A Validity of one this system, the Validity field can be relatively short. A Validity
year or less is RECOMMENDED. The SubjectAltName must have a URI type value of one year or less is RECOMMENDED. The SubjectAltName must
that is set to the SIP URL corresponding to the user AOR. It MAY be have a URI type that is set to the SIP URL corresponding to the user
desirable to put some randomness into the length of time for which AOR. It MAY be desirable to put some randomness into the length of
the certificates are valid so that it does not become necessary to time for which the certificates are valid so that it does not become
renew all the certificates in the system at the same time. necessary to renew all the certificates in the system at the same
time.
When creating a new key pair for a certificate, it is critical to When creating a new key pair for a certificate, it is critical to
have appropriate randomness as described in [RFC4086]. This can be have appropriate randomness as described in [RFC4086]. This can be
challenging on some embedded devices such as some IP Phones and challenging on some embedded devices, such as some IP phones, and
implementors should pay particular attention to this point. implementers should pay particular attention to this point.
It is worth noting that a UA can discover the current time by looking 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 at the Date header field value in the 200 response to a REGISTER
request. request.
10.7. Private Key Storage 10.7. Private Key Storage
The protection afforded private keys is a critical security factor. The protection afforded private keys is a critical security factor.
On a small scale, failure of devices to protect the private keys will On a small scale, failure of devices to protect the private keys will
permit an attacker to masquerade as the user or decrypt their permit an attacker to masquerade as the user or decrypt their
personal information. As noted in the SACRED Framework, when stored personal information. As noted in the SACRED Framework, when stored
on an end user device, such as a diskette or hard drive, credentials on an end-user device, such as a diskette or hard drive, credentials
SHOULD NOT be in the clear. It is RECOMMENDED that private keys be SHOULD NOT be in the clear. It is RECOMMENDED that private keys be
stored securely in the device, more specifically encrypting them stored securely in the device, more specifically, encrypting them
using tamper-resistant hardware encryption and exposing them only using tamper-resistant hardware encryption and exposing them only
when required: for example, the private key is decrypted when needed when required: for example, the private key is decrypted when
to generate a digital signature, and re-encrypted immediately to necessary to generate a digital signature, and re-encrypted
limit exposure in the RAM for a short period of time. Some immediately to limit exposure in the RAM to a short period of time.
implementations may limit access to private keys by prompting users Some implementations may limit access to private keys by prompting
for a PIN prior to allowing access to the private key. users for a PIN prior to allowing access to the private key.
On the server side, the protection of unencrypted PKCS#8 objects is On the server side, the protection of unencrypted PKCS #8 objects is
equally important. A server failing to protect the private keys equally important. Failure of a server to protect the private keys
would be catastrophic as attackers with access to unencrypted PKCS#8 would be catastrophic, as attackers with access to unencrypted
object could masquerade as any user whose private key was not PKCS #8 objects could masquerade as any user whose private key was
encrypted. Therefore, it is also recommended that the private keys not encrypted. Therefore, it is also recommended that the private
be stored securely in the server, more specifically encrypting them keys be stored securely in the server, more specifically, encrypting
using tamper-resistant hardware encryption and exposing them only them using tamper-resistant hardware encryption and exposing them
when required. only when required.
FIPS 140-2 [FIPS-140-2] provides useful guidance on secure storage. FIPS 140-2 [FIPS-140-2] provides useful guidance on secure storage.
10.8. Compromised Authentication Service 10.8. Compromised Authentication Service
One of this worst attacks against this system would be if the One of the worst attacks against the Certificate Management Service
Authentication Service were compromised. This attack is somewhat described in this document would be if the authentication service
analogous to a certification authority being compromised in were compromised. This attack is somewhat analogous to a
traditional PKI systems. The attacker could make a fake certificate certification authority being compromised in traditional PKI systems.
for which it knows the private key, use it to receive any traffic for The attacker could make a fake certificate for which it knows the
a given use, and then re-encrypt that traffic with the correct key private key, use it to receive any traffic for a given use, and then
and forward the communication to the intended receiver. The attacker re-encrypt that traffic with the correct key and forward the
would thus become a man in the middle in the communications. communication to the intended receiver. The attacker would thus
become a "man in the middle" in the communications.
There is not too much that can be done to protect against this. A UA There is not too much that can be done to protect against this type
MAY subscribe to its own certificate under some other identity to try of attack. A UA MAY subscribe to its own certificate under some
to detect whether the credential server is handing out the correct other identity to try to detect whether the credential server is
certificates. It will be difficult to do this in a way that does not handing out the correct certificates. It will be difficult to do
allow the credential server to recognize the user's UA. this in a way that does not allow the credential server to recognize
the user's UA.
The UA MAY also save the fingerprints of the cached certificates and The UA MAY also save the fingerprints of the cached certificates and
warn users when the certificates change significantly before their warn users when the certificates change significantly before their
expiry date. expiry date.
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 of 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 has added
requested to add the registry at: to the "Session Initiation Protocol (SIP) Event Types Namespace"
http://www.iana.org/assignments/sip-events registry.
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
Published Specification(s): This document Published Specification(s): This document
New Event header parameters: This package defines no New Event header parameters: This package defines no
new parameters new parameters
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>
11.2. Credential Event Package 11.2. Credential 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: credential Package Name: credential
Is this registration for a Template Package: No Is this registration for a template-package: No
Published Specification(s): This document Published Specification(s): This document
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>
11.3. Identity Algorithm 11.3. Identity Algorithm
IANA will add the following entry to the "Identity-Info Algorithm IANA added the following entry to the "Identity-Info Algorithm
Parameter Values" registry. Note to RFC Editor: Please replace Parameter Values" registry.
RFCAAAA with the number for this RFC.
'alg' Parameter Name Reference "alg" Parameter Name Reference
---------------------- --------- ---------------------- ---------
rsa-sha256 [RFCAAAA] rsa-sha256 [RFC6072]
12. Acknowledgments 12. Acknowledgments
Many thanks to Eric Rescorla, Russ Housley, Jim Schaad, Rohan Mahy Many thanks to Eric Rescorla, Russ Housley, Jim Schaad, Rohan Mahy,
and Sean Turner for significant help, discussion, and text. Many and Sean Turner for significant help, discussion, and text. Many
others provided useful comments and text, including Kumiko Ono, Peter others provided useful comments and text, including Kumiko Ono, Peter
Gutmann, Yaron Pdut, Aki Niemi, Magnus Nystrom, Paul Hoffman, Adina Gutmann, Yaron Pdut, Aki Niemi, Magnus Nystrom, Paul Hoffman, Adina
Simu, Dan Wing, Mike Hammer, Pasi Eronen, Alexey Melnikov, Tim Polk, Simu, Dan Wing, Mike Hammer, Pasi Eronen, Alexey Melnikov, Tim Polk,
John Elwell, Jonathan Rosenberg and Lyndsay Campbell. John Elwell, Jonathan Rosenberg, and Lyndsay Campbell.
13. References 13. References
13.1. Normative References 13.1. Normative References
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet
Extensions (MIME) Part Two: Media Types", RFC 2046, Mail Extensions (MIME) Part Two: Media Types",
November 1996. RFC 2046, November 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2585] Housley, R. and P. Hoffman, "Internet X.509 Public Key [RFC2585] Housley, R. and P. Hoffman, "Internet X.509 Public Key
Infrastructure Operational Protocols: FTP and HTTP", Infrastructure Operational Protocols: FTP and HTTP",
RFC 2585, May 1999. RFC 2585, May 1999.
[RFC3204] Zimmerer, E., Peterson, J., Vemuri, A., Ong, L., Audet, [RFC3204] Zimmerer, E., Peterson, J., Vemuri, A., Ong, L., Audet,
F., Watson, M., and M. Zonoun, "MIME media types for ISUP F., Watson, M., and M. Zonoun, "MIME media types for
and QSIG Objects", RFC 3204, December 2001. ISUP and QSIG Objects", RFC 3204, December 2001.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G.,
A., Peterson, J., Sparks, R., Handley, M., and E. Johnston, A., Peterson, J., Sparks, R., Handley, M.,
Schooler, "SIP: Session Initiation Protocol", RFC 3261, and E. Schooler, "SIP: Session Initiation Protocol",
June 2002. RFC 3261, 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.
[RFC3903] Niemi, A., "Session Initiation Protocol (SIP) Extension [RFC3370] Housley, R., "Cryptographic Message Syntax (CMS)
for Event State Publication", RFC 3903, October 2004. Algorithms", RFC 3370, August 2002.
[RFC4474] Peterson, J. and C. Jennings, "Enhancements for [RFC3903] Niemi, A., "Session Initiation Protocol (SIP) Extension
Authenticated Identity Management in the Session for Event State Publication", RFC 3903, October 2004.
Initiation Protocol (SIP)", RFC 4474, August 2006.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC4474] Peterson, J. and C. Jennings, "Enhancements for
(TLS) Protocol Version 1.2", RFC 5246, August 2008. Authenticated Identity Management in the Session
Initiation Protocol (SIP)", RFC 4474, August 2006.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer
Housley, R., and W. Polk, "Internet X.509 Public Key Security (TLS) Protocol Version 1.2", RFC 5246,
Infrastructure Certificate and Certificate Revocation List August 2008.
(CRL) Profile", RFC 5280, May 2008.
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Requirements for Security", BCP 106, RFC 4086, June 2005. Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation
List (CRL) Profile", RFC 5280, May 2008.
[RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness
and T. Wright, "Transport Layer Security (TLS) Requirements for Security", BCP 106, RFC 4086,
Extensions", RFC 4366, April 2006. June 2005.
[RFC5754] Turner, S., "Using SHA2 Algorithms with Cryptographic [RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen,
Message Syntax", RFC 5754, January 2010. J., and T. Wright, "Transport Layer Security (TLS)
Extensions", RFC 4366, April 2006.
[RFC5649] Housley, R. and M. Dworkin, "Advanced Encryption Standard [RFC5754] Turner, S., "Using SHA2 Algorithms with Cryptographic
(AES) Key Wrap with Padding Algorithm", RFC 5649, Message Syntax", RFC 5754, January 2010.
September 2009.
[RFC5958] Turner, S., "Asymmetric Key Packages", RFC 5958, [RFC5649] Housley, R. and M. Dworkin, "Advanced Encryption
August 2010. Standard (AES) Key Wrap with Padding Algorithm",
RFC 5649, September 2009.
13.2. Informational References [RFC5958] Turner, S., "Asymmetric Key Packages", RFC 5958,
August 2010.
[RFC2898] Kaliski, B., "PKCS #5: Password-Based Cryptography [RFC5959] Turner, S., "Algorithms for Asymmetric Key Package
Specification Version 2.0", RFC 2898, September 2000. Content Type", RFC 5959, August 2010.
[RFC3760] Gustafson, D., Just, M., and M. Nystrom, "Securely 13.2. Informative References
Available Credentials (SACRED) - Credential Server
Framework", RFC 3760, April 2004.
[RFC3851] Ramsdell, B., "Secure/Multipurpose Internet Mail [RFC2898] Kaliski, B., "PKCS #5: Password-Based Cryptography
Extensions (S/MIME) Version 3.1 Message Specification", Specification Version 2.0", RFC 2898, September 2000.
RFC 3851, July 2004.
[RFC3853] Peterson, J., "S/MIME Advanced Encryption Standard (AES) [RFC3760] Gustafson, D., Just, M., and M. Nystrom, "Securely
Requirement for the Session Initiation Protocol (SIP)", Available Credentials (SACRED) - Credential Server
RFC 3853, July 2004. Framework", RFC 3760, April 2004.
[RFC4662] Roach, A., Campbell, B., and J. Rosenberg, "A Session [RFC3853] Peterson, J., "S/MIME Advanced Encryption Standard
Initiation Protocol (SIP) Event Notification Extension for (AES) Requirement for the Session Initiation Protocol
Resource Lists", RFC 4662, August 2006. (SIP)", RFC 3853, July 2004.
[FIPS-140-2] [RFC4662] Roach, A., Campbell, B., and J. Rosenberg, "A Session
NIST, "Security Requirements for Cryptographic Modules", Initiation Protocol (SIP) Event Notification Extension
June 2005, <http://csrc.nist.gov/publications/fips/ for Resource Lists", RFC 4662, August 2006.
fips140-2/fips1402.pdf>.
[RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose
Internet Mail Extensions (S/MIME) Version 3.2 Message
Specification", RFC 5751, January 2010.
[FIPS-140-2] NIST, "Security Requirements for Cryptographic
Modules", May 2001, <http://csrc.nist.gov/publications/
fips/fips140-2/fips1402.pdf>.
Authors' Addresses Authors' Addresses
Cullen Jennings Cullen Jennings
Cisco Systems Cisco Systems
170 West Tasman Drive 170 West Tasman Drive
San Jose, CA 95134 San Jose, CA 95134
USA USA
Phone: +1 408 421-9990 Phone: +1 408 421-9990
Email: fluffy@cisco.com EMail: fluffy@cisco.com
Jason Fischl (editor) Jason Fischl (editor)
Skype Skype
2145 Hamilton Ave. 3210 Porter Drive
San Jose, CA 95125 Palo Alto, CA 94304
USA USA
Phone: +1-415-202-5192 Phone: +1-415-202-5192
Email: jason.fischl@skype.net EMail: jason.fischl@skype.net
 End of changes. 164 change blocks. 
443 lines changed or deleted 477 lines changed or added

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