One document matched: draft-ietf-sip-eku-08.xml
<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="no" ?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<?rfc sortrefs="no" ?>
<?rfc colonspace='yes' ?>
<?rfc comments='yes' ?>
<?rfc inline='no' ?>
<rfc docName="draft-ietf-sip-eku-08"
category="exp"
ipr="pre5378Trust200902"
>
<front>
<title abbrev="SIP EKU">
Using Extended Key Usage (EKU) for Session Initiation Protocol (SIP)
X.509 Certificates</title>
<author initials= "S." surname="Lawrence" fullname="Scott Lawrence">
<organization>Nortel Networks, Inc.</organization>
<address>
<postal>
<street>600 Technology Park</street>
<city>Billerica</city>
<region>MA</region> <code>01821</code>
<country>USA</country>
</postal>
<phone>+1 978 248 5508</phone>
<email>scott.lawrence@nortel.com</email>
</address>
</author>
<author initials="V.K." surname="Gurbani" fullname="Vijay K. Gurbani">
<organization>Bell Laboratories, Alcatel-Lucent</organization>
<address>
<postal>
<street>1960 Lucent Lane</street>
<street>Room 9C-533</street>
<city>Naperville</city>
<region>IL</region>
<code>60566</code>
<country>USA</country>
</postal>
<phone>+1 630 224-0216</phone>
<email>vkg@bell-labs.com</email>
</address>
</author>
<date month="October" day="20" year="2009" />
<area>Realtime Applications and Infrastructure</area>
<workgroup>SIP WG</workgroup>
<keyword>I-D</keyword>
<keyword>Internet-Draft</keyword>
<abstract>
<t>This 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.
</t>
</abstract>
</front>
<middle>
<section title="Terminology" >
<section title="Key Words">
<t>
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 <xref target="RFC2119">RFC 2119</xref>. </t>
<t>Additionally, the following term is defined:
<list style="empty">
<t>
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.
</t>
</list>
</t>
</section>
<section title="Abstract syntax notation">
<t>
All X.509 certificate <xref target="ITU.X509.2000">X.509</xref>
extensions are defined using ASN.1 <xref target="CCITT.X680.2002">X.680
</xref>,<xref target="CCITT.X690.2002">X.690</xref>.
</t>
</section>
</section>
<section title="Problem statement">
<t>Consider the SIP <xref target="RFC3261">RFC 3261</xref> actors shown in <xref
target="sip-trapezoid"/>.</t>
<figure anchor="sip-trapezoid" title="SIP Trapezoid">
<artwork><![CDATA[
Proxy-A.example.com Proxy-B.example.net
+-------+ +-------+
| Proxy |--------------------| Proxy |
+----+--+ +---+---+
| |
| |
| |
| +---+
0---0 | |
/-\ |___|
+---+ / /
+----+
alice@example.com bob@example.net
]]></artwork>
</figure>
<t>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 <xref
target="RFC3263">RFC 3263</xref> 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
<xref target= "I-D.domain-certs">Domain Certificates in the Session
Initiation Protocol (SIP)</xref>.</t>
<t>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.</t>
</section> <!-- Problem statement -->
<section title="Restricting usage to SIP" anchor="sipusage">
<t>This memo defines a certificate profile for restricting the usage of a
domain name binding to usage as a SIP domain name.
<xref target="RFC5280">RFC 5280</xref> 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:
</t>
<t><list style="empty">
<t>"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."</t>
</list></t>
<t>
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 <xref target="eku-def"/>).
</t>
<section title="Extended Key Usage values for SIP domains" anchor="eku-def">
<t>
<xref target="RFC5280">RFC 5280</xref> 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.
</t>
<figure>
<preamble>
The EKU extension syntax is repeated here for
convenience:
</preamble>
<artwork>
ExtKeyUsageSyntax ::= SEQUENCE SIZE (1..MAX) OF KeyPurposeId
KeyPurposeId ::= OBJECT IDENTIFIER
</artwork>
</figure>
<t>
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).
</t>
<figure>
<artwork>
id-kp OBJECT IDENTIFIER ::=
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) 3 }
id-kp-sipDomain OBJECT IDENTIFIER ::= { id-kp 20 }
</artwork>
</figure>
</section> <!-- eku-def -->
</section> <!-- sipusage -->
<section title="Using the SIP EKU in a certificate" anchor="using-eku">
<t>Section 7.1 of <xref target="I-D.domain-certs">Domain Certificates in the Session Initiation Protocol</xref> 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:
</t>
<t>The implementation MUST examine the Extended Key Usage value(s), if any:
<list style='symbols'>
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
</list>
</t>
</section> <!-- using-eku -->
<section title="Implications for a Certification Authority" anchor="ca">
<t>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.</t>
</section> <!-- ca -->
<section title="Security Considerations" anchor="sec-cons">
<t>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.</t>
</section> <!-- Security Considerations -->
<section title="IANA Considerations" anchor="iana-cons">
<!-- This text is taken from rfc5055, S10. -->
<t>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.</t>
</section> <!-- iana-cons -->
<section title="Acknowledgments">
<t>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.</t>
<t>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.</t>
</section>
</middle>
<back>
<references title= "Normative References" >
<reference anchor="RFC2119">
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</title>
<author initials="S." surname="Bradner">
<organization/></author>
<date month="March" year="1997"/>
</front>
<seriesInfo name="RFC" value="2119"/>
<format type="TXT" target="http://www.ietf.org/rfc/rfc2119.txt"/>
</reference>
<reference anchor="RFC3261">
<front>
<title>SIP: Session Initiation Protocol</title>
<author initials="J." surname="Rosenberg">
<organization></organization>
</author>
<author initials="H." surname="Schulzrinne">
<organization></organization>
</author>
<author initials='G.' surname='Camarillo'>
<organization></organization>
</author>
<author initials='A.' surname='Johnston'>
<organization></organization>
</author>
<author initials='J.' surname='Peterson'>
<organization></organization>
</author>
<author initials='R.' surname='Sparks'>
<organization></organization>
</author>
<author initials='M.' surname='Handley'>
<organization></organization>
</author>
<author initials='E.' surname='Schooler'>
<organization></organization>
</author>
<date month="June" year="2002"/>
</front>
<seriesInfo name="RFC" value="3261"/>
<format type="TXT" target="http://www.ietf.org/rfc/rfc3261.txt"/>
</reference>
<reference anchor="RFC5280">
<front>
<title>Internet X.509 Public Key Infrastructure Certificate and
Certificate Revocation List (CRL) Profile</title>
<author initials="D." surname="Cooper">
<organization></organization>
</author>
<author initials="S." surname="Santesson">
<organization></organization>
</author>
<author initials="S." surname="Farrell">
<organization></organization>
</author>
<author initials="S." surname="Boyen">
<organization></organization>
</author>
<author initials="R." surname="Housley">
<organization></organization>
</author>
<author initials="W." surname="Polk">
<organization></organization>
</author>
<date year='2008' month='May' />
</front>
<seriesInfo name="RFC" value="5280"/>
<format type="TXT" target="http://www.ietf.org/rfc/rfc5280.txt"/>
</reference>
<reference anchor="ITU.X509.2000">
<front>
<title>Information technology - Open Systems Interconnection - The Directory:
Public-key and attribute certificate frameworks</title>
<author>
<organization>International Telecommunications Union</organization>
</author>
<date month="March" year="2000" />
</front>
<seriesInfo name="ITU-T" value="Recommendation X.509" />
<seriesInfo name="ISO" value="Standard 9594-8" />
</reference>
<reference anchor="CCITT.X680.2002">
<front>
<title>Abstract Syntax Notation One (ASN.1): Specification of basic notation</title>
<author>
<organization>International International Telephone and Telegraph
Consultative Committee</organization>
</author>
<date month="July" year="2002" />
</front>
<seriesInfo name="CCITT" value="Recommendation X.680" />
</reference>
<reference anchor="CCITT.X690.2002">
<front>
<title>ASN.1 encoding rules: Specification of basic encoding Rules (BER), Canonical encoding rules (CER) and Distinguished encoding rules (DER)</title>
<author>
<organization>International International Telephone and Telegraph
Consultative Committee</organization>
</author>
<date month="July" year="2002" />
</front>
<seriesInfo name="CCITT" value="Recommendation X.690" />
</reference>
<reference anchor="RFC3263">
<front>
<title>Session Initiation Protocol (SIP): Location SIP Servers</title>
<author initials="J." surname="Rosenberg">
<organization></organization>
</author>
<author initials="H." surname="Schulzrinne">
<organization></organization>
</author>
<date month="June" year="2002"/>
</front>
<seriesInfo name="RFC" value="3263"/>
<format type="TXT" target="http://www.ietf.org/rfc/rfc3263.txt"/>
</reference>
<reference anchor="I-D.domain-certs">
<front>
<title>Domain Certificates in the Session Initiation Protocol (SIP)</title>
<author initials="V." surname="Gurbani"><organization/></author>
<author initials="S." surname="Lawrence"><organization/></author>
<author initials="A." surname="Jeffrey"><organization/></author>
<date month="May" year="2009"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-sip-domain-certs-04.txt"/>
<format type="TXT"
target="http://www.ietf.org/internet-drafts/draft-ietf-sip-domain-certs-04.txt"
/>
</reference>
</references>
<!--
<references title= "Informative References" >
</references> -->
<section title="ASN.1 Module" anchor="asn1">
<figure>
<artwork>
SIPDomainCertExtn
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-sip-domain-extns2007(62) }
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
-- OID Arcs
id-kp OBJECT IDENTIFIER ::=
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) 3 }
-- Extended Key Usage Values
id-kp-sipDomain OBJECT IDENTIFIER ::= { id-kp 20 }
END
</artwork>
</figure>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 21:48:47 |