draft-ietf-sip-certs-14.txt   draft-ietf-sip-certs-15.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: January 1, 2011 Skype Expires: March 25, 2011 Skype
June 30, 2010 September 21, 2010
Certificate Management Service for The Session Initiation Protocol (SIP) Certificate Management Service for The Session Initiation Protocol (SIP)
draft-ietf-sip-certs-14 draft-ietf-sip-certs-15
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
skipping to change at page 1, line 38 skipping to change at page 1, line 38
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. 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."
This Internet-Draft will expire on January 1, 2011. This Internet-Draft will expire on March 25, 2011.
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
skipping to change at page 4, line 4 skipping to change at page 4, line 4
9.2. Setting and Retrieving UA Credentials . . . . . . . . . . 19 9.2. Setting and Retrieving UA Credentials . . . . . . . . . . 19
10. Security Considerations . . . . . . . . . . . . . . . . . . . 20 10. Security Considerations . . . . . . . . . . . . . . . . . . . 20
10.1. Certificate Revocation . . . . . . . . . . . . . . . . . . 23 10.1. Certificate Revocation . . . . . . . . . . . . . . . . . . 23
10.2. Certificate Replacement . . . . . . . . . . . . . . . . . 23 10.2. Certificate Replacement . . . . . . . . . . . . . . . . . 23
10.3. Trusting the Identity of a Certificate . . . . . . . . . . 23 10.3. Trusting the Identity of a Certificate . . . . . . . . . . 23
10.3.1. Extra Assurance . . . . . . . . . . . . . . . . . . . 24 10.3.1. Extra Assurance . . . . . . . . . . . . . . . . . . . 24
10.4. SACRED Framework . . . . . . . . . . . . . . . . . . . . . 25 10.4. SACRED Framework . . . . . . . . . . . . . . . . . . . . . 25
10.5. Crypto Profiles . . . . . . . . . . . . . . . . . . . . . 25 10.5. Crypto Profiles . . . . . . . . . . . . . . . . . . . . . 25
10.6. User Certificate Generation . . . . . . . . . . . . . . . 26 10.6. User Certificate Generation . . . . . . . . . . . . . . . 26
10.7. Private Key Storage . . . . . . . . . . . . . . . . . . . 26 10.7. Private Key Storage . . . . . . . . . . . . . . . . . . . 26
10.8. Compromised Authentication Service . . . . . . . . . . . . 26 10.8. Compromised Authentication Service . . . . . . . . . . . . 27
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
11.1. Certificate Event Package . . . . . . . . . . . . . . . . 27 11.1. Certificate Event Package . . . . . . . . . . . . . . . . 28
11.2. Credential Event Package . . . . . . . . . . . . . . . . . 28 11.2. Credential Event Package . . . . . . . . . . . . . . . . . 28
11.3. Identity Algorithm . . . . . . . . . . . . . . . . . . . . 28 11.3. Identity Algorithm . . . . . . . . . . . . . . . . . . . . 28
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29
13.1. Normative References . . . . . . . . . . . . . . . . . . . 28 13.1. Normative References . . . . . . . . . . . . . . . . . . . 29
13.2. Informational References . . . . . . . . . . . . . . . . . 30 13.2. Informational References . . . . . . . . . . . . . . . . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30
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
skipping to change at page 14, line 35 skipping to change at page 14, line 35
are currently registered. are currently registered.
7.4. NOTIFY Bodies 7.4. NOTIFY Bodies
An implementation compliant to this specification MUST support the An implementation compliant to this specification MUST support the
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
[I-D.turner-asymmetrickeyformat]. [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 additional 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 DER encoded X.509v3 certificate
[RFC2585]. The application/pkcs8 body contains a DER-encoded [RFC2585]. The application/pkcs8 body contains a DER-encoded
[I-D.turner-asymmetrickeyformat] object that contains the private [RFC5958] object that contains the private key. The PKCS#8 objects
key. The PKCS#8 objects MUST be of type PrivateKeyInfo. The MUST be of type PrivateKeyInfo. The integrity and confidentiality of
integrity and confidentiality of the PKCS#8 objects is provided by the PKCS#8 objects is provided by the TLS transport. The transport
the TLS transport. The transport encoding of all the MIME bodies is encoding of all the MIME bodies is binary.
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 re-
subscribe before the subscription has completely expired. subscribe before the subscription has completely expired.
The Subscriber SHOULD subscribe to its credentials whenever a new The Subscriber SHOULD subscribe to its credentials whenever a new
user becomes associated with the device (a new login). The user becomes associated with the device (a new login). The
subscriber SHOULD also renew its subscription immediately after a subscriber SHOULD also renew its subscription immediately after a
skipping to change at page 26, line 14 skipping to change at page 26, line 14
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 id-aes128-wrap-pad as defined in [RFC5649]. encryption algorithm of id-aes128-wrap-pad as defined in [RFC5649].
Some pre-standard deployments of this specification used DES-EDE2- Some pre-standard deployments of this specification used DES-EDE2-
CBC-Pad as defined in [RFC2898] so, for some implementations, it may CBC-Pad as defined in [RFC2898] so, for some implementations, it may
be desirable to also support that algorithm. A different passphrase be desirable to also support that algorithm. A different passphrase
SHOULD be used for the PKCS#8 encryption than is used for SHOULD be used for the PKCS#8 encryption than is used for
authentication of the client. It is important to choose an authentication of the client. It is important to choose an
sufficiently strong passphrases. Specific advice on the passphrase sufficiently strong passphrases. Specific advice on the passphrase
can be found in section 6 of [I-D.turner-asymmetrickeyformat]. can be found in section 6 of [RFC5958].
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 algorithm 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 can be relatively short. A Validity of one
year or less is RECOMMENDED. The SubjectAltName must have a URI type year or less is RECOMMENDED. The SubjectAltName must have a URI type
that is set to the SIP URL corresponding to the user AOR. It MAY be that is set to the SIP URL corresponding to the user AOR. It MAY be
skipping to change at page 26, line 43 skipping to change at page 26, line 43
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 [RFC3760], personal information. As noted in the SACRED Framework, when stored
when stored on an end user device, such as a diskette or hard drive, on an end user device, such as a diskette or hard drive, credentials
credentials SHOULD NOT be in the clear. SHOULD NOT be in the clear. It is RECOMMENDED that private keys be
stored securely in the device, more specifically encrypting them
using tamper-resistant hardware encryption and exposing them only
when required: for example, the private key is decrypted when needed
to generate a digital signature, and re-encrypted immediately to
limit exposure in the RAM for a short period of time. Some
implementations may limit access to private keys by prompting users
for a PIN prior to allowing access to the private key.
On the server side, the protection of unencrypted PKCS#8 objects is
equally important. A server failing to protect the private keys
would be catastrophic as attackers with access to unencrypted PKCS#8
object could masquerade as any user whose private key was not
encrypted. Therefore, it is also recommended that the private keys
be stored securely in the server, more specifically encrypting them
using tamper-resistant hardware encryption and exposing them only
when required.
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 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 certification authority being compromised in analogous to a certification authority being compromised in
traditional PKI systems. The attacker could make a fake certificate traditional PKI systems. The attacker could make a fake certificate
for which it knows the private key, use it to receive any traffic for for which it knows the private key, use it to receive any traffic for
a given use, and then re-encrypt that traffic with the correct key a given use, and then re-encrypt that traffic with the correct key
and forward the communication to the intended receiver. The attacker and forward the communication to the intended receiver. The attacker
skipping to change at page 28, line 32 skipping to change at page 28, line 49
Parameter Values" registry. Note to RFC Editor: Please replace Parameter Values" registry. Note to RFC Editor: Please replace
RFCAAAA with the number for this RFC. RFCAAAA with the number for this RFC.
'alg' Parameter Name Reference 'alg' Parameter Name Reference
---------------------- --------- ---------------------- ---------
rsa-sha256 [RFCAAAA] rsa-sha256 [RFCAAAA]
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
for significant help and discussion. Many others provided useful and Sean Turner for significant help, discussion, and text. Many
comments, including Kumiko Ono, Peter Gutmann, Yaron Pdut, Aki Niemi, others provided useful comments and text, including Kumiko Ono, Peter
Magnus Nystrom, Paul Hoffman, Adina Simu, Dan Wing, Mike Hammer, Pasi Gutmann, Yaron Pdut, Aki Niemi, Magnus Nystrom, Paul Hoffman, Adina
Eronen, Alexey Melnikov, Tim Polk and Lyndsay Campbell. Rohan Mahy, Simu, Dan Wing, Mike Hammer, Pasi Eronen, Alexey Melnikov, Tim Polk,
John Elwell, and Jonathan Rosenberg provided detailed review and John Elwell, Jonathan Rosenberg and Lyndsay Campbell.
text.
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 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
skipping to change at page 29, line 48 skipping to change at page 30, line 16
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 [RFC5649] Housley, R. and M. Dworkin, "Advanced Encryption Standard
(AES) Key Wrap with Padding Algorithm", RFC 5649, (AES) Key Wrap with Padding Algorithm", RFC 5649,
September 2009. September 2009.
[I-D.turner-asymmetrickeyformat] [RFC5958] Turner, S., "Asymmetric Key Packages", RFC 5958,
Turner, S., "Asymmetric Key Packages", August 2010.
draft-turner-asymmetrickeyformat-05 (work in progress),
April 2010.
13.2. Informational References 13.2. Informational References
[RFC2898] Kaliski, B., "PKCS #5: Password-Based Cryptography [RFC2898] Kaliski, B., "PKCS #5: Password-Based Cryptography
Specification Version 2.0", RFC 2898, September 2000. Specification Version 2.0", RFC 2898, September 2000.
[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.
skipping to change at page 30, line 26 skipping to change at page 30, line 40
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)
Requirement for the Session Initiation Protocol (SIP)", Requirement for the Session Initiation Protocol (SIP)",
RFC 3853, July 2004. RFC 3853, July 2004.
[RFC4662] Roach, A., Campbell, B., and J. Rosenberg, "A Session [RFC4662] Roach, A., Campbell, B., and J. Rosenberg, "A Session
Initiation Protocol (SIP) Event Notification Extension for Initiation Protocol (SIP) Event Notification Extension for
Resource Lists", RFC 4662, August 2006. Resource Lists", RFC 4662, August 2006.
[FIPS-140-2]
NIST, "Security Requirements for Cryptographic Modules",
June 2005, <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
 End of changes. 13 change blocks. 
28 lines changed or deleted 47 lines changed or added

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