idnits 2.17.1 draft-williams-http-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 13, 2012) is 4274 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC6631' is defined on line 634, 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) Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). 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 13, 2012 5 Expires: February 14, 2013 7 RESTful Authentication Pattern for the Hypertext Transport Protocol 8 (HTTP) 9 draft-williams-http-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 existing 401 status code and WWW- 15 Authenticate header are used to indicate that authentication is 16 required and for negotiation purposes. The client POSTs an initial 17 authentication message to an indicated login URI, and reply messages 18 are returned as new representations of a session resource named by a 19 session URI. 21 This approach has a number of benefits: it can be implemented with or 22 without help from the HTTP stack, it can be universally implemented 23 on the server side using the Common Information Gateway (CGI) and 24 FastCGI, it results in a session Uniform Resource Identifier (URI) 25 that can be DELETEd to logout, it is completely orthogonal to any 26 HTTP "routers" and proxies, and it naturally (i.e., without changing 27 HTTP) handles multi-legged authentication mechanisms. 29 Among other features supported are: channel binding, an optional 30 round trip optimization for challenge/response mechanisms, some 31 cryptographic protection options for clients that don't use Transport 32 Layer Security (TLS), stronger authentication of servers/services to 33 users (where authentication mechanisms provide that) and more. 35 Status of this Memo 37 This Internet-Draft is submitted in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF). Note that other groups may also distribute 42 working documents as Internet-Drafts. The list of current Internet- 43 Drafts is at http://datatracker.ietf.org/drafts/current/. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 This Internet-Draft will expire on February 14, 2013. 51 Copyright Notice 53 Copyright (c) 2012 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (http://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the Simplified BSD License. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 4 69 2. Conventions used in this document . . . . . . . . . . . . 6 70 3. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . 7 71 3.1. Negotiable Parameters . . . . . . . . . . . . . . . . . . 7 72 3.1.1. Strong Binding to TLS . . . . . . . . . . . . . . . . . . 8 73 3.1.2. WWW-Authenticate Header Value Prefix Syntax . . . . . . . 8 74 3.1.3. WWW-ChannelBinding-Types Header . . . . . . . . . . . . . 8 75 3.1.4. WWW-ChannelBinding-Type Header . . . . . . . . . . . . . . 9 76 3.1.5. WWW-SessionType Header . . . . . . . . . . . . . . . . . . 9 77 3.1.6. WWW-ReplayProtection Header . . . . . . . . . . . . . . . 9 78 3.2. Protocol Flow . . . . . . . . . . . . . . . . . . . . . . 9 79 3.2.1. One Round Trip Optimization: Challenges Born in 80 WWW-Authenticate Headers . . . . . . . . . . . . . . . . . 10 81 3.3. Session Binding Types: Cookie, URI, and MAC . . . . . . . 10 82 3.3.1. The New WWW-Session-URI Header . . . . . . . . . . . . . . 10 83 3.3.2. The New WWW-Session-MAC Header . . . . . . . . . . . . . . 11 84 3.3.3. A MAC Trailer?? . . . . . . . . . . . . . . . . . . . . . 11 85 4. HTTP "Routing" and RESTauth . . . . . . . . . . . . . . . 12 86 5. In-band HTTP Authentication Alternatives . . . . . . . . . 13 87 6. Sample/Potential RESTauth Authentication Mechanisms . . . 14 88 6.1. Adapting SSHv2 Authentication Mechanisms to RESTauth . . . 14 89 6.1.1. RESTauth Mechanism Names for SSHv2 Userauth Methods . . . 14 90 6.1.2. Nonces . . . . . . . . . . . . . . . . . . . . . . . . . . 14 91 6.1.3. "Session ID" . . . . . . . . . . . . . . . . . . . . . . . 15 92 6.2. Adapting IKEv2 Authentication Mechanisms to RESTauth . . . 15 93 6.2.1. Adapting IKEv2 Password Authenticated Connection 94 Establishment (PACE) to RESTauth . . . . . . . . . . . . . 15 95 6.3. Using SASL Authentication Mechanisms with RESTauth . . . . 15 96 6.3.1. Using SCRAM in RESTauth . . . . . . . . . . . . . . . . . 16 97 6.3.2. Using SCRAM with Round Trip Optimization in RESTauth . . . 16 98 6.4. Using GSS-API Authentication Mechanisms with RESTauth . . 16 99 7. IANA Considerations . . . . . . . . . . . . . . . . . . . 17 100 8. Security Considerations . . . . . . . . . . . . . . . . . 18 101 9. TODO . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 102 10. References . . . . . . . . . . . . . . . . . . . . . . . . 20 103 10.1. Normative References . . . . . . . . . . . . . . . . . . . 20 104 10.2. Informative References . . . . . . . . . . . . . . . . . . 20 105 Author's Address . . . . . . . . . . . . . . . . . . . . . 22 107 1. Introduction 109 We propose a pattern for HTTP [RFC2616] [XXX add reference to 110 HTTP/2.0 as well] authentication mechanisms that, by being "RESTful", 111 obtains a number of benefits: 113 o compatibility with "HTTP routing" by making no assumptions that 114 related requests are sent over the same TCP/TLS connection; 116 o a "session URI" results that can be used to multiplex multiple 117 sessions onto the same TCP/TLS connections; 119 o a "session URI" results that can be DELETEd to effect logout; 121 o a "session URI" results that has better security semantics than 122 web cookies; 124 o the ability to refer to multiple sessions in one request wherever 125 such a concept might be useful; 127 o can be implemented by any application without changes being 128 required to any HTTP stack; 130 o can be implemented by the HTTP stack; 132 o on the server side this can be implemented entirely via CGI and 133 FastCGI; 135 o by its RESTful nature, multi-legged authentication message 136 exchanges are naturally handled without making any changes to 137 HTTP. 139 There are probably other benefits not listed above. 141 The rough outline of the protocol is quite simple: initial 142 authentication messages are POSTed to an agreed-upon or indicated 143 resource, which then results in a new resource being created with the 144 authentication reply message as the new resource's representation. 145 Thereafter any additional authentication message exchanges needed 146 (for multi-legged mechanisms) are POSTed to the new resource without 147 a new resource being created. The resource created by the POSTing of 148 the initial authentication mechanism identifies the resulting 149 session, and its URI is known as the session URI. Session URIs can 150 be used to multiplex multiple sessions over the same TCP/TLS 151 connections, implement logout, and share sessions across multiple 152 related servers. 154 Server-initiated authentication is also possible, whereby the server 155 sends a challenge (not much else can be sent of value in an initial 156 authentication message from the server besides a challenge, 157 negotiation parameters, and, perhaps, a digital signature) in 401 158 errors in headers. If the server gives the client has a choice of 159 mechanisms and the client picks one where the server sent the initial 160 authentication message, then the client consumes that message and 161 POSTs subsequent ones to the agreed URI. 163 This document replaces [I-D.williams-rest-gss]. 165 2. Conventions used in this document 167 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 168 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 169 document are to be interpreted as described in [RFC2119]. 171 3. Protocol 173 The are very few normative protocol elements here besides the outline 174 given in Section 1. The normative protocol elements are: 176 o the form of the WWW-Authenticate header values for RESTauth 177 mechanisms; 179 o several new headers for advertising negotiable parameters that are 180 orthogonal to WWW-Authenticate; 182 o the POSTing of authentication messages from the client, with the 183 initial client authentication message going to either a pre-agreed 184 URI or to a URI named in the WWW-Authenticate headers; 186 o the creation of a session URI as a result of the initial POST, and 187 the subsequent POSTing of any additional authentication messages 188 to the session URI; 190 o the new session URI resource representation resulting from POSTs 191 being the server's response authentication message, if any; 193 o the DELETEion of session URIs as signaling logout; 195 o a new header for referencing session URIs in normal HTTP requests; 197 o the use of channel binding [RFC5056] to TLS [RFC5246] for session 198 protection; 200 o the use of session keys as an option for integrity protection when 201 TLS is not used. 203 3.1. Negotiable Parameters 205 As can be seen in the ABNF in the preceding section, the server can 206 offer some negotiable parameters. These are: 208 o Mechanism names; 210 o Channel binding types; 212 o Session binding types; 214 o Replay protection; 216 Each WWW-Authenticate header value offers a single mechanism and 217 negotiable parameters for it. The WWW-ChannelBinding-Types header 218 allows the server to offer channel binding types. 220 3.1.1. Strong Binding to TLS 222 Strong binding to TLS is provided via channel binding [RFC5056]. 223 When a RESTauth mechanism provides strong authentication of the 224 service to the user, the combination of RESTauth and channel binding 225 results in strong authentication of the server to the user even 226 though TLS is used for session transport protection. 228 3.1.2. WWW-Authenticate Header Value Prefix Syntax 230 The ABNF for RESTauth WWW-Authenticate header values is as follows: 232 challenge = ( "RA-" mechname SP restauth-challenge ) 233 mechname = TBD 234 restauth-challenge = ( login-uri SP session-types SP 235 replay-prot SP *1(mech-challenge) ) 236 login-uri = absoluteURI 237 session-types = "s=" session-type / 238 (session-type ":" session-types) 239 session-type = "cookie" / "session-ID" / "MAC" 240 replay-prot = "r=" ("yes" / "no") 241 ; TODO: add production for 242 ; mech-challenge as a base64 string 243 ; TODO: add MAC algorithm offers for alg agility 244 Figure 1: WWW-Authenticate ABNF 246 Figure 1 248 For a DIGEST-like mechanism it might look like "WWW-Authenticate: RA- 249 Digest-SHA-256 tls-server-end-point session-ID no HE4SgWGrd/ 250 3+O7t16HqusA==". For example, the mechname for the Kerberos V5 GSS- 251 API mechanism might be "gss-krb5", and a WWW-Authenticate header 252 value for it might look like "WWW-Authenticate: RA-gss-krb5 253 http://foo.example/restauth-login tls-server-end-point session-ID 254 no". 256 Note that mechanisms that may be used include: GSS mechanisms, SASL 257 mechanisms, ad-hoc mechanisms, and so on. 259 3.1.3. WWW-ChannelBinding-Types Header 261 A new header is added by which servers MUST indicate which channel 262 binding [RFC5056] types -if any- they support for RESTauth 263 authentication; if the server does not support channel binding then 264 this header MUST be absent. The header is named WWW-ChannelBinding- 265 Types. Its values are channel binding types from the channel binding 266 type registry [RFC5929]. 268 3.1.4. WWW-ChannelBinding-Type Header 270 A new header is added by which clients MUST indicate what channel 271 binding type they used when POSTing RESTauth authentication messages, 272 if any; if the client did not use channel binding then this header 273 MUST be absent. The header is named WWW-ChannelBinding-Type. Its 274 value is a channel binding type from the channel binding type 275 registry [RFC5929]. 277 3.1.5. WWW-SessionType Header 279 A new header is added by which clients MUST indicate what session 280 binding type they choose when POSTing RESTauth authentication 281 messages. The header is named WWW-SessionBinding-Type. Its value is 282 a session binding type as shown in Figure 1. This header MUST be 283 present in RESTauth authentication HTTP requests. 285 3.1.6. WWW-ReplayProtection Header 287 A new header is added by which clients MUST indicate whether they 288 desire replay protection when POSTing RESTauth authentication 289 messages. The header is named WWW-SessionBinding-Type. Its value is 290 "yes" or "no" (defaults to "no" if absent) as shown in Figure 1. 292 Replay protection is to be used only when TLS [RFC5246] is not, and 293 only if a session binding type of "MAC" is also requested. 295 3.2. Protocol Flow 297 RESTauth can be initiated by a client that knows a priori that it 298 needs to or wants to use RESTauth. Servers can also tell clients 299 that access to certain resources require authentication, possibly 300 including RESTauth mechanisms. When the server tells the client that 301 it must authenticate the server may also give the client an initial 302 authentication message for one or more mechanisms. 304 When the client knows a priori that it must authenticate then the 305 client MUST know the RESTauth login URI a priori as well, as well as 306 negotiable parameters, all of which the client might know from either 307 an application protocol specification, or from caching this 308 information from earlier RESTauth exchanges. 310 The server MUST use a 401 HTTP status code and WWW-Authenticate 311 headers to inform the client of the need to authenticate in order to 312 access a given resource. For RESTauth mechanisms the WWW- 313 Authenticate header values MUST conform to the ABNF given in 314 Section 3.1.2. 316 To proceed the client chooses a suitable authentication mechanism 317 (for which, presumably, it has credentials for a desired client 318 identity), possibly a channel binding type, possibly a session type, 319 and whether to use replay protection. 321 3.2.1. One Round Trip Optimization: Challenges Born in WWW-Authenticate 322 Headers 324 Some mechanisms may optimize the protocol flow by allowing the server 325 to include challenges in the 401 response's WWW-Authenticate header 326 values. RESTauth allows this, but this feature is OPTIONAL: it must 327 always be possible for a client to initiate RESTauth without first 328 obtaining a challenge in a WWW-Authenticate header value, in which 329 case the client must incur an extra protocol leg by obtaining the 330 challenge (if it is at all necessary) in the server's reply to the 331 client's first authentication message. The reason that this 332 optimization is optional is to allow the implementation of RESTauth 333 mechanisms with frameworks that only support client-initiated 334 authentication. 336 A challenge may consist of a nonce, some encrypted or MACed nonce, a 337 time-stamp, and even seemingly unrelated contents such as 338 certificates and digital signatures. The server MAY include a login 339 URI in challenge-laden WWW-Authenticate headers where the login URI 340 encodes secure state regarding the challenge. 342 3.3. Session Binding Types: Cookie, URI, and MAC 344 A notion of session binding type is added for binding HTTP requests 345 to specific RESTauth login sessions. Three types are provided: 347 Cookies The traditional web cookie approach to session binding; 349 Session URI HTTP requests carry a WWW-Session-URI header identifying 350 the session(s) (similar to cookies, but without all the associated 351 baggage); 353 MAC HTTP requests carry a WWW-Session-URI header identifying the 354 session(s) and a WWW-Session-MAC header that carries a MAC or MACs 355 binding the session URI(s) to the request. 357 3.3.1. The New WWW-Session-URI Header 359 A new HTTP header is added called WWW-Session-URI whose values 360 consist of session URIs. At least one session URI MUST be included. 361 Each session URI is an absoluteURI. Session URIs MUST NOT have 362 unescaped commas (',') embedded in them. Servers MAY fail to 363 implement support for multiple session URIs being referenced by a 364 single request, in which case they MUST answer with error code . 365 Servers MUST validate the session URI before processing the request; 366 if the session URI is invalid the server MUST respond with a 401 (or 367 TBD?) status code. 369 3.3.2. The New WWW-Session-MAC Header 371 [[anchor1: Describe the header, its values, algorithm agility, and 372 what the MAC is to be taken over. Note too that this cannot apply to 373 request contents as we have to consider chunking, and besides, a MAC 374 of contents really has to go as a trailer, not a header.]] 376 3.3.3. A MAC Trailer?? 378 [[anchor2: ... This is only needed for RESTauthTLS, which will 379 probably not be the common mode of use for RESTauth... unless we can 380 produce a MAC trailer extension for HTTP/2.0, in which case this may 381 well become a common mode of RESTauth usage.]]without 383 4. HTTP "Routing" and RESTauth 385 It is common to deploy HTTP services with load-balanced servers 386 behind a load balancer and TLS concentrator. Other techniques may 387 also result in a multiplicity of servers acting on behalf of a single 388 service. The load balancers may even behave like routers and route 389 HTTP requests to the same server for all requests in a single 390 connection, or even route HTTP requests according to the verb and 391 resource. It helps to be able to have a notion of authenticated 392 sessions that can be referenced by all servers responding to a given 393 service name. 395 The server end of a RESTauth authentication message exchange may be 396 terminated by one server, by many servers sharing session state (via 397 the resources named by session URIs), or by a server-side HTTP 398 router. Once a RESTauth session is established we assume that all 399 servers responding to the same service name will be able to access 400 the session resource, validate session URIs, and obtain keys for 401 computing and validating session binding MACs. Alternatively, the 402 router may take responsibility for session binding and signal 403 authorization information from the established session to the HTTP 404 servers behind the router (however, we do not here specify any 405 methods for such signaling). 407 By using REST for the authentication message exchange we allow this 408 disconnection between "session" and "connection", which therefore 409 facilitates "routing" of HTTP requests and even off-loading of 410 authentication and/or session binding to HTTP "routers". 412 This approach should be flexible enough for all existing 413 architectures for deploying HTTP services. 415 5. In-band HTTP Authentication Alternatives 417 RESTauth is "out-of-band" in the sense that the authentication 418 messages are exchanged independently of the application's requests 419 for normal resources. Of course, RESTauth exchanges may well (and 420 often will) happen in the same TCP/TLS connection as normal 421 application requests, so RESTauth is not really out-of-band. We use 422 "out-of-band" and "in-band" very loosely in this section. 424 There exist several "in-band" HTTP authentication alternatives where 425 the authentication message exchanges happen in the context of 426 application resources. Here the HTTP verb and resource are 427 application-specific and have nothing to do with authentication, and 428 the authentication messages are exchanged via HTTP request and 429 response headers with the server responding with a 401 status code 430 until authentication is complete. 432 The extant "Basic" and "DIGEST-MD5" [RFC2617] HTTP authentication 433 methods, as well as HTTP/Negotiate [RFC4559] are "in-band" HTTP 434 authentication methods. 436 In so far as an in-band authentication method results in a web cookie 437 or session URI/ID the distinction between in-band and out-of-band is 438 almost trivial, as described above: authentication messages in 439 headers vs. bodies, and HTTP verb and URL. However, if in-line 440 authentication methods are strongly tied to the TCP/TLS connections 441 over which they were utilized then that is a big disadvantage over 442 RESTauth: each connection requires re-authenticating, and support for 443 HTTP routing schemes is not clear. 445 HTTP/Negotiate is more troublesome because historically it has 446 required re-authentication per-HTTP request(!). 448 Even if the only difference between in-band and out-of-band is a 449 trivial one, using the REST pattern means that authentication can be 450 implemented using with no help from the HTTP stack (even though it's 451 desirable to have it implemented within/by the HTTP stack), whereas 452 there may not be a way to implement in-band authentication without 453 help from the HTTP stack for some stacks. 455 6. Sample/Potential RESTauth Authentication Mechanisms 457 Here we describe (informatively, for now) how to use or adapt a 458 variety of authentication mechanisms, from SSHv2, IKEv2, SASL, GSS- 459 API, and other frameworks, so as to quickly gain a set of usable 460 mechanisms, both, specification- and implementation-wise. This 461 section is also intended to show that adding RESTauth mechanisms is 462 easy. 464 6.1. Adapting SSHv2 Authentication Mechanisms to RESTauth 466 SSHv2 "userauth" mechanisms [RFC4252] typically involve a digital 467 signature (or similar) of an SSHv2 session ID. There is no such 468 thing as an SSHv2 session ID in HTTP. A session URI cannot serve as 469 a stand-in for an SSHv2 session ID because a) the session URI is an 470 outcome of authentication in RESTauth, b) to prevent cut-n-paste and 471 replay attacks the client and the server both must contribute to the 472 entropy of the session ID that is signed by the client. 474 In order to adapt SSHv2 userauth methods properly (i.e., securely), 475 we have replace the SSHv2 session ID in the to-be-signed data with a 476 hash of the channel binding and nonces contributed by the client and 477 the server. As an optimization the server nonce can be sent as a 478 challenge (this saves a round trip). 480 6.1.1. RESTauth Mechanism Names for SSHv2 Userauth Methods 482 For hash agility reasons the hash function name is part of the SSHv2 483 RESTauth mechanism name. To avoid "multi-level negotiation" the 484 SSHv2 userauth method name is also part of the RESTauth mechanism 485 name. 487 The RESTauth mechanism name form for SSHv2 userauth methods, then, 488 is: ssh--. 490 The following RESTauth mechanisms are defined here: 492 o ssh-publickey-SHA-256 494 o ssh-hostbased-SHA-256 496 6.1.2. Nonces 498 The client and the server must each contribute 128-bit nonces. 500 6.1.3. "Session ID" 502 The ssh-publickey-SHA-256 and ssh-hostbased-SHA-256 mechanisms use 503 the following instead of a traditional SSHv2 session ID: 505 o SHA-256((client_nonce XOR server_nonce) || channel_binding) 507 Here the is as per-[RFC5056]: the channel binding 508 type name, followed by the channel binding data (e.g., 'tls-server- 509 end-point' followed by the server EE certificate as sent in the 510 server's TLS Certificate message). 512 Note that use of channel binding when using SSHv2 mechanisms is 513 REQUIRED so as to defeat cut-n-paste attacks by weakly-authenticated 514 servers. 516 6.2. Adapting IKEv2 Authentication Mechanisms to RESTauth 518 [[anchor3: TBD.]] 520 6.2.1. Adapting IKEv2 Password Authenticated Connection Establishment 521 (PACE) to RESTauth 523 [[anchor4: TBD.]] 525 6.3. Using SASL Authentication Mechanisms with RESTauth 527 Simple Authentication and Security Layers (SASL) [RFC4422] is a 528 simple, pluggable framework for authentication mechanisms. 530 To use a SASL mechanism in RESTauth just prefix "SA-" to the SASL 531 mechanism name and use that as the RESTauth mechanism name. If the 532 SASL mechanism is server-initiated then the server's challenge is 533 sent in the server's WWW-Authenticate header value as described 534 above. All other SASL authentication messages are exchanged as 535 described above (i.e., via POSTs, first to the login URI, then to the 536 session URI, with response messages as the new representation of the 537 session resource). 539 The HTTP status code functions as the application's outcome of 540 authentication message. 542 The server's WWW-Authenticate header values function as the mechanism 543 listing operation. SASL security considerations [RFC4422] [RFC5801] 544 apply (particularly regarding the negotiation of channel binding). 546 6.3.1. Using SCRAM in RESTauth 548 SCRAM [RFC5802] is a DIGEST-like mechanism for SASL. Nothing special 549 is needed to use SCRAM versus any other SASL mechanism, except for 550 the round trip optimized form of SCRAM (see below). 552 6.3.2. Using SCRAM with Round Trip Optimization in RESTauth 554 .. 556 6.4. Using GSS-API Authentication Mechanisms with RESTauth 558 The Generic Security Services Application Programming Interface (GSS- 559 API) [RFC2743] is another pluggable mechanism framework. Any GSS-API 560 mechanism that supports channel binding [RFC5056] can be used as SASL 561 mechanisms via the "SASL/GS2" bridge [RFC5801]. This includes the 562 Kerberos V5 GSS-API mechanism [RFC4121]. 564 7. IANA Considerations 566 TBD (header registrations, ...) 568 8. Security Considerations 570 This entire document deals with security considerations. [Add more, 571 like about channel binding, same-origin-like constraints on the login 572 and session absolute URIs', ...] 574 9. TODO 576 [[anchor5: Add references (to HTTP/2.0, CGI/fCGI, ...).]] 578 [[anchor6: Describe MAC session binding option and replay protection 579 in detail. Describe how to extract keys for MAC keying from SASL/ 580 GSS/PACE.]] 582 [[anchor7: Figure out how to adapt IKEv2 password-based methods to 583 RESTauth. This may not be worthwhile (since each method tends to 584 depend heavily on the entire IKEv2 framework in ways that add 585 messaging that we'd not need in RESTauth).]] 587 10. References 589 10.1. Normative References 591 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 592 Requirement Levels", BCP 14, RFC 2119, March 1997. 594 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 595 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 596 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 598 [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 599 Leach, P., Luotonen, A., and L. Stewart, "HTTP 600 Authentication: Basic and Digest Access Authentication", 601 RFC 2617, June 1999. 603 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 604 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 606 [RFC5056] Williams, N., "On the Use of Channel Bindings to Secure 607 Channels", RFC 5056, November 2007. 609 [RFC5929] Altman, J., Williams, N., and L. Zhu, "Channel Bindings 610 for TLS", RFC 5929, July 2010. 612 10.2. Informative References 614 [I-D.williams-rest-gss] 615 Williams, N., "RESTful Hypertext Transfer Protocol 616 Application-Layer Authentication Using Generic Security 617 Services", draft-williams-rest-gss-02 (work in progress), 618 July 2012. 620 [RFC4422] Melnikov, A. and K. Zeilenga, "Simple Authentication and 621 Security Layer (SASL)", RFC 4422, June 2006. 623 [RFC5802] Newman, C., Menon-Sen, A., Melnikov, A., and N. Williams, 624 "Salted Challenge Response Authentication Mechanism 625 (SCRAM) SASL and GSS-API Mechanisms", RFC 5802, July 2010. 627 [RFC4252] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) 628 Authentication Protocol", RFC 4252, January 2006. 630 [RFC4559] Jaganathan, K., Zhu, L., and J. Brezak, "SPNEGO-based 631 Kerberos and NTLM HTTP Authentication in Microsoft 632 Windows", RFC 4559, June 2006. 634 [RFC6631] Kuegler, D. and Y. Sheffer, "Password Authenticated 635 Connection Establishment with the Internet Key Exchange 636 Protocol version 2 (IKEv2)", RFC 6631, June 2012. 638 [RFC2743] Linn, J., "Generic Security Service Application Program 639 Interface Version 2, Update 1", RFC 2743, January 2000. 641 [RFC5801] Josefsson, S. and N. Williams, "Using Generic Security 642 Service Application Program Interface (GSS-API) Mechanisms 643 in Simple Authentication and Security Layer (SASL): The 644 GS2 Mechanism Family", RFC 5801, July 2010. 646 [RFC4121] Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos 647 Version 5 Generic Security Service Application Program 648 Interface (GSS-API) Mechanism: Version 2", RFC 4121, 649 July 2005. 651 Author's Address 653 Nicolas Williams 654 Cryptonector, LLC 656 Email: nico@cryptonector.com