idnits 2.17.1 draft-ietf-oauth-amr-values-01.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 (July 7, 2016) is 2848 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: January 8, 2017 Oracle 6 A. Nadalin 7 Microsoft 8 July 7, 2016 10 Authentication Method Reference Values 11 draft-ietf-oauth-amr-values-01 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 January 8, 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 . . . . . . . . . . . . . . . . . . . 5 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 The set of "amr" values defined by this specification is not intended 85 to be an exhaustive set covering all use cases. Additional values 86 can and will be added to the registry by other specifications. 87 Rather, the values defined herein are an intentionally small set that 88 are already actually being used in practice. 90 For context, while the claim values registered pertain to 91 authentication, note that OAuth 2.0 [RFC6749] is designed for 92 resource authorization and cannot be used for authentication without 93 employing appropriate extensions, such as those defined by OpenID 94 Connect Core 1.0 [OpenID.Core]. The existence of the "amr" claim and 95 values for it should not be taken as encouragement to try to use 96 OAuth 2.0 for authentication without employing extensions enabling 97 secure authentication to be performed. 99 When used with OpenID Connect, if the identity provider supplies an 100 "amr" claim in the ID Token resulting from a successful 101 authentication, the relying party can inspect the values returned and 102 thereby learn details about how the authentication was performed. 103 For instance, the relying party might learn that only a password was 104 used or it might learn that iris recognition was used in combination 105 with a hardware-secured key. Whether "amr" values are provided and 106 which values are understood by what parties are both beyond the scope 107 of this specification. The OpenID Connect MODRNA Authentication 108 Profile 1.0 [OpenID.MODRNA] is one example of an application context 109 that uses "amr" values defined by this specification. 111 1.1. Requirements Notation and Conventions 113 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 114 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 115 "OPTIONAL" in this document are to be interpreted as described in RFC 116 2119 [RFC2119]. 118 1.2. Terminology 120 This specification uses the terms defined by JSON Web Token (JWT) 121 [JWT] and OpenID Connect Core 1.0 [OpenID.Core]. 123 2. Authentication Method Reference Values 125 The "amr" (Authentication Methods References) claim is defined by the 126 OpenID Connect Core 1.0 specification [OpenID.Core] as follows: 128 amr 129 OPTIONAL. Authentication Methods References. JSON array of 130 strings that are identifiers for authentication methods used in 131 the authentication. For instance, values might indicate that both 132 password and OTP authentication methods were used. The definition 133 of particular values to be used in the "amr" Claim is beyond the 134 scope of this specification. Parties using this claim will need 135 to agree upon the meanings of the values used, which may be 136 context-specific. The "amr" value is an array of case sensitive 137 strings. 139 However, OpenID Connect does not specify any particular 140 Authentication Method Reference values to be used in the "amr" claim. 141 The following is a list of Authentication Method Reference values 142 defined by this specification: 144 face 145 Facial recognition 147 fpt 148 Fingerprint biometric 150 geo 151 Use of geolocation information 153 hwk 154 Proof-of-possession (PoP) of a hardware-secured key. See 155 Appendix C of [RFC4211] for a discussion on PoP. 157 iris 158 Iris scan biometric 160 kba 161 Knowledge-based authentication [NIST.800-63-2] 163 mca 164 Multiple-channel authentication. The authentication involves 165 communication over more than one distinct channel. 167 mfa 168 Multiple-factor authentication [NIST.800-63-2]. When this is 169 present, specific authentication methods used may also be 170 included. 172 otp 173 One-time password. One-time password specifications that this 174 authentication method applies to include [RFC4226] and [RFC6238]. 176 pin 177 Personal Identification Number or pattern (not restricted to 178 containing only numbers) that a user enters to unlock a key on the 179 device. This mechanism SHOULD have a way to deter an attacker 180 from obtaining the PIN by trying repeated guesses. 182 pwd 183 Password-based authentication 185 rba 186 Risk-based authentication [JECM] 188 retina 189 Retina scan biometric 191 sc 192 Smart card 194 sms 195 Confirmation using SMS message to the user at a registered number 197 swk 198 Proof-of-possession (PoP) of a software-secured key. See 199 Appendix C of [RFC4211] for a discussion on PoP. 201 tel 202 Confirmation by telephone call to the user at a registered number 204 user 205 User presence test 207 vbm 208 Voice biometric 210 wia 211 Windows integrated authentication, as described in [MSDN] 213 3. 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, but with important 218 differences. An Authentication Context Class specifies a set of 219 business rules that authentications are being requested to satisfy. 220 These rules can often be satisfied by using a number of different 221 specific authentication methods, either singly or in combination. 222 Interactions using "acr_values" request that the specified 223 Authentication Context Classes be used and that the result should 224 contain an "acr" claim saying which Authentication Context Class was 225 satisfied. The "acr" claim in the reply states that the business 226 rules for the class were satisfied -- not how they were satisfied. 228 In contrast, interactions using the "amr" claim make statements about 229 the particular authentication methods that were used. This tends to 230 be more brittle than using "acr", since the authentication methods 231 that may be appropriate for a given authentication will vary over 232 time, both because of the evolution of attacks on existing methods 233 and the deployment of new authentication methods. 235 4. Privacy Considerations 237 The list of "amr" claim values returned in an ID Token reveals 238 information about the way that the end-user authenticated to the 239 identity provider. In some cases, this information may have privacy 240 implications. 242 5. Security Considerations 244 The security considerations in OpenID Connect Core 1.0 [OpenID.Core], 245 OAuth 2.0 [RFC6749], and the OAuth 2.0 Threat Model [RFC6819] apply 246 to this specification. 248 As described in Section 3, taking a dependence upon particular 249 authentication methods may result in brittle systems, since the 250 authentication methods that may be appropriate for a given 251 authentication will vary over time. 253 6. IANA Considerations 255 6.1. Authentication Method Reference Values Registry 257 This specification establishes the IANA "Authentication Method 258 Reference Values" registry for "amr" claim array element values. The 259 registry records the Authentication Method Reference value and a 260 reference to the specification that defines it. This specification 261 registers the Authentication Method Reference values defined in 262 Section 2. 264 Values are registered on an Expert Review [RFC5226] basis after a 265 three-week review period on the jwt-reg-review@ietf.org mailing list, 266 on the advice of one or more Designated Experts. To increase 267 potential interoperability, the experts are requested to encourage 268 registrants to provide the location of a publicly-accessible 269 specification defining the values being registered, so that their 270 intended usage can be more easily understood. 272 Registration requests sent to the mailing list for review should use 273 an appropriate subject (e.g., "Request to register Authentication 274 Method Reference value: otp"). 276 Within the review period, the Designated Experts will either approve 277 or deny the registration request, communicating this decision to the 278 review list and IANA. Denials should include an explanation and, if 279 applicable, suggestions as to how to make the request successful. 280 Registration requests that are undetermined for a period longer than 281 21 days can be brought to the IESG's attention (using the 282 iesg@ietf.org mailing list) for resolution. 284 Criteria that should be applied by the Designated Experts includes 285 determining whether the proposed registration duplicates existing 286 functionality, whether it is likely to be of general applicability or 287 whether it is useful only for a single application, whether the value 288 is actually being used, and whether the registration description is 289 clear. 291 IANA must only accept registry updates from the Designated Experts 292 and should direct all requests for registration to the review mailing 293 list. 295 It is suggested that the same Designated Experts evaluate these 296 registration requests as those who evaluate registration requests for 297 the IANA "JSON Web Token Claims" registry [IANA.JWT.Claims]. 299 6.1.1. Registration Template 301 Authentication Method Reference Name: 302 The name requested (e.g., "otp"). Because a core goal of this 303 specification is for the resulting representations to be compact, 304 it is RECOMMENDED that the name be short -- that is, not to exceed 305 8 characters without a compelling reason to do so. This name is 306 case sensitive. Names may not match other registered names in a 307 case-insensitive manner unless the Designated Experts state that 308 there is a compelling reason to allow an exception. 310 Authentication Method Reference Description: 311 Brief description of the Authentication Method Reference (e.g., 312 "One-time password"). 314 Change Controller: 315 For Standards Track RFCs, state "IESG". For others, give the name 316 of the responsible party. Other details (e.g., postal address, 317 email address, home page URI) may also be included. 319 Specification Document(s): 320 Reference to the document or documents that specify the parameter, 321 preferably including URIs that can be used to retrieve copies of 322 the documents. An indication of the relevant sections may also be 323 included but is not required. 325 6.1.2. Initial Registry Contents 327 o Authentication Method Reference Name: "face" 328 o Authentication Method Reference Description: Facial recognition 329 o Change Controller: IESG 330 o Specification Document(s): Section 2 of [[ this specification ]] 332 o Authentication Method Reference Name: "fpt" 333 o Authentication Method Reference Description: Fingerprint biometric 334 o Change Controller: IESG 335 o Specification Document(s): Section 2 of [[ this specification ]] 337 o Authentication Method Reference Name: "geo" 338 o Authentication Method Reference Description: Geolocation 339 o Change Controller: IESG 340 o Specification Document(s): Section 2 of [[ this specification ]] 342 o Authentication Method Reference Name: "hwk" 343 o Authentication Method Reference Description: Proof-of-possession 344 of a hardware-secured key 345 o Change Controller: IESG 346 o Specification Document(s): Section 2 of [[ this specification ]] 348 o Authentication Method Reference Name: "iris" 349 o Authentication Method Reference Description: Iris scan biometric 350 o Change Controller: IESG 351 o Specification Document(s): Section 2 of [[ this specification ]] 353 o Authentication Method Reference Name: "kba" 354 o Authentication Method Reference Description: Knowledge-based 355 authentication 356 o Change Controller: IESG 357 o Specification Document(s): Section 2 of [[ this specification ]] 359 o Authentication Method Reference Name: "mca" 360 o Authentication Method Reference Description: Multiple-channel 361 authentication 362 o Change Controller: IESG 363 o Specification Document(s): Section 2 of [[ this specification ]] 365 o Authentication Method Reference Name: "mfa" 366 o Authentication Method Reference Description: Multiple-factor 367 authentication 368 o Change Controller: IESG 369 o Specification Document(s): Section 2 of [[ this specification ]] 371 o Authentication Method Reference Name: "otp" 372 o Authentication Method Reference Description: One-time password 373 o Change Controller: IESG 374 o Specification Document(s): Section 2 of [[ this specification ]] 376 o Authentication Method Reference Name: "pin" 377 o Authentication Method Reference Description: Personal 378 Identification Number or pattern 379 o Change Controller: IESG 380 o Specification Document(s): Section 2 of [[ this specification ]] 382 o Authentication Method Reference Name: "pwd" 383 o Authentication Method Reference Description: Password-based 384 authentication 385 o Change Controller: IESG 386 o Specification Document(s): Section 2 of [[ this specification ]] 388 o Authentication Method Reference Name: "rba" 389 o Authentication Method Reference Description: Risk-based 390 authentication 391 o Change Controller: IESG 392 o Specification Document(s): Section 2 of [[ this specification ]] 394 o Authentication Method Reference Name: "retina" 395 o Authentication Method Reference Description: Retina scan biometric 396 o Change Controller: IESG 397 o Specification Document(s): Section 2 of [[ this specification ]] 399 o Authentication Method Reference Name: "sc" 400 o Authentication Method Reference Description: Smart card 401 o Change Controller: IESG 402 o Specification Document(s): Section 2 of [[ this specification ]] 404 o Authentication Method Reference Name: "sms" 405 o Authentication Method Reference Description: Confirmation using 406 SMS 407 o Change Controller: IESG 408 o Specification Document(s): Section 2 of [[ this specification ]] 410 o Authentication Method Reference Name: "swk" 411 o Authentication Method Reference Description: Proof-of-possession 412 of a software-secured key 413 o Change Controller: IESG 414 o Specification Document(s): Section 2 of [[ this specification ]] 416 o Authentication Method Reference Name: "tel" 417 o Authentication Method Reference Description: Confirmation by 418 telephone call 419 o Change Controller: IESG 420 o Specification Document(s): Section 2 of [[ this specification ]] 422 o Authentication Method Reference Name: "user" 423 o Authentication Method Reference Description: User presence test 424 o Change Controller: IESG 425 o Specification Document(s): Section 2 of [[ this specification ]] 427 o Authentication Method Reference Name: "vbm" 428 o Authentication Method Reference Description: Voice biometric 429 o Change Controller: IESG 430 o Specification Document(s): Section 2 of [[ this specification ]] 431 o Authentication Method Reference Name: "wia" 432 o Authentication Method Reference Description: Windows integrated 433 authentication 434 o Change Controller: IESG 435 o Specification Document(s): Section 2 of [[ this specification ]] 437 7. References 439 7.1. Normative References 441 [IANA.JWT.Claims] 442 IANA, "JSON Web Token Claims", 443 . 445 [JECM] Williamson, G., "Enhanced Authentication In Online 446 Banking", Journal of Economic Crime Management 4.2: 18-19, 447 2006, 448 . 451 [JWT] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 452 (JWT)", RFC 7519, May 2015, 453 . 455 [MSDN] Microsoft, "Integrated Windows Authentication with 456 Negotiate", September 2011, 457 . 461 [NIST.800-63-2] 462 National Institute of Standards and Technology (NIST), 463 "Electronic Authentication Guideline", NIST Special 464 Publication 800-63-2, August 2013, 465 . 468 [OpenID.Core] 469 Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and 470 C. Mortimore, "OpenID Connect Core 1.0", November 2014, 471 . 473 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 474 Requirement Levels", BCP 14, RFC 2119, 475 DOI 10.17487/RFC2119, March 1997, 476 . 478 [RFC4211] Schaad, J., "Internet X.509 Public Key Infrastructure 479 Certificate Request Message Format (CRMF)", RFC 4211, 480 DOI 10.17487/RFC4211, September 2005, 481 . 483 [RFC4226] M'Raihi, D., Bellare, M., Hoornaert, F., Naccache, D., and 484 O. Ranen, "HOTP: An HMAC-Based One-Time Password 485 Algorithm", RFC 4226, DOI 10.17487/RFC4226, December 2005, 486 . 488 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 489 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 490 DOI 10.17487/RFC5226, May 2008, 491 . 493 [RFC6238] M'Raihi, D., Machani, S., Pei, M., and J. Rydell, "TOTP: 494 Time-Based One-Time Password Algorithm", RFC 6238, 495 DOI 10.17487/RFC6238, May 2011, 496 . 498 [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", 499 RFC 6749, DOI 10.17487/RFC6749, October 2012, 500 . 502 7.2. Informative References 504 [OpenID.MODRNA] 505 Connotte, J. and J. Bradley, "OpenID Connect MODRNA 506 Authentication Profile 1.0", February 2016, 507 . 510 [RFC6819] Lodderstedt, T., Ed., McGloin, M., and P. Hunt, "OAuth 2.0 511 Threat Model and Security Considerations", RFC 6819, 512 DOI 10.17487/RFC6819, January 2013, 513 . 515 Appendix A. Acknowledgements 517 Caleb Baker participated in specifying the original set of "amr" 518 values. John Bradley, Brian Campbell, William Denniss, James Manger, 519 Nat Sakimura, and Mike Schwartz provided reviews of the 520 specification. 522 Appendix B. Document History 524 [[ to be removed by the RFC editor before publication as an RFC ]] 526 -01 528 o Distinguished between retina and iris biometrics. 529 o Expanded the introduction to provide additional context to 530 readers. 531 o Referenced the OpenID Connect MODRNA Authentication Profile 1.0 532 specification, which uses "amr" values defined by this 533 specification 535 -00 537 o Created the initial working group draft from draft-jones-oauth- 538 amr-values-05 with no normative changes. 540 Authors' Addresses 542 Michael B. Jones 543 Microsoft 545 Email: mbj@microsoft.com 546 URI: http://self-issued.info/ 548 Phil Hunt 549 Oracle 551 Email: phil.hunt@yahoo.com 553 Anthony Nadalin 554 Microsoft 556 Email: tonynad@microsoft.com