idnits 2.17.1 draft-ietf-pkix-wlan-extns-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 357. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 364. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 370. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 390), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 390. ** The document claims conformance with section 10 of RFC 2026, but uses some RFC 3978/3979 boilerplate. As RFC 3978/3979 replaces section 10 of RFC 2026, you should not claim conformance with it if you have changed to using RFC 3978/3979 boilerplate. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** The document seems to lack an RFC 3978 Section 5.4 Reference to BCP 78. ** The document seems to lack an RFC 3978 Section 5.5 (updated by RFC 4748) Disclaimer -- however, there's a paragraph with a matching beginning. Boilerplate error? Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The first octets (the first characters of the first line) of this draft are 'PK', which can make Internet Explorer erroneously think that it is a zip file. It is recommended that you change this, for instance by inserting a blank line before the line starting with 'PK'. == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'EAP-TLS' is mentioned on line 41, but not defined == Unused Reference: 'EAPTLS' is defined on line 289, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3281 (ref. 'ACPROFILE') (Obsoleted by RFC 5755) ** Obsolete normative reference: RFC 3280 (ref. 'PROFILE') (Obsoleted by RFC 5280) -- Obsolete informational reference (is this intentional?): RFC 2284 (ref. 'EAP') (Obsoleted by RFC 3748) -- Obsolete informational reference (is this intentional?): RFC 2716 (ref. 'EAPTLS') (Obsoleted by RFC 5216) Summary: 10 errors (**), 0 flaws (~~), 4 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 PKIX Working Group R. Housley 2 Internet-Draft Vigil Security 3 March 2004 T. Moore 4 Expires: September 2004 Microsoft 6 Certificate Extensions and Attributes Supporting 7 Authentication in PPP and Wireless LAN 8 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Abstract 33 This document defines two EAP extended key usage values and a public 34 key certificate extension to carry Wireless LAN (WLAN) System Service 35 identifiers (SSIDs). 37 1. Introduction 39 Several Extensible Authentication Protocol (EAP) [EAP] authentication 40 methods employ X.509 public key certificates. For example, EAP-TLS 41 [EAP-TLS] can be used with PPP [PPP] as well as IEEE 802.1X [802.1X]. 42 PPP is used for dial-up and VPN environments. IEEE 802.1X defines 43 port-based, network access control, and it is used to provide 44 authenticated network access for Ethernet, Token Ring, and Wireless 45 LANs (WLANs) [802.11]. 47 Automated selection of certificates for PPP and IEEE 802.1X clients 48 is highly desirable. By using certificate extensions to identify the 49 intended environment for a particular certificate, the need for user 50 input is minimized. Further, the certificate extensions facilitate 51 the separation of administrative functions associated with 52 certificates used for different environments. 54 IEEE 802.1X can be used for authentication with multiple networks. 55 For example, the same wireless station might use IEEE 802.1X to 56 authenticate to a corporate IEEE 802.11 WLAN and a public IEEE 802.11 57 "hotspot." Each of these IEEE 802.11 WLANs has a different network 58 name, called Service Set Identifier (SSID). If the network operators 59 have a roaming agreement, then cross realm authentication allows the 60 same certificate to be used on both networks. However, if the 61 networks do not have a roaming agreement, then the IEEE 802.1X client 62 needs select a certificate for the current network environment. 63 Including a list of SSIDs in a certificate extension facilitates 64 automated selection of an appropriate X.509 public key certificate 65 without human user input. Alternatively, a companion attribute 66 certificate could contain the list of SSIDs. 68 1.1. Conventions Used In This Document 70 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 71 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 72 document are to be interpreted as described in RFC 2119 [STDWORDS]. 74 1.2. Abstract Syntax Notation 76 All X.509 certificate [X.509] extensions are defined using ASN.1 77 [X.208, X.209]. 79 2. EAP Extended Key Usage Values 81 RFC 3280 [PROFILE] specifies the extended key usage X.509 certificate 82 extension. The extension indicates one or more purposes for which 83 the certified public key may be used. The extended key usage 84 extension can be used in conjunction with key usage extension, which 85 indicates the intended purpose of the certified public key. For 86 example, the key usage extension might indicate that the certified 87 public key ought to be used only for validating digital signatures. 89 The extended key usage extension definition is repeated here for 90 convenience: 92 id-ce-extKeyUsage OBJECT IDENTIFIER ::= {id-ce 37} 94 ExtKeyUsageSyntax ::= SEQUENCE SIZE (1..MAX) OF KeyPurposeId 96 KeyPurposeId ::= OBJECT IDENTIFIER 98 This specification defines two KeyPurposeId values: one for EAP over 99 PPP, and one for EAP over LAN (EAPOL). Inclusion of the EAP over PPP 100 value indicates that the certified public key is appropriate for use 101 with EAP in the PPP environment, and the inclusion of the EAPOL value 102 indicates that the certified public key is appropriate for use with 103 the EAP in the LAN environment. Inclusion of both values indicates 104 that the certified public key is appropriate for use in either of the 105 environments. 107 id-kp OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) 108 dod(6) internet(1) security(5) mechanisms(5) pkix(7) 3 } 110 id-kp-eapOverPPP OBJECT IDENTIFIER ::= { id-kp 13 } 112 id-kp-eapOverLAN OBJECT IDENTIFIER ::= { id-kp 14 } 114 The extended key usage extension may, at the option of the 115 certificate issuer, be either critical or non-critical. If the 116 extension is marked as critical, then the certified public key MUST 117 be used only for the purposes indicated. However, if the extension 118 is marked as non-critical, then extended key usage extension MAY be 119 used to support the location of an appropriate certified public key. 121 If a certificate contains both a critical key usage extension and a 122 critical extended key usage extension, then both extensions MUST be 123 processed independently, and the certificate MUST only be used for a 124 purpose consistent with both extensions. If there is no purpose 125 consistent with both critical extensions, then the certificate MUST 126 NOT be used for any purpose. 128 3. WLAN SSID Public Key Certificate Extension 130 The Wireless LAN (WLAN) System Service identifiers (SSIDs) public key 131 certificate extension is always non-critical. It contains a list of 132 SSIDs. When more than one certificate includes an extended key usage 133 extension indicating that the certified public key is appropriate for 134 use with the EAP in the LAN environment, then the list of SSIDs MAY 135 be used to select the correct certificate for authentication in a 136 particular WLAN. 138 Since SSID values are unmanaged, the same SSID can appear in 139 different certificates that are intended to be used with different 140 WLANs. When this occurs, automatic selection of the certificate will 141 fail, and the implementation SHOULD obtain help from the user to 142 choose the correct certificate. In cases where a human user is 143 unavailable, each potential certificate MAY be tried until one 144 succeeds. However, by maintaining a cache of Access Point (AP) MAC 145 addresses or authentication server identity with which the 146 certificate has successfully authenticated, user involvement can be 147 minimized. RADIUS [RADIUS1, RADIUS2] is usually used as the 148 authentication service in WLAN deployments. The cache can be used to 149 avoid future human user interaction or certificate selection by 150 trial-and-error. 152 The WLAN SSID extension is identified by id-pe-wlanSSID. 154 id-pe OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) 155 dod(6) internet(1) security(5) mechanisms(5) pkix(7) 1 } 157 id-pe-wlanSSID OBJECT IDENTIFIER ::= { id-pe 13 } 159 The syntax for the WLAN SSID extension is: 161 SSIDList ::= SEQUENCE SIZE (1..MAX) OF SSID 163 SSID ::= OCTET STRING (SIZE (1..32)) 165 4. WLAN SSID Attribute Certificate Attribute 167 When the public key certificate does not include the WLAN SSID 168 certificate extension, then an attribute certificate [ACPROFILE] can 169 be used to associate a list of SSIDs with the public key certificate. 170 The WLAN SSIDs attribute certificate attribute contains a list of 171 SSIDs, and the list of SSIDs MAY be used to select the correct 172 certificate for authentication in a particular WLAN environment. 174 The WLAN SSID attribute certificate attribute is identified by 175 id-aca-wlanSSID. 177 id-aca OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) 178 dod(6) internet(1) security(5) mechanisms(5) pkix(7) 10 } 180 id-aca-wlanSSID OBJECT IDENTIFIER ::= { id-aca 6 } 182 The syntax for the WLAN SSID attribute certificate attribute is 183 exactly the same as the WLAN SSID extension: 185 SSIDList ::= SEQUENCE SIZE (1..MAX) OF SSID 187 SSID ::= OCTET STRING (SIZE (1..32)) 189 5. Security Considerations 191 The procedures and practices employed by the certification authority 192 (CA) MUST ensure that the correct values for the extended key usage 193 extension and SSID extension are inserted in each certificate that is 194 issued. Relying parties may accept or reject a particular 195 certificate for an intended use based on the information provided in 196 these extensions. Incorrect representation of the information in 197 either extension could cause the relying party to reject an otherwise 198 appropriate certificate or accept a certificate that ought to be 199 rejected. 201 If multiple SSIDs are included in a certificate, then information can 202 be obtained from a certificate about the SSIDs associated with 203 several WLANs, not the WLAN that is currently being accessed. The 204 intended use of the SSID extensions is to help a client determine the 205 correct certificate to present when trying to gain access to a WLAN. 206 In most situations, including EAP-TLS, the client will have the 207 opportunity to validate the certificate provided by the server before 208 transmitting one of its own certificates to the server. While the 209 client may not be sure that the server has access to the 210 corresponding private key until later in the protocol exchange, the 211 identity information in the server certificate can be used to 212 determine whether or not the client certificate ought to be provided. 213 When the same client certificate is used to authenticate to multiple 214 WLANs, the list of SSIDs is available servers associated with each 215 WLAN. Of course, the list of SSIDs is also made available to any 216 eavesdroppers on the WLAN. Whenever this SSID disclosure is a 217 concern, different client certificates ought to be used for the each 218 WLAN. 220 SSID values are unmanaged; therefore SSIDs may not be unique. Hence, 221 it is possible for client certificates that are intended to be used 222 with different WLANs to contain the same SSID. In this case, 223 automatic selection of the certificate will fail, and the 224 implementation SHOULD obtain help from the user to choose the correct 225 certificate. In cases where a human user is unavailable, each 226 potential certificate MAY be tried until one succeeds, disclosing the 227 list of SSIDs associated with each certificate, which might otherwise 228 not be disclosed. Therefore, it is RECOMMENDED that sequentially 229 trying each certificate only be employed when user selection is 230 unavailable or impractical. 232 In practice, disclosure of the SSID is of little concern. Some WLAN 233 security experts recommend that the SSID be masked in the beacon sent 234 out by Access Points (APs). The intent is to make it harder for an 235 attacker to find the correct AP to target. However, other WLAN 236 management messages include the SSID, so this practice only forces 237 the attacker to eavesdrop on the WLAN management messages instead of 238 the beacon. Therefore, placing the SSID in the certificate does not 239 make matters worse. 241 6. IANA Considerations 243 Certificate extensions and extended key usage values are identified 244 by object identifiers (OIDs). Some of the OIDs used in this document 245 are copied from X.509 [X.509]. Other OIDs were assigned from an arc 246 delegated by the IANA. No further action by the IANA is necessary 247 for this document or any anticipated updates. 249 7. References 251 Normative and informative references are provided. 253 7.1. Normative References 255 [ACPROFILE] Farrell, S., and R. Housley, "An Internet Attribute 256 Certificate Profile for Authorization", RFC 3281, 257 April 2002. 259 [PROFILE] Housley, R., Polk, W., Ford, W. and D. Solo, "Internet 260 X.509 Public Key Infrastructure: Certificate and 261 Certificate Revocation List (CRL) Profile", RFC 3280, 262 April 2002. 264 [STDWORDS] Bradner, S., "Key words for use in RFCs to Indicate 265 Requirement Levels", BCP 14, RFC 2119, March 1997. 267 [X.208] CCITT. Recommendation X.208: Specification of Abstract 268 Syntax Notation One (ASN.1). 1988. 270 [X.209] CCITT. Recommendation X.209: Specification of Basic 271 Encoding Rules for Abstract Syntax Notation One (ASN.1). 272 1988. 274 [X.509] ITU-T. Recommendation X.509: The Directory - 275 Authentication Framework. 2000. 277 7.2. Informative References 279 [802.11] IEEE Std 802.11, "Wireless LAN Medium Access 280 Control (MAC) and Physical Layer (PHY) Specifications", 281 1999. 283 [802.1X] IEEE Std 802.1X, "Port-based Network Access Control", 284 2001. 286 [EAP] Blunk, L. and J. Vollbrecht, "PPP Extensible 287 Authentication Protocol (EAP)", RFC2284, March 1998. 289 [EAPTLS] Aboba, B. and D. Simon, "PPP EAP TLS Authentication 290 Protocol", RFC2716, October 1999. 292 [PPP] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", 293 STD 51, RFC 1661, July 1994. 295 [RADIUS1] Rigney, C., S. Willens, A. Rubens, and W. Simpson, "Remote 296 Authentication Dial In User Service (RADIUS)", RFC 2865, 297 June 2000. 299 [RADIUS2] Congdon, P., B. Aboba, A. Smith, G. Zorn, and J. Roese, 300 "IEEE 802.1X Remote Authentication Dial In User Service 301 (RADIUS) Usage Guidelines", RFC 3580, September 2003. 303 8. ASN.1 Module 305 WLANCertExtn 306 { iso(1) identified-organization(3) dod(6) internet(1) 307 security(5) mechanisms(5) pkix(7) id-mod(0) 308 id-mod-wlan-extns(24) } 310 DEFINITIONS IMPLICIT TAGS ::= 311 BEGIN 313 -- OID Arcs 315 id-pe OBJECT IDENTIFIER ::= 316 { iso(1) identified-organization(3) dod(6) internet(1) 317 security(5) mechanisms(5) pkix(7) 1 } 319 id-kp OBJECT IDENTIFIER ::= 320 { iso(1) identified-organization(3) dod(6) internet(1) 321 security(5) mechanisms(5) pkix(7) 3 } 323 id-aca OBJECT IDENTIFIER ::= 324 { iso(1) identified-organization(3) dod(6) internet(1) 325 security(5) mechanisms(5) pkix(7) 10 } 327 -- Extended Key Usage Values 329 id-kp-eapOverPPP OBJECT IDENTIFIER ::= { id-kp 13 } 331 id-kp-eapOverLAN OBJECT IDENTIFIER ::= { id-kp 14 } 333 -- Wireless LAN SSID Extension 335 id-pe-wlanSSID OBJECT IDENTIFIER ::= { id-pe 13 } 337 SSIDList ::= SEQUENCE SIZE (1..MAX) OF SSID 339 SSID ::= OCTET STRING (SIZE (1..32)) 341 -- Wireless LAN SSID Attribute Certificate Attribute 342 -- Uses same syntax as the certificate extension: SSIDList 344 id-aca-wlanSSID OBJECT IDENTIFIER ::= { id-aca 6 } 346 END 348 9. Intellectual Property 350 The IETF takes no position regarding the validity or scope of any 351 Intellectual Property Rights or other rights that might be claimed to 352 pertain to the implementation or use of the technology described in 353 this document or the extent to which any license under such rights 354 might or might not be available; nor does it represent that it has 355 made any independent effort to identify any such rights. Information 356 on the procedures with respect to rights in RFC documents can be 357 found in BCP 78 and BCP 79. 359 Copies of IPR disclosures made to the IETF Secretariat and any 360 assurances of licenses to be made available, or the result of an 361 attempt made to obtain a general license or permission for the use of 362 such proprietary rights by implementers or users of this 363 specification can be obtained from the IETF on-line IPR repository at 364 http://www.ietf.org/ipr. 366 The IETF invites any interested party to bring to its attention any 367 copyrights, patents or patent applications, or other proprietary 368 rights that may cover technology that may be required to implement 369 this standard. Please address the information to the IETF at ietf- 370 ipr@ietf.org. 372 10. Author's Address 374 Russell Housley 375 Vigil Security, LLC 376 918 Spring Knoll Drive 377 Herndon, VA 20170 378 USA 379 housley@vigilsec.com 381 Tim Moore 382 Microsoft Corporation 383 One Microsoft Way 384 Redmond, WA 98052 385 USA 386 timmoore@microsoft.com 388 11. Full Copyright Statement 390 Copyright (C) The Internet Society 2004. All Rights Reserved. 392 This document and translations of it may be copied and furnished to 393 others, and derivative works that comment on or otherwise explain it 394 or assist in its implementation may be prepared, copied, published 395 and distributed, in whole or in part, without restriction of any 396 kind, provided that the above copyright notice and this paragraph are 397 included on all such copies and derivative works. However, this 398 document itself may not be modified in any way, such as by removing 399 the copyright notice or references to the Internet Society or other 400 Internet organizations, except as needed for the purpose of 401 developing Internet standards in which case the procedures for 402 copyrights defined in the Internet Standards process must be 403 followed, or as required to translate it into languages other than 404 English. 406 The limited permissions granted above are perpetual and will not be 407 revoked by the Internet Society or its successors or assigns. 409 This document and the information contained herein is provided on an 410 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 411 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 412 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 413 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 414 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.