idnits 2.17.1 draft-woodworth-json-http-auth-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 seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 05, 2017) is 2608 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 7159 (Obsoleted by RFC 8259) ** Obsolete normative reference: RFC 7230 (Obsoleted by RFC 9110, RFC 9112) ** Obsolete normative reference: RFC 7235 (Obsoleted by RFC 9110) Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 httpauth J. Woodworth 2 Internet-Draft D. Ballew 3 Intended status: Experimental CenturyLink, Inc. 4 Expires: August 31, 2017 March 05, 2017 6 HTTP Authentication - |JSON| Scheme 7 draft-woodworth-json-http-auth-01 9 Abstract 11 The |JSON| authentication scheme provides a mechanism for exchanging 12 authentication challenges and credentials as objects in the form of 13 JavaScript Object Notation (JSON). This scheme offers a secure 14 mechanism of providing authenticated access to a set of protected 15 HTTP resources which may be handled by scripting utility framework as 16 in XMLHttpRequest calls (AJAX) or directly by the client's user 17 agent. This chaining feature is unique to this scheme. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. Internet-Drafts are working 23 documents of the Internet Engineering Task Force (IETF). Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. The list of current Internet-Drafts is at 26 http://datatracker.ietf.org/drafts/current. 28 This document may contain material from IETF Documents or IETF 29 Contributions published or made publicly available before November 30 10, 2008. The person(s) controlling the copyright in some of this 31 material may not have granted the IETF Trust the right to allow 32 modifications of such material outside the IETF Standards Process. 33 Without obtaining an adequate license from the person(s) controlling 34 the copyright in such materials, this document may not be modified 35 outside the IETF Standards Process, and derivative works of it may 36 not be created outside the IETF Standards Process, except to format 37 it for publication as an RFC or to translate it into languages other 38 than English. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 Copyright Notice 47 Copyright (c) 2017 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents: 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 3 63 1.1. Background and Related Documents . . . . . . . . . . . 3 64 1.2. Reserved Words . . . . . . . . . . . . . . . . . . . . 3 65 2. The |JSON| HTTP-Authentication Scheme . . . . . . . . . . . 4 66 2.1. JSON Based Payloads . . . . . . . . . . . . . . . . . 4 67 2.2. Chained Authentication Cursor (CAC) . . . . . . . . . 5 68 2.3. Extensible Authentication Indicators (EAI) . . . . . . 5 69 2.4. One-Time Password (OTP) Authentication Capability . . 5 70 3. |JSON| Authentication Scheme Types . . . . . . . . . . . . 6 71 3.1. The "password" |JSON| Authentication Type . . . . . . 6 72 3.2. The "challenge" |JSON| Authentication Type . . . . . . 8 73 3.3. The Hybrid One-Off |JSON| Authentication Type 74 Variant . . . . . . . . . . . . . . . 12 75 4. Implementation Considerations . . . . . . . . . . . . . . . 12 76 4.1 Nonce Generation . . . . . . . . . . . . . . . . . . . . . 13 77 4.2 User-Agent Scripted Authentication . . . . . . . . . . . . 14 78 5. Security Considerations . . . . . . . . . . . . . . . . . . 15 79 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . 15 80 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 15 81 8. References . . . . . . . . . . . . . . . . . . . . . . . . 16 82 8.1. Normative References . . . . . . . . . . . . . . . . . 16 83 8.2. Informative References . . . . . . . . . . . . . . . . 16 85 1. Introduction 87 The |JSON| authentication scheme offers a number of new concepts used 88 to extend or enhance current HTTP-Authentication facilities. 90 New concepts include; JSON Based Challenge/ Response Payloads, 91 Chained Authentication Cursor (CAC), Extensible Authentication 92 Indicators (EAI) and One-Time Password (OTP) Authentication Support. 94 1.1. Background and Related Documents 96 This document assumes the reader is familiar with the basic HTTP and 97 HTTP-Authentication concepts described in [RFC7230] and [RFC7235]. 99 The reader is also assumed to be familiar with the JSON data 100 interchange format and associated terminology described in [RFC7159] 101 as well as the Base64 encoding methods as described in [RFC4648]. 103 1.2. Reserved Words 105 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 106 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 107 document are to be interpreted as described in [RFC2119]. 109 2. The |JSON| HTTP-Authentication Scheme 111 The |JSON| scheme provides an extensible mechanism of providing 112 primary HTTP authentication to a web-based application. This section 113 will cover a number of new concepts intended to extend the 114 flexibility and capabilities of existing HTTP authentication schemes. 116 This scheme follows the methods defined in [RFC7235] to provide 117 authentication challenge and response via the HTTP-Headers "WWW- 118 Authenticate" and "Authorization" respectively. For the moment at 119 least, this document hereby defines proxy authentication as out of 120 scope. 122 2.1. JSON Based Payloads 124 A primary motivation for this document is to offer the ability to 125 leverage scripting capabilities within the client application. While 126 this does fall outside the HTTP protocol itself, modern HTTP clients 127 have advanced to a point where scripting and asynchronous calls to 128 back-end web services have become quite common. These advancements 129 offer an integration between the HTTP protocol and client side logic 130 processing (i.e. scripting). 132 One such advancement along this path is the ubiquity of JSON encoded 133 objects. These objects can be quickly processed and passed over-the- 134 wire to almost any programming language and are native to the default 135 scripting engine of modern browsers. 137 By leveraging the JSON format for passing challenges and responses 138 back and forth a type of protocol-logic bridge can be easily 139 established. 141 This document defines a single JSON object containing zero or more 142 elements where the set of elements is defined by its authentication 143 "type" and whether it is a challenge or response. This document 144 defines 3 types, "password", "challenge", and a hybrid one-off 145 variant each described in detail in sections to follow. This object 146 is Base64 encoded and assigned to the "data" auth-param as defined in 147 [RFC7235], Section 2.1. Additionally, while many examples show JSON 148 object definitions in this document are shown in a "pretty" format to 149 improve readability the over-the-wire encoding is expected to be in a 150 condensed form (minimum whitespace) prior to Base64 encoding. 152 Below is a simple example demonstrating the "password" type: 154 WWW-Authenticate: |JSON| realm="Test Realm", 155 data="eyAidHlwZSIgOiAicGFzc3dvcmQiIH0=" 157 2.2. Chained Authentication Cursor (CAC) 159 Beyond the utilization of the JSON format to exchange and validate 160 authentication credentials, this document establishes the concept of 161 a Chained Authentication Cursor (CAC). 163 The logic used to implement CAC is simpler than the name may imply. 164 In essence, the client's user-agent is currently aware of several 165 authentication schemes, each with their own handler. For example, a 166 handler is defined for the "Basic" scheme, another for the "Digest" 167 scheme, etc. When a challenge is received from the server as a 168 result of a "401 Unauthorized" response, a cursor is assigned and 169 attached to this challenge. This cursor follows the challenge 170 throughout its short life-cycle "Chained" in succession to each of 171 the available user-agent authentication handlers in order to provide 172 the client's response. Each handler may either accept or reject the 173 authentication cursor based entirely upon the scheme passed to it. 174 If the cursor is accepted, it MUST provide a response to be used for 175 the follow-up request. 177 Some handlers in the chain MAY be defined as Extensible 178 Authentication Handlers (EAH) others as Native Authentication 179 Handlers (NAH). EAHs are extensions to the built-in NAHs and are 180 generally provided as either a client extension or scripted handler 181 and can be used to provide custom or interim authentication 182 solutions. Additional recommendations are provided in this document 183 to avoid "Chicken and Egg" scenarios where EAHs are concerned. 185 2.3. Extensible Authentication Indicators (EAI) 187 Schemes used by Extensible Authentication Handlers (EAH) MUST have 188 their intent formally identified by an Extensible Authentication 189 Indicator (EAI). The [US-ASCII] pipe character (|) is reserved for 190 this purpose and if the HTTP-Authentication scheme is surrounded by 191 this character (e.g. "|JSON|", "|Basic|", "|example|", "|pdmk|", 192 "|random|", etc.) an EAH MUST be assumed. If no EAH are defined for 193 an EAI indicated scheme, the indicators MUST be removed and the CAC 194 passed to a handler for the new scheme as next in the chain. For 195 example, if the scheme "|Basic|" is provided in the challenge and no 196 EAH is defined for "|Basic|", then an attempt to pass the CAC to a 197 "Basic" NAH MUST be attempted. This logic MUST be attempted for each 198 EAH in the chain for the active CAC. 200 2.4. One-Time Password (OTP) Authentication Capability 202 This document defines provisions for One-Time Password (OTP) 203 Authentication. This concept, while simple to grasp, causes 204 difficulty in a stateless protocol such as HTTP. Recommendations for 205 overcoming such difficulties are provided in sections which follow. 207 3. |JSON| Authentication Scheme Types 209 The following three authentication types are explicitly defined by 210 this document but others may exist under its umbrella so long as none 211 of the defined requirements are violated. 213 Additionally, the objects and internal elements defined are to be 214 considered a super-set of those implemented and extension or 215 "enrichment" is to be expected and are considered OPTIONAL. However, 216 in order to ensure compatibility all objects and internal elements 217 defined by a type and not defined as OPTIONAL MUST be implemented as 218 defined. 220 3.1. The "password" |JSON| Authentication Type 222 This is the simplest authentication type offered. This type is 223 provided in order to offer scripted capability without a lot of 224 knowledge in cryptography. Due to its clear-text nature it is highly 225 recommended to only be used in an encrypted environment (i.e. 226 SSL/TLS, etc.). 228 The HTTP-Authentication challenge for this type includes the 229 following elements (with definitions): 231 type: REQUIRED 233 The |JSON| Authentication Scheme type of "password" 235 cookie: OPTIONAL 237 This is the name of the HTTP-Cookie as defined by [RFC6265] 238 which will be used by the server for continuing the session 239 after initial HTTP based authentication has completed 241 version: OPTIONAL 243 The |JSON| Authentication Scheme version. This document 244 defines this as 1.0 and version 1.0 MUST be assumed if no 245 version is provided 247 An example challenge for this type is simply: 249 { "type" : "password" } 251 The HTTP-Authentication challenge MUST be Base64 encoded and applied 252 to the "WWW-Authenticate" HTTP-Header as defined by [RFC7235], 253 Section 4.1. 255 The Base64-encoded header with associated realm appears as: 257 WWW-Authenticate: |JSON| realm="Test Realm", 258 data="eyAidHlwZSIgOiAicGFzc3dvcmQiIH0=" 260 The HTTP-Authentication response for this type includes the following 261 elements (with definitions): 263 type: REQUIRED 265 The |JSON| Authentication Scheme type of "password" 267 username: REQUIRED 269 The user associated with this protected resource 271 password: REQUIRED 273 The password associated with this protected resource 275 version: OPTIONAL 277 The |JSON| Authentication Scheme version. This document 278 defines this as 1.0 and version 1.0 MUST be assumed if no 279 version is provided 281 NOTE: Since no protection of credentials is offered by the "password" 282 type, the need for other protections such as replay-prevention is 283 unnecessary and therefore not offered as part of this type. 285 For an example username of "MyUser" and password of "MyPassword" the 286 JSON representation of the response would be: 288 { 289 "type" : "password" 290 ,"username" : "MyUser" 291 ,"password" : "MyPassword" 292 } 294 The Base64-encoded header with associated realm appears as: 296 Authorization: |JSON| realm="Test Realm", 297 data="eyAidHlwZSIgOiAicGFzc3dvcmQiLCAi 298 dXNlcm5hbWUiIDogIk15VXNlciIsICJwYXNzd2 299 9yZCIgOiAiTXlQYXNzd29yZCIgfQ==" 301 NOTE: The "data" element has been expanded to multiple lines for 302 readability purposes only 304 3.2. The "challenge" |JSON| Authentication Type 306 The challenge authentication type provides features to protect the 307 credentials against replay-prevention and over-the-wire interception. 309 The HTTP-Authentication challenge for this type includes the 310 following elements (with definitions). More details are provided in 311 the implementation considerations sections below. 313 type: REQUIRED 315 The |JSON| Authentication Scheme type of "challenge" 317 algorithms: REQUIRED 319 A comma separated list of accepted algorithms as defined by 320 [FIPS-180-4] and [FIPS-202] in order of preference (OPTIONAL 321 whitespace MUST be ignored during selection described below). 323 NOTE: This list of algorithms represents all algorithms the 324 server is capable of and willing to verify hashed passwords 325 received by a client against. In other words, hashed passwords 326 MUST either be known to the server or generated by the server 327 by way of hashing known clear-text passwords for each provided 328 algorithm 330 NOTE: Use of the SHA-1 algorithm is highly discouraged at the 331 time this document is being written and SHOULD NOT be used. 333 nonce: REQUIRED 335 A one-time-only value calculated by the server to be used in 336 client calculations 338 cookie: OPTIONAL 340 This is the name of the HTTP-Cookie as defined by [RFC6265] 341 which will be used by the server for continuing the session 342 after initial HTTP based authentication has completed 344 message: OPTIONAL 346 A string value which MAY be presented to the user as additional 347 information about the authentication challenge or previous 348 attempt. An example would be "Unable to authenticate 349 credentials at this time, please try again later." 351 opaque: OPTIONAL 353 A value calculated by the server to provide additional 354 protection against tampering and session management 356 path: OPTIONAL 358 A value representing the protected resource path. The provided 359 path does not need to be the literal path but can be a symbolic 360 path or hash which can be used by the client and server to 361 limit a set of resources beyond what has been provided by the 362 realm 364 version: OPTIONAL 366 The |JSON| Authentication Scheme version. This document 367 defines this as 1.0 and version 1.0 MUST be assumed if no 368 version is provided 370 window: OPTIONAL 372 An integer value (in seconds) the challenge will be valid for. 373 This value is informational and MAY be used by the client to 374 determine why a previous authentication attempt failed 375 (challenge is no longer valid) 377 An example challenge for this type is: 379 { 380 "type" : "challenge" 381 ,"algorithms" : "SHA-384,SHA-256,SHA-224" 382 ,"nonce" : "1488442706.13154/ 383 339158aa-2504-44a4-bd7a-c86a85c4c7a8, 384 320afaed21f1827383194b49c02008909cf28 385 3ca2f3dca190c2ab958ea580a28" 386 } 387 NOTE: Elements in the object above have been expanded to multiple 388 lines for readability purposes only 390 The Base64-encoded header with associated realm appears as: 392 WWW-Authenticate: |JSON| realm="Test Realm", 393 data="eyJ0eXBlIjoiY2hhbGxlbmdlIiwiYWxnb3JpdG 394 htcyI6IlNIQS0yNTYsU0hBLTEiLCJub25jZSI6 395 IjE0ODg0NDI3MDYuMTMxNTQvMzM5MTU4YWEtMj 396 UwNC00NGE0LWJkN2EtYzg2YTg1YzRjN2E4LDMy 397 MGFmYWVkMjFmMTgyNzM4MzE5NGI0OWMwMjAwOD 398 kwOWNmMjgzY2EyZjNkY2ExOTBjMmFiOTU4ZWE1 399 ODBhMjgifQ==" 401 The HTTP-Authentication response for this type includes the following 402 elements (with definitions). More details are provided in the 403 implementation considerations sections below. 405 type: REQUIRED 407 The |JSON| Authentication Scheme type of "challenge" 409 username: REQUIRED 411 The user associated with this protected resource 413 algorithm: REQUIRED 415 The algorithm selected from the challenge's algorithms element. 416 If no compatible algorithm can be established, the client MUST 417 fail and if applicable provide additional details to the user 419 nonce: REQUIRED 421 This value MUST match the nonce value provided by the server's 422 challenge verbatim 424 token: REQUIRED 426 This value MUST be generated by the client according to the 427 following rules: 429 - A hash of the client provided password MUST be generated 430 using the cryptographic algorithm specified as "algorithm" 431 above. 433 password_hash = ALGORITHM ( password ) 435 - The following values (including quoted colon values ":") 436 MUST be concatenated into a single string value. Optional 437 values which are not defined MUST be replaced by an empty 438 string. Any required field which is not defined MUST fail 439 and if applicable provide additional details to the user 441 pre_token = username + ":" + password_hash + ":" + 442 nonce + ":" + opaque + ":" + 443 algorithm + ":" + cnonce + ":" + 444 message 446 - A hash of the string provided in the previous step MUST be 447 generated using the cryptographic algorithm specified as 448 "algorithm" above. 450 token = ALGORITHM ( pre_token ) 452 NOTE: The output of the ALGORITHM function MUST be encoded as a 453 lowercase hexadecimal value 454 NOTE: Upon receipt of a client's response to a "challenge" type 455 server challenge, the server MUST follow the identical process 456 as above to generate the token on its side of the conversation 457 for an identical match. All necessary elements are expected to 458 be already known, derived by known data or received in the 459 client's response. Nonce, Opaque and other verifiable elements 460 MUST be verified prior to recreating the token in order to 461 verify data against potential tampering 463 cnonce: OPTIONAL 465 A one-time-only value calculated by the client to be used for 466 further limiting replay-attacks 468 message: OPTIONAL 470 A string value which MAY be presented to the server as 471 additional information about the authentication response for 472 logging and debugging purposes. An example would be "CoolAuth- 473 Client/1.0" 475 opaque: OPTIONAL 477 This value MUST match the opaque value provided by the server's 478 challenge verbatim. If no opaque value was provided by the 479 server's challenge, the client MUST NOT provide one in the 480 response 482 version: OPTIONAL 484 The |JSON| Authentication Scheme version. This document 485 defines this as 1.0 and version 1.0 MUST be assumed if no 486 version is provided 488 For an example username of "MyUser", a password of "MyPassword" and 489 the "SHA-256" hashing algorithm the JSON representation of the 490 response would be: 492 { 493 "type" : "challenge" 494 ,"algorithm" : "SHA-256" 495 ,"username" : "MyUser" 496 ,"nonce" : "1488442706.13154/ 497 339158aa-2504-44a4-bd7a-c86a85c4c7a8, 498 320afaed21f1827383194b49c02008909cf28 499 3ca2f3dca190c2ab958ea580a28" 500 ,"token" : "03066bdf1244be4c458fd6ef46af52acceea2 501 0d90ee979b10231018a52d92e66" 502 } 503 NOTE: Elements in the object above have been expanded to multiple 504 lines for readability purposes only 506 The Base64-encoded header with associated realm appears as: 508 Authorization: |JSON| realm="Test Realm", 509 data="eyJ0eXBlIjoiY2hhbGxlbmdlIiwiYWxnb3JpdG 510 htIjoiU0hBLTI1NiIsInVzZXJuYW1lIjoiTXlV 511 c2VyIiwibm9uY2UiOiIxNDg4NDQyNzA2LjEzMT 512 U0LzMzOTE1OGFhLTI1MDQtNDRhNC1iZDdhLWM4 513 NmE4NWM0YzdhOCwzMjBhZmFlZDIxZjE4MjczOD 514 MxOTRiNDljMDIwMDg5MDljZjI4M2NhMmYzZGNh 515 MTkwYzJhYjk1OGVhNTgwYTI4IiwidG9rZW4iOi 516 IwMzA2NmJkZjEyNDRiZTRjNDU4ZmQ2ZWY0NmFm 517 NTJhY2NlZWEyMGQ5MGVlOTc5YjEwMjMxMDE4YT 518 UyZDkyZTY2In0=" 520 NOTE: The "data" element has been expanded to multiple lines for 521 readability purposes only 523 3.3. The Hybrid One-Off |JSON| Authentication Type Variant 525 This document defines a "One-Off" feature which informs the client's 526 user agent the intent of the server's challenge is to fulfill a One- 527 Time-Password (OTP) and client credentials MUST NOT be cached and 528 reused for multiple responses. 530 It must be noted this is a deviation from the standard client 531 behavior in that caching and reusing credentials expected as OTP can 532 have the side-effect of locking the account upon reuse of successful 533 credentials. It is highly recommended a cookie authentication 534 mechanism be used to continue a successfully authenticated session. 535 More details are provided in the implementation considerations 536 sections below. 538 This feature is available for either the "password" or "challenge" 539 types explained in the sections above and is enabled by setting the 540 type to the type prepended by a single exclamation character (!). 542 For an example username of "MyUser" and password of "MyPassword" the 543 JSON representation of the response would be: 545 { 546 "type" : "!password" 547 ,"username" : "MyUser" 548 ,"password" : "MyPassword" 549 } 551 4. Implementation Considerations 553 This document provides the following recommendations to improve 554 overall compatibility between implementations. 556 4.1 Nonce Generation 558 The authors of this document highly recommended two factors when 559 implementing the generation of nonce values. 561 1) Time Component 563 The two main goals for the nonce field is to; a) provide 564 protection against replays of captured credential payloads; and 565 b) make cryptographic analysis more difficult. A simple 566 implementation to meet both of these goals is to provide a time 567 component to the nonce string. 569 The examples in this document use a hi-resolution "epoch" (or unix 570 time) at the start of each nonce followed by a [US-ASCII] forward- 571 slash character "/" and a generated portion. 573 The string "1488442706.13154" from the examples above 574 represents "Thu Mar 2 08:18:26 2017" referenced to the GMT 575 timezone. 577 Using a component like this greatly reduces the risk of nonce 578 reuse and allows for a validity window to easily be established. 579 Since this is generated at the server, no time synchronization 580 needs to be performed with the client and when used for the 581 response, can be directly compared with the same time source. 583 2) Validation Component 585 Since the nonce is used as a component of the client's response 586 and the HTTP protocol is stateless, it is highly recommended the 587 validity of the nonce be confirmed prior to authenticating the 588 request. If, for example, a malicious user was to modify the 589 nonce and use this modified nonce in the response, the security of 590 the requested resource may be jeopardized. 592 This document recommends adding a component which can be easily 593 self-validated and offers protection against such tampering. This 594 can be done by using a secret known only to the server (or set of 595 servers). 597 The examples in this document use a Universally Unique Identifier 598 UUID generator to provide a bit of uniqueness beyond simply the 599 time component discussed above. Most UUID implementations 600 leverage a source of entropy to nearly eliminate the risk of 601 collisions and this along with the time component should make this 602 safe within a reasonable validation window. 604 The UUID is combined with the time component, optional opaque 605 value and secret key to form the full nonce string using the 606 following pattern: 608 time_component + ":" + uuid_component + ":" + 609 opaque + ":" + secret 611 The examples in this document use the following values for this: 613 time_component = "1488442706.13154" 615 uuid_component = "339158aa-2504-44a4-bd7a-c86a85c4c7a8" 617 opaque = "" 619 secret = "MyKey" 621 This equates to the string: 623 1488442706.13154:339158aa-2504-44a4-bd7a-c86a85c4c7a8::MyKey 625 The SHA-256 output of this is: 627 320afaed21f1827383194b49c02008909cf283ca2f3dca19 628 0c2ab958ea580a28 630 NOTE: The above example has been expanded to multiple lines for 631 readability purposes only 633 The final string for this nonce is: 635 1488442706.13154/339158aa-2504-44a4-bd7a-c86a85c4c7a8, 636 320afaed21f1827383194b49c02008909cf283ca2f3dca190c2ab 637 958ea580a28 639 NOTE: The above example has been expanded to multiple lines for 640 readability purposes only 642 4.2 User-Agent Scripted Authentication 644 A highlighted feature of this document is its ability to pass 645 authentication to a scripting facility within the client. This 646 section provides recommendations for implementing this feature. 648 1) Chicken and Egg avoidance: 650 A complication to tying scripts to authentication is the 651 scripts must be loaded prior to the authentication challenge in 652 order for this to work. One way to avoid this is to provide 653 the authentication handler in a script above other scripts in 654 the main document. The main document will need to be able to 655 load without initial authentication for this to work. This 656 solution will not work where Asynchronous Module Definition 657 (AMD) is deployed. 659 Another solution would be to use an authentication entry-point 660 page which would be in an unauthenticated "zone" of the 661 application and once successfully authenticated redirect to the 662 authenticated "zone" leveraging cookies for the transition. 664 2) Where do the Scripted Handlers Live? 666 Assuming this document has found a large adoption, it is 667 recommended the user agent hosts this as a function of the root 668 of in its HTML DOM tree (e.g. "window.AuthHandler();"). 670 This function could provide: 672 a) A test for the existence of an EAH handler for a 673 particular scheme 675 b) Invoke an EAH handler for a particular 677 c) Install an EAH handler for a particular scheme 679 Until interest for such an adoption, we recommended this to be 680 where developers host their EAHs and invoke such EAHs where 681 appropriate. 683 5. Security Considerations 685 This document provides methods for transmitting credentials (or the 686 implicit knowledge of these credentials) from an HTTP client agent 687 (e.g. "browser") to an HTTP server. Methods have been provided in 688 some instances to protect the actual credentials from tampering 689 between this connection but steps must be taken on each side to 690 protect the credential collection and validation points. Any weak 691 point in a security system makes that system in its entirety just as 692 weak. 694 6. IANA Considerations 696 IANA is requested to update their http-authschemes registry 697 to include the 698 "|JSON|" and "|*|" schemes where "|*|" represents any valid token 699 surrounded by [US-ASCII] pipe characters "|" (e.g. "|pdmk|"). 701 7. Acknowledgments 703 This document leans heavily on on the work of others, specifically 704 those responsible for the RFCs listed below. The authors of this 705 document wish to thank each author involved to help get us here. The 706 authors also extend a special thanks to Kathleen Moriarty, for 707 encouraging us to finish this draft. 709 8. References 711 8.1. Normative References 713 [US-ASCII] American National Standards Institute, "Coded Character 714 Set -- 7-bit American Standard Code for Information 715 Interchange", ANSI X3.4, 1986. 717 [FIPS-180-4] National Institute of Standards and Technology (NIST), 718 United States of America, "Secure Hash Standard (SHS)", 719 FIPS PUB 180-4, August 2015 , . 722 [FIPS-202] National Institute of Standards and Technology (NIST), 723 United States of America, "SHA-3 Standard: 724 Permutation-Based Hash and Extendable-Output Functions", 725 FIPS PUB 202, August 2015 , . 728 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 729 Requirement Levels", BCP 14, RFC 2119, March 1997. 731 [RFC4648] S. Josefsson, SJD, "The Base16, Base32, and Base64 732 Data Encodings", RFC 4648, October 2006. 734 [RFC6265] A. Barth, "HTTP State Management Mechanism", RFC 6265, 735 April 2011. 737 [RFC7159] T. Bray, "The JavaScript Object Notation (JSON) Data 738 Interchange Format", RFC 7159, March 2014. 740 [RFC7230] R. Fielding, J. Reschke, "Hypertext Transfer Protocol 741 (HTTP/1.1): Message Syntax and Routing", RFC 7230, 742 June 2014. 744 [RFC7235] R. Fielding, J. Reschke, "Hypertext Transfer Protocol 745 (HTTP/1.1): Authentication", RFC 7235, June 2014. 747 8.2. Informative References 749 Authors' Addresses 750 John Woodworth 751 4250 North Fairfax Drive 752 Arlington, VA 22203 753 USA 755 EMail: John.Woodworth@CenturyLink.com 757 Dean Ballew 758 2355 Dulles Corner Boulevard Suite 200 300 759 Herndon, VA 20171 760 USA 762 EMail: Dean.Ballew@CenturyLink.com 764 Acknowledgement 766 Funding for the RFC Editor function is currently provided by the 767 Internet Society.