idnits 2.17.1 draft-ietf-sip-eku-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 18, 2009) is 5457 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Possible downref: Non-RFC (?) normative reference: ref. '6' == Outdated reference: A later version (-07) exists of draft-ietf-sip-domain-certs-04 Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIP WG S. Lawrence 3 Internet-Draft Nortel Networks, Inc. 4 Intended status: Standards Track V. Gurbani 5 Expires: November 19, 2009 Bell Laboratories, Alcatel-Lucent 6 May 18, 2009 8 Using Extended Key Usage (EKU) for Session Initiation Protocol (SIP) 9 X.509 Certificates 10 draft-ietf-sip-eku-05 12 Status of this Memo 14 This Internet-Draft is submitted to IETF in full conformance with the 15 provisions of BCP 78 and BCP 79. This document may contain material 16 from IETF Documents or IETF Contributions published or made publicly 17 available before November 10, 2008. The person(s) controlling the 18 copyright in some of this material may not have granted the IETF 19 Trust the right to allow modifications of such material outside the 20 IETF Standards Process. Without obtaining an adequate license from 21 the person(s) controlling the copyright in such materials, this 22 document may not be modified outside the IETF Standards Process, and 23 derivative works of it may not be created outside the IETF Standards 24 Process, except to format it for publication as an RFC or to 25 translate it into languages other than English. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF), its areas, and its working groups. Note that 29 other groups may also distribute working documents as Internet- 30 Drafts. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 The list of current Internet-Drafts can be accessed at 38 http://www.ietf.org/ietf/1id-abstracts.txt. 40 The list of Internet-Draft Shadow Directories can be accessed at 41 http://www.ietf.org/shadow.html. 43 This Internet-Draft will expire on November 19, 2009. 45 Copyright Notice 47 Copyright (c) 2009 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents in effect on the date of 52 publication of this document (http://trustee.ietf.org/license-info). 53 Please review these documents carefully, as they describe your rights 54 and restrictions with respect to this document. 56 Abstract 58 This memo documents an extended key usage (EKU) X.509 certificate 59 extension for restricting the applicability of a certificate to use 60 with a Session Initiation Protocol (SIP) service. As such, in 61 addition to providing rules for SIP implementations, this memo also 62 provides guidance to issuers of certificates for use with SIP. 64 Table of Contents 66 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 1.1. Key Words . . . . . . . . . . . . . . . . . . . . . . . . . 3 68 1.2. Abstract syntax notation . . . . . . . . . . . . . . . . . 3 69 2. Problem statement . . . . . . . . . . . . . . . . . . . . . . . 3 70 3. Restricting usage to SIP . . . . . . . . . . . . . . . . . . . 4 71 3.1. Extended Key Usage values for SIP domains . . . . . . . . . 5 72 4. Using the SIP EKU in a certificate . . . . . . . . . . . . . . 5 73 5. Implications for a Certification Authority . . . . . . . . . . 6 74 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 75 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 76 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7 77 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 78 9.1. Normative References . . . . . . . . . . . . . . . . . . . 7 79 9.2. Informative References . . . . . . . . . . . . . . . . . . 8 80 Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . . 8 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 83 1. Terminology 85 1.1. Key Words 87 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 88 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 89 document are to be interpreted as described in RFC 2119 [1]. 91 1.2. Abstract syntax notation 93 All X.509 certificate X.509 [4] extensions are defined using ASN.1 94 X.680 [5],X.690 [6]. 96 2. Problem statement 98 Consider the SIP RFC 3261 [2] trapezoid shown in Figure 1. 100 Proxy-A.example.com Proxy-B.example.net 101 +-------+ +-------+ 102 | Proxy |--------------------| Proxy | 103 +----+--+ +---+---+ 104 | | 105 | | 106 | | 107 | +---+ 108 0---0 | | 109 /-\ |___| 110 +---+ / / 111 +----+ 112 alice@example.com bob@example.net 114 Figure 1: SIP Trapezoid 116 Assume that alice@example.com creates an INVITE for bob@example.net; 117 her user agent routes the request to some proxy in her domain, 118 example.com. Suppose also that example.com is a large organization 119 that maintains several SIP proxies, and her INVITE arrived at an 120 outbound proxy Proxy-A.example.com. In order to route the request 121 onward, Proxy-A uses RFC 3263 [7] resolution and finds that Proxy- 122 B.example.net is a valid proxy for example.net that uses TLS. Proxy- 123 A.example.com requests a TLS connection to Proxy-B.example.net, and 124 in the TLS handshake each presents a certificate to authenticate that 125 connection. The validation of these certificates by each proxy to 126 determine whether or not their peer is authoritative for the 127 appropriate SIP domain is defined in Domain Certificates in the 128 Session Initiation Protocol (SIP) [8]. 130 A SIP domain name is frequently textually identical to the same DNS 131 name used for other purposes. For example, the DNS name example.com 132 can serve as a SIP domain name, an email domain name, and a web 133 service name. Since these different services within a single 134 organization might be administered independently and hosted 135 separately, it is desirable that a certificate be able to bind the 136 DNS name to its usage as a SIP domain name without creating the 137 implication that the entity presenting the certificate is also 138 authoritative for some other purpose. A mechanism is needed to allow 139 the certificate issued to a proxy to be restricted such that the 140 subject name(s) that the certificate contains are valid only for use 141 in SIP. In our example, Proxy-B possesses a certificate making 142 Proxy-B authoritative as a SIP server for the domain example.net; 143 furthermore, Proxy-B has a policy that requires the client's SIP 144 domain be authenticated through a similar certificate. Proxy-A is 145 authoritative as a SIP server for the domain example.com; when 146 Proxy-A makes a TLS connection to Proxy-B, the latter accepts the 147 connection based on its policy. 149 3. Restricting usage to SIP 151 This memo defines a certificate profile for restricting the usage of 152 a domain name binding to usage as a SIP domain name. RFC 5280 [3] 153 Section 4.2.1.12 defines a mechanism for this purpose: an "Extended 154 Key Usage" (EKU) attribute, where the purpose of the EKU extension is 155 described as: 157 "If the extension is present, then the certificate MUST only be 158 used for one of the purposes indicated. If multiple purposes are 159 indicated the application need not recognize all purposes 160 indicated, as long as the intended purpose is present. 161 Certificate using applications MAY require that the extended key 162 usage extension be present and that a particular purpose be 163 indicated in order for the certificate to be acceptable to that 164 application." 166 A Certificate Authority issuing a certificate whose purpose is to 167 bind a SIP domain identity without binding other non-SIP identities 168 MUST include an id-kp-SIPdomain attribute in the Extended Key Usage 169 extension value (see Section 3.1). 171 3.1. Extended Key Usage values for SIP domains 173 RFC 5280 [3] specifies the EKU X.509 certificate Extension for use in 174 the Internet. The extension indicates one or more purposes for which 175 the certified public key is valid. The EKU extension can be used in 176 conjunction with the key usage extension, which indicates how the 177 public key in the certificate is used, in a more basic cryptographic 178 way. 180 The EKU extension syntax is repeated here for convenience: 182 ExtKeyUsageSyntax ::= SEQUENCE SIZE (1..MAX) OF KeyPurposeId 184 KeyPurposeId ::= OBJECT IDENTIFIER 186 This specification defines the KeyPurposeId id-kp-sipDomain. 187 Inclusion of this KeyPurposeId in a certificate indicates that the 188 use of any Subject names in the certificate is restricted to use by a 189 SIP service (along with any usages allowed by other EKU values). 191 id-kp OBJECT IDENTIFIER ::= 192 { iso(1) identified-organization(3) dod(6) internet(1) 193 security(5) mechanisms(5) pkix(7) 3 } 195 id-kp-sipDomain OBJECT IDENTIFIER ::= { id-kp 20 } 197 4. Using the SIP EKU in a certificate 199 Section 7.1 of Domain Certificates in the Session Initiation Protocol 200 [8] contains the steps for finding an identity (or a set of 201 identities) in an X.509 certificate for SIP. In order to determine 202 whether the usage of a certificate is restricted to serve as a SIP 203 certificate only, implementations MUST perform the step given below 204 as a part of the certificate validation: 206 The implementation MUST examine the Extended Key Usage value(s), if 207 any: 209 o If the certificate does not contain any EKU values (the Extended 210 Key Usage extension does not exist), it is a matter of local 211 policy whether or not to accept the certificate for use as a SIP 212 certificate. 214 o If the certificate contains the id-kp-sipDomain EKU extension, 215 then implementations MUST consider the certificate acceptable for 216 use as a SIP certificate. 218 o If the certificate does not contain the id-kp-sipDomain EKU value, 219 but does contain the id-kp-anyExtendedKeyUsage EKU value, it is a 220 matter of local policy whether or not to consider the certificate 221 acceptable for use as a SIP certificate. 223 o If the certificate does not contain the id-kp-sipDomain EKU value, 224 but does contain either the id-kp-serverAuth or id-kp-clientAuth 225 EKU values, it is a matter of local policy whether or not to 226 consider the certificate acceptable for use as a SIP certificate. 228 id-kp-serverAuth and id-kp-clientAuth EKU values are defined in 229 Section 4.2.1.12 of RFC 5280 [3]. 231 o If EKU extension exists but does not contain any of the id-kp- 232 sipDomain, id-kp-anyExtendedKeyUsage, id-kp-serverAuth, or id-kp- 233 clientAuth EKU values, then implementations MUST NOT consider the 234 certificate as acceptable for use as a SIP certificate. 236 5. Implications for a Certification Authority 238 The procedures and practices employed by a certification authority 239 MUST ensure that the correct values for the EKU extension and 240 subjectAltName are inserted in each certificate that is issued. For 241 certificates that indicate authority over a SIP domain, but not over 242 services other than SIP, certificate authorities MUST include the id- 243 kp-sipDomain EKU extension. 245 6. Security Considerations 247 This memo defines an EKU X.509 certificate extension that restricts 248 the the usage of a certificate to a SIP service belonging to an 249 autonomous domain. Relying parties can execute applicable policies 250 (such as those related to billing) on receiving a certificate with 251 the id-kp-sipDomain EKU value. An id-kp-sipDomain EKU value does not 252 introduce any new security or privacy concerns. 254 7. IANA Considerations 256 The id-kp-sipDomain purpose requires an object identifier (OID). The 257 objects are defined in an arc delegated by IANA to the PKIX working 258 group. No further action is necessary by IANA. 260 8. Acknowledgments 262 The following IETF contributors provided substantive input to this 263 document: Jeroen van Bemmel, Michael Hammer, Cullen Jennings, Paul 264 Kyzivat, Derek MacDonald, Dave Oran, Jon Peterson, Eric Rescorla, 265 Jonathan Rosenberg, Russ Housley, Paul Hoffman, and Stephen Kent. 267 Sharon Boyen and Trevor Freeman reviewed the document and facilitated 268 the discussion on id-kp-anyExtendedKeyUsage, id-kpServerAuth and id- 269 kp-ClientAuth purposes in certificates. 271 9. References 273 9.1. Normative References 275 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 276 Levels", RFC 2119, March 1997. 278 [2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 279 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 280 Session Initiation Protocol", RFC 3261, June 2002. 282 [3] Cooper, D., Santesson, S., Farrell, S., Boyen, S., Housley, R., 283 and W. Polk, "Internet X.509 Public Key Infrastructure 284 Certificate and Certificate Revocation List (CRL) Profile", 285 RFC 5280, May 2008. 287 [4] International Telecommunications Union, "Information technology 288 - Open Systems Interconnection - The Directory: Public-key and 289 attribute certificate frameworks", ITU-T Recommendation X.509, 290 ISO Standard 9594-8, March 2000. 292 [5] International International Telephone and Telegraph Consultative 293 Committee, "Abstract Syntax Notation One (ASN.1): Specification 294 of basic notation", CCITT Recommendation X.680, July 2002. 296 [6] International International Telephone and Telegraph Consultative 297 Committee, "ASN.1 encoding rules: Specification of basic 298 encoding Rules (BER), Canonical encoding rules (CER) and 299 Distinguished encoding rules (DER)", CCITT Recommendation X.690, 300 July 2002. 302 [7] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol 303 (SIP): Location SIP Servers", RFC 3263, June 2002. 305 9.2. Informative References 307 [8] Gurbani, V., Lawrence, S., and A. Jeffrey, "Domain Certificates 308 in the Session Initiation Protocol (SIP)", 309 draft-ietf-sip-domain-certs-04.txt (work in progress), May 2009. 311 Appendix A. ASN.1 Module 313 SIPDomainCertExtn 314 { iso(1) identified-organization(3) dod(6) internet(1) 315 security(5) mechanisms(5) pkix(7) id-mod(0) 316 id-mod-sip-domain-extns2007(VALUE-TBD) } 318 DEFINITIONS IMPLICIT TAGS ::= 319 BEGIN 321 -- OID Arcs 323 id-pe OBJECT IDENTIFIER ::= 324 { iso(1) identified-organization(3) dod(6) internet(1) 325 security(5) mechanisms(5) pkix(7) 1 } 327 id-kp OBJECT IDENTIFIER ::= 328 { iso(1) identified-organization(3) dod(6) internet(1) 329 security(5) mechanisms(5) pkix(7) 3 } 331 id-aca OBJECT IDENTIFIER ::= 332 { iso(1) identified-organization(3) dod(6) internet(1) 333 security(5) mechanisms(5) pkix(7) 10 } 335 -- Extended Key Usage Values 337 id-kp-sipDomain OBJECT IDENTIFIER ::= { id-kp 20 } 339 END 341 Authors' Addresses 343 Scott Lawrence 344 Nortel Networks, Inc. 345 600 Technology Park 346 Billerica, MA 01821 347 USA 349 Phone: +1 978 248 5508 350 Email: scott.lawrence@nortel.com 352 Vijay K. Gurbani 353 Bell Laboratories, Alcatel-Lucent 354 1960 Lucent Lane 355 Room 9C-533 356 Naperville, IL 60566 357 USA 359 Phone: +1 630 224-0216 360 Email: vkg@alcatel-lucent.com