Using Extended Key Usage (EKU) for Session Initiation Protocol (SIP)
X.509 CertificatesNortel Networks, Inc.600 Technology ParkBillericaMA01821USA+1 978 248 5508scott.lawrence@nortel.comBell Laboratories, Alcatel-Lucent1960 Lucent LaneRoom 9C-533NapervilleIL60566USA+1 630 224-0216vkg@bell-labs.com
Realtime Applications and Infrastructure
SIP WGI-DInternet-DraftThis memo documents an extended key usage (EKU) X.509 certificate
extension for restricting the applicability of a certificate to use with a
Session Initiation Protocol (SIP) service. As such, in addition to
providing rules for SIP implementations, this memo also provides guidance
to issuers of certificates for use with SIP.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
"SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be
interpreted as described in RFC 2119. Additionally, the following term is defined:
SIP domain identity: A subject identity in the X.509 certificate
that conveys to a recipient of the certificate that the
certificate owner is authoritative for SIP services in the
domain named by that subject identity.
All X.509 certificate X.509
extensions are defined using ASN.1 X.680
,X.690.
Consider the SIP RFC 3261 actors shown in .Assume that alice@example.com creates an INVITE for bob@example.net; her
user agent routes the request to some proxy in her domain, example.com.
Suppose also that example.com is a large organization that maintains
several SIP proxies, and her INVITE arrived at an outbound proxy
Proxy-A.example.com. In order to route the request onward, Proxy-A uses RFC 3263 resolution and finds that
Proxy-B.example.net is a valid proxy for example.net that uses TLS.
Proxy-A.example.com requests a TLS connection to Proxy-B.example.net, and
in the TLS handshake each presents a certificate to authenticate that connection. The
validation of these certificates by each proxy to determine whether or not
their peer is authoritative for the appropriate SIP domain is defined in
Domain Certificates in the Session
Initiation Protocol (SIP).A SIP domain name is frequently textually identical to the same DNS name
used for other purposes. For example, the DNS name example.com can serve
as a SIP domain name, an email domain name, and a web service name. Since
these different services within a single organization might be administered
independently and hosted separately, it is desirable that a certificate be
able to bind the DNS name to its usage as a SIP domain name without
creating the implication that the entity presenting the certificate is also
authoritative for some other purpose. A mechanism is needed to allow
the certificate issued to a proxy to be restricted such that the subject
name(s) that the certificate contains are valid only for use in SIP. In our example,
Proxy-B possesses a certificate making Proxy-B authoritative as a SIP
server for the domain example.net; furthermore, Proxy-B has a policy that
requires the client's SIP domain be authenticated through a similar
certificate. Proxy-A is authoritative as a SIP server for the domain
example.com; when Proxy-A makes a TLS connection to Proxy-B, the
latter accepts the connection based on its policy.This memo defines a certificate profile for restricting the usage of a
domain name binding to usage as a SIP domain name.
RFC 5280 Section
4.2.1.12 defines a mechanism for this purpose: an "Extended Key Usage" (EKU)
attribute, where the purpose of the EKU extension is described as:
"If the extension is present, then the certificate MUST only be used
for one of the purposes indicated. If multiple purposes are
indicated the application need not recognize all purposes indicated,
as long as the intended purpose is present. Certificate using
applications MAY require that the extended key usage extension be
present and that a particular purpose be indicated in order for the
certificate to be acceptable to that application."
A Certificate Authority issuing a certificate whose purpose is to bind a SIP domain identity without
binding other non-SIP identities MUST include an id-kp-SIPdomain attribute
in the Extended Key Usage extension value (see ).
RFC 5280 specifies the EKU
X.509 certificate Extension for use in the Internet. The
extension indicates one or more purposes for which the certified public
key is valid. The EKU extension can be used in conjunction with
the key usage extension, which indicates how the public key in the
certificate is used, in a more basic cryptographic way.
This specification defines the KeyPurposeId id-kp-sipDomain. Inclusion
of this KeyPurposeId in a certificate indicates that the use of any Subject
names in the certificate is restricted to use by a SIP service (along
with any usages allowed by other EKU values).
Section 7.1 of Domain Certificates in the Session Initiation Protocol contains the steps
for finding an identity (or a set of identities) in an X.509 certificate for SIP.
In order to determine whether the usage of a certificate is restricted
to serve as a SIP certificate only, implementations MUST perform the
step given below as a part of the certificate validation:
The implementation MUST examine the Extended Key Usage value(s), if any:
If the certificate does not contain any EKU values (the
Extended Key Usage extension does not exist), it is a matter of local
policy whether or not to accept the certificate for use as a SIP
certificate. Note that since certificates not following this
specification will not have the id-kp-sipDomain EKU value, and many do
not have any EKU values, the more interoperable local policy
would be to accept the certificate.If the certificate contains the id-kp-sipDomain EKU extension, then
implementations of this specification MUST consider the certificate
acceptable for use as a SIP certificate.If the certificate does not contain the id-kp-sipDomain EKU value, but
does contain the id-kp-anyExtendedKeyUsage EKU value, it is a matter of
local policy whether or not to consider the certificate acceptable for
use as a SIP certificate.If the EKU extension exists, but does not contain any of the
id-kp-sipDomain or id-kp-anyExtendedKeyUsage EKU values, then the
certificate MUST NOT be accepted as valid for use as a SIP
certificate.The procedures and practices employed by a certification authority
MUST ensure that the correct values for the EKU extension and subjectAltName
are inserted in each certificate that is issued. For certificates that
indicate authority over a SIP domain, but not over services other than
SIP, certificate authorities MUST include the id-kp-sipDomain EKU
extension.This memo defines an EKU X.509 certificate extension that restricts the
the usage of a certificate to a SIP service
belonging to an autonomous domain. Relying parties can execute applicable
policies (such as those related to billing) on receiving a certificate
with the id-kp-sipDomain EKU value. An id-kp-sipDomain EKU value
does not introduce any new security or privacy concerns.The id-kp-sipDomain purpose requires an object identifier (OID).
The objects are defined in an arc delegated by IANA to the PKIX
working group. No further action is necessary by IANA.The following IETF contributors provided substantive input to this
document: Jeroen van Bemmel, Michael Hammer, Cullen Jennings, Paul Kyzivat,
Derek MacDonald, Dave Oran, Jon Peterson, Eric Rescorla, Jonathan
Rosenberg, Russ Housley, Paul Hoffman, and Stephen Kent.Sharon Boyen and Trevor Freeman reviewed the document and facilitated
the discussion on id-kp-anyExtendedKeyUsage, id-kpServerAuth and
id-kp-ClientAuth purposes in certificates.Key words for use in RFCs to Indicate Requirement LevelsSIP: Session Initiation ProtocolInternet X.509 Public Key Infrastructure Certificate and
Certificate Revocation List (CRL) ProfileInformation technology - Open Systems Interconnection - The Directory:
Public-key and attribute certificate frameworksInternational Telecommunications UnionAbstract Syntax Notation One (ASN.1): Specification of basic notationInternational International Telephone and Telegraph
Consultative CommitteeASN.1 encoding rules: Specification of basic encoding Rules (BER), Canonical encoding rules (CER) and Distinguished encoding rules (DER)International International Telephone and Telegraph
Consultative CommitteeSession Initiation Protocol (SIP): Location SIP ServersDomain Certificates in the Session Initiation Protocol (SIP)