idnits 2.17.1 draft-jones-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 (August 13, 2015) is 3172 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 14, 2016 Oracle 6 A. Nadalin 7 Microsoft 8 August 13, 2015 10 Authentication Method Reference Values 11 draft-jones-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. 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 14, 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 . . . . . . . . . . . . . . . . . . . 5 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 9 75 8.1. Normative References . . . . . . . . . . . . . . . . . . . 9 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 risk 157 Risk-based authentication [JECM] 159 sms 160 Confirmation by SMS reply 162 tel 163 Confirmation by telephone call 165 user 166 User presence test 168 vbm 169 Voice biometric 171 wia 172 Windows integrated authentication, as described in [MSDN] 174 3. Authentication Request Parameter 176 This section defines the following authentication request parameter, 177 augmenting the set of authentication request parameters defined in 178 Section 3.1.2.1 of OpenID Connect Core 1.0 [OpenID.Core]: 180 amr_values 181 OPTIONAL. Requested Authentication Method Reference values. 182 Space-separated string that specifies the "amr" values that the 183 Authorization Server is being requested to use for processing this 184 Authentication Request, with the values appearing in order of 185 preference. The authentication methods used for the 186 authentication performed are returned as the "amr" Claim Value. 188 4. Relationship to "acr" (Authentication Context Class Reference) 190 The "acr" (Authentication Context Class Reference) claim and 191 "acr_values" request parameter are related to the "amr" 192 (Authentication Methods References) claim and "amr_values" request 193 parameter, but with important differences. Authentication Context 194 Classes specify a set of business rules that authentications are 195 being requested to satisfy. These rules can often be satisfied by 196 using a number of different specific authentication methods, either 197 singly or in combination. Interactions using "acr" request that 198 specified Authentication Context Classes be used and reply saying 199 which Authentication Context Class was satisfied. The reply states 200 that it was satisfied -- not how it was satisfied. 202 In contrast, interactions using "amr" make statements about the 203 particular authentication methods that are used. This tends to be 204 more brittle than using "acr" since the authentication methods that 205 may be appropriate for a given authentication will vary over time, 206 both because of the evolution of attacks on existing methods and the 207 creation of new authentication methods. 209 5. Privacy Considerations 211 The list of "amr" claim values returned in an ID Token reveals 212 information about the way that the end-user authenticated to the 213 identity provider. In some cases, this information may have privacy 214 implications. 216 6. Security Considerations 218 The security considerations in OpenID Connect Core 1.0 [OpenID.Core], 219 OAuth 2.0 [RFC6749], and the OAuth 2.0 Threat Model [RFC6819] apply 220 to this specification. 222 As described in Section 4, taking a dependence upon particular 223 authentication methods may result in brittle systems, since the 224 authentication methods that may be appropriate for a given 225 authentication will vary over time. 227 7. IANA Considerations 229 7.1. Authentication Method Reference Values Registry 231 This specification establishes the IANA "Authentication Method 232 Reference Values" registry for "amr" claim array element values. The 233 registry records the Authentication Method Reference value and a 234 reference to the specification that defines it. This specification 235 registers the Authentication Method Reference values defined in 236 Section 2. 238 Values are registered on a Specification Required [RFC5226] basis 239 after a three-week review period on the jwt-reg-review@ietf.org 240 mailing list, on the advice of one or more Designated Experts. 241 However, to allow for the allocation of values prior to publication, 242 the Designated Experts may approve registration once they are 243 satisfied that such a specification will be published. 245 Registration requests sent to the mailing list for review should use 246 an appropriate subject (e.g., "Request to register Authentication 247 Method Reference value: otp"). 249 Within the review period, the Designated Experts will either approve 250 or deny the registration request, communicating this decision to the 251 review list and IANA. Denials should include an explanation and, if 252 applicable, suggestions as to how to make the request successful. 253 Registration requests that are undetermined for a period longer than 254 21 days can be brought to the IESG's attention (using the 255 iesg@ietf.org mailing list) for resolution. 257 Criteria that should be applied by the Designated Experts includes 258 determining whether the proposed registration duplicates existing 259 functionality, whether it is likely to be of general applicability or 260 whether it is useful only for a single application, and whether the 261 registration description is clear. 263 IANA must only accept registry updates from the Designated Experts 264 and should direct all requests for registration to the review mailing 265 list. 267 It is suggested that the same Designated Experts evaluate these 268 registration requests as those who evaluate registration requests for 269 the IANA "JSON Web Token Claims" registry [IANA.JWT.Claims]. 271 7.1.1. Registration Template 273 Authentication Method Reference Name: 274 The name requested (e.g., "otp"). Because a core goal of this 275 specification is for the resulting representations to be compact, 276 it is RECOMMENDED that the name be short -- that is, not to exceed 277 8 characters without a compelling reason to do so. This name is 278 case sensitive. Names may not match other registered names in a 279 case-insensitive manner unless the Designated Experts state that 280 there is a compelling reason to allow an exception. 282 Authentication Method Reference Description: 283 Brief description of the Authentication Method Reference (e.g., 284 "One-time password"). 286 Change Controller: 287 For Standards Track RFCs, state "IESG". For others, give the name 288 of the responsible party. Other details (e.g., postal address, 289 email address, home page URI) may also be included. 291 Specification Document(s): 292 Reference to the document or documents that specify the parameter, 293 preferably including URIs that can be used to retrieve copies of 294 the documents. An indication of the relevant sections may also be 295 included but is not required. 297 7.1.2. Initial Registry Contents 299 o Authentication Method Reference Name: "eye" 300 o Authentication Method Reference Description: Retina scan biometric 301 o Change Controller: IESG 302 o Specification Document(s): Section 2 of [[ this document ]] 304 o Authentication Method Reference Name: "fpt" 305 o Authentication Method Reference Description: Fingerprint biometric 306 o Change Controller: IESG 307 o Specification Document(s): Section 2 of [[ this document ]] 309 o Authentication Method Reference Name: "kba" 310 o Authentication Method Reference Description: Knowledge-based 311 authentication 312 o Change Controller: IESG 313 o Specification Document(s): Section 2 of [[ this document ]] 315 o Authentication Method Reference Name: "mca" 316 o Authentication Method Reference Description: Multiple-channel 317 authentication 318 o Change Controller: IESG 319 o Specification Document(s): Section 2 of [[ this document ]] 321 o Authentication Method Reference Name: "mfa" 322 o Authentication Method Reference Description: Multiple-factor 323 authentication 324 o Change Controller: IESG 325 o Specification Document(s): Section 2 of [[ this document ]] 327 o Authentication Method Reference Name: "otp" 328 o Authentication Method Reference Description: One-time password 329 o Change Controller: IESG 330 o Specification Document(s): Section 2 of [[ this document ]] 332 o Authentication Method Reference Name: "pop" 333 o Authentication Method Reference Description: Proof-of-possession 334 of a key 335 o Change Controller: IESG 336 o Specification Document(s): Section 2 of [[ this document ]] 338 o Authentication Method Reference Name: "pwd" 339 o Authentication Method Reference Description: Password-based 340 authentication 341 o Change Controller: IESG 342 o Specification Document(s): Section 2 of [[ this document ]] 344 o Authentication Method Reference Name: "risk" 345 o Authentication Method Reference Description: Risk-based 346 authentication 347 o Change Controller: IESG 348 o Specification Document(s): Section 2 of [[ this document ]] 350 o Authentication Method Reference Name: "sms" 351 o Authentication Method Reference Description: Confirmation by SMS 352 reply 353 o Change Controller: IESG 354 o Specification Document(s): Section 2 of [[ this document ]] 356 o Authentication Method Reference Name: "tel" 357 o Authentication Method Reference Description: Confirmation by 358 telephone call 360 o Change Controller: IESG 361 o Specification Document(s): Section 2 of [[ this document ]] 363 o Authentication Method Reference Name: "user" 364 o Authentication Method Reference Description: User presence test 365 o Change Controller: IESG 366 o Specification Document(s): Section 2 of [[ this document ]] 368 o Authentication Method Reference Name: "vbm" 369 o Authentication Method Reference Description: Voice biometric 370 o Change Controller: IESG 371 o Specification Document(s): Section 2 of [[ this document ]] 373 o Authentication Method Reference Name: "wia" 374 o Authentication Method Reference Description: Windows integrated 375 authentication 376 o Change Controller: IESG 377 o Specification Document(s): Section 2 of [[ this document ]] 379 7.2. OAuth Parameters Registration 381 This section registers the following parameter in the IANA "OAuth 382 Parameters" registry [IANA.OAuth.Parameters] established in RFC 6749 383 [RFC6749]. 385 7.2.1. Registry Contents 387 o Parameter name: "amr_values" 388 o Parameter usage location: Authorization Request 389 o Change controller: IESG 390 o Specification document(s): Section 3 of [[ this document ]] 391 o Related information: None 393 8. References 395 8.1. Normative References 397 [IANA.JWT.Claims] 398 IANA, "JSON Web Token Claims", 399 . 401 [IANA.OAuth.Parameters] 402 IANA, "OAuth Parameters", 403 . 405 [JECM] Williamson, G., "Enhanced Authentication In Online 406 Banking", Journal of Economic Crime Management 4.2: 18-19, 407 2006, . 411 [JWT] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 412 (JWT)", RFC 7519, May 2015, 413 . 415 [MSDN] Microsoft, "Integrated Windows Authentication with 416 Negotiate", September 2011, . 421 [NIST.800-63-2] 422 National Institute of Standards and Technology (NIST), 423 "Electronic Authentication Guideline", NIST Special 424 Publication 800-63-2, August 2013, . 428 [OpenID.Core] 429 Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and 430 C. Mortimore, "OpenID Connect Core 1.0", November 2014. 432 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 433 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 434 RFC2119, March 1997, 435 . 437 [RFC4211] Schaad, J., "Internet X.509 Public Key Infrastructure 438 Certificate Request Message Format (CRMF)", RFC 4211, 439 DOI 10.17487/RFC4211, September 2005, 440 . 442 [RFC4226] M'Raihi, D., Bellare, M., Hoornaert, F., Naccache, D., and 443 O. Ranen, "HOTP: An HMAC-Based One-Time Password 444 Algorithm", RFC 4226, DOI 10.17487/RFC4226, December 2005, 445 . 447 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 448 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 449 DOI 10.17487/RFC5226, May 2008, 450 . 452 [RFC6238] M'Raihi, D., Machani, S., Pei, M., and J. Rydell, "TOTP: 453 Time-Based One-Time Password Algorithm", RFC 6238, 454 DOI 10.17487/RFC6238, May 2011, 455 . 457 [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", 458 RFC 6749, DOI 10.17487/RFC6749, October 2012, 459 . 461 8.2. Informative References 463 [RFC6819] Lodderstedt, T., Ed., McGloin, M., and P. Hunt, "OAuth 2.0 464 Threat Model and Security Considerations", RFC 6819, 465 DOI 10.17487/RFC6819, January 2013, 466 . 468 Appendix A. Acknowledgements 470 Caleb Baker participated in specifying the original set of 471 "amr_values" values. Brian Campbell, William Denniss, and Nat 472 Sakimura subsequently provided input on the set of "amr_values" 473 values defined. 475 Appendix B. Document History 477 [[ to be removed by the RFC editor before publication as an RFC ]] 479 -01 481 o Added the values "mca" (multiple-channel authentication), "risk" 482 (risk-based authentication), and "user" (user presence test). 484 o Added citations in the definitions of Windows integrated 485 authentication, knowledge-based authentication, risk-based 486 authentication, multiple-factor authentication, one-time password, 487 and proof-of-possession. 489 o Alphabetized the values. 491 o Added Tony Nadalin as an author and added acknowledgements. 493 -00 495 o Defined the IANA "Authentication Method Reference Values" 496 registry. 498 Authors' Addresses 500 Michael B. Jones 501 Microsoft 503 Email: mbj@microsoft.com 504 URI: http://self-issued.info/ 506 Phil Hunt 507 Oracle 509 Email: phil.hunt@yahoo.com 511 Anthony Nadalin 512 Microsoft 514 Email: tonynad@microsoft.com