idnits 2.17.1 draft-wallace-est-alt-challenge-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 13, 2016) is 2897 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) ** Downref: Normative reference to an Informational RFC: RFC 2985 ** Downref: Normative reference to an Informational RFC: RFC 5912 == Outdated reference: A later version (-16) exists of draft-gutmann-scep-01 Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Pritikin 3 Internet-Draft Cisco Systems, Inc. 4 Intended status: Standards Track C. Wallace 5 Expires: October 15, 2016 Red Hound Software, Inc. 6 April 13, 2016 8 Alternative Challenge Password Attributes for Enrollment over Secure 9 Transport 10 draft-wallace-est-alt-challenge-08 12 Abstract 14 This document defines a set of new Certificate Signing Request 15 attributes for use with the Enrollment over Secure Transport (EST) 16 protocol. These attributes provide disambiguation of the existing 17 overloaded uses for the challengePassword attribute defined in PKCS 18 (Public-Key Cryptography Standards) #9 (RFC2985). Uses include the 19 original certificate revocation password, common authentication 20 password uses, and EST-defined linking of transport security 21 identity. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on October 15, 2016. 40 Copyright Notice 42 Copyright (c) 2016 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. Alternative Challenge Password Attributes . . . . . . . . . . 3 60 3.1. OTP Challenge Attribute . . . . . . . . . . . . . . . . . 4 61 3.2. Revocation Challenge Attribute . . . . . . . . . . . . . 4 62 3.3. EST Identity Linking Attribute . . . . . . . . . . . . . 5 63 4. Indicating Support for the Alternative Challenge Attributes . 5 64 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 65 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 66 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 67 7.1. Normative References . . . . . . . . . . . . . . . . . . 6 68 7.2. Informative References . . . . . . . . . . . . . . . . . 7 69 Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 8 70 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 9 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 73 1. Introduction 75 PKCS (Public-Key Cryptography Standards) #9 [RFC2985] defined a 76 challengePassword attribute that has been overloaded by modern 77 protocol usage with the appropriate interpretation being provided by 78 context rather than OID definition. PKCS #9 defines the 79 challengePassword attribute as "a password by which an entity may 80 request certificate revocation". The parsing and embedding of this 81 attribute within Certificate Signing Requests is well supported by 82 common PKI tool sets, but many work-flows leverage this supported 83 field as a one-time password for authentication. For example this is 84 codified in many Simple Certificate Enrollment Protocol (SCEP) 85 implementations as indicated by [I-D.gutmann-scep]. Continuing this 86 trend, Enrollment over Secure Transport (EST) [RFC7030] defines an 87 additional semantic for the challengePassword attribute in 88 Section 3.5, in order to provide a linking of the Certificate Signing 89 Request (CSR) to the secure transport. 91 Where the context of the protocol operation fully defined the proper 92 semantic, and when only one use was required at a time, the 93 overloading of this field did not cause difficulties. Implementation 94 experience with EST has shown this to be a limitation though. There 95 are plausible use cases where it is valuable to use either of the 96 existing methods separately or in concert. For example an EST server 97 might require the client to authenticate itself using the existing 98 client X.509 certificate, the user's username and password and to 99 include a one-time password within the CSR all while maintaining 100 identity linking to bind the CSR to the secure transport. The 101 overloading of a single attribute type should not be the limiting 102 factor for administrators attempting to meet their security 103 requirements. 105 This document defines the otpChallenge attribute for use when a one- 106 time password (OTP) value within the CSR is a requirement. The 107 revocationChallenge attribute is defined to allow disambiguated usage 108 of the original challenge password attribute semantics for 109 certificate revocation. The estIdentityLinking attribute is defined 110 to reference existing EST challenge password semantics with no 111 potential for confusion with legacy challenge password practices. 113 The attributes defined in this specification supplement existing EST 114 mechanisms and are not intended to displace current usage of any 115 existing EST authentication mechanisms. Conveying the authentication 116 value itself as an attribute may be preferable to using an HTTP or 117 Transport Layer Security (TLS) password or other TLS authentication 118 mechanism in environments where the certificate request processing 119 component is removed from the HTTP/TLS termination point, for 120 example, when a web application firewall is used. 122 2. Terminology 124 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 125 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 126 document are to be interpreted as described in [RFC2119]. 128 3. Alternative Challenge Password Attributes 130 The following sections describe three alternative challenge password 131 attributes for use with EST [RFC7030]. Appendix A provides an ASN.1 132 module containing the new definitions. 134 Each attribute described below is defined as a DirectoryString with 135 maximum length 255, which features several possible encoding options. 136 Attribute values generated in accordance this document SHOULD use the 137 PrintableString encoding whenever possible. If internationalization 138 issues make this impossible, the UTF8String alternative SHOULD be 139 used. Attribute processing systems MUST be able to recognize and 140 process the PrintableString and UTF8String string types in 141 DirectoryString values. Support for other string types is OPTIONAL. 143 3.1. OTP Challenge Attribute 145 The otpChallenge attribute is defined as a DirectoryString with an 146 maximum length of 255. This is consistent with the challengePassword 147 attribute as originally defined in PKCS#9 [RFC2985]. The 148 otpChallenge attribute is identified by the id-aa-otpChallenge object 149 identifier. This facilitates reuse of existing challengePassword 150 code by associating the new object identifiers with the existing 151 parsing and generation code. This attribute provides a means of 152 conveying a one-time password value as part of a CSR request. 153 Generation, verification, storage, etc. of the value is not addressed 154 by this specification. [RFC4226] and [RFC6238] define one-time 155 password mechanisms that MAY be used with this attribute. 157 ub-aa-otpChallenge INTEGER ::= 255 158 id-aa-otpChallenge OBJECT IDENTIFIER ::= { 159 id-smime TBD1 160 } 161 otpChallenge ATTRIBUTE ::= { 162 WITH SYNTAX DirectoryString {ub-aa-otpChallenge} 163 EQUALITY MATCHING RULE caseExactMatch 164 SINGLE VALUE TRUE 165 ID id-aa-otpChallenge 166 } 168 3.2. Revocation Challenge Attribute 170 The original PKCS#9 challengePassword field has been overloaded and 171 the common use is unclear. The revocationChallenge attribute defined 172 here provides an unambiguous method of indicating the original PKCS#9 173 intent for this attribute type. The revocationChallenge attribute is 174 identified by the id-aa-revocationChallenge object identifier. 175 [RFC2985] discusses the original semantics for the PKCS #9 challenge 176 password attribute. 178 ub-aa-revocationChallenge INTEGER ::= 255 179 id-aa-revocationChallenge OBJECT IDENTIFIER ::= { 180 id-smime TBD2 181 } 182 revocationChallenge ATTRIBUTE ::= { 183 WITH SYNTAX DirectoryString {ub-aa-revocationChallenge} 184 EQUALITY MATCHING RULE caseExactMatch 185 SINGLE VALUE TRUE 186 ID id-aa-revocationChallenge 187 } 189 3.3. EST Identity Linking Attribute 191 EST defines a mechanism for associating identity information from an 192 authenticated TLS session with proof-of-possession information in a 193 certificate request. The mechanism was labeled using the pkcs-9-at- 194 challengePassword identifier from [RFC2985]. To avoid any confusion 195 with the semantics described in [RFC2985] or any other specifications 196 that similarly defined use of the PKCS #9 challenge password 197 attribute for their own purposes, a new object identifier is defined 198 here and associated with the semantics described in section 3.5 of 199 [RFC7030]. 201 ub-aa-est-identity-linking INTEGER ::= 255 202 id-aa-estIdentityLinking OBJECT IDENTIFIER ::= { 203 id-smime TBD3 204 } 205 estIdentityLinking ATTRIBUTE ::= { 206 WITH SYNTAX DirectoryString {ub-aa-est-identity-linking} 207 EQUALITY MATCHING RULE caseExactMatch 208 SINGLE VALUE TRUE 209 ID id-aa-estIdentityLinking 210 } 212 4. Indicating Support for the Alternative Challenge Attributes 214 The EST server MUST indicate these attributes, as the particular use 215 case requires, in every CSR Attributes Response. An EST server MAY 216 send both the "estIdentityLinking" and also the [RFC7030] 217 "challengePassword" in a CSR Attrs response to ensure support for 218 legacy [RFC7030] clients. 220 The client MUST include every indicated attribute for which it has 221 values in the subsequent CSR. If a client sees "estIdentityLinking" 222 in a CSR Attributes Response it SHOULD prefer that and not include an 223 [RFC7030] "challengePassword" in the resulting CSR. EST clients that 224 include an unsolicited "estIdentityLinking" attribute MAY also 225 include the [RFC7030] "challengePassword" attribute to ensure support 226 for legacy [RFC7030] servers. 228 EST servers MUST evaluate each challenge attribute independently. 229 All challenge attributes included by an EST client MUST be 230 successfully processed by an EST server for a request to be 231 considered valid. The EST server MAY ignore challenge attributes 232 according to local policy, for example if the EST client is an 233 authenticated Registration Authority the EST server ignores the 234 "estIdentityLinking" within a CSR (see Section 3.7 of [RFC7030]). 235 The EST server MAY refuse enrollment requests that are not encoded 236 according to the CA's policy. 238 5. Security Considerations 240 In addition to the security considerations expressed in the EST 241 specification [RFC7030], additional security considerations may be 242 associated with the mechanism used to generate and verify the 243 otpChallenge value. Where a one-time password is used, the security 244 considerations expressed in the "HOTP: An HMAC-Based One-Time 245 Password Algorithm" [RFC4226] or "TOTP: Time-Based One-Time Password 246 Algorithm" [RFC6238] specifications may be relevant. Similarly, the 247 security considerations from [RFC2985] that apply to the challenge 248 attribute are relevant as well. 250 6. IANA Considerations 252 Section 3 defines three attributes that need object identifier 253 assignments from the SMI Security for S/MIME Attributes 254 (1.2.840.113549.1.9.16.2) registry [RFC7107]. 256 [RFC Editor: please replace the TBDx references below, in section 257 3.1, in section 3.2, in section 3.3 and in Appendix A.] 259 Value Description Reference 260 -------- --------------------------------- --------- 261 TBD1 id-aa-otpChallenge [this document] 262 TBD2 id-aa-revocationChallenge [this document] 263 TBD3 id-aa-estIdentityLinking [this document] 265 Appendix A contains an ASN.1 module, and a module identifier needs to 266 be assigned from the SMI Security for PKIX Module Identifier registry 267 [RFC7299]. 269 Value Description Reference 270 -------- --------------------------------- --------- 271 TBD4 id-mod-EST-Alt-Challenge [this document] 273 7. References 275 7.1. Normative References 277 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 278 Requirement Levels", BCP 14, RFC 2119, 279 DOI 10.17487/RFC2119, March 1997, 280 . 282 [RFC2985] Nystrom, M. and B. Kaliski, "PKCS #9: Selected Object 283 Classes and Attribute Types Version 2.0", RFC 2985, 284 DOI 10.17487/RFC2985, November 2000, 285 . 287 [RFC5272] Schaad, J. and M. Myers, "Certificate Management over CMS 288 (CMC)", RFC 5272, DOI 10.17487/RFC5272, June 2008, 289 . 291 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 292 Housley, R., and W. Polk, "Internet X.509 Public Key 293 Infrastructure Certificate and Certificate Revocation List 294 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 295 . 297 [RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the 298 Public Key Infrastructure Using X.509 (PKIX)", RFC 5912, 299 DOI 10.17487/RFC5912, June 2010, 300 . 302 [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., 303 "Enrollment over Secure Transport", RFC 7030, 304 DOI 10.17487/RFC7030, October 2013, 305 . 307 7.2. Informative References 309 [RFC4226] M'Raihi, D., Bellare, M., Hoornaert, F., Naccache, D., and 310 O. Ranen, "HOTP: An HMAC-Based One-Time Password 311 Algorithm", RFC 4226, DOI 10.17487/RFC4226, December 2005, 312 . 314 [RFC6238] M'Raihi, D., Machani, S., Pei, M., and J. Rydell, "TOTP: 315 Time-Based One-Time Password Algorithm", RFC 6238, 316 DOI 10.17487/RFC6238, May 2011, 317 . 319 [RFC7107] Housley, R., "Object Identifier Registry for the S/MIME 320 Mail Security Working Group", RFC 7107, 321 DOI 10.17487/RFC7107, January 2014, 322 . 324 [RFC7299] Housley, R., "Object Identifier Registry for the PKIX 325 Working Group", RFC 7299, DOI 10.17487/RFC7299, July 2014, 326 . 328 [I-D.gutmann-scep] 329 Gutmann, P. and J. Marcon, "Simple Certificate Enrolment 330 Protocol", draft-gutmann-scep-01 (work in progress), 331 September 2015. 333 Appendix A. ASN.1 Module 335 The following ASN.1 module includes the definitions to support usage 336 of the attributes defined in this specification. Modules from 337 [RFC5912] are imported (original standards-track source for the 338 imported structures is [RFC5280] and [RFC5272]. 340 Mod-EST-Alt-Challenge { 341 iso(1) identified-organization(3) dod(6) internet(1) security(5) 342 mechanisms(5) pkix(7) id-mod(0) TBD4 343 } 345 DEFINITIONS IMPLICIT TAGS ::= 346 BEGIN 347 IMPORTS 349 DirectoryString{} 350 FROM PKIX1Explicit-2009 { 351 iso(1) identified-organization(3) dod(6) internet(1) security(5) 352 mechanisms(5) pkix(7) id-mod(0) id-mod-pkix1-explicit-02(51) 353 } 355 ATTRIBUTE 356 FROM PKIX-CommonTypes-2009 { 357 iso(1) identified-organization(3) dod(6) internet(1) security(5) 358 mechanisms(5) pkix(7) id-mod(0) id-mod-pkixCommon-02(57) 359 }; 361 ub-aa-otpChallenge INTEGER ::= 255 362 id-aa-otpChallenge OBJECT IDENTIFIER ::= { 363 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 364 smime(16) aa(2) TBD1 365 } 366 otpChallenge ATTRIBUTE ::= { 367 TYPE DirectoryString {ub-aa-otpChallenge} 368 COUNTS MIN 1 MAX 1 369 IDENTIFIED BY id-aa-otpChallenge 370 } 371 ub-aa-revocationChallenge INTEGER ::= 255 372 id-aa-revocationChallenge OBJECT IDENTIFIER ::= { 373 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 374 smime(16) aa(2) TBD2 375 } 376 revocationChallenge ATTRIBUTE ::= { 377 TYPE DirectoryString {ub-aa-revocationChallenge} 378 COUNTS MIN 1 MAX 1 379 IDENTIFIED BY id-aa-revocationChallenge 380 } 381 ub-aa-est-identity-linking INTEGER ::= 255 382 id-aa-estIdentityLinking OBJECT IDENTIFIER ::= { 383 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 384 smime(16) aa(2) TBD3 385 } 386 estIdentityLinking ATTRIBUTE ::= { 387 TYPE DirectoryString {ub-aa-est-identity-linking} 388 COUNTS MIN 1 MAX 1 389 IDENTIFIED BY id-aa-estIdentityLinking 390 } 391 END 393 Appendix B. Acknowledgements 395 Thanks to Jim Schaad, Dan Harkins, Phil Scheffler, Geoff Beier, Mike 396 Jenkins and Deb Cooley for their feedback. 398 Authors' Addresses 400 Max Pritikin 401 Cisco Systems, Inc. 402 510 McCarthy Drive 403 Milpitas, CA 95035 404 USA 406 Email: pritikin@cisco.com 408 Carl Wallace 409 Red Hound Software, Inc. 411 Email: carl@redhoundsoftware.com