draft-ietf-sip-certs-01.txt   draft-ietf-sip-certs-02.txt 
Network Working Group C. Jennings Network Working Group C. Jennings
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Expires: December 27, 2006 J. Peterson Expires: April 25, 2007 J. Peterson
NeuStar, Inc. NeuStar, Inc.
J. Fischl, Ed. J. Fischl, Ed.
CounterPath Solutions, Inc. CounterPath Solutions, Inc.
June 25, 2006 October 22, 2006
Certificate Management Service for The Session Initiation Protocol (SIP) Certificate Management Service for The Session Initiation Protocol (SIP)
draft-ietf-sip-certs-01 draft-ietf-sip-certs-02
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 37 skipping to change at page 1, line 37
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 27, 2006. This Internet-Draft will expire on April 25, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Society (2006).
Abstract Abstract
This draft defines a Credential Service that allows Session This draft defines a Credential Service that allows Session
Initiation Protocol (SIP) User Agents (UAs) to use a SIP package to Initiation Protocol (SIP) User Agents (UAs) to use a SIP package to
discover the certificates of other users. This mechanism allows user discover the certificates of other users. This mechanism allows user
skipping to change at page 4, line 18 skipping to change at page 4, line 18
integrity using S/MIME [17]. Several security properties of SIP integrity using S/MIME [17]. Several security properties of SIP
depend on S/MIME, and yet it has not been widely deployed. One depend on S/MIME, and yet it has not been widely deployed. One
reason is the complexity of providing a reasonable certificate reason is the complexity of providing a reasonable certificate
distribution infrastructure. This specification proposes a way to distribution infrastructure. This specification proposes a way to
address discovery, retrieval, and management of certificates for SIP address discovery, retrieval, and management of certificates for SIP
deployments. Combined with the SIP Identity [2] specification, this deployments. Combined with the SIP Identity [2] specification, this
specification allows users to have certificates that are not signed specification allows users to have certificates that are not signed
by any well known certificate authority while still strongly binding by any well known certificate authority while still strongly binding
the user's identity to the certificate. the user's identity to the certificate.
In addition, this specification provides a which mechanism allows SIP In addition, this specification provides a mechanism that allows SIP
User Agents such as IP phones to enroll and get their credentials User Agents such as IP phones to enroll and get their credentials
without any more configuration information than they commonly have without any more configuration information than they commonly have
today. The end user expends no extra effort. It follows the Sacred today. The end user expends no extra effort. It follows the Sacred
Framework RFC 3760 [7] for management of the credentials. Framework RFC 3760 [7] for management of the credentials.
2. Definitions 2. Definitions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [5]. document are to be interpreted as described in RFC 2119 [5].
skipping to change at page 7, line 15 skipping to change at page 7, line 15
The private key portion of the credential may have been encrypted The private key portion of the credential may have been encrypted
with a secret that only Bob's UA (and not the credential server) with a secret that only Bob's UA (and not the credential server)
knows. In this case, once Bob's UA decrypts the private key it will knows. In this case, once Bob's UA decrypts the private key it will
be ready to go. Typically Bob's UA would do this when it first be ready to go. Typically Bob's UA would do this when it first
registered on the network. registered on the network.
Some time later Alice decides that she wishes to discover Bob's Some time later Alice decides that she wishes to discover Bob's
certificate so that she can send him an encrypted message or so that certificate so that she can send him an encrypted message or so that
she can verify the signature on a message from Bob. Alice's UA sends she can verify the signature on a message from Bob. Alice's UA sends
a SUBSCRIBE message to Bob's AOR. The proxy in Bob's domain routes a SUBSCRIBE message to Bob's AOR. The proxy in Bob's domain routes
this to the credential server via an authorization service. The this to the credential server via an "authentication service" as
credential server returns a NOTIFY that contains Bob's public defined in [2]. The credential server returns a NOTIFY that contains
certificate in the body. This is routed through an authentication Bob's public certificate in the body. This is routed through an
service that signs that this message really can validly claim to be authentication service that signs that this message really can
from the AOR "sip:bob@example.com". Alice's UA receives the validly claim to be from the AOR "sip:bob@example.com". Alice's UA
certificate and can use it to encrypt a message to Bob. receives the certificate and can use it to encrypt a message to Bob.
It is critical to understand that the only way that Alice can trust It is critical to understand that the only way that Alice can trust
that the certificate really is the one for Bob and that the NOTIFY that the certificate really is the one for Bob and that the NOTIFY
has not been spoofed is for Alice to check that the Identity [2] has not been spoofed is for Alice to check that the Identity [2]
header field value is correct. header field value is correct.
The mechanism described in this document works for both self signed The mechanism described in this document works for both self signed
certificates and certificates signed by well known certificate certificates and certificates signed by well known certificate
authorities. However, most UAs would only use self signed authorities. However, most UAs would only use self signed
certificates and would use an Authentication Service as described in certificates and would use an Authentication Service as described in
skipping to change at page 9, line 12 skipping to change at page 9, line 12
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 UAS receives a request that is encrypted to Bob, it would
be valid and legal for that UA to send a 302 redirecting the call to be valid and legal for that UA to send a 302 redirecting the call to
Charlie. 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.6. as described in Section 6.6.
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
skipping to change at page 10, line 43 skipping to change at page 10, line 43
The credential service is encouraged to keep the subscriptions active The credential service is encouraged to keep the subscriptions active
for AORs that are communicating frequently, but the credential for AORs that are communicating frequently, but the credential
service MAY terminate the subscription at any point in time. service MAY terminate the subscription at any point in time.
6.5. NOTIFY Bodies 6.5. NOTIFY Bodies
The body of a NOTIFY request for this package MUST either be empty or The body of a NOTIFY request for this package MUST either be empty or
contain an application/pkix-cert body (as defined in [10]) that contain an application/pkix-cert body (as defined in [10]) that
contains the certificate, unless an Accept header has negotiated some contains the certificate, unless an Accept header has negotiated some
other type. The Content-Disposition MUST be set to "signal", as other type. The Content-Disposition MUST be set to "signal" as
defined in as defined in [16]. defined in [16].
A future extension MAY define other NOTIFY bodies. If no "Accept" A future extension MAY define other NOTIFY bodies. If no "Accept"
header is present in the SUBSCRIBE, the body type defined in this header is present in the SUBSCRIBE, the body type defined in this
document MUST be assumed. document MUST be assumed.
Implementations which generate large notifications are reminded to Implementations which generate large notifications are reminded to
follow the message size restrictions for unreliable transports follow the message size restrictions for unreliable transports
articulated in Section 18.1.1 of SIP. articulated in Section 18.1.1 of SIP.
6.6. Subscriber Generation of SUBSCRIBE Requests 6.6. Subscriber Generation of SUBSCRIBE Requests
skipping to change at page 18, line 9 skipping to change at page 18, line 9
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 8.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 in which the other below. This must be sent over a TLS connection directly to the
end of the connection presents a certificate that matches the domain of the credential service. The credential service presents a
credential service for Alice and digest challenges the request to certificate where the subjectAltName contains an entry that matches
authenticate her. the domain name in the request line of the PUBLISH request and digest
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
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
skipping to change at page 26, line 25 skipping to change at page 26, line 25
12. References 12. References
12.1. Normative References 12.1. Normative References
[1] RSA Laboratories, "Private-Key Information Syntax Standard, [1] RSA Laboratories, "Private-Key Information Syntax Standard,
Version 1.2", PKCS 8, November 1993. Version 1.2", PKCS 8, November 1993.
[2] Peterson, J. and C. Jennings, "Enhancements for Authenticated [2] Peterson, J. and C. Jennings, "Enhancements for Authenticated
Identity Management in the Session Initiation Protocol (SIP)", Identity Management in the Session Initiation Protocol (SIP)",
draft-ietf-sip-identity-05 (work in progress), May 2005. RFC 4474, August 2006.
[3] Niemi, A., "Session Initiation Protocol (SIP) Extension for [3] Niemi, A., "Session Initiation Protocol (SIP) Extension for
Event State Publication", RFC 3903, October 2004. Event State Publication", RFC 3903, October 2004.
[4] Roach, A., "Session Initiation Protocol (SIP)-Specific Event [4] Roach, A., "Session Initiation Protocol (SIP)-Specific Event
Notification", RFC 3265, June 2002. Notification", RFC 3265, June 2002.
[5] Bradner, S., "Key words for use in RFCs to Indicate Requirement [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
skipping to change at page 27, line 44 skipping to change at page 27, line 44
[17] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions [17] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions
(S/MIME) Version 3.1 Message Specification", RFC 3851, (S/MIME) Version 3.1 Message Specification", RFC 3851,
July 2004. July 2004.
[18] Peterson, J., "S/MIME Advanced Encryption Standard (AES) [18] Peterson, J., "S/MIME Advanced Encryption Standard (AES)
Requirement for the Session Initiation Protocol (SIP)", Requirement for the Session Initiation Protocol (SIP)",
RFC 3853, July 2004. RFC 3853, July 2004.
[19] Roach, A., Rosenberg, J., and B. Campbell, "A Session [19] Roach, A., Rosenberg, J., and B. Campbell, "A Session
Initiation Protocol (SIP) Event Notification Extension for Initiation Protocol (SIP) Event Notification Extension for
Resource Lists", draft-ietf-simple-event-list-07 (work in Resource Lists", RFC 4662, August 2006.
progress), January 2005.
Authors' Addresses Authors' Addresses
Cullen Jennings Cullen Jennings
Cisco Systems Cisco Systems
170 West Tasman Drive 170 West Tasman Drive
MS: SJC-21/2 MS: SJC-21/2
San Jose, CA 95134 San Jose, CA 95134
USA USA
 End of changes. 12 change blocks. 
21 lines changed or deleted 22 lines changed or added

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