idnits 2.17.1 draft-ietf-httpauth-rest-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 date (August 14, 2013) is 3907 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.williams-websec-session-continue-prob' is defined on line 1129, but no explicit reference was found in the text == Unused Reference: 'RFC6631' is defined on line 1192, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 2617 (Obsoleted by RFC 7235, RFC 7615, RFC 7616, RFC 7617) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 5849 (Obsoleted by RFC 6749) -- Obsolete informational reference (is this intentional?): RFC 5996 (Obsoleted by RFC 7296) Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group N. Williams 3 Internet-Draft Cryptonector 4 Intended status: Informational August 14, 2013 5 Expires: February 15, 2014 7 RESTful Authentication Pattern for the Hypertext Transport Protocol 8 (HTTP) 9 draft-ietf-httpauth-rest-auth-01 11 Abstract 13 This document proposes a "RESTful" pattern of authentication for 14 HTTP/1.0, 1.1, and 2.0. The goal is to make it easy to add 15 authentication mechanisms to HTTP applications and to make it easy to 16 implement them even without much help from the HTTP stack (though it 17 is best to integrate authentication into the stack, of course). 18 Another goal is to make it easy to reuse existing authentication 19 mechanisms by allowing the user (that is, the server's operators) to 20 choose what concrete authentication mechanism(s) to use. 22 Among other benefits of RESTauth: it is orthogonal to "HTTP routers" 23 and proxies, it results in session Uniform Resource Identifiers 24 (URIs) that can be DELETEd to logout, naturally supports multi-legged 25 authentication schemes, naturally supports clustering, and can be 26 universally implemented on the server side with such 27 server<->application interfaces as the Common Gateway Interface (CGI) 28 and FastCGI, among others. 30 Status of this Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 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 This Internet-Draft will expire on February 15, 2014. 47 Copyright Notice 48 Copyright (c) 2013 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 4 64 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 4 65 1.1.1. Authentication Infrastructure and Credentials Reuse . . . 5 66 1.2. Protocol Outline . . . . . . . . . . . . . . . . . . . . . 6 67 1.3. API-Imposed Constraints . . . . . . . . . . . . . . . . . 7 68 1.4. Conventions used in this document . . . . . . . . . . . . 7 69 2. Alternatives . . . . . . . . . . . . . . . . . . . . . . . 8 70 2.1. In-band HTTP Authentication . . . . . . . . . . . . . . . 8 71 2.2. Out-of-Band Bearer Token Mechanisms . . . . . . . . . . . 9 72 2.3. Authentication in TLS . . . . . . . . . . . . . . . . . . 9 73 3. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . 10 74 3.1. Negotiable Parameters . . . . . . . . . . . . . . . . . . 10 75 3.1.1. Strong Binding to TLS . . . . . . . . . . . . . . . . . . 11 76 3.1.2. WWW-Authenticate Header Value Prefix Syntax . . . . . . . 11 77 3.1.3. WWW-ChannelBinding-Types Header . . . . . . . . . . . . . 12 78 3.1.4. WWW-ChannelBinding-Type Header . . . . . . . . . . . . . . 12 79 3.1.5. WWW-SessionBinding-Type Header . . . . . . . . . . . . . . 12 80 3.1.6. WWW-ReplayProtection Header . . . . . . . . . . . . . . . 12 81 3.2. Protocol Flow . . . . . . . . . . . . . . . . . . . . . . 12 82 3.2.1. One Round Trip Optimization: Challenges Born in 83 WWW-Authenticate Headers . . . . . . . . . . . . . . . . . 13 84 3.3. Session Binding Types: Cookie, Channel Bound Session 85 URI, and MAC . . . . . . . . . . . . . . . . . . . . . . . 14 86 3.3.1. The New WWW-Session-URI Header . . . . . . . . . . . . . . 14 87 3.3.2. The New WWW-Session-MAC Header . . . . . . . . . . . . . . 14 88 3.3.3. To MAC or not to MAC; A MAC Trailer?? . . . . . . . . . . 15 89 4. Representation of Authenticated Session Resources . . . . 16 90 5. Session URI Origin and Scope . . . . . . . . . . . . . . . 17 91 6. HTTP "Routing" and Authentication . . . . . . . . . . . . 18 92 7. Actual Authentication Mechanisms . . . . . . . . . . . . . 19 93 7.1. OAuth via RESTauth . . . . . . . . . . . . . . . . . . . . 19 94 7.1.1. OAuth 1.0 . . . . . . . . . . . . . . . . . . . . . . . . 19 95 7.1.2. OAuth 2.0 . . . . . . . . . . . . . . . . . . . . . . . . 19 96 7.2. Adapting SSHv2 Authentication Mechanisms to RESTauth . . . 19 97 7.2.1. RESTauth Mechanism Names for SSHv2 Userauth Methods . . . 20 98 7.2.2. Nonces . . . . . . . . . . . . . . . . . . . . . . . . . . 20 99 7.2.3. "Session ID" . . . . . . . . . . . . . . . . . . . . . . . 20 100 7.3. Adapting IKEv2 Authentication Mechanisms to RESTauth . . . 20 101 7.3.1. Adapting IKEv2 Password Authenticated Connection 102 Establishment (PACE) to RESTauth . . . . . . . . . . . . . 20 103 7.4. Using SASL Authentication Mechanisms with RESTauth . . . . 21 104 7.4.1. Using SCRAM in RESTauth . . . . . . . . . . . . . . . . . 21 105 7.4.2. Using SCRAM with Round Trip Optimization in RESTauth . . . 22 106 7.5. Using GSS-API Authentication Mechanisms with RESTauth . . 23 107 8. Implementation Advice . . . . . . . . . . . . . . . . . . 25 108 8.1. Server-Side Implementation Advice . . . . . . . . . . . . 25 109 8.1.1. Channel Binding on the Server Side . . . . . . . . . . . . 25 110 8.1.2. Server Cluster / Routing Support . . . . . . . . . . . . . 25 111 8.2. Client-Side Implementation Advice . . . . . . . . . . . . 26 112 8.2.1. Channel Binding on the Client Side . . . . . . . . . . . . 27 113 9. IANA Considerations . . . . . . . . . . . . . . . . . . . 28 114 10. Security Considerations . . . . . . . . . . . . . . . . . 29 115 11. TODO . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 116 12. References . . . . . . . . . . . . . . . . . . . . . . . . 31 117 12.1. Normative References . . . . . . . . . . . . . . . . . . . 31 118 12.2. Informative References . . . . . . . . . . . . . . . . . . 31 119 Author's Address . . . . . . . . . . . . . . . . . . . . . 33 121 1. Introduction 123 There is a great need for improved authentication options in HTTP 124 applications, both web browser and non-browser applications. At this 125 time there are a number of proposals being made in the HTTPauth 126 Working Group (WG). This proposal is just one of many. 128 Some of the goals of RESTauth are: 130 o an authentication protocol that reuses existing authentication 131 mechanisms -- in principle any and all mechanisms that we have in 132 the Internet protocols, including: SASL [RFC4422], GSS-API 133 [RFC2743], SSHv2 [RFC4251], IKEv2 [RFC5996], and other frameworks, 134 as well as ad-hoc mechanisms and/or standard mechanisms used 135 outside such frameworks; 137 o an authentication protocol that layers above HTTP so that 138 applications may implement it with little or no help from (read: 139 modifications to) the existing HTTP stacks that they use, all the 140 while not precluding native support for RESTauth by any HTTP 141 stack; 143 o an authentication protocol that supports a notion of sessions 144 without depending on having a single HTTP/TLS/TCP connection, and 145 which can be logged out explicitly, with explicit scoping of 146 sessions; 148 o an authentication protocol that naturally supports HTTP server- 149 side routing and clustering. 151 We propose a pattern for HTTP [RFC2616] [TODO: add reference to 152 HTTP/2.0 as well?] authentication mechanisms that, by being 153 "RESTful", obtains these goals naturally. 155 1.1. Motivation 157 Existing HTTP authentication mechanisms leave much to be desired. 159 Existing "in-band" mechanisms: 161 o Basic [RFC2617]; 163 o Digest [RFC2617]; 165 o Negotiate [RFC4559]. 167 Other existing mechanisms: 169 o ad-hoc username-and-password authentication using HTML forms 170 POSTed over HTTP, plus web cookies; 172 o various bearer token mechanisms [TODO: add examples, such as 173 OAuth]; 175 o various non-bearer token mechanisms which are not generalized or 176 generalizable to a larger universe of authentication mechanisms 177 [TODO: add examples, such as BrowserID]. 179 In enterprise and educational settings it is common to need support 180 for Kerberos [RFC4120]. Of the above only Negotiate supports 181 Kerberos meaningfully or at all, and does so badly, requiring re- 182 authentication for every request in many implementations (among other 183 problems; see Section 2.1 for more). 185 Enterprises and educational settings also often have RADIUS 186 [RFC2865], often used via EAP [RFC3748]. These could be supported by 187 the generic security mechanism based on EAP, RADIUS, and SAML being 188 developed by the ABFAB WG [TODO: add references!]. These mechanisms 189 in particular will be difficult to use via Negotiate because they 190 involve multiple round trips, which Negotiate supports half- 191 heartedly; see Section 2.1. 193 1.1.1. Authentication Infrastructure and Credentials Reuse 195 All too commonly the community invents new authentication mechanisms 196 that require their own authentication infrastructures or bridges to 197 other mechanisms' existing infrastructures. This is a costly habit: 198 costly for those who must deploy these. A pattern of authentication 199 mechanism reuse would greatly improve this situation. 201 Most, if not all [classical, not quantum mechanical] authentication 202 mechanisms involve an exchange of one or more authentication 203 messages, accept as input the names of the peers being authenticated, 204 and on success output some information such as the names of the 205 authenticated peers, trust transit paths, session keys, and so on. 207 Actual mechanisms differ in minor details, such as which party sends 208 the first authentication mechanism (but there is always an initiator, 209 even if initiation is implied by connecting to a network, for example 210 as in EAP, which can be thought of as sending an empty initial 211 authentication message). These differences can be abstracted. 212 Indeed, we have at least _five_ authentication mechanism frameworks 213 in Internet protocols: 215 o Generic Security Services (GSS-API) [RFC2743]; 217 o Simple Authentication and Security Layers (SASL) [RFC4422]; 219 o Secure Shell version 2 (SSHv2) [RFC4251]; 221 o Internet Key Exchange Protocol versions 1 and 2 (IKEv2) [RFC5996]; 223 o Extensible Authentication protocol (EAP) [RFC3748]. 225 Five authentication frameworks is an embarrassment of riches. And 226 yet we continually implement new ad-hoc authentication mechanisms -- 227 this is not just embarrassing (it isn't really embarrassing, as it is 228 a part of the human condition that we continually re-invent things), 229 but wasteful, both because it means we fail to reuse existing code 230 and specifications, and because it means users are faced with costly 231 deployment headaches. 233 There are also many authentication mechanisms that support (or could 234 easily be extended to) federation. 236 The desire to re-invent authentication mechanisms (and frameworks) to 237 avoid technologies of the past (e.g., ASN.1 and its encoding rules) 238 or specific instantiations of them (e.g., GSS-API) is understandable, 239 but at the very least it should be made easy for developers to add 240 application support for arbitrary authentication mechanisms of any 241 given users choice. The only way to enable use of the user's choice 242 of authentication mechanism is through a common protocol that embeds 243 that authentication mechanism's messages, and that is _exactly_ what 244 RESTauth aims to be for HTTP. 246 1.2. Protocol Outline 248 1. initial authentication messages are POSTed to an agreed-upon or 249 indicated "login" resource... 251 2. ....which then results in a new resource being created with the 252 authentication reply message as the new resource's 253 representation. 255 3. Thereafter any additional authentication message exchanges needed 256 (for multi-legged mechanisms) are POSTed to the new resource 257 without creating additional resources. 259 4. The resource created by the POSTing of the initial authentication 260 mechanism identifies the resulting session, and its URI is known 261 as the session URI. 263 5. Session URIs can be used to multiplex multiple sessions over the 264 same TCP/TLS connections, implement logout, and share sessions 265 across multiple related servers. 267 Authentication using mechanisms that require that the server send the 268 first authentication message is also possible, in either of two ways: 269 the initial authentication message is sent in headers in a 401 270 response, or the client POSTs an empty first message to the login 271 resource. 273 1.3. API-Imposed Constraints 275 To the extent that existing Application Programming Interfaces (APIs) 276 assume specific styles of HTTP authentication message flows, if we 277 want those APIs to support RESTauth backwards-compatibly, then those 278 APIs may impose constraints on RESTauth. 280 For example, the Android Account Manager API assumes a single round 281 trip for authentication [TODO: add reference!]. But the Android 282 Account Manager could perform all but the last round trip on behalf 283 of the application, then let the application perform the last round 284 trip. In order for that to work we need the authentication message 285 exchange to be orthogonal to TCP/TLS connections -- that is, we need 286 it to be possible to use multiple TCP/TLS connections for completing 287 a single authentication exchange. This is because the application 288 and the account manager will likely be using different TCP/TLS 289 connections. 291 A typical constraining characteristic might be that an API assumes 292 the use of GET with tokens encoded into the URI or into a header, or 293 that the API makes no room for the use of headers in authentication 294 message exchanges. 296 One way to work around such constraints may be to provide various 297 options in RESTauth. Another might be to use OAuth 1.0 [RFC5849] or 298 2.0 [RFC6749] as a bridge: the API would use this framework under the 299 covers then obtain OAuth credentials from the server that the 300 application can then use in any way that the API's form allows for. 302 [[anchor1: TODO: Add a table/list of various known APIs and their 303 characteristics that might constrain this and/or other frameworks.]] 305 1.4. Conventions used in this document 307 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 308 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 309 document are to be interpreted as described in [RFC2119]. 311 2. Alternatives 313 2.1. In-band HTTP Authentication 315 RESTauth is "out-of-band" in the sense that the authentication 316 messages are exchanged independently of the application's requests 317 for normal resources, with authentication tokens sent as message 318 bodies rather than as header values. Of course, RESTauth exchanges 319 may well (and often will) happen in the same TCP/TLS connection as 320 normal application requests, so RESTauth is not out-of-band in the 321 sense of using distinct transport connections. We use "out-of-band" 322 and "in-band" very loosely in this section. 324 There exist several "in-band" HTTP authentication alternatives where 325 the authentication message exchanges happen in the context of 326 application resources. Here the HTTP verb and resource are 327 application-specific and have nothing to do with authentication, and 328 the authentication messages are exchanged via HTTP request and 329 response headers with the server responding with a 401 status code 330 until authentication is complete. 332 The extant "Basic" and "DIGEST-MD5" [RFC2617] HTTP authentication 333 methods, as well as HTTP/Negotiate [RFC4559] are "in-band" HTTP 334 authentication methods. 336 In so far as an in-band authentication method results in a cookie or 337 session URI/ID the distinction between in-band and out-of-band is 338 almost trivial, as described above: authentication messages in 339 headers vs. bodies, and HTTP verb and URL. However, if in-line 340 authentication methods are strongly tied to the TCP/TLS connections 341 over which they were utilized then that is a big disadvantage over 342 RESTauth: each connection requires re-authenticating, and support for 343 HTTP routing schemes is not clear. Indeed, in common implementations 344 of HTTP Basic, Digest, and Negotiate, cases every request requires 345 authentication, which can be particularly costly for the Negotiate 346 case. 348 Additionally, Negotiate can require multiple round trips but provides 349 no mechanism for explicitly associating a given GSS-API security 350 context token with a given GSS-API security context: it has to be 351 assumed that all messages are serialized and only one multi-round 352 trip security context establishment can be ongoing in any given HTTP 353 connection. 355 Even if the only difference between in-band and out-of-band is a 356 trivial one, using the REST pattern means that authentication can be 357 implemented using with no help from the HTTP stack (even though it's 358 desirable to have it implemented within/by the HTTP stack), whereas 359 there may not be a way to implement in-band authentication without 360 help from the HTTP stack for some stacks. 362 2.2. Out-of-Band Bearer Token Mechanisms 364 Some HTTP/web authentication mechanisms used on the web involve out- 365 of-band (that is, outside the application's HTTP connections to a 366 server) communications to get bearer tokens, which the application 367 then includes in its HTTP requests (or perhaps it POSTs them to the 368 target server). 370 The main problem with bearer token systems is that they depend 371 utterly on the ability of TLS to authenticate services. Other 372 mechanisms, ones that depend on proof-of-secret/ 373 private-key-possession, can often provide better security in the face 374 of weak TLS server authentication. 376 2.3. Authentication in TLS 378 A number of proposals use TLS [RFC5246] for authentication, some 379 adding extensions for sending user credentials encrypted to avoid the 380 overhead of renegotiation for privacy protection of user credentials. 382 There are several problems with user authentication in TLS: 384 o authentication mechanisms requiring multiple round trips are not 385 supported, and though there may not be any reason to not permit 386 them, in practice any extension of TLS handshakes to multiple 387 round trips is likely to cause much trouble in adapting existing 388 TLS implementations; 390 o new interfaces are required, affecting HTTP stacks and 391 applications both in addition to TLS itself (compare to RESTauth, 392 which requires only changes to applications, and which welcomes, 393 but does not require, support by HTTP stacks), and we know from 394 experience that it takes a long time to deploy solutions that 395 require modifying implementations of multiple network layers. 397 3. Protocol 399 The are few normative protocol elements here besides the outline 400 given in Section 1. The normative protocol elements are: 402 o the form of the WWW-Authenticate header values -in 401 responses- 403 for RESTauth mechanisms; 405 o several new headers for advertising negotiable parameters that are 406 orthogonal to WWW-Authenticate; 408 o the POSTing of authentication messages from the client, with the 409 initial client authentication message going to either a pre-agreed 410 URI or to a URI named in the WWW-Authenticate headers; 412 o the creation of a session URI as a result of the initial POST, and 413 the subsequent POSTing of any additional authentication messages 414 to the session URI; 416 o the new session URI resource representation resulting from POSTs 417 being the server's response authentication message, if any; 419 o the DELETEion of session URIs as signaling logout; 421 o a new header for referencing session URIs in normal HTTP requests; 423 o the use of channel binding [RFC5056] to TLS [RFC5246] for session 424 protection; 426 And for applications that may not use TLS/HTTPS: 428 o the use of session keys as an option for integrity protection when 429 TLS is not used (a light-weight security mode); see 430 [I-D.williams-websec-session-continue-proto]. 432 3.1. Negotiable Parameters 434 As can be seen in the ABNF in the preceding section, the server can 435 offer some negotiable parameters. These are: 437 o Authentication mechanism names; 439 o Channel binding types; 441 o Session binding types; 443 o Replay protection; 444 Each WWW-Authenticate [RFC2617] header value offers a single 445 mechanism and negotiable parameters for it; because headers can have 446 multiple values, WWW-Authenticate provides a method for negotiating 447 authentication mechanisms. The WWW-ChannelBinding-Types header 448 (added here) allows the server to list channel binding types 449 supported by it. 451 3.1.1. Strong Binding to TLS 453 Strong binding to TLS is provided via channel binding [RFC5056]. 454 When a RESTauth mechanism provides strong authentication of the 455 service to the user, the combination of RESTauth and channel binding 456 results in strong authentication of the server to the user even 457 though TLS is used for session transport protection. 459 3.1.2. WWW-Authenticate Header Value Prefix Syntax 461 The ABNF for RESTauth WWW-Authenticate header values is as follows: 463 challenge = ( "RA-" mechname SP restauth-challenge ) 464 mechname = 1*( ALPHA / DIGIT / "-" ) 465 restauth-challenge = ( login-uri SP session-types SP 466 replay-prot SP *1(mech-challenge) ) 467 login-uri = absoluteURI 468 session-types = "s=" session-type / 469 (session-type ":" session-types) 470 session-type = "cookie" / "session-ID" / 471 "channel-bound-session-ID" / 472 "MAC" 473 ; new session-types may be added 474 replay-prot = "r=" ("yes" / "no") 475 mech-challenge = 477 Figure 1: RESTauth WWW-Authenticate ABNF 479 For a DIGEST-like mechanism it might look like "WWW-Authenticate: RA- 480 Digest-SHA-256 tls-server-end-point session-ID no HE4SgWGrd/ 481 3+O7t16HqusA==". For example, the mechname for the Kerberos V5 GSS- 482 API mechanism might be "gss-krb5", and a WWW-Authenticate header 483 value for it might look like "WWW-Authenticate: RA-gss-krb5 484 http://foo.example/restauth-login tls-server-end-point channel-bound- 485 session-ID r=no". 487 Note that mechanisms that may be used include: GSS mechanisms, SASL 488 mechanisms, ad-hoc mechanisms, and so on. 490 3.1.3. WWW-ChannelBinding-Types Header 492 A new header is added by which servers MUST indicate which channel 493 binding [RFC5056] types -if any- they support for RESTauth 494 authentication; if the server does not support channel binding then 495 this header MUST be absent. The header is named WWW-ChannelBinding- 496 Types. Its values are channel binding types from the channel binding 497 type registry, such as the TLS channel binding types [RFC5929]. 499 3.1.4. WWW-ChannelBinding-Type Header 501 A new header is added by which clients MUST indicate what channel 502 binding type they used when POSTing RESTauth authentication messages, 503 if any; if the client did not use channel binding then this header 504 MUST be absent. If the mechanism used has its own method for 505 indicating the use of channel binding, then this header MAY be 506 ommitted. The header is named WWW-ChannelBinding-Type. Its value is 507 a channel binding type from the channel binding type registry 508 [RFC5929]. 510 3.1.5. WWW-SessionBinding-Type Header 512 A new header is added by which clients MUST indicate what session 513 binding type they choose when POSTing RESTauth authentication 514 messages. The header is named WWW-SessionBinding-Type. Its value is 515 a session binding type as shown in Figure 1. This header SHOULD be 516 present in RESTauth authentication HTTP requests, but may be ommitted 517 when the selected mechanism provides its own session binding facility 518 that is distinct from RESTauth's (this helps adapt OAuth to RESTauth 519 with minimal or no changes). 521 3.1.6. WWW-ReplayProtection Header 523 A new header is added by which clients MUST indicate whether they 524 desire replay protection when POSTing RESTauth authentication 525 messages. The header is named WWW-SessionBinding-Type. Its value is 526 "yes" or "no" (defaults to "no" if absent) as shown in Figure 1. 528 Replay protection is to be used only when TLS [RFC5246] is not used, 529 and only if a session binding type of "MAC" is also requested. 531 3.2. Protocol Flow 533 RESTauth can be initiated by a client that knows a priori that it 534 needs to or wants to use RESTauth. Servers can also tell clients 535 that access to certain resources require authentication, possibly 536 including RESTauth mechanisms. When the server tells the client that 537 it must authenticate (using a 401 response, as usual), the server may 538 also give the client an initial authentication message for one or 539 more mechanisms. 541 When the client knows a priori that it must authenticate then the 542 client MUST know the RESTauth login URI a priori as well, as well as 543 negotiable parameters, all of which the client might know from either 544 an application protocol specification, or from caching this 545 information from earlier RESTauth exchanges. 547 The server MUST use a 401 HTTP status code and WWW-Authenticate 548 headers to inform the client of the need to authenticate in order to 549 access a given resource. For RESTauth mechanisms the WWW- 550 Authenticate header values MUST conform to the ABNF given in 551 Section 3.1.2. 553 To proceed the client chooses a suitable authentication mechanism 554 (for which, presumably, it has credentials for a desired client 555 identity), possibly a channel binding type, possibly a session type, 556 and whether to use replay protection. 558 3.2.1. One Round Trip Optimization: Challenges Born in WWW-Authenticate 559 Headers 561 Some mechanisms may optimize the protocol flow by allowing the server 562 to include challenges in the 401 response's WWW-Authenticate header 563 values. DIGEST-MD5 works this way, for example, sending a challenge 564 nonce to be fed into the digest function (along with other client- 565 side inputs). 567 RESTauth allows this, but this feature is OPTIONAL: it must always be 568 possible for a client to initiate RESTauth without first obtaining a 569 challenge in a WWW-Authenticate header value, in which case the 570 client may incur an extra protocol leg by obtaining the challenge (if 571 it is at all necessary) in the server's reply to the client's first 572 authentication message. There are two reasons for making this 573 optional: 575 1. to allow client applications that know a priori that they must 576 authenticate (and how to), requiring no further negotiation; 578 2. to support authentication mechanisms that require that the client 579 initiate authentication message exchanges. 581 A challenge may consist of a nonce, some encrypted or MACed nonce, a 582 time-stamp, certificates and digital signatures, etcetera. The 583 server may include a login URI in challenge-laden WWW-Authenticate 584 headers where the login URI encodes secure state regarding the 585 challenge (e.g., the challenge encrypted in a symmetric key known 586 only to the server). 588 3.3. Session Binding Types: Cookie, Channel Bound Session URI, and MAC 590 A notion of session binding type is added for binding HTTP requests 591 to specific RESTauth login sessions. Three types are provided: 593 Cookies The traditional HTTP cookie approach to session binding; 595 Session URI HTTP requests carry a WWW-Session-URI header identifying 596 the session(s) (similar to cookies, but without all the associated 597 baggage); 599 Channel Bound Session URI Like Session URI, but may only be used in 600 HTTPS connections with the same channel bindings. (This implies 601 use of the 'tls-server-end-point' channel binding type.) 603 MAC HTTP requests carry a WWW-Session-URI header identifying the 604 session(s) and a WWW-Session-MAC header that carries a MAC or MACs 605 binding the session URI(s) to the request. 607 3.3.1. The New WWW-Session-URI Header 609 A new HTTP header is added called WWW-Session-URI whose values 610 consist of session URIs. At least one session URI MUST be included. 611 Each session URI is an absoluteURI. Session URIs MUST NOT have 612 unescaped commas (',') embedded in them. Servers MAY fail to 613 implement support for multiple session URIs being referenced by a 614 single request, in which case they MUST answer with error code . 615 Servers MUST validate the session URI before processing the request; 616 if the session URI is invalid the server MUST respond with a 401 (or 617 TBD?) status code. 619 Note that referencing multiple session URIs is permitted, but this 620 may not be meaningful for the application, thus the server MAY reject 621 this (TODO: specify a status code for this?). 623 [[anchor2: I can imagine a webmail application where a client can be 624 logged in as multiple users and get a unified view of the users' 625 mailboxes. This seems unlikely, but why rule out such use cases?]] 627 3.3.2. The New WWW-Session-MAC Header 629 [[anchor3: Describe the header, its values, algorithm agility, and 630 what the MAC is to be taken over. Note too that this cannot apply to 631 request contents as we have to consider chunking, and besides, a MAC 632 of contents really has to go as a trailer, not a header.]] 634 [[anchor4: We may want to remove this anyways and leave it for a 635 session continuation spec. Or we may want to require the use of 636 HTTPS.]] 638 3.3.3. To MAC or not to MAC; A MAC Trailer?? 640 [[anchor5: ... This is only needed for RESTauth *without* TLS, which 641 will probably not be the common mode of use for RESTauth... unless we 642 can produce a MAC trailer extension for HTTP/2.0, in which case this 643 may well become a common mode of RESTauth usage.]] 645 [[anchor6: We may want to remove this anyways and leave it for a 646 session continuation spec. Or we may want to require the use of 647 HTTPS.]] 649 4. Representation of Authenticated Session Resources 651 It will generally be useful to be able to GET a session resource to 652 obtain information about the authenticated user. A GET on a session 653 resource which is not fully established SHOULD return an empty body. 655 [[anchor7: TODO: Add a media type for session resource 656 representation.]] 658 [[anchor8: Use JSON instead of ABNF? A schema language would be 659 nice.]] 661 session = 1*( session-param ) 662 session-param = session-param-name '=' session-param-value 663 session-param-name = 1*( ALPHA / DIGIT / '-' / '_' ) 664 session-param-value = 666 Figure 2: Session resource representation ABNF 668 Session parameters include: 670 established "true" or "false" 672 expiration_time Datetime when the session expires. 674 session_key_MAC_req Session key for MACs in requests. 676 session_key_MAC_resp Session key for MACs in responses. 678 authorization_data Information about the authenticated user. 680 user_id The authenticated user identity. 682 The server MAY exclude any part of this when the entity requesting a 683 session resource is the session's user. The server MUST exclude (or 684 respond with 401) all of the session resource's representation when 685 the entity requesting it is not authenticated or authorized to see 686 it. The server SHOULD exclude locally-determined authorization_data 687 and/or user_id information when the entity requesting the resource is 688 the session's user. 690 5. Session URI Origin and Scope 692 [[anchor9: TODO: Add a notion of session origin and scope. The 693 origin can probably be determined naturally from the session URI. 694 The scope should be set by the server. Perhaps we can also have the 695 scope reflected in the session URI's representation, which would 696 allow the scope of a session to change over time.]] 698 [[anchor10: Clearly, using a session from one origin at another will 699 require a channel binding verification operation. This will have to 700 be added.]] 702 6. HTTP "Routing" and Authentication 704 It is common to deploy HTTP services with load-balanced servers 705 behind a load balancer and TLS concentrator. Other techniques may 706 also result in a multiplicity of servers acting on behalf of a single 707 service. The load balancers may even behave like routers and route 708 HTTP requests to the same server for all requests in a single 709 connection, or even route HTTP requests according to the verb and 710 resource. It helps to be able to have a notion of authenticated 711 sessions that can be referenced by all servers responding to a given 712 service name. 714 The server end of a RESTauth authentication message exchange may be 715 terminated by one server, by many servers sharing session state (via 716 the resources named by session URIs), or by a server-side HTTP 717 router. Once a RESTauth session is established we assume that all 718 servers responding to the same service name will be able to access 719 the session resource, validate session URIs, and obtain keys for 720 computing and validating session binding MACs. Alternatively, the 721 router may take responsibility for session binding and signal 722 authorization information from the established session to the HTTP 723 servers behind the router (however, we do not here specify any 724 methods for such signaling). 726 By using REST for the authentication message exchange we allow this 727 disconnection between "session" and "connection", which therefore 728 facilitates "routing" of HTTP requests and even off-loading of 729 authentication and/or session binding to HTTP "routers". 731 This approach should be flexible enough for all existing 732 architectures for deploying HTTP services. 734 7. Actual Authentication Mechanisms 736 Here we describe (INFORMATIVELY for the time being) how to use or 737 adapt a variety of authentication mechanisms, from SSHv2, IKEv2, 738 SASL, GSS-API, and other frameworks, so as to quickly gain a set of 739 usable mechanisms, both, specification- and implementation-wise. 740 This section is also intended to show that adding RESTauth mechanisms 741 is easy. 743 Reuse of existing authentication mechanisms is a key goal of 744 RESTauth: let us stop inventing wheels that require costly deployment 745 of new authentication infrastructures (and credentials) and/or 746 bridges to other authentication infrastructures. 748 7.1. OAuth via RESTauth 750 OAuth 1.0 RFC5849 and OAuth 2.0 [RFC6749] are commonly deployed. 751 Being able to use OAuth via RESTauth would be useful. We attempt to 752 make RESTauth such that at least for OAuth 1.0 there is a standard 753 way to use OAuth such that it conforms to RESTauth. 755 7.1.1. OAuth 1.0 757 For OAuth 1.0 [RFC5849] the "form-encoded body" form (see section 758 3.5.2 of [RFC5849]) of OAuth 1.0 conforms to RESTauth without further 759 changes. 761 7.1.2. OAuth 2.0 763 [It looks like OAuth 2.0 [RFC6749] also uses POST to send tokens to 764 the server, and it looks like it too effectively conforms to 765 RESTauth.] 767 7.2. Adapting SSHv2 Authentication Mechanisms to RESTauth 769 SSHv2 "userauth" mechanisms [RFC4252] typically involve a digital 770 signature (or similar) of an SSHv2 session ID. There is no such 771 thing as an SSHv2 session ID in HTTP. A session URI cannot serve as 772 a stand-in for an SSHv2 session ID because a) the session URI is an 773 outcome of authentication in RESTauth, b) to prevent cut-n-paste and 774 replay attacks the client and the server both must contribute to the 775 entropy of the session ID that is signed by the client. 777 In order to adapt SSHv2 userauth methods properly (i.e., securely), 778 we have replace the SSHv2 session ID in the to-be-signed data with a 779 hash of the channel binding and nonces contributed by the client and 780 the server. As an optimization the server nonce can be sent as a 781 challenge (this saves a round trip). 783 7.2.1. RESTauth Mechanism Names for SSHv2 Userauth Methods 785 For hash agility reasons the hash function name is part of the SSHv2 786 RESTauth mechanism name. To avoid "multi-level negotiation" the 787 SSHv2 userauth method name is also part of the RESTauth mechanism 788 name. 790 The RESTauth mechanism name form for SSHv2 userauth methods, then, 791 is: ssh--. 793 The following RESTauth mechanisms are defined here: 795 o ssh-publickey-SHA-256 797 o ssh-hostbased-SHA-256 799 7.2.2. Nonces 801 The client and the server must each contribute 128-bit nonces. 803 7.2.3. "Session ID" 805 The ssh-publickey-SHA-256 and ssh-hostbased-SHA-256 mechanisms use 806 the following instead of a traditional SSHv2 session ID: 808 o SHA-256(channel_binding || server_nonce || client_nonce) 810 Here the is as per-[RFC5056]: the channel binding 811 type name, followed by the channel binding data (e.g., 'tls-server- 812 end-point' followed by the server EE certificate as sent in the 813 server's TLS Certificate message). 815 Note that use of channel binding when using SSHv2 mechanisms is 816 REQUIRED so as to defeat cut-n-paste attacks by weakly-authenticated 817 servers. 819 7.3. Adapting IKEv2 Authentication Mechanisms to RESTauth 821 [[anchor11: TBD.]] 823 7.3.1. Adapting IKEv2 Password Authenticated Connection Establishment 824 (PACE) to RESTauth 826 [[anchor12: TBD.]] 828 7.4. Using SASL Authentication Mechanisms with RESTauth 830 Simple Authentication and Security Layers (SASL) [RFC4422] is a 831 simple, pluggable framework for authentication mechanisms. 833 To use a SASL mechanism in RESTauth just prefix "SA-" to the SASL 834 mechanism name and use that as the RESTauth mechanism name. If the 835 SASL mechanism is server-initiated then the server's challenge is 836 sent in the server's WWW-Authenticate header value as described 837 above. All other SASL authentication messages are exchanged as 838 described above (i.e., via POSTs, first to the login URI, then to the 839 session URI, with response messages as the new representation of the 840 session resource). 842 The HTTP status code functions as the application's outcome of 843 authentication message. If SASL succeeds but authorization fails 844 then the server should respond with a 401 status code to the POST of 845 the final SASL authentication message from the client. 847 The server's WWW-Authenticate header values function as the mechanism 848 listing operation. SASL security considerations [RFC4422] [RFC5801] 849 apply (particularly regarding the negotiation of channel binding 850 support). 852 7.4.1. Using SCRAM in RESTauth 854 The Salted Challenge Response Authentication Mechanism (SCRAM) 855 [RFC5802] is a DIGEST-like mechanism for SASL. Nothing special is 856 needed to use SCRAM versus any other SASL mechanism, except for a 857 round trip optimized form of SCRAM, if we decide to pursue that (see 858 Section 7.4.2). 860 The following figure shows what SCRAM in RESTauth looks like. Note 861 that the resource representations are taken verbatim from [RFC5802]. 863 C->S: GET /some-resources HTTP/1.1 864 Host: A.example 866 S->C: HTTP/1.1 401 Unauthorized 867 WWW-Authenticate: RA-SA-SCRAM-SHA-1 \ 868 http://A.example/rest-sa-scram \ 869 s=session-ID,MIC r=no 870 WWW-ChannelBinding-Types: tls-server-end-point 872 C->S: POST /rest-sa-scram HTTP/1.1 873 Host: A.example 874 WWW-ChannelBinding-Type: tls-server-end-point 875 WWW-SessionBinding-Type: session-ID 876 Content-Type: application/octet-stream 877 Content-Length: nnn 879 n,,n=user,r=fyko+d2lbbFgONRv9qkxdawL 881 S->C: HTTP/1.1 201 882 Location http://A.example/restauth-9d0af5f680d4ff46 883 Content-Type: application/octet-stream 884 Content-Length: nnn 886 r=fyko+d2lbbFgONRv9qkxdawL3rfcNHYJY1ZVvWVs7j, 887 s=QSXCR+Q6sek8bf92,i=4096 889 C->S: POST /restauth-9d0af5f680d4ff46 HTTP/1.1 890 Host: A.example 891 Content-Type: application/octet-stream 892 Content-Length: nnn 894 c=biws,r=fyko+d2lbbFgONRv9qkxdawL3rfcNHYJY1ZVvWVs7j, 895 p=v0X8v3Bz2T0CJGbJQyF0X+HI4Ts= 897 S->C: HTTP/1.1 200 898 Content-Type: application/octet-stream 899 Content-Length: nnn 901 v=rmF9pqV8S7suAoZWja4dJRkFsKQ= 903 Figure 3: RESTauth w/ SCRAM 905 7.4.2. Using SCRAM with Round Trip Optimization in RESTauth 907 [[anchor13: This might work by having the authentication ID function 908 as the salt and the server offering a challenge nonce and iteration 909 count in its optimistic challenge. However, it's not clear that a 910 round trip optimized form of SCRAM is desirable.]] 911 The following figure shows what a round trip optimized RESTauth w/ 912 SCRAM exchange might look like. 914 [[anchor14: NOTE: SCRAM was not intended to be used this way. In 915 particular this approach forces the use of an algorithmic salt, to be 916 derived only from either the username or the username and the 917 server's name (or else to be remembered by the user, but that's not 918 likely).]] 920 C->S: GET /some-resources HTTP/1.1 921 Host: A.example 923 S->C: HTTP/1.1 401 Unauthorized 924 WWW-Authenticate: RA-SA-SCRAM-SHA-1 \ 925 http://A.example/rest-sa-scram \ 926 s=session-ID,MIC r=no \ 927 r=fyko+d2l...JY1ZVvWVs7j,i=4096 928 WWW-ChannelBinding-Types: tls-server-end-point 930 C->S: POST /rest-sa-scram HTTP/1.1 931 Host: A.example 932 WWW-ChannelBinding-Type: tls-server-end-point 933 WWW-SessionBinding-Type: session-ID 934 Content-Type: application/octet-stream 935 Content-Length: nnn 937 n,,n=user,r=fyko+d2lbbFgONRv9qkxdawL, 938 c=biws,r=fyko+d2lbbFgONRv9qkxdawL3rfcNHYJY1ZVvWVs7j, 939 p=v0X8v3Bz2T0CJGbJQyF0X+HI4Ts= 941 S->C: HTTP/1.1 200 942 Content-Type: application/octet-stream 943 Content-Length: nnn 945 v=rmF9pqV8S7suAoZWja4dJRkFsKQ= 947 Figure 4: RESTauth w/ round trip optimized SCRAM 949 7.5. Using GSS-API Authentication Mechanisms with RESTauth 951 The Generic Security Services Application Programming Interface (GSS- 952 API) [RFC2743] is another pluggable mechanism framework. Any GSS-API 953 mechanism that supports channel binding [RFC5056] can be used as SASL 954 mechanisms via the "SASL/GS2" bridge [RFC5801]. This includes the 955 Kerberos V5 GSS-API mechanism [RFC4121]. 957 GSS-API security mechanisms could also be used without SASL/GS2, but 958 SASL/GS2 barely adds any overhead or complexity (a SASL 959 implementation is not required in order to use SASL/GS2, just a GSS 960 implementation): a simple header is to be prefixed to the initial 961 security context token and to the channel binding data, with both 962 peers always providing channel binding data. 964 8. Implementation Advice 966 RESTauth can be implemented without having to modify the HTTP nor TLS 967 stacks. 969 The simplest thing to do is to implement a small API to produce and 970 consume HTTP messages. 972 8.1. Server-Side Implementation Advice 974 On the server side the simplest thing to do is to implement POST 975 handlers for the login and session resource URI namespace. The 976 aspects of implementation that will be stack-specific are: 978 o WWW-Authenticate header value generation; 980 o Routing of GET and POST requests on the login and session 981 resources to the RESTauth handlers; 983 o The interface between the web server and the handlers. 985 The FCGI interface is widely supported, allowing RESTauth to be 986 implemented in a nearly universal way on the server side. 988 8.1.1. Channel Binding on the Server Side 990 The simplest way to implement channel binding on the server side is 991 to use 'tls-server-end-point' channel bindings, using a table of 992 server certificates indexed by fully-qualified server hostname 993 values, with the Host: header value used to index this table. The 994 server's end entity (EE) certificate is the channel binding data. 996 8.1.2. Server Cluster / Routing Support 998 Because each RESTauth session is a first-class resource named by a 999 URI (natch), multiple servers behind a given origin may recognize and 1000 handle all the sessions that they should be able to: all the sessions 1001 created at that origin, and all the sessions scoped to include that 1002 origin. This is handled by the simple expedient of doing an HTTP GET 1003 of the session resource claimed by a client. Note that the 1004 representation of a session resource can be cached easily, and 1005 updates can be checked with HEAD or conditional GETs, as one would 1006 expect of any RESTful HTTP API. 1008 It is important that server MUST NOT attempt to GET (or HEAD) session 1009 resources for origins that the server does not respond to or which 1010 the server does not expect to share sessions with the server's 1011 origin(s). 1013 8.2. Client-Side Implementation Advice 1015 There are many HTTPS client stacks, too many, each with its own APIs, 1016 to make it possible to implement RESTauth universally. The 1017 application will have to bridge any generic RESTauth APIs with the 1018 HTTP stack. 1020 A reasonable implementation strategy is to build a generic RESTauth 1021 interface that 1023 o consumes 401 responses (or just their WWW-Authenticate header 1024 values) 1026 o consumes channel binding data (see below) 1028 o generates HTTP requests to send to login or session URIs 1030 o consumes HTTP responses to requests sent to login or session URIs 1032 The application would have to extract relevant responses and channel 1033 binding data from the HTTP stack to feed to the RESTauth interface, 1034 and it would have to extract requests from the RESTauth interface and 1035 feed them to the HTTP stack. 1037 The interfaces, abstractly, should be: 1039 restauth_new() Create a RESTauth context handle; 1041 restauth_401() Consume a 401 and update or create a RESTauth context 1042 handle; 1044 restauth_login() Produce a POST to a login resource URI (either 1045 provided explicitly or obtained from a 401); 1047 restauth_login_continue() Consume a response to a POST to a login 1048 resource and output a) status (complete or continue), b) possibly 1049 a POST to a session URI; 1051 restauth_logout() Produce a DELETE of the given session URI or the 1052 given RESTauth context's session URI. 1054 Channel binding type and data would be given to restauth_login(). 1056 Specific programming language bindings of this API are easy enough to 1057 produce. Whether the API outputs or consumes complete messages or 1058 decomposed messages (start-line, headers, body, trailers) will depend 1059 on the APIs of the HTTP stack being targeted. A utility API that 1060 composes/decomposes HTTP messages will help make a RESTauth 1061 implementation widely reusable. 1063 8.2.1. Channel Binding on the Client Side 1065 Most HTTPS stacks provide a way for the client application to obtain 1066 the server's EE certificate; this is sufficient to implement 'tls- 1067 server-end-point' channel binding. 1069 9. IANA Considerations 1071 TBD (header registrations, ...) 1073 10. Security Considerations 1075 This entire document deals with security considerations. [Add more, 1076 like about channel binding, same-origin-like constraints on the login 1077 and session absolute URIs', ...] 1079 Note that though servers can GET/HEAD session resources, they MUST 1080 only do it for session resources for recognized origins. See 1081 Section 8.1.2. 1083 [[anchor15: ...]] 1085 11. TODO 1087 [[anchor16: Add references (to HTTP/2.0, CGI/fCGI, ...).]] 1089 [[anchor17: Decide whether to support a MAC type of session 1090 continuation, or only channel bound sessions.]] 1092 [[anchor18: Describe or remove the MAC session binding option and 1093 replay protection in detail -- or remove it altogether. Describe how 1094 to extract keys for MAC keying from SASL/GSS/PACE.]] 1096 [[anchor19: Figure out how to adapt IKEv2 password-based methods to 1097 RESTauth. This may not be worthwhile (since each method tends to 1098 depend heavily on the entire IKEv2 framework in ways that add 1099 messaging that we'd not need in RESTauth).]] 1101 [[anchor20: Normatively specify bindings to SASL and/or GSS-API 1102 security mechanisms. Include support for BrowserID.]] 1104 12. References 1106 12.1. Normative References 1108 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1109 Requirement Levels", BCP 14, RFC 2119, March 1997. 1111 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1112 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1113 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1115 [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 1116 Leach, P., Luotonen, A., and L. Stewart, "HTTP 1117 Authentication: Basic and Digest Access Authentication", 1118 RFC 2617, June 1999. 1120 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1121 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 1123 [RFC5056] Williams, N., "On the Use of Channel Bindings to Secure 1124 Channels", RFC 5056, November 2007. 1126 [RFC5929] Altman, J., Williams, N., and L. Zhu, "Channel Bindings 1127 for TLS", RFC 5929, July 2010. 1129 [I-D.williams-websec-session-continue-prob] 1130 Williams, N., "Hypertext Transport Protocol (HTTP) Session 1131 Continuation: Problem Statement", 1132 draft-williams-websec-session-continue-prob-00 (work in 1133 progress), January 2013. 1135 [I-D.williams-websec-session-continue-proto] 1136 Williams, N., "Hypertext Transport Protocol (HTTP) Session 1137 Continuation Protocol", 1138 draft-williams-websec-session-continue-proto-00 (work in 1139 progress), January 2013. 1141 12.2. Informative References 1143 [RFC2743] Linn, J., "Generic Security Service Application Program 1144 Interface Version 2, Update 1", RFC 2743, January 2000. 1146 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 1147 "Remote Authentication Dial In User Service (RADIUS)", 1148 RFC 2865, June 2000. 1150 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 1151 Levkowetz, "Extensible Authentication Protocol (EAP)", 1152 RFC 3748, June 2004. 1154 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 1155 Kerberos Network Authentication Service (V5)", RFC 4120, 1156 July 2005. 1158 [RFC4121] Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos 1159 Version 5 Generic Security Service Application Program 1160 Interface (GSS-API) Mechanism: Version 2", RFC 4121, 1161 July 2005. 1163 [RFC4251] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) 1164 Protocol Architecture", RFC 4251, January 2006. 1166 [RFC4252] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) 1167 Authentication Protocol", RFC 4252, January 2006. 1169 [RFC4422] Melnikov, A. and K. Zeilenga, "Simple Authentication and 1170 Security Layer (SASL)", RFC 4422, June 2006. 1172 [RFC4559] Jaganathan, K., Zhu, L., and J. Brezak, "SPNEGO-based 1173 Kerberos and NTLM HTTP Authentication in Microsoft 1174 Windows", RFC 4559, June 2006. 1176 [RFC5801] Josefsson, S. and N. Williams, "Using Generic Security 1177 Service Application Program Interface (GSS-API) Mechanisms 1178 in Simple Authentication and Security Layer (SASL): The 1179 GS2 Mechanism Family", RFC 5801, July 2010. 1181 [RFC5802] Newman, C., Menon-Sen, A., Melnikov, A., and N. Williams, 1182 "Salted Challenge Response Authentication Mechanism 1183 (SCRAM) SASL and GSS-API Mechanisms", RFC 5802, July 2010. 1185 [RFC5849] Hammer-Lahav, E., "The OAuth 1.0 Protocol", RFC 5849, 1186 April 2010. 1188 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, 1189 "Internet Key Exchange Protocol Version 2 (IKEv2)", 1190 RFC 5996, September 2010. 1192 [RFC6631] Kuegler, D. and Y. Sheffer, "Password Authenticated 1193 Connection Establishment with the Internet Key Exchange 1194 Protocol version 2 (IKEv2)", RFC 6631, June 2012. 1196 [RFC6749] Hardt, D., "The OAuth 2.0 Authorization Framework", 1197 RFC 6749, October 2012. 1199 Author's Address 1201 Nicolas Williams 1202 Cryptonector, LLC 1204 Email: nico@cryptonector.com