idnits 2.17.1 draft-jones-oauth-amr-values-03.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 (December 4, 2015) is 3065 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. 'JECM' -- Possible downref: Non-RFC (?) normative reference: ref. 'MSDN' ** Downref: Normative reference to an Informational RFC: RFC 4226 ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) ** Downref: Normative reference to an Informational RFC: RFC 6238 Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 OAuth Working Group M. Jones 3 Internet-Draft Microsoft 4 Intended status: Standards Track P. Hunt 5 Expires: June 6, 2016 Oracle 6 A. Nadalin 7 Microsoft 8 December 4, 2015 10 Authentication Method Reference Values 11 draft-jones-oauth-amr-values-03 13 Abstract 15 The "amr" (Authentication Methods References) claim is defined and 16 registered in the IANA "JSON Web Token Claims" registry but no 17 standard Authentication Method Reference values are currently 18 defined. This specification establishes a registry for 19 Authentication Method Reference values and defines an initial set of 20 Authentication Method Reference values. It also defines the 21 "amr_values" (requested Authentication Method Reference values) 22 request parameter for requesting that a set of Authentication Method 23 Reference values be used for processing the Authentication Request. 25 Status of this Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on June 6, 2016. 42 Copyright Notice 44 Copyright (c) 2015 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 1.1. Requirements Notation and Conventions . . . . . . . . . . 3 61 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Authentication Method Reference Values . . . . . . . . . . . . 3 63 3. Authentication Request Parameter . . . . . . . . . . . . . . . 5 64 4. Relationship to "acr" (Authentication Context Class 65 Reference) . . . . . . . . . . . . . . . . . . . . . . . . . . 5 66 5. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 6 67 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 68 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 69 7.1. Authentication Method Reference Values Registry . . . . . 6 70 7.1.1. Registration Template . . . . . . . . . . . . . . . . 7 71 7.1.2. Initial Registry Contents . . . . . . . . . . . . . . 7 72 7.2. OAuth Parameters Registration . . . . . . . . . . . . . . 9 73 7.2.1. Registry Contents . . . . . . . . . . . . . . . . . . 9 74 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 75 8.1. Normative References . . . . . . . . . . . . . . . . . . . 10 76 8.2. Informative References . . . . . . . . . . . . . . . . . . 11 77 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 11 78 Appendix B. Document History . . . . . . . . . . . . . . . . . . 11 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 81 1. Introduction 83 The "amr" (Authentication Methods References) claim is defined and 84 registered in the IANA "JSON Web Token Claims" registry 85 [IANA.JWT.Claims] but no standard Authentication Method Reference 86 values are currently defined. This specification establishes a 87 registry for Authentication Method Reference values and defines an 88 initial set of Authentication Method Reference values. It also 89 defines the "amr_values" (requested Authentication Method Reference 90 values) request parameter for requesting that a set of Authentication 91 Method Reference values be used for processing the Authentication 92 Request. 94 The set of "amr" values defined by this specification is not intended 95 to be an exhaustive set covering all use cases. Additional values 96 can and will be added to the registry by other specifications. 97 Rather, the values defined herein are an intentionally small set that 98 are already actually being used in practice. 100 1.1. Requirements Notation and Conventions 102 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 103 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 104 "OPTIONAL" in this document are to be interpreted as described in RFC 105 2119 [RFC2119]. 107 1.2. Terminology 109 This specification uses the terms defined by JSON Web Token (JWT) 110 [JWT] and OpenID Connect Core 1.0 [OpenID.Core]. 112 2. Authentication Method Reference Values 114 The "amr" (Authentication Methods References) claim is defined by the 115 OpenID Connect Core 1.0 specification [OpenID.Core] as follows: 117 amr 118 OPTIONAL. Authentication Methods References. JSON array of 119 strings that are identifiers for authentication methods used in 120 the authentication. For instance, values might indicate that both 121 password and OTP authentication methods were used. The definition 122 of particular values to be used in the "amr" Claim is beyond the 123 scope of this specification. Parties using this claim will need 124 to agree upon the meanings of the values used, which may be 125 context-specific. The "amr" value is an array of case sensitive 126 strings. 128 However, OpenID Connect does not specify any particular 129 Authentication Method Reference values to be used in the "amr" claim. 130 The following is a list of Authentication Method Reference values 131 defined by this specification: 133 eye 134 Retina scan biometric 136 fpt 137 Fingerprint biometric 139 kba 140 Knowledge-based authentication [NIST.800-63-2] 142 mca 143 Multiple-channel authentication. The authentication involves 144 communication over more than one distinct channel. 146 mfa 147 Multiple-factor authentication [NIST.800-63-2]. When this is 148 present, specific authentication methods used may also be 149 included. 151 otp 152 One-time password. One-time password specifications that this 153 authentication method applies to include [RFC4226] and [RFC6238]. 155 pop 156 Proof-of-possession (PoP) of a key. See Appendix C of [RFC4211] 157 for a discussion on PoP. 159 pwd 160 Password-based authentication 162 rba 163 Risk-based authentication [JECM] 165 sc 166 Smart card 168 sms 169 Confirmation by SMS message 171 tel 172 Confirmation by telephone call 174 user 175 User presence test 177 vbm 178 Voice biometric 180 wia 181 Windows integrated authentication, as described in [MSDN] 183 3. Authentication Request Parameter 185 This section defines the following authentication request parameter, 186 augmenting the set of authentication request parameters defined in 187 Section 3.1.2.1 of OpenID Connect Core 1.0 [OpenID.Core]: 189 amr_values 190 OPTIONAL. Requested Authentication Method Reference values. 191 Space-separated string that specifies the "amr" values that the 192 Authorization Server is being requested to use for processing this 193 Authentication Request, with the values appearing in order of 194 preference. The authentication methods used for the 195 authentication performed are returned as the "amr" Claim Value. 197 4. Relationship to "acr" (Authentication Context Class Reference) 199 The "acr" (Authentication Context Class Reference) claim and 200 "acr_values" request parameter are related to the "amr" 201 (Authentication Methods References) claim and "amr_values" request 202 parameter, but with important differences. An Authentication Context 203 Class specifies a set of business rules that authentications are 204 being requested to satisfy. These rules can often be satisfied by 205 using a number of different specific authentication methods, either 206 singly or in combination. Interactions using "acr_values" request 207 that the specified Authentication Context Classes be used and that 208 the result should contain an "acr" claim saying which Authentication 209 Context Class was satisfied. The "acr" claim in the reply states 210 that the business rules for the class were satisfied -- not how they 211 were satisfied. 213 In contrast, interactions using "amr_values" and/or "amr" make 214 statements about the particular authentication methods that are being 215 requested and that were used. This tends to be more brittle than 216 using "acr", since the authentication methods that may be appropriate 217 for a given authentication will vary over time, both because of the 218 evolution of attacks on existing methods and the deployment of new 219 authentication methods. 221 5. Privacy Considerations 223 The list of "amr" claim values returned in an ID Token reveals 224 information about the way that the end-user authenticated to the 225 identity provider. In some cases, this information may have privacy 226 implications. 228 6. Security Considerations 230 The security considerations in OpenID Connect Core 1.0 [OpenID.Core], 231 OAuth 2.0 [RFC6749], and the OAuth 2.0 Threat Model [RFC6819] apply 232 to this specification. 234 As described in Section 4, taking a dependence upon particular 235 authentication methods may result in brittle systems, since the 236 authentication methods that may be appropriate for a given 237 authentication will vary over time. 239 7. IANA Considerations 241 7.1. Authentication Method Reference Values Registry 243 This specification establishes the IANA "Authentication Method 244 Reference Values" registry for "amr" claim array element values. The 245 registry records the Authentication Method Reference value and a 246 reference to the specification that defines it. This specification 247 registers the Authentication Method Reference values defined in 248 Section 2. 250 Values are registered on a Specification Required [RFC5226] basis 251 after a three-week review period on the jwt-reg-review@ietf.org 252 mailing list, on the advice of one or more Designated Experts. 253 However, to allow for the allocation of values prior to publication, 254 the Designated Experts may approve registration once they are 255 satisfied that such a specification will be published. 257 Registration requests sent to the mailing list for review should use 258 an appropriate subject (e.g., "Request to register Authentication 259 Method Reference value: otp"). 261 Within the review period, the Designated Experts will either approve 262 or deny the registration request, communicating this decision to the 263 review list and IANA. Denials should include an explanation and, if 264 applicable, suggestions as to how to make the request successful. 265 Registration requests that are undetermined for a period longer than 266 21 days can be brought to the IESG's attention (using the 267 iesg@ietf.org mailing list) for resolution. 269 Criteria that should be applied by the Designated Experts includes 270 determining whether the proposed registration duplicates existing 271 functionality, whether it is likely to be of general applicability or 272 whether it is useful only for a single application, whether the value 273 is actually being used, and whether the registration description is 274 clear. 276 IANA must only accept registry updates from the Designated Experts 277 and should direct all requests for registration to the review mailing 278 list. 280 It is suggested that the same Designated Experts evaluate these 281 registration requests as those who evaluate registration requests for 282 the IANA "JSON Web Token Claims" registry [IANA.JWT.Claims]. 284 7.1.1. Registration Template 286 Authentication Method Reference Name: 287 The name requested (e.g., "otp"). Because a core goal of this 288 specification is for the resulting representations to be compact, 289 it is RECOMMENDED that the name be short -- that is, not to exceed 290 8 characters without a compelling reason to do so. This name is 291 case sensitive. Names may not match other registered names in a 292 case-insensitive manner unless the Designated Experts state that 293 there is a compelling reason to allow an exception. 295 Authentication Method Reference Description: 296 Brief description of the Authentication Method Reference (e.g., 297 "One-time password"). 299 Change Controller: 300 For Standards Track RFCs, state "IESG". For others, give the name 301 of the responsible party. Other details (e.g., postal address, 302 email address, home page URI) may also be included. 304 Specification Document(s): 305 Reference to the document or documents that specify the parameter, 306 preferably including URIs that can be used to retrieve copies of 307 the documents. An indication of the relevant sections may also be 308 included but is not required. 310 7.1.2. Initial Registry Contents 312 o Authentication Method Reference Name: "eye" 313 o Authentication Method Reference Description: Retina scan biometric 314 o Change Controller: IESG 315 o Specification Document(s): Section 2 of [[ this specification ]] 317 o Authentication Method Reference Name: "fpt" 318 o Authentication Method Reference Description: Fingerprint biometric 319 o Change Controller: IESG 320 o Specification Document(s): Section 2 of [[ this specification ]] 322 o Authentication Method Reference Name: "kba" 323 o Authentication Method Reference Description: Knowledge-based 324 authentication 325 o Change Controller: IESG 326 o Specification Document(s): Section 2 of [[ this specification ]] 328 o Authentication Method Reference Name: "mca" 329 o Authentication Method Reference Description: Multiple-channel 330 authentication 331 o Change Controller: IESG 332 o Specification Document(s): Section 2 of [[ this specification ]] 334 o Authentication Method Reference Name: "mfa" 335 o Authentication Method Reference Description: Multiple-factor 336 authentication 337 o Change Controller: IESG 338 o Specification Document(s): Section 2 of [[ this specification ]] 340 o Authentication Method Reference Name: "otp" 341 o Authentication Method Reference Description: One-time password 342 o Change Controller: IESG 343 o Specification Document(s): Section 2 of [[ this specification ]] 345 o Authentication Method Reference Name: "pop" 346 o Authentication Method Reference Description: Proof-of-possession 347 of a key 348 o Change Controller: IESG 349 o Specification Document(s): Section 2 of [[ this specification ]] 351 o Authentication Method Reference Name: "pwd" 352 o Authentication Method Reference Description: Password-based 353 authentication 354 o Change Controller: IESG 355 o Specification Document(s): Section 2 of [[ this specification ]] 357 o Authentication Method Reference Name: "rba" 358 o Authentication Method Reference Description: Risk-based 359 authentication 361 o Change Controller: IESG 362 o Specification Document(s): Section 2 of [[ this specification ]] 364 o Authentication Method Reference Name: "sc" 365 o Authentication Method Reference Description: Smart card 366 o Change Controller: IESG 367 o Specification Document(s): Section 2 of [[ this specification ]] 369 o Authentication Method Reference Name: "sms" 370 o Authentication Method Reference Description: Confirmation by SMS 371 reply 372 o Change Controller: IESG 373 o Specification Document(s): Section 2 of [[ this specification ]] 375 o Authentication Method Reference Name: "tel" 376 o Authentication Method Reference Description: Confirmation by 377 telephone call 378 o Change Controller: IESG 379 o Specification Document(s): Section 2 of [[ this specification ]] 381 o Authentication Method Reference Name: "user" 382 o Authentication Method Reference Description: User presence test 383 o Change Controller: IESG 384 o Specification Document(s): Section 2 of [[ this specification ]] 386 o Authentication Method Reference Name: "vbm" 387 o Authentication Method Reference Description: Voice biometric 388 o Change Controller: IESG 389 o Specification Document(s): Section 2 of [[ this specification ]] 391 o Authentication Method Reference Name: "wia" 392 o Authentication Method Reference Description: Windows integrated 393 authentication 394 o Change Controller: IESG 395 o Specification Document(s): Section 2 of [[ this specification ]] 397 7.2. OAuth Parameters Registration 399 This section registers the following parameter in the IANA "OAuth 400 Parameters" registry [IANA.OAuth.Parameters] established in RFC 6749 401 [RFC6749]. 403 7.2.1. Registry Contents 405 o Parameter name: "amr_values" 406 o Parameter usage location: Authorization Request 407 o Change controller: IESG 408 o Specification document(s): Section 3 of [[ this specification ]] 409 o Related information: None 411 8. References 413 8.1. Normative References 415 [IANA.JWT.Claims] 416 IANA, "JSON Web Token Claims", 417 . 419 [IANA.OAuth.Parameters] 420 IANA, "OAuth Parameters", 421 . 423 [JECM] Williamson, G., "Enhanced Authentication In Online 424 Banking", Journal of Economic Crime Management 4.2: 18-19, 425 2006, . 429 [JWT] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 430 (JWT)", RFC 7519, May 2015, 431 . 433 [MSDN] Microsoft, "Integrated Windows Authentication with 434 Negotiate", September 2011, . 439 [NIST.800-63-2] 440 National Institute of Standards and Technology (NIST), 441 "Electronic Authentication Guideline", NIST Special 442 Publication 800-63-2, August 2013, . 446 [OpenID.Core] 447 Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and 448 C. Mortimore, "OpenID Connect Core 1.0", November 2014. 450 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 451 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 452 RFC2119, March 1997, 453 . 455 [RFC4211] Schaad, J., "Internet X.509 Public Key Infrastructure 456 Certificate Request Message Format (CRMF)", RFC 4211, 457 DOI 10.17487/RFC4211, September 2005, 458 . 460 [RFC4226] M'Raihi, D., Bellare, M., Hoornaert, F., Naccache, D., and 461 O. Ranen, "HOTP: An HMAC-Based One-Time Password 462 Algorithm", RFC 4226, DOI 10.17487/RFC4226, December 2005, 463 . 465 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 466 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 467 DOI 10.17487/RFC5226, May 2008, 468 . 470 [RFC6238] M'Raihi, D., Machani, S., Pei, M., and J. Rydell, "TOTP: 471 Time-Based One-Time Password Algorithm", RFC 6238, 472 DOI 10.17487/RFC6238, May 2011, 473 . 475 [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", 476 RFC 6749, DOI 10.17487/RFC6749, October 2012, 477 . 479 8.2. Informative References 481 [RFC6819] Lodderstedt, T., Ed., McGloin, M., and P. Hunt, "OAuth 2.0 482 Threat Model and Security Considerations", RFC 6819, 483 DOI 10.17487/RFC6819, January 2013, 484 . 486 Appendix A. Acknowledgements 488 Caleb Baker participated in specifying the original set of 489 "amr_values" values. Brian Campbell, William Denniss, and Nat 490 Sakimura subsequently provided input on the set of "amr_values" 491 values defined. 493 Appendix B. Document History 495 [[ to be removed by the RFC editor before publication as an RFC ]] 497 -03 499 o Added language about adding values based upon them being in actual 500 use. 502 -02 504 o Changed the identifier for risk-based authentication from "risk" 505 to "rba", by popular acclaim. 507 o Added "sc" (smart card). 509 -01 511 o Added the values "mca" (multiple-channel authentication), "risk" 512 (risk-based authentication), and "user" (user presence test). 514 o Added citations in the definitions of Windows integrated 515 authentication, knowledge-based authentication, risk-based 516 authentication, multiple-factor authentication, one-time password, 517 and proof-of-possession. 519 o Alphabetized the values. 521 o Added Tony Nadalin as an author and added acknowledgements. 523 -00 525 o Defined the IANA "Authentication Method Reference Values" 526 registry. 528 Authors' Addresses 530 Michael B. Jones 531 Microsoft 533 Email: mbj@microsoft.com 534 URI: http://self-issued.info/ 536 Phil Hunt 537 Oracle 539 Email: phil.hunt@yahoo.com 541 Anthony Nadalin 542 Microsoft 544 Email: tonynad@microsoft.com