idnits 2.17.1 draft-montenegro-httpbis-multilegged-auth-00.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 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 29, 2012) is 4318 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'RFC2119' on line 119 looks like a reference Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Silvera 3 Internet-Draft M. Cox 4 Expires: December 31, 2012 I. Pashov 5 O. Mazahir 6 G. Montenegro 7 Microsoft 8 June 29, 2012 10 Multilegged Authentication for HTTP Multiplexing 11 draft-montenegro-httpbis-multilegged-auth-00 13 Abstract 15 In line with the HTTP compatibility goal for HTTP 2.0, HTTP 2.0 must 16 also be compatible with currently deployed authentication schemes. 17 This draft addresses this goal in the presence of multiplexing 18 (expected to be part of HTTP 2.0), while addressing some of the 19 issues currently encountered when performing multilegged 20 authentication. 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on December 31, 2012. 39 Copyright Notice 41 Copyright (c) 2012 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 58 2. Multilegged Authentication in HTTP 1.X . . . . . . . . . . . . 4 59 3. Multilegged Authentication in the Presence of HTTP 2.0 60 Multiplexing . . . . . . . . . . . . . . . . . . . . . . . . . 6 61 3.1. Auth-ID Header and Security Context Lifetime . . . . . . . 8 62 4. Stateful Authentication to Proxies . . . . . . . . . . . . . . 10 63 4.1. HTTP 2.0 Client Authenticating to an HTTP 2.0 Server 64 via Proxy . . . . . . . . . . . . . . . . . . . . . . . . 10 65 4.2. HTTP 2.0 Client Authenticating to an HTTP 1.1 Server 66 via Proxy . . . . . . . . . . . . . . . . . . . . . . . . 10 67 4.3. HTTP 1.1 Client Connecting to an HTTP 2.0 Server via 68 Proxy . . . . . . . . . . . . . . . . . . . . . . . . . . 10 69 5. Authentication and multi-host sessions . . . . . . . . . . . . 11 70 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 71 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 74 1. Overview 76 This document defines multilegged authentication for HTTP 77 multiplexing. 79 Without reliable support for Kerberos and other multilegged auth 80 schemes, the reach of HTTP2.0 will be greatly diminished in 81 corporations that rely on these authentication schemes to protect 82 their intranet resources. 84 HTTP 2.0 should be semantically compatible with HTTP 1.1, but it 85 should not have the same "stateless" requirement as HTTP 1.1, as many 86 things other than multilegged authentication, require server side 87 state. In order to preserve this requirement, we propose that 88 additional state needed for HTTP 2.0, be stored at the session layer. 89 The HTTP 1.1 concept of "connection-based authentication" can be 90 implemented in HTTP 2.0 by moving the state from the TCP connection 91 layer to the HTTP 2.0 session layer. 93 The following table summarizes widely deployed authentication 94 schemes, their authentication types and the authentication level they 95 provide: 97 Table 1: 98 +-----------+------------------------+----------------------+ 99 | Scheme | Type of Authentication | Authentication Level | 100 +-----------+------------------------+----------------------+ 101 | Basic | Per Request | Request | 102 | Digest | Per Request | Request | 103 | NTLM | Multilegged | Connection | 104 | Kerberos | Multilegged |Connection or Request | 105 | Negotiate | Multilegged |Connection or Request | 106 +-----------+------------------------+----------------------+ 108 RFC 2616 defines HTTP as a stateless protocol and dictates that 109 authentication schemes MUST be stateless. However, multilegged 110 authentication support for multiplexing requires state to associate 111 separate request/response pairs that are part of the same multilegged 112 authentication process. 114 1.1. Requirements Language 116 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 117 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 118 document are to be interpreted as described in [RFC2119]. 120 2. Multilegged Authentication in HTTP 1.X 122 As implied by its name, multilegged authentication requires multiple 123 roundtrips to establish an authenticated communication channel 124 between client and server. If the resource requested by a client 125 requires authentication, the server initiates the authentication 126 process as follows: 128 Figure 1: Multilegged authentication example: 130 Client Server 131 | | 132 | -------- (0) HTTP GET Request ----> | 133 | | 134 | <------- (1) HTTP 401 ------------- | 135 | | 136 | -------- (2) HTTP Get Request ----> | 137 | w Auth header | 138 | | 139 | <------- (3) HTTP 401 ------------- | 140 | | 141 | -------- (4) HTTP Get Request ----> | 142 | w Auth header | 143 | | 144 | <------- (5) HTTP 200 OK----------- | 145 | | 146 | | 147 v v 149 1. Server sends HTTP 401 response because the resource requested 150 requires authentication. 152 2. Client re-issues the HTTP GET request for the resource, including 153 authentication headers. 155 3. Server responds with an HTTP 401 and authentication headers 156 requesting additional information. 158 4. Client re-issues the HTTP GET Request for the resource, including 159 authentication headers with the additional information required 160 to complete authentication. 162 5. If authentication succeeds, the server responds with an HTTP 200 163 OK message including the requested resource. 165 Multilegged authentication requires state to be communicated between 166 multiple streams. Network flows 3 and 4 in Figure 1 need to share 167 state in order for authentication to succeed. Some multilegged 168 authentication schemes (i.e. Kerberos and Negotiate) can 169 authenticate either a connection or individual requests, which has 170 historically caused a lot if issues with multilegged authentication 171 in HTTP 1.1. 173 3. Multilegged Authentication in the Presence of HTTP 2.0 Multiplexing 175 Figure 2 below provides a detailed breakdown of proposed network 176 flows to implement multilegged authentication for HTTP 2.0 177 multiplexing: 179 Figure 2 - Proposed multilegged authentication: 181 Multiplexing 182 Client HTTP Server 183 | | 184 | -------- HTTP GET Request ------> | 185 | | 186 | <------- (0) HTTP 401 ------------- | 187 | | 188 | -------- (1) HTTP Get Request ----> | 189 | w Auth header |[Auth-ID header 190 | | generated (1.5)] 191 | <------- (2) HTTP 401 ------------- | 192 | w Auth-ID header | 193 | | 194 | -------- (3) HTTP Get Request ----> |[Persisted-auth header 195 | w Auth header and | generated (3.5)] 196 | Auth-ID header | 197 | | 198 | <------- (4) HTTP 200 OK----------- | 199 | w optional | 200 | PersistedAuth header | 201 | | 202 | | 203 v v 205 1. Server sends HTTP 401 response because the resource requested 206 requires authentication. 208 2. Client re-issues the HTTP GET request for the resource, including 209 authentication headers. 211 Multilegged authentication schemes could authenticate individual 212 requests or the HTTP 2.0 session. Clients SHOULD NOT 213 authenticate individual streams belonging to an authenticated 214 HTTP 2.0 session. The following describes client behavior when 215 attempting to authenticate streams, for which it does not know if 216 the negotiation will result in request based or HTTP 2.0 session 217 based authentication: 219 If an HTTP 2.0 session has a stream in process of authenticating 220 using a multilegged authentication scheme, the client SHOULD 221 queue all subsequent requests (regardless of whether they require 222 authentication) on the session until the multilegged 223 authentication completes. 225 If a server receives multiple authenticated requests from the 226 same client, it SHOULD NOT block responses. It is the client's 227 responsibility to queue requests when a multilegged stream 228 authentication process has been initiated in the session. If the 229 client does not queue the requests, then it might unnecessarily 230 authenticate streams in a session that has already been 231 authenticated. 233 If connection-based multilegged authentication succeeds on a 234 previously authenticated session, the server SHOULD discard the 235 previous authentication context and authenticate the session with 236 the newly negotiated authentication context. 238 3. Server responds with an HTTP 401 and authentication headers 239 requesting additional information. 241 A session's lifetime is not tied to the duration of a request/ 242 response pair. If the authentication scheme used to validate the 243 client's identity is a multilegged scheme, servers MUST generate 244 a new "Auth-ID" (1.5 in Figure 2) header. The Auth-ID value is 245 an opaque blob that SHOULD NOT be interpreted. It MUST be sent 246 in its complete form to continue an authentication process. The 247 server uses this to look up the correct security context to 248 process this authentication request. 250 The HTTP 401 response from the server MUST contain the "Auth-ID" 251 header to enable sharing of authentication context across 252 streams, as required for multilegged authentication. 254 4. Client re-issues the HTTP GET request for the resource and MUST 255 include the required authentication headers and the "Auth-ID" 256 header, to inform the server that the request is part of a 257 previously initiated multilegged authentication process. 259 5. Authentication succeeds and the server returns the requested 260 resource, along with level of multilegged authentication scheme: 262 Some multilegged authentication schemes can result in per-request 263 or per-connection (i.e., Kerberos or Negotiate) authentication. 264 When a session is authenticated, servers MUST generate a 265 Persistent-auth header 3.5 in Figure 2) and send it along with 266 the HTTP 200 OK response. The client MUST use the presence or 267 absence) of the Persistent-auth header to determine what action 268 to take with previously queued requests due to multilegged 269 authentication being in progress: 271 1. If the session was authenticated, as indicated by the 272 presence of the Persistent-auth header, the client does not 273 need to authenticate new streams it creates to service the 274 queued requests on the authenticated session. 276 Clients SHOULD assume that successful authentication with 277 schemes that only support connection-based authentication 278 (i.e. NTLM) always result in an authenticated session, even 279 if the Persisted-auth header is not present. 281 2. If the session was not authenticated, as indicated by the 282 absence of the Persistent-auth header, the client SHOULD 283 remember the negotiated authentication scheme used for 284 authentication. The client SHOULD NOT block streams on the 285 session when processing requests using the multilegged 286 authentication scheme that previously resulted in per-request 287 authentication. 289 A server MAY generate and add Auth-ID header as soon as it knows 290 that the requested authentication scheme is multilegged. The 291 client MUST add the Auth-ID header to all subsequent requests 292 required to complete the authentication process. 294 A server MAY generate a Persistent-auth request as soon as it 295 knows that the requested authentication scheme will authenticate 296 the session. The client CANNOT make any assumptions by the 297 absence of the Persistent-auth header, until the authentication 298 process is complete and it receives the final server response 299 containing the requested resource. 301 3.1. Auth-ID Header and Security Context Lifetime 303 Servers create and store security context information when they 304 create the Auth-ID header. An Auth-ID header CANNOT be reused across 305 sessions. 307 The Auth-ID mapping is destroyed when the authentication process 308 completes. Completion of the authentication process can be a 309 successful authentication or failure to authenticate. TBD: Should 310 Auth-IDs be random numbers? The security vs look-up perf 311 implications should be weighed. 313 Servers SHOULD limit the number of incomplete security contexts per 314 session, to protect against misbehaving clients that cause the server 315 to create multiple authentication contexts but never complete the 316 authentication process. Servers SHOULD define a maximum number of 317 incomplete security contexts and ignore SYN streams from misbehaving 318 clients. 320 Per-session security contexts are transient and servers SHOULD 321 discard them when request processing completes. There SHOULD only be 322 one complete security context open per session. 324 4. Stateful Authentication to Proxies 326 HTTP proxies MUST add a new Remote-http-version header to inform the 327 client of the HTTP version of the remote host. HTTP 2.0 clients can 328 make authentication decisions based on the HTTP version of the target 329 server. Proxy and gateway applications should take the consideration 330 outlined by RFC 2616 when forwarding messages between client and 331 servers with different protocol version capabilities. 333 4.1. HTTP 2.0 Client Authenticating to an HTTP 2.0 Server via Proxy 335 Authentication from an HTTP 2.0 (or greater) client to an HTTP 2.0 336 (or greater) server will work without additional changes, other than 337 those described in the Multilegged Authentication for HTTP 338 multiplexing proposal section of this document. Proxies MUST bind 339 the client-to-proxy and proxy-to-server connections. 341 4.2. HTTP 2.0 Client Authenticating to an HTTP 1.1 Server via Proxy 343 HTTP 2.0 (or greater) clients that establish an authenticated 344 connection to an HTTP 1.1 server (via a proxy) SHOULD downgrade HTTP 345 version to HTTP 1.1, to avoid serialization. 347 HTTP 2.0 clients can multiplex streams within the authenticated HTTP 348 2.0 client-proxy session, but the proxy MUST serialize requests 349 through the authenticated HTTP 1.1 proxy-server connection. 351 HTTP 2.0 clients could decide to downgrade all requests requiring 352 authentication (via a proxy) to HTTP 1.1 servers or only downgrade 353 authenticated sessions, as indicated by the presence of the 354 Persisted-auth header. 356 4.3. HTTP 1.1 Client Connecting to an HTTP 2.0 Server via Proxy 358 No changes required to support this scenario as HTTP 1.1 clients 359 ignore HTTP 2.0 headers. 361 5. Authentication and multi-host sessions 363 The proposed authentication mechanism works only if there is a limit 364 of one unique host per HTTP 2.0 session. 366 6. Security Considerations 368 Implementers should be aware of the security considerations defined 369 by the individual authentication schemes supported. The following 370 are some general security considerations that are independent of the 371 proposed authentication mechanism. 373 The proposed authentication mechanism is only used to provide 374 authentication of a user to a server. It provides no facilities for 375 protecting the HTTP headers or data including the Authorization and 376 WWW-Authenticate headers that are used to implement this mechanism. 378 Alternate mechanisms such as TLS can be used to provide 379 confidentiality. Hashes of the TLS certificates can be used as 380 channel bindings to secure the channel. In this case clients would 381 need to enforce that the channel binding information is valid. 383 If an HTTP proxy is used between the client and server, it MUST take 384 care to not share authenticated connections between different 385 authenticated clients to the same server. If this is not honored, 386 then the server can easily lose track of security context 387 associations. 389 A proxy that correctly honors client to server authentication 390 integrity will supply the "Proxy-support: Session-Based- 391 Authentication" HTTP header to the client in HTTP responses from the 392 proxy. 394 7. Acknowledgements 396 Thanks to the following individuals who provided helpful feedback and 397 contributed to discussions on this document: Paul Leach, Nathan Ide 398 and Rob Trace. 400 Authors' Addresses 402 Jonathan Silvera 403 Microsoft 405 Email: JSilvera@microsoft.com 407 Matthew Cox 408 Microsoft 410 Email: MaCox@microsoft.com 412 Ivan Pashov 413 Microsoft 415 Email: IvanPash@microsoft.com 417 Osama Mazahir 418 Microsoft 420 Email: OsamaM@microsoft.com 422 Gabriel Montenegro 423 Microsoft 425 Email: Gabriel.Montenegro@microsoft.com