draft-ietf-sip-certs-12.txt   draft-ietf-sip-certs-13.txt 
Network Working Group C. Jennings Network Working Group C. Jennings
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Intended status: Standards Track J. Fischl, Ed. Intended status: Standards Track J. Fischl, Ed.
Expires: September 23, 2010 Skype Expires: December 19, 2010 Skype
March 22, 2010 June 17, 2010
Certificate Management Service for The Session Initiation Protocol (SIP) Certificate Management Service for The Session Initiation Protocol (SIP)
draft-ietf-sip-certs-12 draft-ietf-sip-certs-13
Abstract Abstract
This draft defines a Credential Service that allows Session This draft defines a Credential Service that allows Session
Initiation Protocol (SIP) User Agents (UAs) to use a SIP event Initiation Protocol (SIP) User Agents (UAs) to use a SIP event
package to discover the certificates of other users. This mechanism package to discover the certificates of other users. This mechanism
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 to IETF in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF). Note that other groups may also distribute
other groups may also distribute working documents as Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at This Internet-Draft will expire on December 19, 2010.
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 23, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents 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
described in the BSD License. described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this 10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow material may not have granted the IETF Trust the right to allow
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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. UA Behavior with Certificates . . . . . . . . . . . . . . . . 8 4. UA Behavior with Certificates . . . . . . . . . . . . . . . . 9
5. UA Behavior with Credentials . . . . . . . . . . . . . . . . . 9 5. UA Behavior with Credentials . . . . . . . . . . . . . . . . . 10
6. Event Package Formal Definition for "certificate" . . . . . . 10 6. Event Package Formal Definition for "certificate" . . . . . . 11
6.1. Event Package Name . . . . . . . . . . . . . . . . . . . . 10 6.1. Event Package Name . . . . . . . . . . . . . . . . . . . . 11
6.2. SUBSCRIBE Bodies . . . . . . . . . . . . . . . . . . . . . 10 6.2. SUBSCRIBE Bodies . . . . . . . . . . . . . . . . . . . . . 11
6.3. Subscription Duration . . . . . . . . . . . . . . . . . . 10 6.3. Subscription Duration . . . . . . . . . . . . . . . . . . 11
6.4. NOTIFY Bodies . . . . . . . . . . . . . . . . . . . . . . 10 6.4. NOTIFY Bodies . . . . . . . . . . . . . . . . . . . . . . 11
6.5. Subscriber Generation of SUBSCRIBE Requests . . . . . . . 11 6.5. Subscriber Generation of SUBSCRIBE Requests . . . . . . . 12
6.6. Notifier Processing of SUBSCRIBE Requests . . . . . . . . 11 6.6. Notifier Processing of SUBSCRIBE Requests . . . . . . . . 12
6.7. Notifier Generation of NOTIFY Requests . . . . . . . . . . 11 6.7. Notifier Generation of NOTIFY Requests . . . . . . . . . . 12
6.8. Subscriber Processing of NOTIFY Requests . . . . . . . . . 12 6.8. Subscriber Processing of NOTIFY Requests . . . . . . . . . 13
6.9. Handling of Forked Requests . . . . . . . . . . . . . . . 12 6.9. Handling of Forked Requests . . . . . . . . . . . . . . . 13
6.10. Rate of Notifications . . . . . . . . . . . . . . . . . . 12 6.10. Rate of Notifications . . . . . . . . . . . . . . . . . . 13
6.11. State Agents and Lists . . . . . . . . . . . . . . . . . . 12 6.11. State Agents and Lists . . . . . . . . . . . . . . . . . . 13
6.12. Behavior of a Proxy Server . . . . . . . . . . . . . . . . 12 6.12. Behavior of a Proxy Server . . . . . . . . . . . . . . . . 13
7. Event Package Formal Definition for "credential" . . . . . . . 13 7. Event Package Formal Definition for "credential" . . . . . . . 14
7.1. Event Package Name . . . . . . . . . . . . . . . . . . . . 13 7.1. Event Package Name . . . . . . . . . . . . . . . . . . . . 14
7.2. SUBSCRIBE Bodies . . . . . . . . . . . . . . . . . . . . . 13 7.2. SUBSCRIBE Bodies . . . . . . . . . . . . . . . . . . . . . 14
7.3. Subscription Duration . . . . . . . . . . . . . . . . . . 13 7.3. Subscription Duration . . . . . . . . . . . . . . . . . . 14
7.4. NOTIFY Bodies . . . . . . . . . . . . . . . . . . . . . . 13 7.4. NOTIFY Bodies . . . . . . . . . . . . . . . . . . . . . . 14
7.5. Subscriber Generation of SUBSCRIBE Requests . . . . . . . 14 7.5. Subscriber Generation of SUBSCRIBE Requests . . . . . . . 15
7.6. Notifier Processing of SUBSCRIBE Requests . . . . . . . . 14 7.6. Notifier Processing of SUBSCRIBE Requests . . . . . . . . 15
7.7. Notifier Generation of NOTIFY Requests . . . . . . . . . . 14 7.7. Notifier Generation of NOTIFY Requests . . . . . . . . . . 15
7.8. Generation of PUBLISH Requests . . . . . . . . . . . . . . 15 7.8. Generation of PUBLISH Requests . . . . . . . . . . . . . . 16
7.9. Notifier Processing of PUBLISH Requests . . . . . . . . . 15 7.9. Notifier Processing of PUBLISH Requests . . . . . . . . . 16
7.10. Subscriber Processing of NOTIFY Requests . . . . . . . . . 16 7.10. Subscriber Processing of NOTIFY Requests . . . . . . . . . 17
7.11. Handling of Forked Requests . . . . . . . . . . . . . . . 16 7.11. Handling of Forked Requests . . . . . . . . . . . . . . . 17
7.12. Rate of Notifications . . . . . . . . . . . . . . . . . . 16 7.12. Rate of Notifications . . . . . . . . . . . . . . . . . . 17
7.13. State Agents and Lists . . . . . . . . . . . . . . . . . . 16 7.13. State Agents and Lists . . . . . . . . . . . . . . . . . . 17
7.14. Behavior of a Proxy Server . . . . . . . . . . . . . . . . 17 7.14. Behavior of a Proxy Server . . . . . . . . . . . . . . . . 18
8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 8. Identity Signatures . . . . . . . . . . . . . . . . . . . . . 18
8.1. Encrypted Page Mode IM Message . . . . . . . . . . . . . . 17 9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
8.2. Setting and Retrieving UA Credentials . . . . . . . . . . 18 9.1. Encrypted Page Mode IM Message . . . . . . . . . . . . . . 18
9. Security Considerations . . . . . . . . . . . . . . . . . . . 18 9.2. Setting and Retrieving UA Credentials . . . . . . . . . . 19
9.1. Certificate Revocation . . . . . . . . . . . . . . . . . . 21 10. Security Considerations . . . . . . . . . . . . . . . . . . . 20
9.2. Certificate Replacement . . . . . . . . . . . . . . . . . 21 10.1. Certificate Revocation . . . . . . . . . . . . . . . . . . 23
9.3. Trusting the Identity of a Certificate . . . . . . . . . . 22 10.2. Certificate Replacement . . . . . . . . . . . . . . . . . 23
9.3.1. Extra Assurance . . . . . . . . . . . . . . . . . . . 23 10.3. Trusting the Identity of a Certificate . . . . . . . . . . 23
9.4. SACRED Framework . . . . . . . . . . . . . . . . . . . . . 23 10.3.1. Extra Assurance . . . . . . . . . . . . . . . . . . . 24
9.5. Crypto Profiles . . . . . . . . . . . . . . . . . . . . . 23 10.4. SACRED Framework . . . . . . . . . . . . . . . . . . . . . 25
9.6. User Certificate Generation . . . . . . . . . . . . . . . 24 10.5. Crypto Profiles . . . . . . . . . . . . . . . . . . . . . 25
9.7. Compromised Authentication Service . . . . . . . . . . . . 24 10.6. User Certificate Generation . . . . . . . . . . . . . . . 26
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 10.7. Compromised Authentication Service . . . . . . . . . . . . 26
10.1. Certificate Event Package . . . . . . . . . . . . . . . . 25
10.2. Credential Event Package . . . . . . . . . . . . . . . . . 25 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25 11.1. Certificate Event Package . . . . . . . . . . . . . . . . 27
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 11.2. Credential Event Package . . . . . . . . . . . . . . . . . 27
12.1. Normative References . . . . . . . . . . . . . . . . . . . 26 11.3. Identity Algorithm . . . . . . . . . . . . . . . . . . . . 27
12.2. Informational References . . . . . . . . . . . . . . . . . 27 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28
13.1. Normative References . . . . . . . . . . . . . . . . . . . 28
13.2. Informational References . . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 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 S/MIME [RFC3851]. Several
security properties of [RFC3261] depend on S/MIME, and yet it has not security properties of [RFC3261] depend on S/MIME, and yet it has not
been widely deployed. One reason is the complexity of providing a been widely deployed. One reason is the complexity of providing a
reasonable certificate distribution infrastructure. This reasonable certificate distribution infrastructure. This
specification proposes a way to address discovery, retrieval, and specification proposes a way to address discovery, retrieval, and
management of certificates for SIP deployments. Combined with the management of certificates for SIP deployments. Combined with the
skipping to change at page 5, line 38 skipping to change at page 5, line 38
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
Certificate: A PKIX [RFC5280] style certificate containing a public Certificate: A PKIX [RFC5280] style certificate containing a public
key and a list of identities in the SubjectAltName that are bound key and a list of identities in the SubjectAltName that are bound
to this key. The certificates discussed in this draft are to this key. The certificates discussed in this draft are
generally self signed and use the mechanisms in the SIP Identity generally self signed and use the mechanisms in the SIP Identity
[RFC4474] specification to vouch for their validity. Certificates [RFC4474] specification to vouch for their validity. Certificates
that are signed by a certificate authority can also be used with that are signed by a certificate authority can also be used with
all the mechanisms in this draft, however, they need not be all the mechanisms in this draft, however, they need not be
validated by the receiver (although the receiver can validate them validated by the receiver (although the receiver can validate them
for extra assurance; see Section 9.3.1). for extra assurance; see Section 10.3.1).
Credential: For this document, credential means the combination of a Credential: For this document, credential means the combination of a
certificate and the associated private key. certificate and the associated private key.
Password Phrase: A password used to encrypt a PKCS#8 private key. Password Phrase: A password used to encrypt a PKCS#8 private key.
3. Overview 3. Overview
The general approach is to provide a new SIP service referred to as a The general approach is to provide a new SIP service referred to as a
"credential service" that allows SIP User Agents (UAs) to subscribe "credential service" that allows SIP User Agents (UAs) to subscribe
to other users' certificates using a new SIP event package [RFC3265]. to other users' certificates using a new SIP event package [RFC3265].
The certificate is delivered to the subscribing UA in a corresponding The certificate is delivered to the subscribing UA in a corresponding
skipping to change at page 10, line 49 skipping to change at page 10, line 49
does this by waiting a random amount of time between 0 and 300 does this by waiting a random amount of time between 0 and 300
seconds. If no new credentials have been received in that time, seconds. If no new credentials have been received in that time,
the UA creates new credentials to replace the expiring ones and the UA creates new credentials to replace the expiring ones and
sends them in a PUBLISH request following the rules for modifying sends them in a PUBLISH request following the rules for modifying
event state from Section 4.4 of [RFC3903]. event state from 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 Credentials are created by creating a new key pair which will require
appropriate randomness, [RFC4086] and then creating a certificate as appropriate randomness, [RFC4086] and then creating a certificate as
described in Section 9.6. The UA MAY encrypt the private key with a described in Section 10.6. The UA MAY encrypt the private key with a
password phrase supplied by the user. Next, the UA updates the password phrase supplied by the user. Next, the UA updates the
user's credential by sending a PUBLISH [RFC3903] request with the user's credential by sending a PUBLISH [RFC3903] request with the
credentials or just the certificate as described in Section 7.8. 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"
skipping to change at page 13, line 9 skipping to change at page 13, line 9
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 9.3 to decide if the received certificate can procedures in Section 10.3 to decide if the received certificate can
be used. The UA needs to cache this certificate for future use. The be used. The UA needs to cache this certificate for future use. The
maximum length of time it should be cached for is discussed in maximum length of time it should be cached for is discussed in
Section 9.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
skipping to change at page 17, line 14 skipping to change at page 17, line 14
o The notBefore validity time MUST NOT be in the future. o The notBefore validity time MUST NOT be in the future.
o The notAfter validity time MUST be in the future. o The notAfter validity time MUST be in the future.
o If a CA Basic Constraint is set in the certificate, it is set to o If a CA Basic Constraint is set in the certificate, it is set to
false. false.
If all of these succeed, the credential service updates the If all of these succeed, the credential service updates the
credential for this URI, processes all the active certificates and credential for this URI, processes all the active certificates and
credential subscriptions to this URI, and generates a NOTIFY request credential subscriptions to this URI, and generates a NOTIFY request
with the new credential or certificate. 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 could
be used and offers no additional security guarentees. 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 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
skipping to change at page 18, line 10 skipping to change at page 18, line 10
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 described in Section 6.12.
8. Examples 8. Identity Signatures
The [RFC4474] Authentication service defined an signature algorithm
based on SHA1 called rsa-sha1. This specification adds an signature
algorithm that is roughly the same but based on SHA256 and called
rsa-sha256.
When using the rsa-sha256 algorithm, the signature MUST be computed
in exactly the same way as described in section 9 of [RFC4474] with
the exception that instead of using sha1WithRSAEncryption, the
computation is done using sha256WithRSAEncryption as described in
[RFC5754].
Implementations of this specification MUST implement both rsa-sha1
and rsa-sha256. The IANA registration for rsa-sha256 is defined in
Section 11.3.
9. Examples
In all these examples, large parts of the messages are omitted to In all these examples, large parts of the messages are omitted to
highlight what is relevant to this draft. The lines in the examples highlight what is relevant to this draft. The lines in the examples
that are prefixed by $ represent encrypted blocks of data. that are prefixed by $ represent encrypted blocks of data.
8.1. Encrypted Page Mode IM Message 9.1. Encrypted Page Mode IM Message
In this example, Alice sends Bob an encrypted page mode instant In this example, Alice sends Bob an encrypted page mode instant
message. Alice does not already have Bob's public key from previous message. Alice does not already have Bob's public key from previous
communications, so she fetches Bob's public key from Bob's credential communications, so she fetches Bob's public key from Bob's credential
service: service:
SUBSCRIBE sip:bob@biloxi.example.com SIP/2.0 SUBSCRIBE sip:bob@biloxi.example.com SIP/2.0
... ...
Event: certificate Event: certificate
The credential service responds with the certificate in a NOTIFY. The credential service responds with the certificate in a NOTIFY.
NOTIFY alice@atlanta.example.com SIP/2.0 NOTIFY alice@atlanta.example.com SIP/2.0
Subscription-State: active; expires=7200 Subscription-State: active; expires=7200
.... ....
From: <sip:bob@biloxi.example.com>;tag=1234 From: <sip:bob@biloxi.example.com>;tag=1234
Identity: "NJguAbpmYXjnlxFmlOkumMI+MZXjB2iV/NW5xsFQqzD/p4yiovrJBqhd3T Identity: ".... stuff removed ...."
ZkegnsmoHryzk9gTBH7Gj/erixEFIf82o3Anmb+CIbrgdl03gGaD6ICvkp Identity-Info: <https://atlanta.example.com/cert>;alg=rsa-sha256
VqoMXZZjdvSpycyHOhh1cmUx3b9Vr3pZuEh+cB01pbMQ8B1ch++iMjw="
Identity-Info: <https://atlanta.example.com/cert>;alg=rsa-sha1
.... ....
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 message to Bob and can encrypt the Next, Alice sends a SIP MESSAGE message to Bob and can encrypt the
body using Bob's public key as shown below. 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" >
8.2. Setting and Retrieving UA Credentials 9.2. Setting and Retrieving UA Credentials
When Alice's UA wishes to publish Alice's public and private keys to When Alice's UA wishes to publish Alice's public and private keys to
the credential service, it sends a PUBLISH request like the one 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 digest
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
skipping to change at page 19, line 46 skipping to change at page 20, line 27
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 UA will
be digest challenged, and the NOTIFY will include a body similar to be digest challenged, and the NOTIFY will include a body similar to
the one in the PUBLISH section above. the one in the PUBLISH section above.
9. 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
skipping to change at page 22, line 16 skipping to change at page 23, line 11
certificate to lose confidential information. Failing to use TLS or certificate to lose confidential information. Failing to use TLS or
selecting a poor cipher suite (such as NULL encryption) may result in selecting a poor cipher suite (such as NULL encryption) may result in
credentials, including private keys, being sent unencrypted over the credentials, including private keys, being sent unencrypted over the
network and will render the whole system useless. 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.
9.1. Certificate Revocation 10.1. Certificate Revocation
If a particular credential needs to be revoked, the new credential is If a particular credential needs to be revoked, the new credential is
simply published to the credential service. Every device with a copy simply published to the credential service. Every device with a copy
of the old credential or certificate in its cache will have a of the old credential or certificate in its cache will have a
subscription and will rapidly (order of seconds) be notified and subscription and will rapidly (order of seconds) be notified and
replace its cache. Clients that are not subscribed will subscribe replace its cache. Clients that are not subscribed will subscribe
when they next need to use the certificate and will get the new when they next need to use the certificate and will get the new
certificate. certificate.
It is possible that an attacker could mount a DOS attack such that It is possible that an attacker could mount a DOS attack such that
skipping to change at page 22, line 45 skipping to change at page 23, line 40
applications, a default time of 1 day is suggested, but for some applications, a default time of 1 day is suggested, but for some
applications it may be desirable to set the time to zero so that no applications it may be desirable to set the time to zero so that no
certificates are cached at all and the credential is checked for certificates are cached at all and the credential is checked for
validity every time the certificate is used. 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.
9.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.
9.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 CA, and one of the names in If the certificate is signed by a trusted CA, and one of the names in
the SubjectAltName matches the original URI, then this certificate the SubjectAltName matches the original URI, then this certificate
skipping to change at page 24, line 5 skipping to change at page 24, line 46
with. The certificate in the body contains the public key for the with. The certificate in the body contains the public key for the
identity. Only the UA that can authenticate as this AOR, or devices identity. Only the UA that can authenticate as this AOR, or devices
with access to the private key of the domain, can tamper with this with access to the private key of the domain, can tamper with this
body. This stops other users from being able to provide a false body. This stops other users from being able to provide a false
public key. This chain of assertion from original URI, to From, to public key. This chain of assertion from original URI, to From, to
body, to public key is critical to the security of the mechanism body, to public key is critical to the security of the mechanism
described in this specification. If any of the steps above are not described in this specification. If any of the steps above are not
followed, this chain of security will be broken and the system will followed, this chain of security will be broken and the system will
not work. not work.
9.3.1. Extra Assurance 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 which 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) certificate authority user verification and key issuance isolated) certificate 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 which is not self-signed,
it MAY attempt to validate it using the rules in Section 6 of it MAY attempt to validate it using the rules in Section 6 of
[RFC5280]. If the certificate validates successfully and the names [RFC5280]. If the certificate validates successfully and the names
correctly match the user's AOR (see Section 9.6), then the correctly match the user's AOR (see Section 10.6), then the
implementation SHOULD provide some indication that the certificate implementation SHOULD provide some indication that the certificate
has been validated with an external authority. In general, failure has been validated with an external authority. In general, failure
to validate a certificate via this mechanism SHOULD not be used as a to validate a certificate via this mechanism SHOULD NOT be used as a
reason to reject the certificate. However, if the certificate is reason to reject the certificate. However, if the certificate is
revoked, then the implementation SHOULD reject it. revoked, then the implementation SHOULD reject it.
9.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 SACRED Framework
[RFC3760]. While this mechanism is fully described in this document, [RFC3760]. While this mechanism is fully described in this document,
the requirements and background are more thoroughly discussed in the requirements and background are more thoroughly discussed in
[RFC3760]. [RFC3760].
Specifically, Section 7.5, Section 7.6 and Section 7.9 follow the Specifically, Section 7.5, Section 7.6 and Section 7.9 follow the
cTLS architecture described in section 4.2.2 of [RFC3760]. The cTLS architecture described in section 4.2.2 of [RFC3760]. The
client authenticates the server using the server's TLS certificate. client authenticates the server using the server's TLS certificate.
The server authenticates the client using a SIP digest transaction The server authenticates the client using a SIP digest transaction
inside the TLS session. The TLS sessions form a strong session key inside the TLS session. The TLS sessions form a strong session key
that is used to protect the credentials being exchanged. that is used to protect the credentials being exchanged.
9.5. Crypto Profiles 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. 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
[RFC5246].
The PKCS#8 in the clients MUST implement PBES2 with a key derivation The PKCS#8 in the clients MUST implement PBES2 with a key derivation
algorithm of PBKDF2 using HMAC with SHA-256 [RFC5754] and an algorithm of PBKDF2 using HMAC with SHA-256 [RFC5754] and an
encryption algorithm of DES-EDE2-CBC-Pad as defined in [RFC2898]. It encryption algorithm of id-aes128-wrap-pad as defined in [RFC5649].
is RECOMMENDED that this profile be used when using PKCS#8. A Some per-standard deployments of this specification used DES-EDE2-
different passphrase SHOULD be used for the PKCS#8 encryption than is CBC-Pad as defined in [RFC2898] so, for some implementations, it may
used for server authentication. be desirable to also support that algorithm. A different passphrase
SHOULD be used for the PKCS#8 encryption than is used for server
authentication.
9.6. User Certificate Generation 10.6. User Certificate Generation
The certificates should be consistent with [RFC5280]. A The certificates should be consistent with [RFC5280]. The
signatureAlgorithm of sha1WithRSAEncryption MUST be implemented. The sha1WithRSAEncryption and sha256WithRSAEncryption algorithm for the
Issuers SHOULD be the same as the subject. Given the ease of issuing signatureAlgorithm MUST be implemented. The Issuers SHOULD be the
new certificates with this system, the Validity can be relatively same as the subject. Given the ease of issuing new certificates with
short. A Validity of one year or less is RECOMMENDED. The this system, the Validity can be relatively short. A Validity of one
subjectAltName must have a URI type that is set to the SIP URL year or less is RECOMMENDED. The subjectAltName must have a URI type
corresponding to the user AOR. It MAY be desirable to put some that is set to the SIP URL corresponding to the user AOR. It MAY be
randomness into the length of time for which the certificates are desirable to put some randomness into the length of time for which
valid so that it does not become necessary to renew all the the certificates are valid so that it does not become necessary to
certificates in the system at the same time. renew all the certificates in the system at the same time.
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.
9.7. Compromised Authentication Service 10.7. Compromised Authentication Service
One of this worst attacks against this system would be if the One of this worst attacks against this system would be if the
Authentication Service were compromised. This attack is somewhat Authentication Service were compromised. This attack is somewhat
analogous to a CA being compromised in traditional PKI systems. The analogous to a CA being compromised in traditional PKI systems. The
attacker could make a fake certificate for which it knows the private attacker could make a fake certificate for which it knows the private
key, use it to receive any traffic for a given use, and then re- key, use it to receive any traffic for a given use, and then re-
encrypt that traffic with the correct key and forward the encrypt that traffic with the correct key and forward the
communication to the intended receiver. The attacker would thus communication to the intended receiver. The attacker would thus
become a man in the middle in the communications. become a man in the middle in the communications.
skipping to change at page 26, line 5 skipping to change at page 26, line 47
allow the credential server to recognize the user's UA. allow the credential server to recognize the user's UA.
The UA MAY also save the fingerprints of the cached certificates and The UA MAY also save the fingerprints of the cached certificates and
warn users when the certificates change 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 for the cached
certificates so that they can be verified by some other out of band certificates so that they can be verified by some other out of band
means. means.
10. IANA Considerations 11. IANA Considerations
This specification defines two new event packages that IANA is This specification defines two new event packages that IANA is
requested to add the registry at: requested to add the registry at:
http://www.iana.org/assignments/sip-events http://www.iana.org/assignments/sip-events
10.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>
10.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. Acknowledgments 11.3. Identity Algorithm
Many thanks to Eric Rescorla, Jim Schaad, Rohan Mahy for significant IANA will add the following entry to the "Identity-Info Algorithm
help and discussion. Many others provided useful comments, including Parameter Values" registry. Note to RFC Editor: Please replace
Kumiko Ono, Peter Gutmann, Russ Housley, Yaron Pdut, Aki Niemi, RFCAAAA with the number for this RFC.
'alg' Parameter Name Reference
---------------------- ---------
rsa-sha256 [RFCAAA]
12. Acknowledgments
Many thanks to Eric Rescorla, Russ Housley, Jim Schaad, Rohan Mahy
for significant help and discussion. Many others provided useful
comments, including Kumiko Ono, Peter Gutmann, Yaron Pdut, Aki Niemi,
Magnus Nystrom, Paul Hoffman, Adina Simu, Dan Wing, Mike Hammer, Pasi Magnus Nystrom, Paul Hoffman, Adina Simu, Dan Wing, Mike Hammer, Pasi
Eronen, Alexey Melnikov, Tim Polk and Lyndsay Campbell. Rohan Mahy, Eronen, Alexey Melnikov, Tim Polk and Lyndsay Campbell. Rohan Mahy,
John Elwell, and Jonathan Rosenberg provided detailed review and John Elwell, and Jonathan Rosenberg provided detailed review and
text. text.
12. References 13. References
12.1. Normative References 13.1. Normative References
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types", RFC 2046, Extensions (MIME) Part Two: Media Types", RFC 2046,
November 1996. 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.
[RFC2898] Kaliski, B., "PKCS #5: Password-Based Cryptography
Specification Version 2.0", RFC 2898, September 2000.
[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 ISUP
and QSIG Objects", RFC 3204, December 2001. and QSIG Objects", RFC 3204, December 2001.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002. June 2002.
[RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific [RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific
skipping to change at page 28, line 15 skipping to change at page 29, line 20
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness
Requirements for Security", BCP 106, RFC 4086, June 2005. Requirements for Security", BCP 106, RFC 4086, June 2005.
[RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., [RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,
and T. Wright, "Transport Layer Security (TLS) and T. Wright, "Transport Layer Security (TLS)
Extensions", RFC 4366, April 2006. Extensions", RFC 4366, April 2006.
[RFC5754] Turner, S., "Using SHA2 Algorithms with Cryptographic [RFC5754] Turner, S., "Using SHA2 Algorithms with Cryptographic
Message Syntax", RFC 5754, January 2010. Message Syntax", RFC 5754, January 2010.
[RFC5649] Housley, R. and M. Dworkin, "Advanced Encryption Standard
(AES) Key Wrap with Padding Algorithm", RFC 5649,
September 2009.
[I-D.turner-asymmetrickeyformat] [I-D.turner-asymmetrickeyformat]
Turner, S., "Asymmetric Key Packages", Turner, S., "Asymmetric Key Packages",
draft-turner-asymmetrickeyformat-04 (work in progress), draft-turner-asymmetrickeyformat-05 (work in progress),
March 2010. April 2010.
12.2. Informational References 13.2. Informational References
[RFC2898] Kaliski, B., "PKCS #5: Password-Based Cryptography
Specification Version 2.0", RFC 2898, September 2000.
[RFC3760] Gustafson, D., Just, M., and M. Nystrom, "Securely [RFC3760] Gustafson, D., Just, M., and M. Nystrom, "Securely
Available Credentials (SACRED) - Credential Server Available Credentials (SACRED) - Credential Server
Framework", RFC 3760, April 2004. Framework", RFC 3760, April 2004.
[RFC3851] Ramsdell, B., "Secure/Multipurpose Internet Mail [RFC3851] Ramsdell, B., "Secure/Multipurpose Internet Mail
Extensions (S/MIME) Version 3.1 Message Specification", Extensions (S/MIME) Version 3.1 Message Specification",
RFC 3851, July 2004. RFC 3851, July 2004.
[RFC3853] Peterson, J., "S/MIME Advanced Encryption Standard (AES) [RFC3853] Peterson, J., "S/MIME Advanced Encryption Standard (AES)
 End of changes. 42 change blocks. 
121 lines changed or deleted 152 lines changed or added

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