idnits 2.17.1 draft-ietf-oauth-amr-values-00.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 (March 17, 2016) is 2959 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: September 18, 2016 Oracle 6 A. Nadalin 7 Microsoft 8 March 17, 2016 10 Authentication Method Reference Values 11 draft-ietf-oauth-amr-values-00 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 September 18, 2016. 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 . . . . . . . . . . . . . . . . . . . 5 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 . . . . . . . . . . . . . . . . . . . . . . . . . 9 69 7.1. Normative References . . . . . . . . . . . . . . . . . . 9 70 7.2. Informative References . . . . . . . . . . . . . . . . . 11 71 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 11 72 Appendix B. Document History . . . . . . . . . . . . . . . . . . 11 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 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 1.1. Requirements Notation and Conventions 101 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 102 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 103 "OPTIONAL" in this document are to be interpreted as described in RFC 104 2119 [RFC2119]. 106 1.2. Terminology 108 This specification uses the terms defined by JSON Web Token (JWT) 109 [JWT] and OpenID Connect Core 1.0 [OpenID.Core]. 111 2. Authentication Method Reference Values 113 The "amr" (Authentication Methods References) claim is defined by the 114 OpenID Connect Core 1.0 specification [OpenID.Core] as follows: 116 amr 117 OPTIONAL. Authentication Methods References. JSON array of 118 strings that are identifiers for authentication methods used in 119 the authentication. For instance, values might indicate that both 120 password and OTP authentication methods were used. The definition 121 of particular values to be used in the "amr" Claim is beyond the 122 scope of this specification. Parties using this claim will need 123 to agree upon the meanings of the values used, which may be 124 context-specific. The "amr" value is an array of case sensitive 125 strings. 127 However, OpenID Connect does not specify any particular 128 Authentication Method Reference values to be used in the "amr" claim. 129 The following is a list of Authentication Method Reference values 130 defined by this specification: 132 eye 133 Retina scan biometric 135 face 136 Facial recognition 138 fpt 139 Fingerprint biometric 141 geo 142 Use of geolocation information 144 hwk 145 Proof-of-possession (PoP) of a hardware-secured key. See 146 Appendix C of [RFC4211] for a discussion on PoP. 148 kba 149 Knowledge-based authentication [NIST.800-63-2] 151 mca 152 Multiple-channel authentication. The authentication involves 153 communication over more than one distinct channel. 155 mfa 156 Multiple-factor authentication [NIST.800-63-2]. When this is 157 present, specific authentication methods used may also be 158 included. 160 otp 161 One-time password. One-time password specifications that this 162 authentication method applies to include [RFC4226] and [RFC6238]. 164 pin 165 Personal Identification Number or pattern (not restricted to 166 containing only numbers) that a user enters to unlock a key on the 167 device. This mechanism SHOULD have a way to deter an attacker 168 from obtaining the PIN by trying repeated guesses. 170 pwd 171 Password-based authentication 173 rba 174 Risk-based authentication [JECM] 176 sc 177 Smart card 179 sms 180 Confirmation using SMS message to the user at a registered number 182 swk 183 Proof-of-possession (PoP) of a software-secured key. See 184 Appendix C of [RFC4211] for a discussion on PoP. 186 tel 187 Confirmation by telephone call to the user at a registered number 189 user 190 User presence test 192 vbm 193 Voice biometric 195 wia 196 Windows integrated authentication, as described in [MSDN] 198 3. Relationship to "acr" (Authentication Context Class Reference) 200 The "acr" (Authentication Context Class Reference) claim and 201 "acr_values" request parameter are related to the "amr" 202 (Authentication Methods References) claim, but with important 203 differences. An Authentication Context Class specifies a set of 204 business rules that authentications are being requested to satisfy. 205 These rules can often be satisfied by using a number of different 206 specific authentication methods, either singly or in combination. 207 Interactions using "acr_values" request that the specified 208 Authentication Context Classes be used and that the result should 209 contain an "acr" claim saying which Authentication Context Class was 210 satisfied. The "acr" claim in the reply states that the business 211 rules for the class were satisfied -- not how they were satisfied. 213 In contrast, interactions using the "amr" claim make statements about 214 the particular authentication methods that were used. This tends to 215 be more brittle than using "acr", since the authentication methods 216 that may be appropriate for a given authentication will vary over 217 time, both because of the evolution of attacks on existing methods 218 and the deployment of new authentication methods. 220 4. Privacy Considerations 222 The list of "amr" claim values returned in an ID Token reveals 223 information about the way that the end-user authenticated to the 224 identity provider. In some cases, this information may have privacy 225 implications. 227 5. Security Considerations 229 The security considerations in OpenID Connect Core 1.0 [OpenID.Core], 230 OAuth 2.0 [RFC6749], and the OAuth 2.0 Threat Model [RFC6819] apply 231 to this specification. 233 As described in Section 3, taking a dependence upon particular 234 authentication methods may result in brittle systems, since the 235 authentication methods that may be appropriate for a given 236 authentication will vary over time. 238 6. IANA Considerations 240 6.1. Authentication Method Reference Values Registry 242 This specification establishes the IANA "Authentication Method 243 Reference Values" registry for "amr" claim array element values. The 244 registry records the Authentication Method Reference value and a 245 reference to the specification that defines it. This specification 246 registers the Authentication Method Reference values defined in 247 Section 2. 249 Values are registered on an Expert Review [RFC5226] basis after a 250 three-week review period on the jwt-reg-review@ietf.org mailing list, 251 on the advice of one or more Designated Experts. To increase 252 potential interoperability, the experts are requested to encourage 253 registrants to provide the location of a publicly-accessible 254 specification defining the values being registered, so that their 255 intended usage can be more easily understood. 257 Registration requests sent to the mailing list for review should use 258 an appropriate subject (e.g., "Request to register Authentication 259 Method Reference value: otp"). 261 Within the review period, the Designated Experts will either approve 262 or deny the registration request, communicating this decision to the 263 review list and IANA. Denials should include an explanation and, if 264 applicable, suggestions as to how to make the request successful. 265 Registration requests that are undetermined for a period longer than 266 21 days can be brought to the IESG's attention (using the 267 iesg@ietf.org mailing list) for resolution. 269 Criteria that should be applied by the Designated Experts includes 270 determining whether the proposed registration duplicates existing 271 functionality, whether it is likely to be of general applicability or 272 whether it is useful only for a single application, whether the value 273 is actually being used, and whether the registration description is 274 clear. 276 IANA must only accept registry updates from the Designated Experts 277 and should direct all requests for registration to the review mailing 278 list. 280 It is suggested that the same Designated Experts evaluate these 281 registration requests as those who evaluate registration requests for 282 the IANA "JSON Web Token Claims" registry [IANA.JWT.Claims]. 284 6.1.1. Registration Template 286 Authentication Method Reference Name: 287 The name requested (e.g., "otp"). Because a core goal of this 288 specification is for the resulting representations to be compact, 289 it is RECOMMENDED that the name be short -- that is, not to exceed 290 8 characters without a compelling reason to do so. This name is 291 case sensitive. Names may not match other registered names in a 292 case-insensitive manner unless the Designated Experts state that 293 there is a compelling reason to allow an exception. 295 Authentication Method Reference Description: 296 Brief description of the Authentication Method Reference (e.g., 297 "One-time password"). 299 Change Controller: 300 For Standards Track RFCs, state "IESG". For others, give the name 301 of the responsible party. Other details (e.g., postal address, 302 email address, home page URI) may also be included. 304 Specification Document(s): 305 Reference to the document or documents that specify the parameter, 306 preferably including URIs that can be used to retrieve copies of 307 the documents. An indication of the relevant sections may also be 308 included but is not required. 310 6.1.2. Initial Registry Contents 312 o Authentication Method Reference Name: "eye" 313 o Authentication Method Reference Description: Retina scan biometric 314 o Change Controller: IESG 315 o Specification Document(s): Section 2 of [[ this specification ]] 317 o Authentication Method Reference Name: "face" 318 o Authentication Method Reference Description: Facial recognition 319 o Change Controller: IESG 320 o Specification Document(s): Section 2 of [[ this specification ]] 322 o Authentication Method Reference Name: "fpt" 323 o Authentication Method Reference Description: Fingerprint biometric 324 o Change Controller: IESG 325 o Specification Document(s): Section 2 of [[ this specification ]] 327 o Authentication Method Reference Name: "geo" 328 o Authentication Method Reference Description: Geolocation 329 o Change Controller: IESG 330 o Specification Document(s): Section 2 of [[ this specification ]] 331 o Authentication Method Reference Name: "hwk" 332 o Authentication Method Reference Description: Proof-of-possession 333 of a hardware-secured key 334 o Change Controller: IESG 335 o Specification Document(s): Section 2 of [[ this specification ]] 337 o Authentication Method Reference Name: "kba" 338 o Authentication Method Reference Description: Knowledge-based 339 authentication 340 o Change Controller: IESG 341 o Specification Document(s): Section 2 of [[ this specification ]] 343 o Authentication Method Reference Name: "mca" 344 o Authentication Method Reference Description: Multiple-channel 345 authentication 346 o Change Controller: IESG 347 o Specification Document(s): Section 2 of [[ this specification ]] 349 o Authentication Method Reference Name: "mfa" 350 o Authentication Method Reference Description: Multiple-factor 351 authentication 352 o Change Controller: IESG 353 o Specification Document(s): Section 2 of [[ this specification ]] 355 o Authentication Method Reference Name: "otp" 356 o Authentication Method Reference Description: One-time password 357 o Change Controller: IESG 358 o Specification Document(s): Section 2 of [[ this specification ]] 360 o Authentication Method Reference Name: "pin" 361 o Authentication Method Reference Description: Personal 362 Identification Number or pattern 363 o Change Controller: IESG 364 o Specification Document(s): Section 2 of [[ this specification ]] 366 o Authentication Method Reference Name: "pwd" 367 o Authentication Method Reference Description: Password-based 368 authentication 369 o Change Controller: IESG 370 o Specification Document(s): Section 2 of [[ this specification ]] 372 o Authentication Method Reference Name: "rba" 373 o Authentication Method Reference Description: Risk-based 374 authentication 375 o Change Controller: IESG 376 o Specification Document(s): Section 2 of [[ this specification ]] 378 o Authentication Method Reference Name: "sc" 379 o Authentication Method Reference Description: Smart card 380 o Change Controller: IESG 381 o Specification Document(s): Section 2 of [[ this specification ]] 383 o Authentication Method Reference Name: "sms" 384 o Authentication Method Reference Description: Confirmation using 385 SMS 386 o Change Controller: IESG 387 o Specification Document(s): Section 2 of [[ this specification ]] 389 o Authentication Method Reference Name: "swk" 390 o Authentication Method Reference Description: Proof-of-possession 391 of a software-secured key 392 o Change Controller: IESG 393 o Specification Document(s): Section 2 of [[ this specification ]] 395 o Authentication Method Reference Name: "tel" 396 o Authentication Method Reference Description: Confirmation by 397 telephone call 398 o Change Controller: IESG 399 o Specification Document(s): Section 2 of [[ this specification ]] 401 o Authentication Method Reference Name: "user" 402 o Authentication Method Reference Description: User presence test 403 o Change Controller: IESG 404 o Specification Document(s): Section 2 of [[ this specification ]] 406 o Authentication Method Reference Name: "vbm" 407 o Authentication Method Reference Description: Voice biometric 408 o Change Controller: IESG 409 o Specification Document(s): Section 2 of [[ this specification ]] 411 o Authentication Method Reference Name: "wia" 412 o Authentication Method Reference Description: Windows integrated 413 authentication 414 o Change Controller: IESG 415 o Specification Document(s): Section 2 of [[ this specification ]] 417 7. References 419 7.1. Normative References 421 [IANA.JWT.Claims] 422 IANA, "JSON Web Token Claims", 423 . 425 [JECM] Williamson, G., "Enhanced Authentication In Online 426 Banking", Journal of Economic Crime Management 4.2: 18-19, 427 2006, 428 . 431 [JWT] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 432 (JWT)", RFC 7519, May 2015, 433 . 435 [MSDN] Microsoft, "Integrated Windows Authentication with 436 Negotiate", September 2011, 437 . 441 [NIST.800-63-2] 442 National Institute of Standards and Technology (NIST), 443 "Electronic Authentication Guideline", NIST Special 444 Publication 800-63-2, August 2013, 445 . 448 [OpenID.Core] 449 Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and 450 C. Mortimore, "OpenID Connect Core 1.0", November 2014. 452 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 453 Requirement Levels", BCP 14, RFC 2119, 454 DOI 10.17487/RFC2119, March 1997, 455 . 457 [RFC4211] Schaad, J., "Internet X.509 Public Key Infrastructure 458 Certificate Request Message Format (CRMF)", RFC 4211, 459 DOI 10.17487/RFC4211, September 2005, 460 . 462 [RFC4226] M'Raihi, D., Bellare, M., Hoornaert, F., Naccache, D., and 463 O. Ranen, "HOTP: An HMAC-Based One-Time Password 464 Algorithm", RFC 4226, DOI 10.17487/RFC4226, December 2005, 465 . 467 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 468 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 469 DOI 10.17487/RFC5226, May 2008, 470 . 472 [RFC6238] M'Raihi, D., Machani, S., Pei, M., and J. Rydell, "TOTP: 473 Time-Based One-Time Password Algorithm", RFC 6238, 474 DOI 10.17487/RFC6238, May 2011, 475 . 477 [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", 478 RFC 6749, DOI 10.17487/RFC6749, October 2012, 479 . 481 7.2. Informative References 483 [RFC6819] Lodderstedt, T., Ed., McGloin, M., and P. Hunt, "OAuth 2.0 484 Threat Model and Security Considerations", RFC 6819, 485 DOI 10.17487/RFC6819, January 2013, 486 . 488 Appendix A. Acknowledgements 490 Caleb Baker participated in specifying the original set of "amr" 491 values. John Bradley, Brian Campbell, William Denniss, James Manger, 492 and Nat Sakimura provided reviews of the specification. 494 Appendix B. Document History 496 [[ to be removed by the RFC editor before publication as an RFC ]] 498 -00 500 o Created the initial working group draft from draft-jones-oauth- 501 amr-values-05 with no normative changes. 503 Authors' Addresses 505 Michael B. Jones 506 Microsoft 508 Email: mbj@microsoft.com 509 URI: http://self-issued.info/ 511 Phil Hunt 512 Oracle 514 Email: phil.hunt@yahoo.com 515 Anthony Nadalin 516 Microsoft 518 Email: tonynad@microsoft.com