idnits 2.17.1 draft-jones-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 (August 21, 2015) is 3165 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: February 22, 2016 Oracle 6 A. Nadalin 7 Microsoft 8 August 21, 2015 10 Authentication Method Reference Values 11 draft-jones-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. It also defines the 21 "amr_values" (requested Authentication Method Reference values) 22 request parameter for requesting that a set of Authentication Method 23 Reference values be used for processing the Authentication Request. 25 Status of this Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on February 22, 2016. 42 Copyright Notice 44 Copyright (c) 2015 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 1.1. Requirements Notation and Conventions . . . . . . . . . . 3 61 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Authentication Method Reference Values . . . . . . . . . . . . 3 63 3. Authentication Request Parameter . . . . . . . . . . . . . . . 5 64 4. Relationship to "acr" (Authentication Context Class 65 Reference) . . . . . . . . . . . . . . . . . . . . . . . . . . 5 66 5. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 5 67 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 68 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 69 7.1. Authentication Method Reference Values Registry . . . . . 6 70 7.1.1. Registration Template . . . . . . . . . . . . . . . . 7 71 7.1.2. Initial Registry Contents . . . . . . . . . . . . . . 7 72 7.2. OAuth Parameters Registration . . . . . . . . . . . . . . 9 73 7.2.1. Registry Contents . . . . . . . . . . . . . . . . . . 9 74 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 75 8.1. Normative References . . . . . . . . . . . . . . . . . . . 10 76 8.2. Informative References . . . . . . . . . . . . . . . . . . 11 77 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 11 78 Appendix B. Document History . . . . . . . . . . . . . . . . . . 11 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 81 1. Introduction 83 The "amr" (Authentication Methods References) claim is defined and 84 registered in the IANA "JSON Web Token Claims" registry 85 [IANA.JWT.Claims] but no standard Authentication Method Reference 86 values are currently defined. This specification establishes a 87 registry for Authentication Method Reference values and defines an 88 initial set of Authentication Method Reference values. It also 89 defines the "amr_values" (requested Authentication Method Reference 90 values) request parameter for requesting that a set of Authentication 91 Method Reference values be used for processing the Authentication 92 Request. 94 1.1. Requirements Notation and Conventions 96 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 97 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 98 "OPTIONAL" in this document are to be interpreted as described in RFC 99 2119 [RFC2119]. 101 1.2. Terminology 103 This specification uses the terms defined by JSON Web Token (JWT) 104 [JWT] and OpenID Connect Core 1.0 [OpenID.Core]. 106 2. Authentication Method Reference Values 108 The "amr" (Authentication Methods References) claim is defined by the 109 OpenID Connect Core 1.0 specification [OpenID.Core] as follows: 111 amr 112 OPTIONAL. Authentication Methods References. JSON array of 113 strings that are identifiers for authentication methods used in 114 the authentication. For instance, values might indicate that both 115 password and OTP authentication methods were used. The definition 116 of particular values to be used in the "amr" Claim is beyond the 117 scope of this specification. Parties using this claim will need 118 to agree upon the meanings of the values used, which may be 119 context-specific. The "amr" value is an array of case sensitive 120 strings. 122 However, OpenID Connect does not specify any particular 123 Authentication Method Reference values to be used in the "amr" claim. 124 The following is a list of Authentication Method Reference values 125 defined by this specification: 127 eye 128 Retina scan biometric 130 fpt 131 Fingerprint biometric 133 kba 134 Knowledge-based authentication [NIST.800-63-2] 136 mca 137 Multiple-channel authentication. The authentication involves 138 communication over more than one distinct channel. 140 mfa 141 Multiple-factor authentication [NIST.800-63-2]. When this is 142 present, specific authentication methods used may also be 143 included. 145 otp 146 One-time password. One-time password specifications that this 147 authentication method applies to include [RFC4226] and [RFC6238]. 149 pop 150 Proof-of-possession (PoP) of a key. See Appendix C of [RFC4211] 151 for a discussion on PoP. 153 pwd 154 Password-based authentication 156 rba 157 Risk-based authentication [JECM] 159 sc 160 Smart card 162 sms 163 Confirmation by SMS reply 165 tel 166 Confirmation by telephone call 168 user 169 User presence test 171 vbm 172 Voice biometric 174 wia 175 Windows integrated authentication, as described in [MSDN] 177 3. Authentication Request Parameter 179 This section defines the following authentication request parameter, 180 augmenting the set of authentication request parameters defined in 181 Section 3.1.2.1 of OpenID Connect Core 1.0 [OpenID.Core]: 183 amr_values 184 OPTIONAL. Requested Authentication Method Reference values. 185 Space-separated string that specifies the "amr" values that the 186 Authorization Server is being requested to use for processing this 187 Authentication Request, with the values appearing in order of 188 preference. The authentication methods used for the 189 authentication performed are returned as the "amr" Claim Value. 191 4. Relationship to "acr" (Authentication Context Class Reference) 193 The "acr" (Authentication Context Class Reference) claim and 194 "acr_values" request parameter are related to the "amr" 195 (Authentication Methods References) claim and "amr_values" request 196 parameter, but with important differences. An Authentication Context 197 Class specifies a set of business rules that authentications are 198 being requested to satisfy. These rules can often be satisfied by 199 using a number of different specific authentication methods, either 200 singly or in combination. Interactions using "acr_values" request 201 that the specified Authentication Context Classes be used and that 202 the result should contain an "acr" claim saying which Authentication 203 Context Class was satisfied. The "acr" claim in the reply states 204 that the business rules for the class were satisfied -- not how they 205 were was satisfied. 207 In contrast, interactions using "amr_values" and/or "amr" make 208 statements about the particular authentication methods that are being 209 requested and that were used. This tends to be more brittle than 210 using "acr", since the authentication methods that may be appropriate 211 for a given authentication will vary over time, both because of the 212 evolution of attacks on existing methods and the deployment of new 213 authentication methods. 215 5. Privacy Considerations 217 The list of "amr" claim values returned in an ID Token reveals 218 information about the way that the end-user authenticated to the 219 identity provider. In some cases, this information may have privacy 220 implications. 222 6. Security Considerations 224 The security considerations in OpenID Connect Core 1.0 [OpenID.Core], 225 OAuth 2.0 [RFC6749], and the OAuth 2.0 Threat Model [RFC6819] apply 226 to this specification. 228 As described in Section 4, taking a dependence upon particular 229 authentication methods may result in brittle systems, since the 230 authentication methods that may be appropriate for a given 231 authentication will vary over time. 233 7. IANA Considerations 235 7.1. Authentication Method Reference Values Registry 237 This specification establishes the IANA "Authentication Method 238 Reference Values" registry for "amr" claim array element values. The 239 registry records the Authentication Method Reference value and a 240 reference to the specification that defines it. This specification 241 registers the Authentication Method Reference values defined in 242 Section 2. 244 Values are registered on a Specification Required [RFC5226] basis 245 after a three-week review period on the jwt-reg-review@ietf.org 246 mailing list, on the advice of one or more Designated Experts. 247 However, to allow for the allocation of values prior to publication, 248 the Designated Experts may approve registration once they are 249 satisfied that such a specification will be published. 251 Registration requests sent to the mailing list for review should use 252 an appropriate subject (e.g., "Request to register Authentication 253 Method Reference value: otp"). 255 Within the review period, the Designated Experts will either approve 256 or deny the registration request, communicating this decision to the 257 review list and IANA. Denials should include an explanation and, if 258 applicable, suggestions as to how to make the request successful. 259 Registration requests that are undetermined for a period longer than 260 21 days can be brought to the IESG's attention (using the 261 iesg@ietf.org mailing list) for resolution. 263 Criteria that should be applied by the Designated Experts includes 264 determining whether the proposed registration duplicates existing 265 functionality, whether it is likely to be of general applicability or 266 whether it is useful only for a single application, and whether the 267 registration description is clear. 269 IANA must only accept registry updates from the Designated Experts 270 and should direct all requests for registration to the review mailing 271 list. 273 It is suggested that the same Designated Experts evaluate these 274 registration requests as those who evaluate registration requests for 275 the IANA "JSON Web Token Claims" registry [IANA.JWT.Claims]. 277 7.1.1. Registration Template 279 Authentication Method Reference Name: 280 The name requested (e.g., "otp"). Because a core goal of this 281 specification is for the resulting representations to be compact, 282 it is RECOMMENDED that the name be short -- that is, not to exceed 283 8 characters without a compelling reason to do so. This name is 284 case sensitive. Names may not match other registered names in a 285 case-insensitive manner unless the Designated Experts state that 286 there is a compelling reason to allow an exception. 288 Authentication Method Reference Description: 289 Brief description of the Authentication Method Reference (e.g., 290 "One-time password"). 292 Change Controller: 293 For Standards Track RFCs, state "IESG". For others, give the name 294 of the responsible party. Other details (e.g., postal address, 295 email address, home page URI) may also be included. 297 Specification Document(s): 298 Reference to the document or documents that specify the parameter, 299 preferably including URIs that can be used to retrieve copies of 300 the documents. An indication of the relevant sections may also be 301 included but is not required. 303 7.1.2. Initial Registry Contents 305 o Authentication Method Reference Name: "eye" 306 o Authentication Method Reference Description: Retina scan biometric 307 o Change Controller: IESG 308 o Specification Document(s): Section 2 of [[ this document ]] 310 o Authentication Method Reference Name: "fpt" 311 o Authentication Method Reference Description: Fingerprint biometric 312 o Change Controller: IESG 313 o Specification Document(s): Section 2 of [[ this document ]] 315 o Authentication Method Reference Name: "kba" 316 o Authentication Method Reference Description: Knowledge-based 317 authentication 318 o Change Controller: IESG 319 o Specification Document(s): Section 2 of [[ this document ]] 321 o Authentication Method Reference Name: "mca" 322 o Authentication Method Reference Description: Multiple-channel 323 authentication 324 o Change Controller: IESG 325 o Specification Document(s): Section 2 of [[ this document ]] 327 o Authentication Method Reference Name: "mfa" 328 o Authentication Method Reference Description: Multiple-factor 329 authentication 330 o Change Controller: IESG 331 o Specification Document(s): Section 2 of [[ this document ]] 333 o Authentication Method Reference Name: "otp" 334 o Authentication Method Reference Description: One-time password 335 o Change Controller: IESG 336 o Specification Document(s): Section 2 of [[ this document ]] 338 o Authentication Method Reference Name: "pop" 339 o Authentication Method Reference Description: Proof-of-possession 340 of a key 341 o Change Controller: IESG 342 o Specification Document(s): Section 2 of [[ this document ]] 344 o Authentication Method Reference Name: "pwd" 345 o Authentication Method Reference Description: Password-based 346 authentication 347 o Change Controller: IESG 348 o Specification Document(s): Section 2 of [[ this document ]] 350 o Authentication Method Reference Name: "rba" 351 o Authentication Method Reference Description: Risk-based 352 authentication 353 o Change Controller: IESG 354 o Specification Document(s): Section 2 of [[ this document ]] 356 o Authentication Method Reference Name: "sc" 357 o Authentication Method Reference Description: Smart card 358 o Change Controller: IESG 359 o Specification Document(s): Section 2 of [[ this document ]] 361 o Authentication Method Reference Name: "sms" 362 o Authentication Method Reference Description: Confirmation by SMS 363 reply 364 o Change Controller: IESG 365 o Specification Document(s): Section 2 of [[ this document ]] 367 o Authentication Method Reference Name: "tel" 368 o Authentication Method Reference Description: Confirmation by 369 telephone call 370 o Change Controller: IESG 371 o Specification Document(s): Section 2 of [[ this document ]] 373 o Authentication Method Reference Name: "user" 374 o Authentication Method Reference Description: User presence test 375 o Change Controller: IESG 376 o Specification Document(s): Section 2 of [[ this document ]] 378 o Authentication Method Reference Name: "vbm" 379 o Authentication Method Reference Description: Voice biometric 380 o Change Controller: IESG 381 o Specification Document(s): Section 2 of [[ this document ]] 383 o Authentication Method Reference Name: "wia" 384 o Authentication Method Reference Description: Windows integrated 385 authentication 386 o Change Controller: IESG 387 o Specification Document(s): Section 2 of [[ this document ]] 389 7.2. OAuth Parameters Registration 391 This section registers the following parameter in the IANA "OAuth 392 Parameters" registry [IANA.OAuth.Parameters] established in RFC 6749 393 [RFC6749]. 395 7.2.1. Registry Contents 397 o Parameter name: "amr_values" 398 o Parameter usage location: Authorization Request 399 o Change controller: IESG 400 o Specification document(s): Section 3 of [[ this document ]] 401 o Related information: None 403 8. References 404 8.1. Normative References 406 [IANA.JWT.Claims] 407 IANA, "JSON Web Token Claims", 408 . 410 [IANA.OAuth.Parameters] 411 IANA, "OAuth Parameters", 412 . 414 [JECM] Williamson, G., "Enhanced Authentication In Online 415 Banking", Journal of Economic Crime Management 4.2: 18-19, 416 2006, . 420 [JWT] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 421 (JWT)", RFC 7519, May 2015, 422 . 424 [MSDN] Microsoft, "Integrated Windows Authentication with 425 Negotiate", September 2011, . 430 [NIST.800-63-2] 431 National Institute of Standards and Technology (NIST), 432 "Electronic Authentication Guideline", NIST Special 433 Publication 800-63-2, August 2013, . 437 [OpenID.Core] 438 Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and 439 C. Mortimore, "OpenID Connect Core 1.0", November 2014. 441 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 442 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 443 RFC2119, March 1997, 444 . 446 [RFC4211] Schaad, J., "Internet X.509 Public Key Infrastructure 447 Certificate Request Message Format (CRMF)", RFC 4211, 448 DOI 10.17487/RFC4211, September 2005, 449 . 451 [RFC4226] M'Raihi, D., Bellare, M., Hoornaert, F., Naccache, D., and 452 O. Ranen, "HOTP: An HMAC-Based One-Time Password 453 Algorithm", RFC 4226, DOI 10.17487/RFC4226, December 2005, 454 . 456 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 457 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 458 DOI 10.17487/RFC5226, May 2008, 459 . 461 [RFC6238] M'Raihi, D., Machani, S., Pei, M., and J. Rydell, "TOTP: 462 Time-Based One-Time Password Algorithm", RFC 6238, 463 DOI 10.17487/RFC6238, May 2011, 464 . 466 [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", 467 RFC 6749, DOI 10.17487/RFC6749, October 2012, 468 . 470 8.2. Informative References 472 [RFC6819] Lodderstedt, T., Ed., McGloin, M., and P. Hunt, "OAuth 2.0 473 Threat Model and Security Considerations", RFC 6819, 474 DOI 10.17487/RFC6819, January 2013, 475 . 477 Appendix A. Acknowledgements 479 Caleb Baker participated in specifying the original set of 480 "amr_values" values. Brian Campbell, William Denniss, and Nat 481 Sakimura subsequently provided input on the set of "amr_values" 482 values defined. 484 Appendix B. Document History 486 [[ to be removed by the RFC editor before publication as an RFC ]] 488 -02 490 o Changed the identifier for risk-based authentication from "risk" 491 to "rba", by popular acclaim. 493 o Added "sc" (smart card). 495 -01 496 o Added the values "mca" (multiple-channel authentication), "risk" 497 (risk-based authentication), and "user" (user presence test). 499 o Added citations in the definitions of Windows integrated 500 authentication, knowledge-based authentication, risk-based 501 authentication, multiple-factor authentication, one-time password, 502 and proof-of-possession. 504 o Alphabetized the values. 506 o Added Tony Nadalin as an author and added acknowledgements. 508 -00 510 o Defined the IANA "Authentication Method Reference Values" 511 registry. 513 Authors' Addresses 515 Michael B. Jones 516 Microsoft 518 Email: mbj@microsoft.com 519 URI: http://self-issued.info/ 521 Phil Hunt 522 Oracle 524 Email: phil.hunt@yahoo.com 526 Anthony Nadalin 527 Microsoft 529 Email: tonynad@microsoft.com