idnits 2.17.1 draft-ietf-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 (November 13, 2016) is 2692 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) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). 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: May 17, 2017 Oracle 6 A. Nadalin 7 Microsoft 8 November 13, 2016 10 Authentication Method Reference Values 11 draft-ietf-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. 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 May 17, 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 . . . . . . . . . . . . . . 8 68 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 69 7.1. Normative References . . . . . . . . . . . . . . . . . . 10 70 7.2. Informative References . . . . . . . . . . . . . . . . . 11 71 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 12 72 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 12 73 Appendix C. Document History . . . . . . . . . . . . . . . . . . 12 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 76 1. Introduction 78 The "amr" (Authentication Methods References) claim is defined and 79 registered in the IANA "JSON Web Token Claims" registry 80 [IANA.JWT.Claims] but no standard Authentication Method Reference 81 values are currently defined. This specification establishes a 82 registry for Authentication Method Reference values and defines an 83 initial set of Authentication Method Reference values. 85 For context, the "amr" (Authentication Methods References) claim is 86 defined by Section 2 of the OpenID Connect Core 1.0 specification 87 [OpenID.Core] as follows: 89 amr 90 OPTIONAL. Authentication Methods References. JSON array of 91 strings that are identifiers for authentication methods used in 92 the authentication. For instance, values might indicate that both 93 password and OTP authentication methods were used. The definition 94 of particular values to be used in the "amr" Claim is beyond the 95 scope of this specification. Parties using this claim will need 96 to agree upon the meanings of the values used, which may be 97 context-specific. The "amr" value is an array of case sensitive 98 strings. 100 The "amr" values defined by this specification is not intended to be 101 an exhaustive set covering all use cases. Additional values can and 102 will be added to the registry by other specifications. Rather, the 103 values defined herein are an intentionally small set that are already 104 actually being used in practice. 106 For context, while the claim values registered pertain to 107 authentication, note that OAuth 2.0 [RFC6749] is designed for 108 resource authorization and cannot be used for authentication without 109 employing appropriate extensions, such as those defined by OpenID 110 Connect Core 1.0 [OpenID.Core]. The existence of the "amr" claim and 111 values for it should not be taken as encouragement to try to use 112 OAuth 2.0 for authentication without employing extensions enabling 113 secure authentication to be performed. 115 When used with OpenID Connect, if the identity provider supplies an 116 "amr" claim in the ID Token resulting from a successful 117 authentication, the relying party can inspect the values returned and 118 thereby learn details about how the authentication was performed. 119 For instance, the relying party might learn that only a password was 120 used or it might learn that iris recognition was used in combination 121 with a hardware-secured key. Whether "amr" values are provided and 122 which values are understood by what parties are both beyond the scope 123 of this specification. The OpenID Connect MODRNA Authentication 124 Profile 1.0 [OpenID.MODRNA] is one example of an application context 125 that uses "amr" values defined by this specification. 127 1.1. Requirements Notation and Conventions 129 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 130 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 131 "OPTIONAL" in this document are to be interpreted as described in RFC 132 2119 [RFC2119]. 134 1.2. Terminology 136 This specification uses the terms defined by JSON Web Token (JWT) 137 [JWT] and OpenID Connect Core 1.0 [OpenID.Core]. 139 2. Authentication Method Reference Values 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] [ISO29115] 163 mca 164 Multiple-channel authentication. The authentication involves 165 communication over more than one distinct communication channel. 166 For instance, a multiple-channel authentication might involve both 167 entering information into a workstation's browser and providing 168 information on a telephone call to a pre-registered number. 170 mfa 171 Multiple-factor authentication [NIST.800-63-2] [ISO29115]. When 172 this is present, specific authentication methods used may also be 173 included. 175 otp 176 One-time password. One-time password specifications that this 177 authentication method applies to include [RFC4226] and [RFC6238]. 179 pin 180 Personal Identification Number or pattern (not restricted to 181 containing only numbers) that a user enters to unlock a key on the 182 device. This mechanism should have a way to deter an attacker 183 from obtaining the PIN by trying repeated guesses. 185 pwd 186 Password-based authentication 188 rba 189 Risk-based authentication [JECM] 191 retina 192 Retina scan biometric 194 sc 195 Smart card 197 sms 198 Confirmation using SMS message to the user at a registered number 200 swk 201 Proof-of-possession (PoP) of a software-secured key. See 202 Appendix C of [RFC4211] for a discussion on PoP. 204 tel 205 Confirmation by telephone call to the user at a registered number 207 user 208 User presence test 210 vbm 211 Voice biometric 213 wia 214 Windows integrated authentication, as described in [MSDN] 216 3. Relationship to "acr" (Authentication Context Class Reference) 218 The "acr" (Authentication Context Class Reference) claim and 219 "acr_values" request parameter are related to the "amr" 220 (Authentication Methods References) claim, but with important 221 differences. An Authentication Context Class specifies a set of 222 business rules that authentications are being requested to satisfy. 223 These rules can often be satisfied by using a number of different 224 specific authentication methods, either singly or in combination. 225 Interactions using "acr_values" request that the specified 226 Authentication Context Classes be used and that the result should 227 contain an "acr" claim saying which Authentication Context Class was 228 satisfied. The "acr" claim in the reply states that the business 229 rules for the class were satisfied -- not how they were satisfied. 231 In contrast, interactions using the "amr" claim make statements about 232 the particular authentication methods that were used. This tends to 233 be more brittle than using "acr", since the authentication methods 234 that may be appropriate for a given authentication will vary over 235 time, both because of the evolution of attacks on existing methods 236 and the deployment of new authentication methods. 238 4. Privacy Considerations 240 The list of "amr" claim values returned in an ID Token reveals 241 information about the way that the end-user authenticated to the 242 identity provider. In some cases, this information may have privacy 243 implications. 245 While this specification defines identifiers for particular kinds of 246 credentials, it does not define how these credentials are stored or 247 protected. For instance, ensuring the security and privacy of 248 biometric credentials that are referenced by some of the defined 249 Authentication Method Reference values is beyond the scope of this 250 specification. 252 5. Security Considerations 254 The security considerations in OpenID Connect Core 1.0 [OpenID.Core] 255 and OAuth 2.0 [RFC6749] and the OAuth 2.0 Threat Model [RFC6819] 256 apply to applications using this specification. 258 As described in Section 3, taking a dependence upon particular 259 authentication methods may result in brittle systems, since the 260 authentication methods that may be appropriate for a given 261 authentication will vary over time. 263 6. IANA Considerations 265 6.1. Authentication Method Reference Values Registry 267 This specification establishes the IANA "Authentication Method 268 Reference Values" registry for "amr" claim array element values. The 269 registry records the Authentication Method Reference value and a 270 reference to the specification that defines it. This specification 271 registers the Authentication Method Reference values defined in 272 Section 2. 274 Values are registered on an Expert Review [RFC5226] basis after a 275 three-week review period on the jwt-reg-review@ietf.org mailing list, 276 on the advice of one or more Designated Experts. To increase 277 potential interoperability, the experts are requested to encourage 278 registrants to provide the location of a publicly-accessible 279 specification defining the values being registered, so that their 280 intended usage can be more easily understood. 282 Registration requests sent to the mailing list for review should use 283 an appropriate subject (e.g., "Request to register Authentication 284 Method Reference value: otp"). 286 Within the review period, the Designated Experts will either approve 287 or deny the registration request, communicating this decision to the 288 review list and IANA. Denials should include an explanation and, if 289 applicable, suggestions as to how to make the request successful. 290 Registration requests that are undetermined for a period longer than 291 21 days can be brought to the IESG's attention (using the 292 iesg@ietf.org mailing list) for resolution. 294 Criteria that should be applied by the Designated Experts includes 295 determining whether the proposed registration duplicates existing 296 functionality, whether it is likely to be of general applicability or 297 whether it is useful only for a single application, whether the value 298 is actually being used, and whether the registration description is 299 clear. 301 IANA must only accept registry updates from the Designated Experts 302 and should direct all requests for registration to the review mailing 303 list. 305 It is suggested that the same Designated Experts evaluate these 306 registration requests as those who evaluate registration requests for 307 the IANA "JSON Web Token Claims" registry [IANA.JWT.Claims]. 309 6.1.1. Registration Template 311 Authentication Method Reference Name: 312 The name requested (e.g., "otp"). Because a core goal of this 313 specification is for the resulting representations to be compact, 314 it is RECOMMENDED that the name be short -- that is, not to exceed 315 8 characters without a compelling reason to do so. This name is 316 case sensitive. Names may not match other registered names in a 317 case-insensitive manner unless the Designated Experts state that 318 there is a compelling reason to allow an exception. 320 Authentication Method Reference Description: 321 Brief description of the Authentication Method Reference (e.g., 322 "One-time password"). 324 Change Controller: 325 For Standards Track RFCs, state "IESG". For others, give the name 326 of the responsible party. Other details (e.g., postal address, 327 email address, home page URI) may also be included. 329 Specification Document(s): 330 Reference to the document or documents that specify the parameter, 331 preferably including URIs that can be used to retrieve copies of 332 the documents. An indication of the relevant sections may also be 333 included but is not required. 335 6.1.2. Initial Registry Contents 337 o Authentication Method Reference Name: "face" 338 o Authentication Method Reference Description: Facial recognition 339 o Change Controller: IESG 340 o Specification Document(s): Section 2 of [[ this specification ]] 342 o Authentication Method Reference Name: "fpt" 343 o Authentication Method Reference Description: Fingerprint biometric 344 o Change Controller: IESG 345 o Specification Document(s): Section 2 of [[ this specification ]] 347 o Authentication Method Reference Name: "geo" 348 o Authentication Method Reference Description: Geolocation 349 o Change Controller: IESG 350 o Specification Document(s): Section 2 of [[ this specification ]] 352 o Authentication Method Reference Name: "hwk" 353 o Authentication Method Reference Description: Proof-of-possession 354 of a hardware-secured key 355 o Change Controller: IESG 356 o Specification Document(s): Section 2 of [[ this specification ]] 358 o Authentication Method Reference Name: "iris" 359 o Authentication Method Reference Description: Iris scan biometric 360 o Change Controller: IESG 361 o Specification Document(s): Section 2 of [[ this specification ]] 363 o Authentication Method Reference Name: "kba" 364 o Authentication Method Reference Description: Knowledge-based 365 authentication 366 o Change Controller: IESG 367 o Specification Document(s): Section 2 of [[ this specification ]] 369 o Authentication Method Reference Name: "mca" 370 o Authentication Method Reference Description: Multiple-channel 371 authentication 372 o Change Controller: IESG 373 o Specification Document(s): Section 2 of [[ this specification ]] 375 o Authentication Method Reference Name: "mfa" 376 o Authentication Method Reference Description: Multiple-factor 377 authentication 378 o Change Controller: IESG 379 o Specification Document(s): Section 2 of [[ this specification ]] 381 o Authentication Method Reference Name: "otp" 382 o Authentication Method Reference Description: One-time password 383 o Change Controller: IESG 384 o Specification Document(s): Section 2 of [[ this specification ]] 386 o Authentication Method Reference Name: "pin" 387 o Authentication Method Reference Description: Personal 388 Identification Number or pattern 389 o Change Controller: IESG 390 o Specification Document(s): Section 2 of [[ this specification ]] 392 o Authentication Method Reference Name: "pwd" 393 o Authentication Method Reference Description: Password-based 394 authentication 395 o Change Controller: IESG 396 o Specification Document(s): Section 2 of [[ this specification ]] 398 o Authentication Method Reference Name: "rba" 399 o Authentication Method Reference Description: Risk-based 400 authentication 401 o Change Controller: IESG 402 o Specification Document(s): Section 2 of [[ this specification ]] 404 o Authentication Method Reference Name: "retina" 405 o Authentication Method Reference Description: Retina scan biometric 406 o Change Controller: IESG 407 o Specification Document(s): Section 2 of [[ this specification ]] 409 o Authentication Method Reference Name: "sc" 410 o Authentication Method Reference Description: Smart card 411 o Change Controller: IESG 412 o Specification Document(s): Section 2 of [[ this specification ]] 414 o Authentication Method Reference Name: "sms" 415 o Authentication Method Reference Description: Confirmation using 416 SMS 417 o Change Controller: IESG 418 o Specification Document(s): Section 2 of [[ this specification ]] 420 o Authentication Method Reference Name: "swk" 421 o Authentication Method Reference Description: Proof-of-possession 422 of a software-secured key 423 o Change Controller: IESG 424 o Specification Document(s): Section 2 of [[ this specification ]] 426 o Authentication Method Reference Name: "tel" 427 o Authentication Method Reference Description: Confirmation by 428 telephone call 429 o Change Controller: IESG 430 o Specification Document(s): Section 2 of [[ this specification ]] 431 o Authentication Method Reference Name: "user" 432 o Authentication Method Reference Description: User presence test 433 o Change Controller: IESG 434 o Specification Document(s): Section 2 of [[ this specification ]] 436 o Authentication Method Reference Name: "vbm" 437 o Authentication Method Reference Description: Voice biometric 438 o Change Controller: IESG 439 o Specification Document(s): Section 2 of [[ this specification ]] 441 o Authentication Method Reference Name: "wia" 442 o Authentication Method Reference Description: Windows integrated 443 authentication 444 o Change Controller: IESG 445 o Specification Document(s): Section 2 of [[ this specification ]] 447 7. References 449 7.1. Normative References 451 [IANA.JWT.Claims] 452 IANA, "JSON Web Token Claims", 453 . 455 [JWT] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 456 (JWT)", RFC 7519, May 2015, 457 . 459 [OpenID.Core] 460 Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and 461 C. Mortimore, "OpenID Connect Core 1.0", November 2014, 462 . 464 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 465 Requirement Levels", BCP 14, RFC 2119, 466 DOI 10.17487/RFC2119, March 1997, 467 . 469 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 470 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 471 DOI 10.17487/RFC5226, May 2008, 472 . 474 [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", 475 RFC 6749, DOI 10.17487/RFC6749, October 2012, 476 . 478 7.2. Informative References 480 [ISO29115] 481 International Organization for Standardization, "ISO/IEC 482 29115:2013 -- Information technology - Security techniques 483 - Entity authentication assurance framework", ISO/ 484 IEC 29115:2013, April 2013, 485 . 488 [JECM] Williamson, G., "Enhanced Authentication In Online 489 Banking", Journal of Economic Crime Management 4.2: 18-19, 490 2006, 491 . 494 [MSDN] Microsoft, "Integrated Windows Authentication with 495 Negotiate", September 2011, 496 . 500 [NIST.800-63-2] 501 National Institute of Standards and Technology (NIST), 502 "Electronic Authentication Guideline", NIST Special 503 Publication 800-63-2, August 2013, 504 . 507 [OpenID.MODRNA] 508 Connotte, J. and J. Bradley, "OpenID Connect MODRNA 509 Authentication Profile 1.0", September 2016, 510 . 513 [RFC4211] Schaad, J., "Internet X.509 Public Key Infrastructure 514 Certificate Request Message Format (CRMF)", RFC 4211, 515 DOI 10.17487/RFC4211, September 2005, 516 . 518 [RFC4226] M'Raihi, D., Bellare, M., Hoornaert, F., Naccache, D., and 519 O. Ranen, "HOTP: An HMAC-Based One-Time Password 520 Algorithm", RFC 4226, DOI 10.17487/RFC4226, December 2005, 521 . 523 [RFC6238] M'Raihi, D., Machani, S., Pei, M., and J. Rydell, "TOTP: 524 Time-Based One-Time Password Algorithm", RFC 6238, 525 DOI 10.17487/RFC6238, May 2011, 526 . 528 [RFC6819] Lodderstedt, T., Ed., McGloin, M., and P. Hunt, "OAuth 2.0 529 Threat Model and Security Considerations", RFC 6819, 530 DOI 10.17487/RFC6819, January 2013, 531 . 533 Appendix A. Examples 535 In some cases, the "amr" claim value returned may contain a single 536 Authentication Method Reference value. For example, the following 537 "amr" claim value indicates that the authentication performed used an 538 iris scan biometric: 540 "amr": ["iris"] 542 In other cases, the "amr" claim value returned may contain multiple 543 Authentication Method Reference values. For example, the following 544 "amr" claim value indicates that the authentication performed used a 545 password and knowledge-based authentication: 547 "amr": ["pwd", "kba"] 549 Appendix B. Acknowledgements 551 Caleb Baker participated in specifying the original set of "amr" 552 values. John Bradley, Brian Campbell, William Denniss, James Manger, 553 Nat Sakimura, and Mike Schwartz provided reviews of the 554 specification. 556 Appendix C. Document History 558 [[ to be removed by the RFC editor before publication as an RFC ]] 560 -04 562 o Added examples with single and multiple values. 563 o Clarified that the actual credentials referenced are not part of 564 this specification to avoid additional privacy concerns for 565 biometric data. 566 o Clarified that the OAuth 2.0 Threat Model [RFC6819] applies to 567 applications using this specification. 569 -03 570 o Addressed shepherd comments. 572 -02 574 o Addressed working group last call comments. 576 -01 578 o Distinguished between retina and iris biometrics. 579 o Expanded the introduction to provide additional context to 580 readers. 581 o Referenced the OpenID Connect MODRNA Authentication Profile 1.0 582 specification, which uses "amr" values defined by this 583 specification. 585 -00 587 o Created the initial working group draft from draft-jones-oauth- 588 amr-values-05 with no normative changes. 590 Authors' Addresses 592 Michael B. Jones 593 Microsoft 595 Email: mbj@microsoft.com 596 URI: http://self-issued.info/ 598 Phil Hunt 599 Oracle 601 Email: phil.hunt@yahoo.com 603 Anthony Nadalin 604 Microsoft 606 Email: tonynad@microsoft.com