idnits 2.17.1
draft-hallambaker-httpsession-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 issues found here.
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
** There are 5 instances of too long lines in the document, the longest one
being 14 characters in excess of 72.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
== The document seems to lack the recommended RFC 2119 boilerplate, even if
it appears to use RFC 2119 keywords.
(The document does seem to have the reference to RFC 2119 which the
ID-Checklist requires).
-- The document date (April 04, 2013) is 4040 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: 'CRIME' is mentioned on line 121, but not defined
== Missing Reference: 'BEAST' is mentioned on line 121, but not defined
== Missing Reference: 'TBS' is mentioned on line 389, but not defined
== Missing Reference: 'RFC 2104' is mentioned on line 401, but not defined
== Missing Reference: 'RFC 4493' is mentioned on line 418, but not defined
== Missing Reference: 'IANA TBS' is mentioned on line 640, but not defined
== Missing Reference: 'RFC3275' is mentioned on line 882, but not defined
== Missing Reference: 'RFC4120' is mentioned on line 886, but not defined
== Missing Reference: 'RFC5652' is mentioned on line 890, but not defined
== Missing Reference: 'RFC6265' is mentioned on line 893, but not defined
== Unused Reference: 'RFC2119' is defined on line 861, but no explicit
reference was found in the text
== Unused Reference: 'RFC2965' is defined on line 868, but no explicit
reference was found in the text
== Unused Reference: 'RFC5246' is defined on line 874, 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 2965 (Obsoleted by RFC 6265)
** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446)
Summary: 4 errors (**), 0 flaws (~~), 15 warnings (==), 1 comment (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 Internet Engineering Task Force P. M. Hallam-Baker
3 Internet-Draft Comodo Group Inc.
4 Intended status: Standards Track April 04, 2013
5 Expires: October 06, 2013
7 HTTP Session Management
8 draft-hallambaker-httpsession-00
10 Abstract
12 The HTTP Session Management Mechanism provides a mean of securely
13 establishing a persistent authentication session between a HTTP
14 client and server that does not rely on the presentation of a
15 confidential bearer token. The Session Management Mechanism is
16 intended to provide a replacement for the existing HTTP State
17 Management Mechanism (Cookies) for this purpose.
19 This document defines the HTTP Accept-Session, Set-Session and
20 Session headers and specifies their use to establish symmetric
21 authentication keys and their use to authenticate and verify specific
22 parts of an HTTP message. Other means by which keys used to
23 authenticate the messages are established are outside the scope of
24 this document.
26 Status of This Memo
28 This Internet-Draft is submitted in full conformance with the
29 provisions of BCP 78 and BCP 79.
31 Internet-Drafts are working documents of the Internet Engineering
32 Task Force (IETF). Note that other groups may also distribute
33 working documents as Internet-Drafts. The list of current Internet-
34 Drafts is at http://datatracker.ietf.org/drafts/current/.
36 Internet-Drafts are draft documents valid for a maximum of six months
37 and may be updated, replaced, or obsoleted by other documents at any
38 time. It is inappropriate to use Internet-Drafts as reference
39 material or to cite them other than as "work in progress."
41 This Internet-Draft will expire on October 06, 2013.
43 Copyright Notice
45 Copyright (c) 2013 IETF Trust and the persons identified as the
46 document authors. All rights reserved.
48 This document is subject to BCP 78 and the IETF Trust's Legal
49 Provisions Relating to IETF Documents
50 (http://trustee.ietf.org/license-info) in effect on the date of
51 publication of this document. Please review these documents
52 carefully, as they describe your rights and restrictions with respect
53 to this document. Code Components extracted from this document must
54 include Simplified BSD License text as described in Section 4.e of
55 the Trust Legal Provisions and are provided without warranty as
56 described in the Simplified BSD License.
58 Table of Contents
60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
61 1.1. Relationship to Other Authentication Technologies . . . . 4
62 1.2. Example: Web Browser User Authentication . . . . . . . . 5
63 1.3. Use in Web Services . . . . . . . . . . . . . . . . . . . 8
64 2. Session Context . . . . . . . . . . . . . . . . . . . . . . . 8
65 2.1. Fixed Session Context . . . . . . . . . . . . . . . . . . 9
66 2.1.1. Id: Identifier . . . . . . . . . . . . . . . . . . . 9
67 2.1.2. Key: Authentication Key . . . . . . . . . . . . . . . 9
68 2.1.3. MAC: Message Authentication Code Algorithm . . . . . 9
69 2.1.4. Scope Attributes . . . . . . . . . . . . . . . . . . 10
70 2.1.5. Replay Attack Prevention . . . . . . . . . . . . . . 11
71 2.1.6. Direction . . . . . . . . . . . . . . . . . . . . . . 11
72 2.1.7. TLS Binding (Fixed) . . . . . . . . . . . . . . . . . 12
73 2.1.8. Domain: String . . . . . . . . . . . . . . . . . . . 12
74 2.2. Session Context State Attributes . . . . . . . . . . . . 12
75 2.2.1. Expiry time: Max-Age . . . . . . . . . . . . . . . . 12
76 2.2.2. Now: Time Offset (Time) . . . . . . . . . . . . . . . 12
77 2.2.2.1. Now: Last Now (Time) . . . . . . . . . . . . . . 12
78 2.2.3. Count: Last Count (Count) . . . . . . . . . . . . . . 13
79 2.2.4. Nonce: Last Nonce (Nonce) . . . . . . . . . . . . . . 13
80 3. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
81 3.1. Accept-Session Header . . . . . . . . . . . . . . . . . . 13
82 3.2. Set-Session Header . . . . . . . . . . . . . . . . . . . 14
83 3.3. Session Header . . . . . . . . . . . . . . . . . . . . . 15
84 3.3.1. Required Attributes . . . . . . . . . . . . . . . . . 15
85 3.3.1.1. Attribute Value=[base64(value)] (required) . . . 15
86 3.3.1.2. Replay Attack Prevention Attributes . . . . . . . 16
87 3.3.2. TLS Channel Binding Attributes . . . . . . . . . . . 16
88 3.3.2.1. Attribute tlsu=[value] . . . . . . . . . . . . . 16
89 3.3.2.2. Attribute tlss=[value] . . . . . . . . . . . . . 16
90 3.3.3. Preparing the Input to the Authentication Algorithm . 16
91 4. Processing . . . . . . . . . . . . . . . . . . . . . . . . . 17
92 4.1. Calculating the Authentication Value . . . . . . . . . . 17
93 4.1.1. Start line . . . . . . . . . . . . . . . . . . . . . 17
94 4.1.2. Canonical Headers . . . . . . . . . . . . . . . . . . 17
95 4.1.3. Message Content . . . . . . . . . . . . . . . . . . . 17
97 4.2. Generating a Session Header . . . . . . . . . . . . . . . 18
98 4.3. Authenticating a HTTP Message under a Session Context . . 18
99 5. Security Considerations . . . . . . . . . . . . . . . . . . . 18
100 5.1. Data outside the specified scope is not authenticated . . 18
101 5.2. Truncated Hash Algorithms . . . . . . . . . . . . . . . . 18
102 5.3. Randomness of Secret Keys and nonces . . . . . . . . . . 18
103 5.4. Weak Ciphers . . . . . . . . . . . . . . . . . . . . . . 19
104 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
105 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
106 7.1. Normative References . . . . . . . . . . . . . . . . . . 19
107 7.2. Non Normative References . . . . . . . . . . . . . . . . 19
108 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 20
110 1. Introduction
112 The HTTP State Management Mechanism 'Cookies'[RFC6265] was intended
113 to allow HTTP [RFC2616] servers to let servers maintain a stateful
114 session over the mostly stateless HTTP protocol. While the exchange
115 of static tokens is an acceptable mechanism for maintaining state,
116 use of static tokens as bearer tokens for an authentication mechanism
117 is not. Such tokens are not bound to any part of the message they
118 purport to authenticate and may be disclosed to intermediaries.
120 While use of TLS transport provides a confidentiality enhancement for
121 HTTP content, recent research [CRIME], [BEAST] demonstrates that
122 relying on a transport or network layer to protect the
123 confidentiality of a bearer authentication token is fundamentaly
124 unsound. The interaction of HTTP header compression mechanisms and a
125 Turing complete active code mechanism under control of the attacker
126 produces a threat model in which the capabilities afforded the
127 attacker far exceed the capabilities that it is sensible to expect a
128 protocol design to resist.
130 The HTTP Accept-Session, Set-Session and Session headers provide a
131 simple and effective means of maintaining a HTTP authentication
132 session without passing static authentication data in either
133 direction after the authentication session has been established. The
134 design of the Set-Session and Session headers permit them to be used
135 as a replacement for the Set-Cookie and Cookie headers in situations
136 where they are supported by both the client and the server and ensure
137 correct behavior by intermediaries conformant to the HTTP
138 specification.
140 A HTTP authentication session MAY be established inband by means of
141 the Set-Session header. The Set-Session header specifies a unique
142 identifier for the session and determines the session parameters
143 including the cryptographic algorithm and shared key.
145 Applications SHOULD make use of cryptographic enhancements to protect
146 the confidentiality of a session context established using the Set-
147 Session header.
149 Clients and Servers MAY support other means of establishing a HTTP
150 authentication session. For example in a federated authentication
151 scheme such as SAML, Kerberos or OpenID, the authentication session
152 might be provided by a third party.
154 Once the HTTP authentication session is established, a Session header
155 is added to HTTP requests and/or responses as directed by the session
156 context. The session header specified the session identifier and an
157 authentication value calculated over portions of the HTTP message and
158 other attributes to which it is bound as directed by the
159 corresponding session context. The bound attributes and portions of
160 the HTTP message cannot then be changed without invalidating the
161 authentication value.
163 The use of bound attributes permits protection against TLS channel
164 rebinding and/or HTTP message replay attacks.
166 The portions of a HTTP message to which it is desirable to bind an
167 authentication session depend on the situation. Binding the
168 authentication session to the message content prevents modification
169 of the content but imposes more constraints on implementations than
170 binding to the message start line. Interactions with intermediaries
171 and in particular intermediarries that are not fully compliant with
172 the HTTP specification also raise concerns Web browsers are typically
173 coded to be tollerant of such implementation defects and operate
174 despite unauthorized modification of content by caches and other
175 intermediaries. The prefered behavior of a Web Service client in
176 such situations is likely to be to abort the transaction rather than
177 risk continuing with corrupted data.
179 1.1. Relationship to Other Authentication Technologies
181 The term 'user authentication' is applied to three separate concerns;
182 credential management, credential presentation and session
183 continuation.
185 Credential Management describes the means by which credentials are
186 created, issued and revoked.
188 Credential Presentation describes the means by which a party
189 demonstrates holdership of a credential to establish an
190 authentication session.
192 Session Continuation describes the means by which a party
193 demonstrates that a particular transaction is taking place within
194 the context of a particular authentication session.
196 The HTTP Session Management Mechanism is designed to support only
197 Session Continuation and to compliment existing and future mechanisms
198 for Credential management and Credential Presentation. While a
199 session continuation mechanism is not in itself a solution to the
200 problem of user authentication, the provision of a robust session
201 continuation mechanism that does not depend on a bearer token
202 addresses the most challenging problem facing the designers of SAML,
203 OpenID and OAUTH.
205 1.2. Example: Web Browser User Authentication
207 The principal mechanism for user authentication in use today is to
208 present a HTML form in which the user enters their username and
209 password.
211 This approach has many known defects. These include the risk of
212 impersonation of the Web site causing the user to enter their
213 username and password into a form controlled by the attack and the
214 strong likelihood that the user will use the same password across
215 multiple sites. But since they are related to the functions of
216 Credential Management and Presentation, these defects are out of
217 scope of this document.
219 The client indicates that it supports the session header by including
220 one or more Accept-Session headers in the request transfering the
221 username and password values. The Accept-Session header specifies
222 the scope and replay binding options that the client offers to
223 support.
225 [If a public key exchange mechansism such as Diffie-Hellman was to be
226 supported in the protocol, the client would specify its public
227 Diffie-Hellman key in the request. Note however that this raises a
228 tradeoff between privacy and performance concerns as using the same
229 DH public key for each request provides the server with an easily
230 linkable identifier.]
231 POST /login.php HTTP/1.1
232 Host: example.com
233 Cache-Control: no-store
234 Content-Type: application/x-www-form-urlencoded
235 Content-Length: 29
236 Accept-Session: Start=required Request=required Content=optional Time=required
238 username=skroob&password=1234
240 If the browser does not specify a Accept-Session header the server
241 MAY reject the connection request entirely or fallback to the
242 traditional Cookie mechanism as determined by site policy.
244 If the service accepts the offer of session management support, it
245 includes a Set-session Header in the response specifying the session
246 context:
248 HTTP/1.1 201 OK
249 Content-Length: 35
250 Set-Session:
251 Id=TUMnorO0SjHHS7D2uFcGlRYJ0Hd3eibwe0ogptoNMQuCYmCHfHAJcJlyvi
252 j8WoXDglTSOkctnmoBzl8W0NLSlcgSyZcmsAyoWs8y1Rn2ZlO2WBgoWrFIOqPa4
253 oB29dgs/ei6ieINZtmvXNCm2NUkWA==
254 Key=7eb219188339135ba51e8715f3900bfb974995e145d6e490e4addbbdb26f4bb4
255 Alg=HMAC-SHA256 Start=True Request=True Time=True Now=745531 Domain=example.com
256 Max-Age=31536000
258
Authenticated
260 In this case the server avoids the need to track per client state by
261 using a time based mechanism to avoid replay attacks and storing the
262 state associated with the client session as encrypted data within the
263 session identifier. The scope of the content binding is limited to
264 the start line and the timer to be used for replay attack prevention
265 has an offset 745531 seconds in the past.
267 Once the session has been established, the client MUST include a
268 Session header in subsequent HTTP requests made to the specified DNS
269 domains.
271 GET /status.php HTTP/1.1
272 Host: example.com
273 Cache-Control: no-store
274 Content-Type: application/x-www-form-urlencoded
275 Content-Length: 29
276 Session: Id=TUMnorO0SjHHS7D2uFcGlRYJ0Hd3eibwe0ogptoNMQuCYmCHfHAJcJlyvi
277 j8WoXDglTSOkctnmoBzl8W0NLSlcgSyZcmsAyoWs8y1Rn2ZlO2WBgoWrFIOqPa4
278 oB29dgs/ei6ieINZtmvXNCm2NUkWA==
279 Value=cjkMkfnnYP8JYWZAbRLvtpqImmOK3rsrOT1XcvAgHDk=;
280 Now=745533
282 In this case the session scope does not specify responses and so the
283 response does not require an Session header but a server MAY provide
284 one so as to specify updated values for the replay attack prevention
285 attributes Now and/or Count. Whenever a Session header is present
286 the Id and Value attributes MUST be specified and correct:
288 HTTP/1.1 201 OK
289 Content-Length: 35
290 Session:
291 Id=TUMnorO0SjHHS7D2uFcGlRYJ0Hd3eibwe0ogptoNMQuCYmCHfHAJcJlyvi
292 j8WoXDglTSOkctnmoBzl8W0NLSlcgSyZcmsAyoWs8y1Rn2ZlO2WBgoWrFIOqPa4
293 oB29dgs/ei6ieINZtmvXNCm2NUkWA==
294 Value=cjkMkfnnYP8JYWZAbRLvtpqImmOK3rsrOT1XcvAgHDk=;
295 Now=745532
297 Shield is Closed
299 In this particular instance the clock at the server is running behind
300 that of the client requiring the timer offset value to be decreased
301 by one second. To ensure that the replay attack protection values
302 only increase or stay the same, the client uses the last value of the
303 old time offset until the new time offset value has superceded it.
305 The Web Browser MAY terminate the session by simply deleting the
306 session context information from its store preventing reuse. A
307 client MAY inform the server that the session context is about to be
308 deleted by including a Session header with the Deleted attribute:
310 HEAD /status.php HTTP/1.1
311 Host: example.com
312 Session: Id=TUMnorO0SjHHS7D2uFcGlRYJ0Hd3eibwe0ogptoNMQuCYmCHfHAJcJlyvi
313 j8WoXDglTSOkctnmoBzl8W0NLSlcgSyZcmsAyoWs8y1Rn2ZlO2WBgoWrFIOqPa4
314 oB29dgs/ei6ieINZtmvXNCm2NUkWA==
315 Value=cjkMkfnnYP8JYWZAbRLvtpqImmOK3rsrOT1XcvAgHDk=;
316 Deleted
318 A server may inform the client that the session has been terminated
319 by including a Session header with the Deleted attribute in the
320 response.
322 1.3. Use in Web Services
324 Use of HTTP Session Managment simplifies implemenatation of Web
325 Services. Using the SOAP [TBS] approach a Web Service message is
326 encoded in XML [TBS], wrapped in a SOAP envelope and a WS-Security
327 [TBS] header with an XML Signature [TBS] attached. The whole package
328 is then attached to a HTTP message as a content payload.
330 This approach involves a considerable degree of complexity and in
331 most cases does nothing more than attach an authentication data.
332 Carrying the authentication value as a HTTP header eliminates the
333 need for the SOAP and WS-Security layers entirely.
335 Use of session management in Web Services presents different
336 requirements and constraints. In the case of an entirely new Web
337 Service with no deployment history, there is no need to consider
338 support for legacy code at all, eliminating one of the principal
339 constraints governing use of new HTTP protocol features in Web
340 Browsers.
342 A Web Service specification MAY require clients and servers to
343 support and/or use scope and/or replay prevention mechanisms that are
344 optional in this document. For example an Web Service exchanging
345 payment transaction requests in XML is likely to require the
346 authentication scope to include the message content and to support
347 counter and nonce based replay attack prevention mechanisms.
349 A single HTTP message MAY have multiple Session headers. This
350 facilitates support for multi-party transactions in which A submits a
351 transaction to B who countersigns it and passes it to C who is
352 required to chek that she has proof of agreement by both A and B.
354 Use of the Session header permits the developer to isolate integrity
355 and authentication checks to a single point of control, as is advised
356 by best security practice. The security monitor examines a HTTP
357 message, verifies that the required integrity data is present and
358 correct and only passes the payload on for processing by the Web
359 Service itself if and only if the verification checks have been
360 passed.
362 2. Session Context
364 The processing of the Session header is determined by the session
365 context which consists of a set of fixed attributes that remain
366 constant for the lifetime of the session and state attributes that
367 are updated as Session headers are generated and verified.
369 2.1. Fixed Session Context
371 The fixed session context elements are set when the session is
372 established and remain constant for the lifetime of the session. The
373 values specified can only be changed by establishing a new session
374 which MUST have a different session identifier.
376 2.1.1. Id: Identifier
378 The session identifier is a statistically unique sequence of binary
379 data which SHOULD be unique, MUST be statistically unique, SHOULD be
380 less than 512 octets in length and MUST NOT be longer than 4096
381 octets in length.
383 Servers MAY avoid the need to maintain per-session server side state
384 by encoding the some or all of the fixed session context parameters
385 in to the identifier. Servers MUST ensure that appropriate
386 cryptographic enhancements are employed to authenticate the sessikon
387 context and protect the confidentiality of the authentication key.
388 The scheme used to construct the session identifiers used in the
389 examples is described in Appendix [TBS]
391 2.1.2. Key: Authentication Key
393 The cryptographic key to be used to calculate the authentication
394 value.
396 2.1.3. MAC: Message Authentication Code Algorithm
398 The message authentication algorithm to be used to calculate the
399 authentication value.
401 HMAC construction [RFC 2104]:
403 HMAC-SHA256-64 HMAC using the SHA-1 algorithm with the output
404 truncated to the first 64 bits.
406 HMAC-SHA256-128 HMAC using the SHA-1 algorithm with the output
407 truncated to the first 64 bits.
409 HMAC-SHA512-256 HMAC using the SHA-1 algorithm with the output
410 truncated to the first 256 bits.
412 HMAC-SHA2-256-128 HMAC using the SHA-2 algorithm with the output
413 truncated to the first 128 bits.
415 HMAC-SHA2-512-256 HMAC using the SHA-2 algorithm with the output
416 truncated to the first 256 bits.
418 CMAC Construction [RFC 4493]:
420 CMAC-AES128-64 The AES algorithm employed in CMAC mode with a 128
421 bit key and the output truncated to the first 64 bits.
423 CMAC-AES128 The AES algorithm employed in CMAC mode with a 128 bit
424 key and the entire output.
426 CMAC-AES256 The AES algorithm employed in CMAC mode with a 256 bit
427 key and the entire output. NB: RFC 4493 only specifies CMAC for
428 128 bit keys so this would need an extension.
430 2.1.4. Scope Attributes
432 The scope attributes specify which parts of the message are
433 authenticated.
435 [Separating the scope attribute from the authentication context so
436 that it is specified in each Session header would permit the scope of
437 the authentication check to be declared to intermediaries and allows
438 the same authentication context to be used to authenticate different
439 portions of the HTTP message separately. I do not see the need to do
440 this however and doing this would likely lead to implementations that
441 are vulnerable to downgrade attacks by scope stripping.]
443 The scope is specified by the start, header and content attributes.
444 The order in which the scope attributes are specified in the HTTP
445 Set-Session header is immaterial. The scope is always constructed in
446 the same order as the elements occur in a HTTP message, i.e. start,
447 dummy headers and content.
449 Content: Boolean If set true, the specified scope includes the
450 message body. The content transfer encoding (e.g. chunked) is
451 ignored for the purpose of determining the content.
453 ContentDigest: Label If a message digest algorithm is specified the
454 authentication scope MAY be calculated indirectly by first
455 calculating a Message Digest value over the content and using the
456 resulting value in place of the actual content value to calculate
457 the Message Authentication Code value.
459 Start: Boolean If set true, the specified scope includes the message
460 start line. This being the request Line in the case of a request
461 and the status line in the case of a response.
463 [The inclusion of HTTP headers in the authentication scope was
464 considered but rejected as unnecessarily complex. At the very least
465 headers would have to be duplicated. This does however have the
466 unfortunate side effect of leaving the content meta-data outside the
467 authentication scope. Perhaps there is a way that this could be
468 finessed. For example a content-metadata option?]
470 2.1.5. Replay Attack Prevention
472 Three mechanisms for preventing message replay attacks are defined.
474 Nonce: Boolean Challenge response mechanisms are supported by the
475 nnonce and cnnonce attributes. The challenger specifies a new
476 nonce using the nnonce attribute which the responder MUST use to
477 calculate the authentication value. In the case that the nonce
478 value to be used cannot be determined by the context, an
479 authentication protocol MAY require the reponder to return the
480 value of the challenge nonce using the rnonce attribute.
482 This approach provides a very high degree of protection but is
483 limited to sequential protocols in which there is only one
484 exchange in progress at the same time.
486 Counter: Boolean Counter based mechanisms are supported by the count
487 attribute. The value of a counter MUST increase for successive
488 transactions within the same transaction stream. Concurrency MAY
489 be supported by specifying multiple streams but this requires a
490 separate counter state to be maintained for each transaction
491 stream.
493 Time: Boolean Time based approaches are supported by the time
494 attribute. If the value of the time attribute falls within the
495 permitted acceptance window, the message MAY be accepted.
496 Otherwise the message MUST be rejected.
498 Using a time based approach avoids the need to maintain state at
499 either the client or server. The principal disadvantage of this
500 approach being that the mechanism only protects against a replay
501 attack within a specific time.
503 Another disadvantage to the time based approach is that it relies
504 on the sender and receiver maintaining a tollerably close time
505 synchronization over the duration of the transaction and for the
506 latency introduced by the communication path being tollerably
507 small.
509 2.1.6. Direction
510 A session MAY be defined to apply to requests only, responses only or
511 to both requests and responses.
513 Request: Boolean This session context applies to requests.
515 Response: Boolean This session context applies to responses.
517 2.1.7. TLS Binding (Fixed)
519 The TLS binding attribute specifies whether TLS channel binding is to
520 be used.
522 2.1.8. Domain: String
524 The DNS Domain(s) to which the session context applies. The syntax
525 and semantics of the Domain attribute are identical to those of the
526 Domain attribute of the Cookie header defined in [].
528 2.2. Session Context State Attributes
530 2.2.1. Expiry time: Max-Age
532 The time at which the session expires. To avoid the need for the
533 client or server to have access to a realtime clock, Set-Session and
534 Session headers specify the expiry time as the remaining lifetime of
535 the session from the instant the header is generated in seconds.
537 A server MAY update the value Max-Age value to extend the lifetime of
538 the session before expiry by specifying a new value for Max-Age in
539 the Session header.
541 2.2.2. Now: Time Offset (Time)
543 The Time Offset value is used to calculate the value of the Now
544 attribute in the session header and is only required when the Time
545 replay protection mechanism is in use.
547 To avoid the need for clients or servers to have access to a
548 reference time source, time values used to protect against replay
549 attack are specified relative to an arbitrary epoch start time
550 specified by the server. The Time Offset value is the difference
551 between the time epoch specified by the server and the local time
552 according to the machine. A server MAY use the same epoch start time
553 for all clients or use a different epoch for each one.
555 2.2.2.1. Now: Last Now (Time)
556 If the local clock at the client runs faster or slower than that of
557 the server, a timing discrepancy emerges over time. A client SHOULD
558 and a server MAY correct for such inaccuracies by noting the value of
559 the now attribute specified by the other party and adjusting the
560 local time offset value accordingly provided that the mechanism
561 employed to do so ensures that the values of the now attribute in a
562 HTTP message is never less than the value specified in a previous
563 header.
565 Recording the value of the last value of Now specified in a header
566 permits this condition to be met.
568 2.2.3. Count: Last Count (Count)
570 If counter based replay attack prevention is in use the client and
571 server MUST maintain a record of the last value of the counter for
572 each concurrent stream active within the session.
574 2.2.4. Nonce: Last Nonce (Nonce)
576 If nonce based replay attack prevention is in use, the parties MUST
577 maintain a record of the last nonce value so as to be able to return
578 it when necessary.
580 In most circumstances the nonce value is used immediately and need
581 not be stored.
583 3. Syntax
585 3.1. Accept-Session Header
587 The Accept-Session header is used to negotiate the establishment of
588 an authentication context. When used in a request the Accept-Session
589 header specifies a set of acceptable parameters for the session
590 context.
592 MAC=[Label(,Label)*] The message authentication algorithms the
593 client is willing to support.
595 Content=[Optional | Required] Offers or requires the inclusion of
596 the message content in the authentication scope.
598 ContentDigest=[Optional | Required] Offers or requires the inclusion
599 of the message content by means of a content digest in the
600 authentication scope.
602 Start=[Optional | Required] Offers or requires the inclusion of the
603 message start line in the authentication scope.
605 Request=[Optional | Required] Offers or requires the use of a
606 Session header in a request message.
608 Response=[Optional | Required] Offers or requires the use of a
609 Session header in a response message.
611 TLSBinging=[Optional | Required] Offers or requires the use of TLS
612 Binding [Need to think this through further]
614 Nonce=[Optional | Required] Offers or requires the use of the nonce
615 replay attack prevention mechanism.
617 Counter=[Optional | Required] Offers or requires the use of the
618 counter replay attack prevention mechanism.
620 Time=[Optional | Required] Offers or requires the use of the time
621 replay attack prevention mechanism.
623 When used by the client to offer the use of an authentication
624 session, all header attributes are optional. Note however that even
625 though it is permissable for a client to offer an empty Accept-
626 Session header, doing so does not allow a valid session context to be
627 established as the server is required to specify at least an
628 authentication scope and MAC algorithm from amongst those offered by
629 the client.
631 3.2. Set-Session Header
633 Id=[base64(value)] The session context identifier as in base64
634 encoding.
636 Key=[base64(value)] The cryptographic key to be used to calculate
637 the authentication value in base64 encoding.
639 MAC=[Label] The message authentication algorithm to be used to
640 calculate the authentication value as defined in [IANA TBS].
642 Content Specifies the inclusion of the message content in the
643 authentication scope.
645 ContentDigest Specifies the inclusion of the message content by
646 means of a content digest in the authentication scope.
648 Start Specifies the inclusion of the message start line in the
649 authentication scope.
651 Request Specifies the use of a Session header in a request message.
653 Response Specifies the use of a Session header in a response
654 message.
656 TLSBinging Specifies the use of TLS Binding [Need to think this
657 through further]
659 Nonce Specifies the use of the nonce replay attack prevention
660 mechanism.
662 Counter Specifies the use of the counter replay attack prevention
663 mechanism.
665 Time Specifies the use of the time replay attack prevention
666 mechanism.
668 A Set-Session header MUST contain the following elements:
670 Id
672 Key
674 MAC
676 At least one Scope attribute offered by the client
678 At least one direction attribute
680 A Max-Age value
682 3.3. Session Header
684 The Session header has the tag 'Session' and takes a sequence of
685 attribute values as follows:
687 [Insert ABNF here]
689 3.3.1. Required Attributes
691 3.3.1.1. Attribute Value=[base64(value)] (required)
693 The value attribute specifies the value resulting from applying the
694 authentication context and nonce (if present) to the specified scope.
696 3.3.1.2. Replay Attack Prevention Attributes
698 Three means of protection against replay attack are supported:
700 An authentication protocol MAY employ multiple replay attack
701 protection schemes within the same exchange. For example a time
702 based approach MAY be employed to perform an initial check before
703 retreiving the state information needed to validate a Counter or
704 Challenge Response based mechanism.
706 3.3.1.2.1. Attribute nnonce=[base64(value)], rnonce=[base64(value)]
708 The nnonce and rnonce attributes specify a nonce value to be used in
709 combination with a challenge-response mechanism defined by the
710 specified authentication context. The nnonce attribute is used to
711 specify a new nonce value, the rnonce attribute is used to specify a
712 returned nonce value.
714 3.3.1.2.2. Attribute count=[hex(stream),hex(count)]
716 Specifies a stream identifier and a count value that MUST increase
717 monotonically for successive messages with the same identifier. The
718 stream and count values are specified as hexadecimal encoded positive
719 integers.
721 3.3.1.2.2.1. Attribute time=[value]
723 Specifies a time value to be used in combination with the specified
724 authentication context. The format of the time value is determined
725 by the authentication context.
727 3.3.2. TLS Channel Binding Attributes
729 TLS channel binding is used to ensure that the HTTP session is
730 protected by TLS and to prevent man in the middle attacks against
731 TLS.
733 3.3.2.1. Attribute tlsu=[value]
735 Specifies the TLS unique channel binding as specified in [RFC5929].
737 3.3.2.2. Attribute tlss=[value]
739 Specifies the TLS server end point channel binding as specified in
740 [RFC5929].
742 3.3.3. Preparing the Input to the Authentication Algorithm
744 [Should specify how the content scope is assembles and how the replay
745 attack attributes are included within it.]
747 4. Processing
749 4.1. Calculating the Authentication Value
751 The input to the MAC algorithm is the concatenation of the following
752 values.
754 The Start Line Is included if and only if the value of the start
755 attribute of the session context is true.
757 The Canonical HTTP Headers Are always included.
759 The Message Content Is included if and only if the value of the
760 content attribute of the session context is true.
762 4.1.1. Start line
764 The Start line is the HTTP start line including the final CRLF.
766 Example:
768 4.1.2. Canonical Headers
770 The canonical form of the header(s) specified for inclusion in the
771 authentication scope by the session context sorted into alphabetical
772 order. At present only the Session header is specified and MUST
773 always be included.
775 The canonical Session header contains all the attributes of the
776 Session header to be added to the HTTP message with the exception of
777 the Value attribute. Attributes MUST be specified in alphabetical
778 order.
780 Example:
782 4.1.3. Message Content
784 If the Content-Digest parameter of the session context is empty the
785 Message content value is the actual value of the message content
786 ignoring any transfer encoding but after any content-encoding has
787 taken place.
789 If the Content-Digest parameter of the session context specifies at
790 least one Message Digest algorithm, the sender MAY chose to calculate
791 the authentication value over the actual value of the content as
792 specified above or first apply one of the specified message digest
793 algorithms to the actual value of the message content as specified
794 above and then calculate the authentication value over the resulting
795 digest value.
797 Example:
799 4.2. Generating a Session Header
801 Generating a Session Header requires the following steps to be
802 performed:
804 The Session header parameters are calculated according to the
805 session context.
807 If necessary, the session context is updated to reflect new values
808 of relevant replay attack prevention attributes.
810 The authentication value is calculated over the specified scope.
812 The Session header is added to the HTTP headers.
814 4.3. Authenticating a HTTP Message under a Session Context
816 This is the opposite of generating.
818 5. Security Considerations
820 5.1. Data outside the specified scope is not authenticated
822 The integrity check only extends to the portions of the message that
823 are within the specified scope.
825 5.2. Truncated Hash Algorithms
827 If the authentication context permits the use of a truncated MAC, it
828 MUST specify the minimum length of the MAC after truncation and
829 verifiers MUST reject MAC values shorter than that length as invalid.
831 5.3. Randomness of Secret Keys and nonces
833 The security of any cryptographic protocol relies on the difficulty
834 of guessing secret keys. Secret keys and nonces SHOULD be generated
835 using a mechanism that ensures that the range of possible values is
836 sufficiently large to prevent 'brute force' guessing attacks. For
837 more information see [RFC4086].
839 5.4. Weak Ciphers
841 Specification of the cryptographic algorithms used to construct the
842 Integrity header value is implicit in the authentication context
843 identifier and thus outside the scope of this specification.
845 6. IANA Considerations
847 Add the 'Session' and 'Set-Session' headers to the list of
848 provisional HTTP headers.
850 [Upgrade if/when this becomes an RFC]
852 Create a registry for Session Header attributes. The initial
853 contents of the registry to be:
855 [Stuff from rest of document.]
857 7. References
859 7.1. Normative References
861 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
862 Requirement Levels", BCP 14, RFC 2119, March 1997.
864 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
865 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
866 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
868 [RFC2965] Kristol, D. M. and L. Montulli, "HTTP State Management
869 Mechanism", RFC 2965, October 2000.
871 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness
872 Requirements for Security", BCP 106, RFC 4086, June 2005.
874 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
875 (TLS) Protocol Version 1.2", RFC 5246, August 2008.
877 [RFC5929] Altman, J., Williams, N., and L. Zhu, "Channel Bindings
878 for TLS", RFC 5929, July 2010.
880 7.2. Non Normative References
882 [RFC3275] Eastlake, D., Reagle, J., and D. Solo, "(Extensible Markup
883 Language) XML-Signature Syntax and Processing", RFC 3275,
884 March 2002.
886 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
887 Kerberos Network Authentication Service (V5)", RFC 4120,
888 July 2005.
890 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
891 RFC 5652, September 2009.
893 [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265,
894 April 2011.
896 Author's Address
898 Phillip Hallam-Baker
899 Comodo Group Inc.
901 Email: philliph@comodo.com