draft-ietf-sip-certs-13.txt   draft-ietf-sip-certs-14.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: December 19, 2010 Skype Expires: January 1, 2011 Skype
June 17, 2010 June 30, 2010
Certificate Management Service for The Session Initiation Protocol (SIP) Certificate Management Service for The Session Initiation Protocol (SIP)
draft-ietf-sip-certs-13 draft-ietf-sip-certs-14
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 December 19, 2010. This Internet-Draft will expire on January 1, 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 3, line 52 skipping to change at page 3, line 52
9.1. Encrypted Page Mode IM Message . . . . . . . . . . . . . . 18 9.1. Encrypted Page Mode IM Message . . . . . . . . . . . . . . 18
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. Compromised Authentication Service . . . . . . . . . . . . 26 10.7. Private Key Storage . . . . . . . . . . . . . . . . . . . 26
10.8. Compromised Authentication Service . . . . . . . . . . . . 26
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
11.1. Certificate Event Package . . . . . . . . . . . . . . . . 27 11.1. Certificate Event Package . . . . . . . . . . . . . . . . 27
11.2. Credential Event Package . . . . . . . . . . . . . . . . . 27 11.2. Credential Event Package . . . . . . . . . . . . . . . . . 28
11.3. Identity Algorithm . . . . . . . . . . . . . . . . . . . . 27 11.3. Identity Algorithm . . . . . . . . . . . . . . . . . . . . 28
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28
13.1. Normative References . . . . . . . . . . . . . . . . . . . 28 13.1. Normative References . . . . . . . . . . . . . . . . . . . 28
13.2. Informational References . . . . . . . . . . . . . . . . . 29 13.2. Informational References . . . . . . . . . . . . . . . . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 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
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
SIP Identity [RFC4474] specification, this specification allows users SIP Identity [RFC4474] specification, this specification allows users
to have certificates that are not signed by any well known to have certificates that are not signed by any well known
certificate authority while still strongly binding the user's certification authority while still strongly binding the user's
identity to the certificate. 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 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 certification 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 10.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 and decrypt a PKCS#8
private key.
3. Overview 3. Overview
The general approach is to provide a new SIP service referred to as a The general approach is to provide a new SIP service referred to as a
"credential service" that allows SIP User Agents (UAs) to subscribe "credential service" that allows SIP User Agents (UAs) to subscribe
to other users' certificates using a new SIP event package [RFC3265]. to other users' certificates using a new SIP event package [RFC3265].
The certificate is delivered to the subscribing UA in a corresponding The certificate is delivered to the subscribing UA in a corresponding
SIP NOTIFY request. 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
skipping to change at page 8, line 28 skipping to change at page 8, line 28
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 certificate 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
certificate authorities, certificate 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 which has been rarely implemented
by commercial certificate authorities. However, most UAs would only by commercial certification authorities. However, most UAs would
use self signed certificates and would use an Authentication Service only use self-signed certificates and would use an Authentication
as described in [RFC4474] to provide a strong binding of an AOR to Service as described in [RFC4474] to provide a strong binding of an
the certificates. AOR to the certificates.
The mechanisms described in this draft allow for three different The mechanisms described in this draft allow for three different
styles of deployment: styles of deployment:
1. Deployments where the credential server only stores certificates 1. Deployments where the credential server only stores certificates
and does not store any private key information. If the and does not store any private key information. If the
deployment had users with multiple devices, some other scheme deployment had users with multiple devices, some other scheme
(perhaps even manual provisioning) would be used to get the right (perhaps even manual provisioning) would be used to get the right
private keys onto all the devices that a user uses. private keys onto all the devices that a user uses.
2. Deployments where the credential server stores certificates and 2. Deployments where the credential server stores certificates and
skipping to change at page 10, line 48 skipping to change at page 10, line 48
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 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 as described in [RFC4086] and then creating a
described in Section 10.6. The UA MAY encrypt the private key with a certificate as described in Section 10.6. The UA MAY encrypt the
password phrase supplied by the user. Next, the UA updates the private key with a password phrase supplied by the user as specified
user's credential by sending a PUBLISH [RFC3903] request with the in Section 10.5. Next, the UA updates the user's credential by
credentials or just the certificate as described in Section 7.8. 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].
skipping to change at page 13, line 32 skipping to change at page 13, line 32
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 certificate server described in this section which serves The credential server described in this section which serves
certificates is a state agent as defined in [RFC3265] and certificates is a state agent as defined in [RFC3265] and
implementations of the certificate 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
skipping to change at page 14, line 45 skipping to change at page 14, line 45
[I-D.turner-asymmetrickeyformat]. [I-D.turner-asymmetrickeyformat].
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
[RFC5208] object that contains the private key. The PKCS#8 objects [I-D.turner-asymmetrickeyformat] object that contains the private
MUST be of type PrivateKeyInfo. The integrity and confidentiality of key. The PKCS#8 objects MUST be of type PrivateKeyInfo. The
the PKCS#8 objects is provided by the TLS transport. The transport integrity and confidentiality of the PKCS#8 objects is provided by
encoding of all the MIME bodies is binary. 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 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 16, line 41 skipping to change at page 16, line 41
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 flag 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 to update credentials,
it MUST authenticate and authorize this request the same way as for it MUST authenticate and authorize this request the same way as for
subscriptions for credentials. If the authorization succeeds, then subscriptions for credentials. If the authorization succeeds, then
the credential service MUST perform the following check on the the credential service MUST perform the following check on the
certificate: 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 is set in the certificate, it is set to o If a cA Basic Constraint flag is set in the certificate, it is set
false. 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 could
be used and offers no additional security guarantees. 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
skipping to change at page 18, line 13 skipping to change at page 18, line 13
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. Identity Signatures 8. Identity Signatures
The [RFC4474] Authentication service defined an signature algorithm The [RFC4474] Authentication service defined an signature algorithm
based on SHA1 called rsa-sha1. This specification adds an signature based on SHA-1 called rsa-sha1. This specification adds an signature
algorithm that is roughly the same but based on SHA256 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
skipping to change at page 19, line 32 skipping to change at page 19, line 32
... ...
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 public and private keys to When Alice's UA wishes to publish Alice's certificate and private key
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 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
... ...
Event: credential Event: credential
Content-Type: multipart/mixed;boundary=boundary Content-Type: multipart/mixed;boundary=boundary
Content-Disposition: signal Content-Disposition: signal
--boundary --boundary
skipping to change at page 24, line 8 skipping to change at page 24, line 8
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 CA, and one of the names in If the certificate is signed by a trusted certification authority,
the SubjectAltName matches the original URI, then this certificate and one of the names in the SubjectAltName matches the original URI,
MAY be used but only for exactly the original URI and not for other then this certificate MAY be used but only for exactly the original
identities found in the SubjectAltName. Otherwise, there are several URI and not for other identities found in the SubjectAltName.
steps the UA MUST perform before using this certificate. Otherwise, there are several steps the UA MUST perform before using
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.)
skipping to change at page 25, line 5 skipping to change at page 25, line 6
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 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) 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 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 10.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
skipping to change at page 25, line 42 skipping to change at page 25, line 43
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.
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]. [RFC5246]. If additional cipher suites are supported, then
implementations MUST NOT negotiate a cipher suite that employs NULL
encryption, integrity, or authentication algorithms.
Implementations of TLS typically support multiple versions of the
Transport Layer Security protocol as well as the older Secure Sockets
Layer (SSL) protocol. Because of known security vulnerabilities,
clients and servers MUST NOT request, offer, or use SSL 2.0. See
Appendix E.2 of [RFC5246]for further details.
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 per-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 server SHOULD be used for the PKCS#8 encryption than is used for
authentication. authentication of the client. It is important to choose an
sufficiently strong passphrases. Specific advice on the passphrase
can be found in section 6 of [I-D.turner-asymmetrickeyformat].
10.6. User Certificate Generation 10.6. User Certificate Generation
The certificates should 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
desirable to put some randomness into the length of time for which desirable to put some randomness into the length of time for which
the certificates are valid so that it does not become necessary to the certificates are valid so that it does not become necessary to
renew all the certificates in the system at the same time. renew all the certificates in the system at the same time.
When creating a new key pair for a certificate, it is critical to
have appropriate randomness as described in [RFC4086]. This can be
challenging on some embedded devices such as some IP Phones and
implementors 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. Compromised Authentication Service 10.7. Private Key Storage
The protection afforded private keys is a critical security factor.
On a small scale, failure of devices to protect the private keys will
permit an attacker to masquerade as the user or decrypt their
personal information. As noted in the SACRED Framework [RFC3760],
when stored on an end user device, such as a diskette or hard drive,
credentials SHOULD NOT be in the clear.
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 CA being compromised in traditional PKI systems. The analogous to a certification authority being compromised in
attacker could make a fake certificate for which it knows the private traditional PKI systems. The attacker could make a fake certificate
key, use it to receive any traffic for a given use, and then re- for which it knows the private key, use it to receive any traffic for
encrypt that traffic with the correct key and forward the a given use, and then re-encrypt that traffic with the correct key
communication to the intended receiver. The attacker would thus and forward the communication to the intended receiver. The attacker
become a man in the middle in the communications. 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. A UA
MAY subscribe to its own certificate under some other identity to try MAY subscribe to its own certificate under some other identity to try
to detect whether the credential server is handing out the correct to detect whether the credential server is handing out the correct
certificates. It will be difficult to do this in a way that does not certificates. It will be difficult to do this in a way that does not
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.
skipping to change at page 27, line 46 skipping to change at page 28, line 27
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 will add the following entry to the "Identity-Info Algorithm
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 [RFCAAA] 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 for significant help and discussion. Many others provided useful
comments, including Kumiko Ono, Peter Gutmann, Yaron Pdut, Aki Niemi, 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.
skipping to change at page 28, line 44 skipping to change at page 29, line 26
[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 [RFC3903] Niemi, A., "Session Initiation Protocol (SIP) Extension
for Event State Publication", RFC 3903, October 2004. for Event State Publication", RFC 3903, October 2004.
[RFC4474] Peterson, J. and C. Jennings, "Enhancements for [RFC4474] Peterson, J. and C. Jennings, "Enhancements for
Authenticated Identity Management in the Session Authenticated Identity Management in the Session
Initiation Protocol (SIP)", RFC 4474, August 2006. Initiation Protocol (SIP)", RFC 4474, August 2006.
[RFC5208] Kaliski, B., "Public-Key Cryptography Standards (PKCS) #8:
Private-Key Information Syntax Specification Version 1.2",
RFC 5208, May 2008.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008. (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, May 2008. (CRL) Profile", RFC 5280, May 2008.
[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.
 End of changes. 34 change blocks. 
67 lines changed or deleted 91 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/