idnits 2.17.1 draft-ietf-sip-eku-08.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 (October 20, 2009) is 5301 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-07) exists of draft-ietf-sip-domain-certs-04 Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 2 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: Experimental V. Gurbani 5 Expires: April 23, 2010 Bell Laboratories, Alcatel-Lucent 6 October 20, 2009 8 Using Extended Key Usage (EKU) for Session Initiation Protocol (SIP) 9 X.509 Certificates 10 draft-ietf-sip-eku-08 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 April 23, 2010. 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 . . . . . . . . . . . . . . . . . . . . . . . . 6 77 9. Normative References . . . . . . . . . . . . . . . . . . . . . 7 78 Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . . 8 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 81 1. Terminology 83 1.1. Key Words 85 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 86 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 87 document are to be interpreted as described in RFC 2119 [1]. 89 Additionally, the following term is defined: 91 SIP domain identity: A subject identity in the X.509 certificate 92 that conveys to a recipient of the certificate that the 93 certificate owner is authoritative for SIP services in the domain 94 named by that subject identity. 96 1.2. Abstract syntax notation 98 All X.509 certificate X.509 [4] extensions are defined using ASN.1 99 X.680 [5],X.690 [6]. 101 2. Problem statement 103 Consider the SIP RFC 3261 [2] actors shown in Figure 1. 105 Proxy-A.example.com Proxy-B.example.net 106 +-------+ +-------+ 107 | Proxy |--------------------| Proxy | 108 +----+--+ +---+---+ 109 | | 110 | | 111 | | 112 | +---+ 113 0---0 | | 114 /-\ |___| 115 +---+ / / 116 +----+ 117 alice@example.com bob@example.net 119 Figure 1: SIP Trapezoid 121 Assume that alice@example.com creates an INVITE for bob@example.net; 122 her user agent routes the request to some proxy in her domain, 123 example.com. Suppose also that example.com is a large organization 124 that maintains several SIP proxies, and her INVITE arrived at an 125 outbound proxy Proxy-A.example.com. In order to route the request 126 onward, Proxy-A uses RFC 3263 [7] resolution and finds that Proxy- 127 B.example.net is a valid proxy for example.net that uses TLS. Proxy- 128 A.example.com requests a TLS connection to Proxy-B.example.net, and 129 in the TLS handshake each presents a certificate to authenticate that 130 connection. The validation of these certificates by each proxy to 131 determine whether or not their peer is authoritative for the 132 appropriate SIP domain is defined in Domain Certificates in the 133 Session Initiation Protocol (SIP) [8]. 135 A SIP domain name is frequently textually identical to the same DNS 136 name used for other purposes. For example, the DNS name example.com 137 can serve as a SIP domain name, an email domain name, and a web 138 service name. Since these different services within a single 139 organization might be administered independently and hosted 140 separately, it is desirable that a certificate be able to bind the 141 DNS name to its usage as a SIP domain name without creating the 142 implication that the entity presenting the certificate is also 143 authoritative for some other purpose. A mechanism is needed to allow 144 the certificate issued to a proxy to be restricted such that the 145 subject name(s) that the certificate contains are valid only for use 146 in SIP. In our example, Proxy-B possesses a certificate making 147 Proxy-B authoritative as a SIP server for the domain example.net; 148 furthermore, Proxy-B has a policy that requires the client's SIP 149 domain be authenticated through a similar certificate. Proxy-A is 150 authoritative as a SIP server for the domain example.com; when 151 Proxy-A makes a TLS connection to Proxy-B, the latter accepts the 152 connection based on its policy. 154 3. Restricting usage to SIP 156 This memo defines a certificate profile for restricting the usage of 157 a domain name binding to usage as a SIP domain name. RFC 5280 [3] 158 Section 4.2.1.12 defines a mechanism for this purpose: an "Extended 159 Key Usage" (EKU) attribute, where the purpose of the EKU extension is 160 described as: 162 "If the extension is present, then the certificate MUST only be 163 used for one of the purposes indicated. If multiple purposes are 164 indicated the application need not recognize all purposes 165 indicated, as long as the intended purpose is present. 166 Certificate using applications MAY require that the extended key 167 usage extension be present and that a particular purpose be 168 indicated in order for the certificate to be acceptable to that 169 application." 171 A Certificate Authority issuing a certificate whose purpose is to 172 bind a SIP domain identity without binding other non-SIP identities 173 MUST include an id-kp-SIPdomain attribute in the Extended Key Usage 174 extension value (see Section 3.1). 176 3.1. Extended Key Usage values for SIP domains 178 RFC 5280 [3] specifies the EKU X.509 certificate Extension for use in 179 the Internet. The extension indicates one or more purposes for which 180 the certified public key is valid. The EKU extension can be used in 181 conjunction with the key usage extension, which indicates how the 182 public key in the certificate is used, in a more basic cryptographic 183 way. 185 The EKU extension syntax is repeated here for convenience: 187 ExtKeyUsageSyntax ::= SEQUENCE SIZE (1..MAX) OF KeyPurposeId 189 KeyPurposeId ::= OBJECT IDENTIFIER 191 This specification defines the KeyPurposeId id-kp-sipDomain. 192 Inclusion of this KeyPurposeId in a certificate indicates that the 193 use of any Subject names in the certificate is restricted to use by a 194 SIP service (along with any usages allowed by other EKU values). 196 id-kp OBJECT IDENTIFIER ::= 197 { iso(1) identified-organization(3) dod(6) internet(1) 198 security(5) mechanisms(5) pkix(7) 3 } 200 id-kp-sipDomain OBJECT IDENTIFIER ::= { id-kp 20 } 202 4. Using the SIP EKU in a certificate 204 Section 7.1 of Domain Certificates in the Session Initiation Protocol 205 [8] contains the steps for finding an identity (or a set of 206 identities) in an X.509 certificate for SIP. In order to determine 207 whether the usage of a certificate is restricted to serve as a SIP 208 certificate only, implementations MUST perform the step given below 209 as a part of the certificate validation: 211 The implementation MUST examine the Extended Key Usage value(s), if 212 any: 214 o If the certificate does not contain any EKU values (the Extended 215 Key Usage extension does not exist), it is a matter of local 216 policy whether or not to accept the certificate for use as a SIP 217 certificate. Note that since certificates not following this 218 specification will not have the id-kp-sipDomain EKU value, and 219 many do not have any EKU values, the more interoperable local 220 policy would be to accept the certificate. 222 o If the certificate contains the id-kp-sipDomain EKU extension, 223 then implementations of this specification MUST consider the 224 certificate acceptable for use as a SIP certificate. 226 o If the certificate does not contain the id-kp-sipDomain EKU value, 227 but does contain the id-kp-anyExtendedKeyUsage EKU value, it is a 228 matter of local policy whether or not to consider the certificate 229 acceptable for use as a SIP certificate. 231 o If the EKU extension exists, but does not contain any of the id- 232 kp-sipDomain or id-kp-anyExtendedKeyUsage EKU values, then the 233 certificate MUST NOT be accepted as valid for use as a SIP 234 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. Normative References 273 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 274 Levels", RFC 2119, March 1997. 276 [2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 277 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 278 Session Initiation Protocol", RFC 3261, June 2002. 280 [3] Cooper, D., Santesson, S., Farrell, S., Boyen, S., Housley, R., 281 and W. Polk, "Internet X.509 Public Key Infrastructure 282 Certificate and Certificate Revocation List (CRL) Profile", 283 RFC 5280, May 2008. 285 [4] International Telecommunications Union, "Information technology 286 - Open Systems Interconnection - The Directory: Public-key and 287 attribute certificate frameworks", ITU-T Recommendation X.509, 288 ISO Standard 9594-8, March 2000. 290 [5] International International Telephone and Telegraph Consultative 291 Committee, "Abstract Syntax Notation One (ASN.1): Specification 292 of basic notation", CCITT Recommendation X.680, July 2002. 294 [6] International International Telephone and Telegraph Consultative 295 Committee, "ASN.1 encoding rules: Specification of basic 296 encoding Rules (BER), Canonical encoding rules (CER) and 297 Distinguished encoding rules (DER)", CCITT Recommendation X.690, 298 July 2002. 300 [7] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol 301 (SIP): Location SIP Servers", RFC 3263, June 2002. 303 [8] Gurbani, V., Lawrence, S., and A. Jeffrey, "Domain Certificates 304 in the Session Initiation Protocol (SIP)", 305 draft-ietf-sip-domain-certs-04.txt (work in progress), May 2009. 307 Appendix A. ASN.1 Module 309 SIPDomainCertExtn 310 { iso(1) identified-organization(3) dod(6) internet(1) 311 security(5) mechanisms(5) pkix(7) id-mod(0) 312 id-mod-sip-domain-extns2007(62) } 314 DEFINITIONS IMPLICIT TAGS ::= 315 BEGIN 317 -- OID Arcs 319 id-kp OBJECT IDENTIFIER ::= 320 { iso(1) identified-organization(3) dod(6) internet(1) 321 security(5) mechanisms(5) pkix(7) 3 } 323 -- Extended Key Usage Values 325 id-kp-sipDomain OBJECT IDENTIFIER ::= { id-kp 20 } 327 END 329 Authors' Addresses 331 Scott Lawrence 332 Nortel Networks, Inc. 333 600 Technology Park 334 Billerica, MA 01821 335 USA 337 Phone: +1 978 248 5508 338 Email: scott.lawrence@nortel.com 340 Vijay K. Gurbani 341 Bell Laboratories, Alcatel-Lucent 342 1960 Lucent Lane 343 Room 9C-533 344 Naperville, IL 60566 345 USA 347 Phone: +1 630 224-0216 348 Email: vkg@bell-labs.com