idnits 2.17.1 draft-ietf-oauth-amr-values-02.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 (September 9, 2016) is 2779 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: March 13, 2017 Oracle 6 A. Nadalin 7 Microsoft 8 September 9, 2016 10 Authentication Method Reference Values 11 draft-ietf-oauth-amr-values-02 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. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 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 This Internet-Draft will expire on March 13, 2017. 39 Copyright Notice 41 Copyright (c) 2016 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 1.1. Requirements Notation and Conventions . . . . . . . . . . 3 58 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Authentication Method Reference Values . . . . . . . . . . . 3 60 3. Relationship to "acr" (Authentication Context Class 61 Reference) . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 4. Privacy Considerations . . . . . . . . . . . . . . . . . . . 6 63 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 64 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 65 6.1. Authentication Method Reference Values Registry . . . . . 6 66 6.1.1. Registration Template . . . . . . . . . . . . . . . . 7 67 6.1.2. Initial Registry Contents . . . . . . . . . . . . . . 7 68 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 69 7.1. Normative References . . . . . . . . . . . . . . . . . . 10 70 7.2. Informative References . . . . . . . . . . . . . . . . . 11 71 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 11 72 Appendix B. Document History . . . . . . . . . . . . . . . . . . 12 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 75 1. Introduction 77 The "amr" (Authentication Methods References) claim is defined and 78 registered in the IANA "JSON Web Token Claims" registry 79 [IANA.JWT.Claims] but no standard Authentication Method Reference 80 values are currently defined. This specification establishes a 81 registry for Authentication Method Reference values and defines an 82 initial set of Authentication Method Reference values. 84 For context, the "amr" (Authentication Methods References) claim is 85 defined by Section 2 of the OpenID Connect Core 1.0 specification 86 [OpenID.Core] as follows: 88 amr 89 OPTIONAL. Authentication Methods References. JSON array of 90 strings that are identifiers for authentication methods used in 91 the authentication. For instance, values might indicate that both 92 password and OTP authentication methods were used. The definition 93 of particular values to be used in the "amr" Claim is beyond the 94 scope of this specification. Parties using this claim will need 95 to agree upon the meanings of the values used, which may be 96 context-specific. The "amr" value is an array of case sensitive 97 strings. 99 The "amr" values defined by this specification is not intended to be 100 an exhaustive set covering all use cases. Additional values can and 101 will be added to the registry by other specifications. Rather, the 102 values defined herein are an intentionally small set that are already 103 actually being used in practice. 105 For context, while the claim values registered pertain to 106 authentication, note that OAuth 2.0 [RFC6749] is designed for 107 resource authorization and cannot be used for authentication without 108 employing appropriate extensions, such as those defined by OpenID 109 Connect Core 1.0 [OpenID.Core]. The existence of the "amr" claim and 110 values for it should not be taken as encouragement to try to use 111 OAuth 2.0 for authentication without employing extensions enabling 112 secure authentication to be performed. 114 When used with OpenID Connect, if the identity provider supplies an 115 "amr" claim in the ID Token resulting from a successful 116 authentication, the relying party can inspect the values returned and 117 thereby learn details about how the authentication was performed. 118 For instance, the relying party might learn that only a password was 119 used or it might learn that iris recognition was used in combination 120 with a hardware-secured key. Whether "amr" values are provided and 121 which values are understood by what parties are both beyond the scope 122 of this specification. The OpenID Connect MODRNA Authentication 123 Profile 1.0 [OpenID.MODRNA] is one example of an application context 124 that uses "amr" values defined by this specification. 126 1.1. Requirements Notation and Conventions 128 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 129 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 130 "OPTIONAL" in this document are to be interpreted as described in RFC 131 2119 [RFC2119]. 133 1.2. Terminology 135 This specification uses the terms defined by JSON Web Token (JWT) 136 [JWT] and OpenID Connect Core 1.0 [OpenID.Core]. 138 2. Authentication Method Reference Values 140 The following is a list of Authentication Method Reference values 141 defined by this specification: 143 face 144 Facial recognition 146 fpt 147 Fingerprint biometric 149 geo 150 Use of geolocation information 152 hwk 153 Proof-of-possession (PoP) of a hardware-secured key. See 154 Appendix C of [RFC4211] for a discussion on PoP. 156 iris 157 Iris scan biometric 159 kba 160 Knowledge-based authentication [NIST.800-63-2] 162 mca 163 Multiple-channel authentication. The authentication involves 164 communication over more than one distinct communication channel. 165 For instance, a multiple-channel authentication might involve both 166 entering information into a workstation's browser and providing 167 information on a telephone call to a pre-registered number. 169 mfa 170 Multiple-factor authentication [NIST.800-63-2]. When this is 171 present, specific authentication methods used may also be 172 included. 174 otp 175 One-time password. One-time password specifications that this 176 authentication method applies to include [RFC4226] and [RFC6238]. 178 pin 179 Personal Identification Number or pattern (not restricted to 180 containing only numbers) that a user enters to unlock a key on the 181 device. This mechanism should have a way to deter an attacker 182 from obtaining the PIN by trying repeated guesses. 184 pwd 185 Password-based authentication 187 rba 188 Risk-based authentication [JECM] 190 retina 191 Retina scan biometric 193 sc 194 Smart card 196 sms 197 Confirmation using SMS message to the user at a registered number 199 swk 200 Proof-of-possession (PoP) of a software-secured key. See 201 Appendix C of [RFC4211] for a discussion on PoP. 203 tel 204 Confirmation by telephone call to the user at a registered number 206 user 207 User presence test 209 vbm 210 Voice biometric 212 wia 213 Windows integrated authentication, as described in [MSDN] 215 3. Relationship to "acr" (Authentication Context Class Reference) 217 The "acr" (Authentication Context Class Reference) claim and 218 "acr_values" request parameter are related to the "amr" 219 (Authentication Methods References) claim, but with important 220 differences. An Authentication Context Class specifies a set of 221 business rules that authentications are being requested to satisfy. 222 These rules can often be satisfied by using a number of different 223 specific authentication methods, either singly or in combination. 224 Interactions using "acr_values" request that the specified 225 Authentication Context Classes be used and that the result should 226 contain an "acr" claim saying which Authentication Context Class was 227 satisfied. The "acr" claim in the reply states that the business 228 rules for the class were satisfied -- not how they were satisfied. 230 In contrast, interactions using the "amr" claim make statements about 231 the particular authentication methods that were used. This tends to 232 be more brittle than using "acr", since the authentication methods 233 that may be appropriate for a given authentication will vary over 234 time, both because of the evolution of attacks on existing methods 235 and the deployment of new authentication methods. 237 4. 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 5. 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 3, 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 6. IANA Considerations 257 6.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 an Expert Review [RFC5226] basis after a 267 three-week review period on the jwt-reg-review@ietf.org mailing list, 268 on the advice of one or more Designated Experts. To increase 269 potential interoperability, the experts are requested to encourage 270 registrants to provide the location of a publicly-accessible 271 specification defining the values being registered, so that their 272 intended usage can be more easily understood. 274 Registration requests sent to the mailing list for review should use 275 an appropriate subject (e.g., "Request to register Authentication 276 Method Reference value: otp"). 278 Within the review period, the Designated Experts will either approve 279 or deny the registration request, communicating this decision to the 280 review list and IANA. Denials should include an explanation and, if 281 applicable, suggestions as to how to make the request successful. 282 Registration requests that are undetermined for a period longer than 283 21 days can be brought to the IESG's attention (using the 284 iesg@ietf.org mailing list) for resolution. 286 Criteria that should be applied by the Designated Experts includes 287 determining whether the proposed registration duplicates existing 288 functionality, whether it is likely to be of general applicability or 289 whether it is useful only for a single application, whether the value 290 is actually being used, and whether the registration description is 291 clear. 293 IANA must only accept registry updates from the Designated Experts 294 and should direct all requests for registration to the review mailing 295 list. 297 It is suggested that the same Designated Experts evaluate these 298 registration requests as those who evaluate registration requests for 299 the IANA "JSON Web Token Claims" registry [IANA.JWT.Claims]. 301 6.1.1. Registration Template 303 Authentication Method Reference Name: 304 The name requested (e.g., "otp"). Because a core goal of this 305 specification is for the resulting representations to be compact, 306 it is RECOMMENDED that the name be short -- that is, not to exceed 307 8 characters without a compelling reason to do so. This name is 308 case sensitive. Names may not match other registered names in a 309 case-insensitive manner unless the Designated Experts state that 310 there is a compelling reason to allow an exception. 312 Authentication Method Reference Description: 313 Brief description of the Authentication Method Reference (e.g., 314 "One-time password"). 316 Change Controller: 317 For Standards Track RFCs, state "IESG". For others, give the name 318 of the responsible party. Other details (e.g., postal address, 319 email address, home page URI) may also be included. 321 Specification Document(s): 322 Reference to the document or documents that specify the parameter, 323 preferably including URIs that can be used to retrieve copies of 324 the documents. An indication of the relevant sections may also be 325 included but is not required. 327 6.1.2. Initial Registry Contents 329 o Authentication Method Reference Name: "face" 330 o Authentication Method Reference Description: Facial recognition 331 o Change Controller: IESG 332 o Specification Document(s): Section 2 of [[ this specification ]] 333 o Authentication Method Reference Name: "fpt" 334 o Authentication Method Reference Description: Fingerprint biometric 335 o Change Controller: IESG 336 o Specification Document(s): Section 2 of [[ this specification ]] 338 o Authentication Method Reference Name: "geo" 339 o Authentication Method Reference Description: Geolocation 340 o Change Controller: IESG 341 o Specification Document(s): Section 2 of [[ this specification ]] 343 o Authentication Method Reference Name: "hwk" 344 o Authentication Method Reference Description: Proof-of-possession 345 of a hardware-secured key 346 o Change Controller: IESG 347 o Specification Document(s): Section 2 of [[ this specification ]] 349 o Authentication Method Reference Name: "iris" 350 o Authentication Method Reference Description: Iris scan biometric 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 357 o Change Controller: IESG 358 o Specification Document(s): Section 2 of [[ this specification ]] 360 o Authentication Method Reference Name: "mca" 361 o Authentication Method Reference Description: Multiple-channel 362 authentication 363 o Change Controller: IESG 364 o Specification Document(s): Section 2 of [[ this specification ]] 366 o Authentication Method Reference Name: "mfa" 367 o Authentication Method Reference Description: Multiple-factor 368 authentication 369 o Change Controller: IESG 370 o Specification Document(s): Section 2 of [[ this specification ]] 372 o Authentication Method Reference Name: "otp" 373 o Authentication Method Reference Description: One-time password 374 o Change Controller: IESG 375 o Specification Document(s): Section 2 of [[ this specification ]] 377 o Authentication Method Reference Name: "pin" 378 o Authentication Method Reference Description: Personal 379 Identification Number or pattern 380 o Change Controller: IESG 381 o Specification Document(s): Section 2 of [[ this specification ]] 383 o Authentication Method Reference Name: "pwd" 384 o Authentication Method Reference Description: Password-based 385 authentication 386 o Change Controller: IESG 387 o Specification Document(s): Section 2 of [[ this specification ]] 389 o Authentication Method Reference Name: "rba" 390 o Authentication Method Reference Description: Risk-based 391 authentication 392 o Change Controller: IESG 393 o Specification Document(s): Section 2 of [[ this specification ]] 395 o Authentication Method Reference Name: "retina" 396 o Authentication Method Reference Description: Retina scan biometric 397 o Change Controller: IESG 398 o Specification Document(s): Section 2 of [[ this specification ]] 400 o Authentication Method Reference Name: "sc" 401 o Authentication Method Reference Description: Smart card 402 o Change Controller: IESG 403 o Specification Document(s): Section 2 of [[ this specification ]] 405 o Authentication Method Reference Name: "sms" 406 o Authentication Method Reference Description: Confirmation using 407 SMS 408 o Change Controller: IESG 409 o Specification Document(s): Section 2 of [[ this specification ]] 411 o Authentication Method Reference Name: "swk" 412 o Authentication Method Reference Description: Proof-of-possession 413 of a software-secured key 414 o Change Controller: IESG 415 o Specification Document(s): Section 2 of [[ this specification ]] 417 o Authentication Method Reference Name: "tel" 418 o Authentication Method Reference Description: Confirmation by 419 telephone call 420 o Change Controller: IESG 421 o Specification Document(s): Section 2 of [[ this specification ]] 423 o Authentication Method Reference Name: "user" 424 o Authentication Method Reference Description: User presence test 425 o Change Controller: IESG 426 o Specification Document(s): Section 2 of [[ this specification ]] 428 o Authentication Method Reference Name: "vbm" 429 o Authentication Method Reference Description: Voice biometric 430 o Change Controller: IESG 431 o Specification Document(s): Section 2 of [[ this specification ]] 433 o Authentication Method Reference Name: "wia" 434 o Authentication Method Reference Description: Windows integrated 435 authentication 436 o Change Controller: IESG 437 o Specification Document(s): Section 2 of [[ this specification ]] 439 7. References 441 7.1. Normative References 443 [IANA.JWT.Claims] 444 IANA, "JSON Web Token Claims", 445 . 447 [JECM] Williamson, G., "Enhanced Authentication In Online 448 Banking", Journal of Economic Crime Management 4.2: 18-19, 449 2006, 450 . 453 [JWT] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 454 (JWT)", RFC 7519, May 2015, 455 . 457 [MSDN] Microsoft, "Integrated Windows Authentication with 458 Negotiate", September 2011, 459 . 463 [NIST.800-63-2] 464 National Institute of Standards and Technology (NIST), 465 "Electronic Authentication Guideline", NIST Special 466 Publication 800-63-2, August 2013, 467 . 470 [OpenID.Core] 471 Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and 472 C. Mortimore, "OpenID Connect Core 1.0", November 2014, 473 . 475 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 476 Requirement Levels", BCP 14, RFC 2119, 477 DOI 10.17487/RFC2119, March 1997, 478 . 480 [RFC4211] Schaad, J., "Internet X.509 Public Key Infrastructure 481 Certificate Request Message Format (CRMF)", RFC 4211, 482 DOI 10.17487/RFC4211, September 2005, 483 . 485 [RFC4226] M'Raihi, D., Bellare, M., Hoornaert, F., Naccache, D., and 486 O. Ranen, "HOTP: An HMAC-Based One-Time Password 487 Algorithm", RFC 4226, DOI 10.17487/RFC4226, December 2005, 488 . 490 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 491 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 492 DOI 10.17487/RFC5226, May 2008, 493 . 495 [RFC6238] M'Raihi, D., Machani, S., Pei, M., and J. Rydell, "TOTP: 496 Time-Based One-Time Password Algorithm", RFC 6238, 497 DOI 10.17487/RFC6238, May 2011, 498 . 500 [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", 501 RFC 6749, DOI 10.17487/RFC6749, October 2012, 502 . 504 7.2. Informative References 506 [OpenID.MODRNA] 507 Connotte, J. and J. Bradley, "OpenID Connect MODRNA 508 Authentication Profile 1.0", February 2016, 509 . 512 [RFC6819] Lodderstedt, T., Ed., McGloin, M., and P. Hunt, "OAuth 2.0 513 Threat Model and Security Considerations", RFC 6819, 514 DOI 10.17487/RFC6819, January 2013, 515 . 517 Appendix A. Acknowledgements 519 Caleb Baker participated in specifying the original set of "amr" 520 values. John Bradley, Brian Campbell, William Denniss, James Manger, 521 Nat Sakimura, and Mike Schwartz provided reviews of the 522 specification. 524 Appendix B. Document History 526 [[ to be removed by the RFC editor before publication as an RFC ]] 528 -02 530 o Addressed working group last call comments. 532 -01 534 o Distinguished between retina and iris biometrics. 535 o Expanded the introduction to provide additional context to 536 readers. 537 o Referenced the OpenID Connect MODRNA Authentication Profile 1.0 538 specification, which uses "amr" values defined by this 539 specification. 541 -00 543 o Created the initial working group draft from draft-jones-oauth- 544 amr-values-05 with no normative changes. 546 Authors' Addresses 548 Michael B. Jones 549 Microsoft 551 Email: mbj@microsoft.com 552 URI: http://self-issued.info/ 554 Phil Hunt 555 Oracle 557 Email: phil.hunt@yahoo.com 559 Anthony Nadalin 560 Microsoft 562 Email: tonynad@microsoft.com