idnits 2.17.1 draft-jones-oauth-amr-values-04.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 15, 2015) is 3055 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 17, 2016 Oracle 6 A. Nadalin 7 Microsoft 8 December 15, 2015 10 Authentication Method Reference Values 11 draft-jones-oauth-amr-values-04 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 17, 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 . . . . . . . . . . . . . . 8 72 7.2. OAuth Parameters Registration . . . . . . . . . . . . . . 10 73 7.2.1. Registry Contents . . . . . . . . . . . . . . . . . . 10 74 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 75 8.1. Normative References . . . . . . . . . . . . . . . . . . . 11 76 8.2. Informative References . . . . . . . . . . . . . . . . . . 12 77 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 12 78 Appendix B. Document History . . . . . . . . . . . . . . . . . . 12 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 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 face 137 Facial recognition 139 fpt 140 Fingerprint biometric 142 geo 143 Use of geolocation information 145 hwk 146 Proof-of-possession (PoP) of a hardware-secured key. See Appendix 147 C of [RFC4211] for a discussion on PoP. 149 kba 150 Knowledge-based authentication [NIST.800-63-2] 152 mca 153 Multiple-channel authentication. The authentication involves 154 communication over more than one distinct channel. 156 mfa 157 Multiple-factor authentication [NIST.800-63-2]. When this is 158 present, specific authentication methods used may also be 159 included. 161 otp 162 One-time password. One-time password specifications that this 163 authentication method applies to include [RFC4226] and [RFC6238]. 165 pin 166 Personal Identification Number or pattern (not restricted to 167 containing only numbers) that a user enters to unlock a key on the 168 device. This mechanism SHOULD have a way to deter an attacker 169 from obtaining the PIN by trying repeated guesses. 171 pwd 172 Password-based authentication 174 rba 175 Risk-based authentication [JECM] 177 sc 178 Smart card 180 sms 181 Confirmation using SMS message to the user at a registered number 183 swk 184 Proof-of-possession (PoP) of a software-secured key. See Appendix 185 C of [RFC4211] for a discussion on PoP. 187 tel 188 Confirmation by telephone call to the user at a registered number 190 user 191 User presence test 193 vbm 194 Voice biometric 196 wia 197 Windows integrated authentication, as described in [MSDN] 199 3. Authentication Request Parameter 201 This section defines the following authentication request parameter, 202 augmenting the set of authentication request parameters defined in 203 Section 3.1.2.1 of OpenID Connect Core 1.0 [OpenID.Core]: 205 amr_values 206 OPTIONAL. Requested Authentication Method Reference values. 207 Space-separated string that specifies the "amr" values that the 208 Authorization Server is being requested to use for processing this 209 Authentication Request, with the values appearing in order of 210 preference. The authentication methods used for the 211 authentication performed are returned as the "amr" Claim Value. 213 4. Relationship to "acr" (Authentication Context Class Reference) 215 The "acr" (Authentication Context Class Reference) claim and 216 "acr_values" request parameter are related to the "amr" 217 (Authentication Methods References) claim and "amr_values" request 218 parameter, but with important differences. An Authentication Context 219 Class specifies a set of business rules that authentications are 220 being requested to satisfy. These rules can often be satisfied by 221 using a number of different specific authentication methods, either 222 singly or in combination. Interactions using "acr_values" request 223 that the specified Authentication Context Classes be used and that 224 the result should contain an "acr" claim saying which Authentication 225 Context Class was satisfied. The "acr" claim in the reply states 226 that the business rules for the class were satisfied -- not how they 227 were satisfied. 229 In contrast, interactions using "amr_values" and/or "amr" make 230 statements about the particular authentication methods that are being 231 requested and that were used. This tends to be more brittle than 232 using "acr", since the authentication methods that may be appropriate 233 for a given authentication will vary over time, both because of the 234 evolution of attacks on existing methods and the deployment of new 235 authentication methods. 237 5. Privacy Considerations 239 The list of "amr" claim values returned in an ID Token reveals 240 information about the way that the end-user authenticated to the 241 identity provider. In some cases, this information may have privacy 242 implications. 244 6. Security Considerations 246 The security considerations in OpenID Connect Core 1.0 [OpenID.Core], 247 OAuth 2.0 [RFC6749], and the OAuth 2.0 Threat Model [RFC6819] apply 248 to this specification. 250 As described in Section 4, taking a dependence upon particular 251 authentication methods may result in brittle systems, since the 252 authentication methods that may be appropriate for a given 253 authentication will vary over time. 255 7. IANA Considerations 257 7.1. Authentication Method Reference Values Registry 259 This specification establishes the IANA "Authentication Method 260 Reference Values" registry for "amr" claim array element values. The 261 registry records the Authentication Method Reference value and a 262 reference to the specification that defines it. This specification 263 registers the Authentication Method Reference values defined in 264 Section 2. 266 Values are registered on a Specification Required [RFC5226] basis 267 after a three-week review period on the jwt-reg-review@ietf.org 268 mailing list, on the advice of one or more Designated Experts. 269 However, to allow for the allocation of values prior to publication, 270 the Designated Experts may approve registration once they are 271 satisfied that such a specification will be published. 273 Registration requests sent to the mailing list for review should use 274 an appropriate subject (e.g., "Request to register Authentication 275 Method Reference value: otp"). 277 Within the review period, the Designated Experts will either approve 278 or deny the registration request, communicating this decision to the 279 review list and IANA. Denials should include an explanation and, if 280 applicable, suggestions as to how to make the request successful. 281 Registration requests that are undetermined for a period longer than 282 21 days can be brought to the IESG's attention (using the 283 iesg@ietf.org mailing list) for resolution. 285 Criteria that should be applied by the Designated Experts includes 286 determining whether the proposed registration duplicates existing 287 functionality, whether it is likely to be of general applicability or 288 whether it is useful only for a single application, whether the value 289 is actually being used, and whether the registration description is 290 clear. 292 IANA must only accept registry updates from the Designated Experts 293 and should direct all requests for registration to the review mailing 294 list. 296 It is suggested that the same Designated Experts evaluate these 297 registration requests as those who evaluate registration requests for 298 the IANA "JSON Web Token Claims" registry [IANA.JWT.Claims]. 300 7.1.1. Registration Template 302 Authentication Method Reference Name: 303 The name requested (e.g., "otp"). Because a core goal of this 304 specification is for the resulting representations to be compact, 305 it is RECOMMENDED that the name be short -- that is, not to exceed 306 8 characters without a compelling reason to do so. This name is 307 case sensitive. Names may not match other registered names in a 308 case-insensitive manner unless the Designated Experts state that 309 there is a compelling reason to allow an exception. 311 Authentication Method Reference Description: 312 Brief description of the Authentication Method Reference (e.g., 313 "One-time password"). 315 Change Controller: 316 For Standards Track RFCs, state "IESG". For others, give the name 317 of the responsible party. Other details (e.g., postal address, 318 email address, home page URI) may also be included. 320 Specification Document(s): 321 Reference to the document or documents that specify the parameter, 322 preferably including URIs that can be used to retrieve copies of 323 the documents. An indication of the relevant sections may also be 324 included but is not required. 326 7.1.2. Initial Registry Contents 328 o Authentication Method Reference Name: "eye" 329 o Authentication Method Reference Description: Retina scan biometric 330 o Change Controller: IESG 331 o Specification Document(s): Section 2 of [[ this specification ]] 333 o Authentication Method Reference Name: "face" 334 o Authentication Method Reference Description: Facial recognition 335 o Change Controller: IESG 336 o Specification Document(s): Section 2 of [[ this specification ]] 338 o Authentication Method Reference Name: "fpt" 339 o Authentication Method Reference Description: Fingerprint biometric 340 o Change Controller: IESG 341 o Specification Document(s): Section 2 of [[ this specification ]] 343 o Authentication Method Reference Name: "geo" 344 o Authentication Method Reference Description: Geolocation 345 o Change Controller: IESG 346 o Specification Document(s): Section 2 of [[ this specification ]] 348 o Authentication Method Reference Name: "hwk" 349 o Authentication Method Reference Description: Proof-of-possession 350 of a hardware-secured key 351 o Change Controller: IESG 352 o Specification Document(s): Section 2 of [[ this specification ]] 354 o Authentication Method Reference Name: "kba" 355 o Authentication Method Reference Description: Knowledge-based 356 authentication 358 o Change Controller: IESG 359 o Specification Document(s): Section 2 of [[ this specification ]] 361 o Authentication Method Reference Name: "mca" 362 o Authentication Method Reference Description: Multiple-channel 363 authentication 364 o Change Controller: IESG 365 o Specification Document(s): Section 2 of [[ this specification ]] 367 o Authentication Method Reference Name: "mfa" 368 o Authentication Method Reference Description: Multiple-factor 369 authentication 370 o Change Controller: IESG 371 o Specification Document(s): Section 2 of [[ this specification ]] 373 o Authentication Method Reference Name: "otp" 374 o Authentication Method Reference Description: One-time password 375 o Change Controller: IESG 376 o Specification Document(s): Section 2 of [[ this specification ]] 378 o Authentication Method Reference Name: "pin" 379 o Authentication Method Reference Description: Personal 380 Identification Number or pattern 381 o Change Controller: IESG 382 o Specification Document(s): Section 2 of [[ this specification ]] 384 o Authentication Method Reference Name: "pwd" 385 o Authentication Method Reference Description: Password-based 386 authentication 387 o Change Controller: IESG 388 o Specification Document(s): Section 2 of [[ this specification ]] 390 o Authentication Method Reference Name: "rba" 391 o Authentication Method Reference Description: Risk-based 392 authentication 393 o Change Controller: IESG 394 o Specification Document(s): Section 2 of [[ this specification ]] 396 o Authentication Method Reference Name: "sc" 397 o Authentication Method Reference Description: Smart card 398 o Change Controller: IESG 399 o Specification Document(s): Section 2 of [[ this specification ]] 401 o Authentication Method Reference Name: "sms" 402 o Authentication Method Reference Description: Confirmation using 403 SMS 405 o Change Controller: IESG 406 o Specification Document(s): Section 2 of [[ this specification ]] 408 o Authentication Method Reference Name: "swk" 409 o Authentication Method Reference Description: Proof-of-possession 410 of a software-secured key 411 o Change Controller: IESG 412 o Specification Document(s): Section 2 of [[ this specification ]] 414 o Authentication Method Reference Name: "tel" 415 o Authentication Method Reference Description: Confirmation by 416 telephone call 417 o Change Controller: IESG 418 o Specification Document(s): Section 2 of [[ this specification ]] 420 o Authentication Method Reference Name: "user" 421 o Authentication Method Reference Description: User presence test 422 o Change Controller: IESG 423 o Specification Document(s): Section 2 of [[ this specification ]] 425 o Authentication Method Reference Name: "vbm" 426 o Authentication Method Reference Description: Voice biometric 427 o Change Controller: IESG 428 o Specification Document(s): Section 2 of [[ this specification ]] 430 o Authentication Method Reference Name: "wia" 431 o Authentication Method Reference Description: Windows integrated 432 authentication 433 o Change Controller: IESG 434 o Specification Document(s): Section 2 of [[ this specification ]] 436 7.2. OAuth Parameters Registration 438 This section registers the following parameter in the IANA "OAuth 439 Parameters" registry [IANA.OAuth.Parameters] established in RFC 6749 440 [RFC6749]. 442 7.2.1. Registry Contents 444 o Parameter name: "amr_values" 445 o Parameter usage location: Authorization Request 446 o Change controller: IESG 447 o Specification document(s): Section 3 of [[ this specification ]] 448 o Related information: None 450 8. References 451 8.1. Normative References 453 [IANA.JWT.Claims] 454 IANA, "JSON Web Token Claims", 455 . 457 [IANA.OAuth.Parameters] 458 IANA, "OAuth Parameters", 459 . 461 [JECM] Williamson, G., "Enhanced Authentication In Online 462 Banking", Journal of Economic Crime Management 4.2: 18-19, 463 2006, . 467 [JWT] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 468 (JWT)", RFC 7519, May 2015, 469 . 471 [MSDN] Microsoft, "Integrated Windows Authentication with 472 Negotiate", September 2011, . 477 [NIST.800-63-2] 478 National Institute of Standards and Technology (NIST), 479 "Electronic Authentication Guideline", NIST Special 480 Publication 800-63-2, August 2013, . 484 [OpenID.Core] 485 Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and 486 C. Mortimore, "OpenID Connect Core 1.0", November 2014. 488 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 489 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 490 RFC2119, March 1997, 491 . 493 [RFC4211] Schaad, J., "Internet X.509 Public Key Infrastructure 494 Certificate Request Message Format (CRMF)", RFC 4211, 495 DOI 10.17487/RFC4211, September 2005, 496 . 498 [RFC4226] M'Raihi, D., Bellare, M., Hoornaert, F., Naccache, D., and 499 O. Ranen, "HOTP: An HMAC-Based One-Time Password 500 Algorithm", RFC 4226, DOI 10.17487/RFC4226, December 2005, 501 . 503 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 504 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 505 DOI 10.17487/RFC5226, May 2008, 506 . 508 [RFC6238] M'Raihi, D., Machani, S., Pei, M., and J. Rydell, "TOTP: 509 Time-Based One-Time Password Algorithm", RFC 6238, 510 DOI 10.17487/RFC6238, May 2011, 511 . 513 [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", 514 RFC 6749, DOI 10.17487/RFC6749, October 2012, 515 . 517 8.2. Informative References 519 [RFC6819] Lodderstedt, T., Ed., McGloin, M., and P. Hunt, "OAuth 2.0 520 Threat Model and Security Considerations", RFC 6819, 521 DOI 10.17487/RFC6819, January 2013, 522 . 524 Appendix A. Acknowledgements 526 Caleb Baker participated in specifying the original set of 527 "amr_values" values. John Bradley, Brian Campbell, William Denniss, 528 and Nat Sakimura subsequently provided input on the set of 529 "amr_values" values defined. 531 Appendix B. Document History 533 [[ to be removed by the RFC editor before publication as an RFC ]] 535 -04 537 o Added the values "face" (facial recognition), "geo" (geolocation), 538 "hwk" (proof-of-possession of a hardware-secured key), "pin" 539 (Personal Identification Number or pattern), and "swk" (proof-of- 540 possession of a software-secured key), and removed the value "pop" 541 (proof-of-possession), based on input from members of the OpenID 542 Foundation MODRNA working group. 544 -03 545 o Added language about adding values based upon them being in actual 546 use. 548 -02 550 o Changed the identifier for risk-based authentication from "risk" 551 to "rba", by popular acclaim. 553 o Added "sc" (smart card). 555 -01 557 o Added the values "mca" (multiple-channel authentication), "risk" 558 (risk-based authentication), and "user" (user presence test). 560 o Added citations in the definitions of Windows integrated 561 authentication, knowledge-based authentication, risk-based 562 authentication, multiple-factor authentication, one-time password, 563 and proof-of-possession. 565 o Alphabetized the values. 567 o Added Tony Nadalin as an author and added acknowledgements. 569 -00 571 o Defined the IANA "Authentication Method Reference Values" 572 registry. 574 Authors' Addresses 576 Michael B. Jones 577 Microsoft 579 Email: mbj@microsoft.com 580 URI: http://self-issued.info/ 582 Phil Hunt 583 Oracle 585 Email: phil.hunt@yahoo.com 586 Anthony Nadalin 587 Microsoft 589 Email: tonynad@microsoft.com