One document matched: draft-ietf-sip-eku-00.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="DOCNAME"
category="std"
ipr="full3978"
updates="3261"
>
<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>Bluesocket Inc.</organization>
<address>
<postal>
<street>10 North Ave.</street>
<city>Burlington</city>
<region>MA</region> <code>01803</code>
<country>USA</country>
</postal>
<phone>+1 781 229 0533</phone>
<email>slawrence@bluesocket.com</email>
</address>
</author>
<author initials="V.K." surname="Gurbani" fullname="Vijay K. Gurbani">
<organization>Bell Laboratories, Alcatel-Lucent</organization>
<address>
<postal>
<street>2701 Lucent Lane</street>
<street>Room 9F-546</street>
<city>Lisle</city>
<region>IL</region>
<code>60532</code>
<country>USA</country>
</postal>
<phone>+1 630 224-0216</phone>
<email>vkg@alcatel-lucent.com</email>
</address>
</author>
<date year="2007"/>
<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 identifying the holder of a certificate as authoritative for a Session
Initiation Protocol (SIP) service in the domain named by the DNS name in
the certificate.</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>
</section>
<section title="Abstract syntax notation">
<t>
All X.509 certificate <xref target="CCITT.X509.1988">X.509</xref>
extensions are defined using ASN.1 <xref target="CCITT.X680.1994">X.680
</xref>,<xref target="ITU.X690.1994">X.690</xref>.
</t>
</section>
</section>
<section title="Problem statement">
<t>Consider the SIP <xref target="RFC3261"/> trapezoid shown in <xref
target="sip-trapezoid"/>.</t>
<figure anchor="sip-trapezoid" title="SIP Trapezoid">
<artwork><![CDATA[
proxyA.example.com ------------ proxyB.example.net
| |
| |
| |
| +---+
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 normal resolution rules cause her
INVITE to be sent to an outbound proxy proxyA.example.com, which then
uses <xref target="RFC3263">RFC 3263</xref> resolution and finds that
proxyB.example.net is a valid proxy for example.net that uses TLS.
proxyA.example.com requests a TLS connection to proxyB.example.net, and
each presents a certificate to authenticate that connection. This is
the basic mutual authentication model explored in depth in <xref target=
"I-D.domain-certs"/>.</t>
<t>However, there arise certain cases where one SIP proxy needs to know
whether it has reached an authoritative proxy in target SIP domain. For
instance, billing transactions may be triggered when an authoritative SIP
proxy in one domain sends messages to its equivalent in another domain.
In <xref target="sip-trapezoid"/>, proxyA.example.com performs certain DNS
manipulations to arrive at proxyB.example.net. Because of these DNS
machinations, proxyA has a certain expectation that proxyB is a valid
proxy in the example.net domain and is authorized to receive inbound
requests targeted to that domain.</t>
<t>However, the problem for proxyB is different; it is presented with a
connection from a specific host, but what it needs to determine is whether
or not that connection can be treated as coming from a particular SIP
domain. If it receives a certificate that contains only the name
proxyA.example.com, then it cannot determine that proxyA is authorized to
act as a SIP outbound proxy for example.com, because example.com may
use different systems for inbound messages so SIP DNS resolution of
example.com may not lead to proxyA.example.com (if this is the case,
proxyB should not reuse this connection if it needs to send a request
to example.com). The certificate usage in SIP should not require that
every outbound proxy for a domain must also be an inbound proxy for
that domain, but should provide for certificate based binding of the
SIP domain name to a particular connection.</t>
<t>Thus, there is a need for an extra attribute that allows a proxy to
know that its peer is an authorized proxy for that domain. This memo
discusses such an attribute as part of the X.509 certificate exchanged
by the proxies when a TLS connection is first established.</t>
</section> <!-- Problem statement -->
<section title="Restricting usage to SIP" anchor="sipusage">
<t>The intent of this draft is to define certificate profile for binding a SIP
domain name to a connection. A SIP domain name is frequently textually
identical to the same DNS name used for other purposes. For example, the DNS
name example.com may serve as a SIP domain name, an email domain name, and
web service name. Since these different services within a single organization
may well be administered independently and hosted separately, it should be
possible to create a certificate that binds the DNS name to its usage as a
SIP domain name without creating the implication that the usage is also valid
for some other purpose. <xref target="RFC3280">RFC 3280</xref> section
4.2.1.13 defines a mechanism for this purpose: an "Extended Key Usage"
attribute. Certificates whose purpose is to bind a SIP domain
identity without binding other non-SIP identities MUST include an
id-kp-SIPdomain attribute.
</t>
<section title="Extended Key Usage values for SIP domains">
<t>
<xref target="RFC3280">RFC 3280</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 may be used. The EKU extension can be used in conjunction with
the key usage extension, which indicates how the public key in the
certificate may be 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 any DNS Subject
names in the certificate are intended to identify the holder as
authoritative for a SIP service in the domain named by the DNS name(s)
in question. Whether or not to include this restriction is up to the
certificate issuer, but if it is included, it MUST be marked as
critical so that implementations that do not understand it will not
accept the certificate for any other purpose.
</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 VALUE-TBD }
</artwork>
</figure>
<t>See <xref target='using-eku'/> for how the presence of an
id-kp-sipDomain value affects the interpretation of the certificate.</t>
</section>
</section> <!-- problem-mutual -->
<section title="Using the SIP EKU in a certificate" anchor="using-eku">
<t>Section 7.1 of <xref target="I-D.domain-certs"/> contains two steps
for finding an identity (or a set of identities) in an X.509 certificate.
In order to determine whether a SIP proxy is authoritative for its
domain, implementations MUST perform the step given below first, and
then proceed with the steps in Section 7.1 of
<xref target="I-D.domain-certs"/>.
</t>
<t>The key usage value(s), if any, MUST be examined to determine whether
or not the certificate is valid for use in SIP:
<list style='symbols'>
<t>If the certificate contains any EKU extension other than id-kp-sipDomain,
and does not contain the id-kp-sipDomain extension, then the certificate
MUST NOT be accepted as valid for use as a SIP certificate, and none
of the identities it contains are acceptable for SIP domain
authentication.</t>
<t>If the certificate contains the id-kp-anyExtendedKeyUsage extension
and also contains the id-kp-sipDomain extension, then the certificate
can be used as a SIP certificate. Furthermore, it can also be used for
any other application that the key usage extension permits.</t>
<t>If the certificate does not contain any EKU values, it is a matter of
local policy whether or not to accept it for use as a SIP certificate.</t>
</list></t>
<t>A summary of the logic flow for peer certificate validation follows:
<list style="numbers">
<t>If no EKU extension, apply local policy and accept the certificate.</t>
<t>If EKU is present and contains id-kp-sipDomain, accept the
certificate.</t>
<t>If any EKU is present and contains both id-kp-anyExtendedKeyUsage and
id-kp-sipDomain, accept the certificate.</t>
<t>If any EKU is present but does not include id-kp-sipDomain, reject the
certificate.</t>
</list>
</t>
</section> <!-- using-eku -->
<section title="Guidelines for a Certification Authority" anchor="ca">
<t>The procedures and practices employed by the 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 enables
the holder of a certificate to be authoritative for a SIP service
belonging to an autonomous domain. Relying parties may 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. At the very most,
it simply allows the relying party to know that the holder of the certificate
is authoritative for the SIP service in a certain domain. In the absence
of the id-kp-sipDomain EKU value, this information can be collected over
time by a peer in any case.</t>
</section> <!-- Security Considerations -->
<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, and Stephen Kent. Special acknowledgement is
due to Sharon Boyen for reviewing the document and pointing out the role of
id-kp-anyExtendedKeyUsage 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="RFC3280">
<front>
<title>Internet X.509 Public Key Infrastructure Certificate and
Certificate Revocation List (CRL) Profile</title>
<author initials="R." surname="Housley">
<organization></organization>
</author>
<author initials="W." surname="Polk">
<organization></organization>
</author>
<author initials="W." surname="Ford">
<organization></organization>
</author>
<author initials="D." surname="Solo">
<organization></organization>
</author>
<date year='2002' month='April' />
</front>
<seriesInfo name="RFC" value="3280"/>
<format type="TXT" target="http://www.ietf.org/rfc/rfc3280.txt"/>
</reference>
<reference anchor="CCITT.X509.1988">
<front>
<title>Information Technology - Open Systems Interconnection - The Directory: Authentication Framework</title>
<author>
<organization>International International Telephone and Telegraph
Consultative Committee</organization>
</author>
<date month="November" year="1988" />
</front>
<seriesInfo name="CCITT" value="Recommendation X.509" />
</reference>
<reference anchor="CCITT.X680.1994">
<front>
<title>Specification of 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="1994" />
</front>
<seriesInfo name="CCITT" value="Recommendation X.680" />
</reference>
<reference anchor="ITU.X690.1994">
<front>
<title>Information Technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)</title>
<author>
<organization>International Telecommunications Union</organization>
</author>
<date month="" year="1994" />
</front>
<seriesInfo name="ITU-T" 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>
</references>
<references title= "Informative References" >
<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="November" year="2007"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-sip-domain-certs-00.txt"/>
<format type="TXT"
target="http://www.ietf.org/internet-drafts/draft-ietf-sip-domain-certs-00.txt"/>
</reference>
</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(VALUE-TBD) }
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
-- OID Arcs
id-pe OBJECT IDENTIFIER ::=
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) 1 }
id-kp OBJECT IDENTIFIER ::=
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) 3 }
id-aca OBJECT IDENTIFIER ::=
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) 10 }
-- Extended Key Usage Values
id-kp-sipDomain OBJECT IDENTIFIER ::= { id-kp VALUE-TBD }
END
</artwork>
</figure>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 01:51:43 |