idnits 2.17.1
draft-hallambaker-httpsession-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 :
----------------------------------------------------------------------------
** There are 5 instances of too long lines in the document, the longest one
being 14 characters in excess of 72.
== There are 1 instance of lines with non-RFC2606-compliant FQDNs in the
document.
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 (May 14, 2013) is 4000 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 909, but not defined
== Missing Reference: 'BEAST' is mentioned on line 907, but not defined
== Missing Reference: 'TBS' is mentioned on line 325, but not defined
== Missing Reference: 'RFC3275' is mentioned on line 911, but not defined
== Missing Reference: 'RFC4120' is mentioned on line 915, but not defined
== Missing Reference: 'RFC5652' is mentioned on line 919, but not defined
== Missing Reference: 'RFC6265' is mentioned on line 922, but not defined
== Unused Reference: 'RFC2119' is defined on line 879, but no explicit
reference was found in the text
== Unused Reference: 'RFC2965' is defined on line 886, but no explicit
reference was found in the text
== Unused Reference: 'RFC5246' is defined on line 895, but no explicit
reference was found in the text
** Downref: Normative reference to an Informational RFC: RFC 2104
** 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)
** Downref: Normative reference to an Informational RFC: RFC 4493
** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446)
Summary: 6 errors (**), 0 flaws (~~), 13 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 May 14, 2013
5 Expires: November 15, 2013
7 HTTP Session Management
8 draft-hallambaker-httpsession-01
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 November 15, 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 . . . . . . . . . . . . . . . . . . . 7
64 2. Session Context . . . . . . . . . . . . . . . . . . . . . . . 8
65 2.1. Fixed Session Context . . . . . . . . . . . . . . . . . . 8
66 2.1.1. Id: Identifier . . . . . . . . . . . . . . . . . . . 8
67 2.1.2. MAC: Message Authentication Code Algorithm . . . . . 9
68 2.1.3. Key: Authentication Key . . . . . . . . . . . . . . . 9
69 2.1.4. Scope Attributes . . . . . . . . . . . . . . . . . . 9
70 2.1.5. Replay Attacks . . . . . . . . . . . . . . . . . . . 10
71 2.1.5.1. Request Replay Attack . . . . . . . . . . . . . . 10
72 2.1.5.2. Response Replay Attack . . . . . . . . . . . . . 11
73 2.1.6. Direction . . . . . . . . . . . . . . . . . . . . . . 11
74 2.1.7. TLS Binding (Fixed) . . . . . . . . . . . . . . . . . 11
75 2.1.8. Domain: String . . . . . . . . . . . . . . . . . . . 11
76 2.2. Session Context State Attributes . . . . . . . . . . . . 12
77 2.2.1. Expiry time: Max-Age . . . . . . . . . . . . . . . . 12
78 2.2.2. Now: Time Offset (Time) . . . . . . . . . . . . . . . 12
79 2.2.2.1. Now: Last Now (Time) . . . . . . . . . . . . . . 12
80 2.2.3. Count: Last Count (Count) . . . . . . . . . . . . . . 12
81 2.2.4. Nonce: Last Nonce (Nonce) . . . . . . . . . . . . . . 13
82 3. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
83 3.1. Accept-Session Header . . . . . . . . . . . . . . . . . . 13
84 3.2. Set-Session Header . . . . . . . . . . . . . . . . . . . 14
85 3.3. Session Header . . . . . . . . . . . . . . . . . . . . . 15
86 3.3.1. Value=[Binary] (required) . . . . . . . . . . . . . . 16
87 3.3.2. Nonce=[Binary] . . . . . . . . . . . . . . . . . . . 16
88 3.3.3. Stream=[Decimal] . . . . . . . . . . . . . . . . . . 16
89 3.3.3.1. Count=[Decimal] . . . . . . . . . . . . . . . . . 16
90 3.3.3.2. Time=[NTime] . . . . . . . . . . . . . . . . . . 16
91 3.3.3.3. Attribute tlsu=[value] . . . . . . . . . . . . . 16
92 3.3.3.4. Attribute tlss=[value] . . . . . . . . . . . . . 16
93 3.3.4. Preparing the Input to the Authentication Algorithm . 16
94 4. Processing . . . . . . . . . . . . . . . . . . . . . . . . . 17
95 4.1. Calculating the Authentication Value . . . . . . . . . . 17
96 4.1.1. Start line . . . . . . . . . . . . . . . . . . . . . 17
97 4.1.2. Canonical Headers . . . . . . . . . . . . . . . . . . 17
98 4.1.3. Message Content . . . . . . . . . . . . . . . . . . . 17
99 4.2. Generating a Session Header . . . . . . . . . . . . . . . 18
100 4.3. Verifying a HTTP Message under a Session Context . . . . 18
101 5. Security Considerations . . . . . . . . . . . . . . . . . . . 18
102 5.1. Data outside the specified scope is not authenticated . . 18
103 5.2. Truncated Hash Algorithms . . . . . . . . . . . . . . . . 18
104 5.3. Randomness of Secret Keys and nonces . . . . . . . . . . 18
105 5.4. Weak Ciphers . . . . . . . . . . . . . . . . . . . . . . 19
106 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
107 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
108 7.1. Normative References . . . . . . . . . . . . . . . . . . 19
109 7.2. Non Normative References . . . . . . . . . . . . . . . . 20
110 Appendix A. Session Identifier Encoding . . . . . . . . . . . . 20
111 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 20
113 1. Introduction
115 The HTTP State Management Mechanism 'Cookies'[RFC6265] was intended
116 to allow HTTP [RFC2616] servers to let servers maintain a stateful
117 session over the mostly stateless HTTP protocol. While the exchange
118 of static tokens is an acceptable mechanism for maintaining state,
119 use of static tokens as bearer tokens for authentication is not.
120 Such tokens are not bound to any part of the message they purport to
121 authenticate and may be disclosed to intermediaries including HTTP
122 proxies and caches.
124 While use of TLS transport provides a confidentiality enhancement for
125 HTTP content, recent research [CRIME], [BEAST] demonstrates that
126 relying on a transport or network layer to protect the
127 confidentiality of a bearer authentication token is fundamentaly
128 unsound. The interaction of HTTP header compression mechanisms and a
129 Turing complete active code mechanism under control of the attacker
130 produces a threat model in which the capabilities afforded the
131 attacker far exceed the capabilities that it is sensible to expect a
132 protocol design to resist.
134 The HTTP Accept-Session, Set-Session and Session headers provide a
135 simple and effective means of maintaining a HTTP authentication
136 session without passing static authentication data in either
137 direction after the authentication session has been established. The
138 design of the Set-Session and Session headers permit them to be used
139 as a replacement for the Set-Cookie and Cookie headers in situations
140 where they are supported by both the client and the server and ensure
141 correct behavior by intermediaries conformant to the HTTP
142 specification.
144 A HTTP authentication session MAY be established inband by means of
145 the Set-Session header. The Set-Session header specifies a unique
146 identifier for the session and determines the session parameters
147 including the cryptographic algorithm and shared key.
149 Applications SHOULD make use of cryptographic enhancements to protect
150 the confidentiality of a session context established using the Set-
151 Session header.
153 Clients and Servers MAY support other means of establishing a HTTP
154 authentication session. For example in a federated authentication
155 scheme such as SAML, Kerberos or OpenID, the authentication session
156 might be provided by a third party.
158 Once the HTTP authentication session is established, a Session header
159 is added to HTTP requests and/or responses as directed by the session
160 context. The session header specifies the session identifier and an
161 authentication value calculated over portions of the HTTP message and
162 other attributes to which it is bound as directed by the
163 corresponding session context. The bound attributes and portions of
164 the HTTP message cannot then be changed without invalidating the
165 authentication value.
167 The use of bound attributes permits protection against TLS channel
168 rebinding and/or HTTP message replay attacks.
170 The portions of a HTTP message to which it is desirable to bind an
171 authentication session depend on the situation. Binding the
172 authentication session to the message content prevents modification
173 of the content but imposes more constraints on implementations than
174 binding to the message start line. Interactions with intermediaries
175 and in particular intermediarries that are not fully compliant with
176 the HTTP specification also raise concerns Web browsers are typically
177 coded to be tollerant of such implementation defects and operate
178 despite unauthorized modification of content by caches and other
179 intermediaries. The prefered behavior of a Web Service client in
180 such situations is likely to be to abort the transaction rather than
181 risk continuing with corrupted data.
183 1.1. Relationship to Other Authentication Technologies
185 The term 'user authentication' is commonly used in three separate
186 contexts; credential management, credential presentation and session
187 continuation:
189 Credential Management describes the means by which credentials are
190 created, issued and revoked.
192 Credential Presentation describes the means by which a party
193 demonstrates holdership of a credential to establish an
194 authentication session.
196 Session Continuation describes the means by which a party
197 demonstrates that a particular transaction is taking place within
198 the context of a particular authentication session.
200 The HTTP Session Management Mechanism is designed to support only
201 Session Continuation and to compliment existing and future mechanisms
202 for Credential management and Credential Presentation. While a
203 session continuation mechanism is not in itself a solution to the
204 problem of user authentication, the provision of a robust session
205 continuation mechanism that does not depend on a bearer token
206 addresses the most challenging problem facing the designers of SAML,
207 OpenID and OAUTH.
209 1.2. Example: Web Browser User Authentication
211 The principal mechanism for user authentication in use today is to
212 present a HTML form in which the user enters their username and
213 password.
215 This approach has many known defects that are outside the scope of
216 this document. These include the risk of impersonation of the Web
217 site causing the user to enter their username and password into a
218 form controlled by the attack and the strong likelihood that the user
219 will use the same password across multiple sites.
221 The client indicates that it supports the session header by including
222 one or more Accept-Session headers in the request transfering the
223 username and password values. The Accept-Session header specifies
224 the scope and replay binding options that the client offers to
225 support.
227 [NB: These examples are not yet generated from running code and are
228 for illustrative purposes only]
230 POST /login.php HTTP/1.1
231 Host: example.com
232 Cache-Control: no-store
233 Content-Type: application/x-www-form-urlencoded
234 Content-Length: 29
235 Accept-Session: Start=required Request=required Content=optional Time=required
237 username=skroob&password=1234
238 If the browser does not specify a Accept-Session header the server
239 MAY reject the connection request entirely or fallback to the
240 traditional Cookie mechanism as determined by site policy.
242 If the service accepts the offer of session management support, it
243 includes a Set-session Header in the response specifying the session
244 context:
246 HTTP/1.1 201 OK
247 Content-Length: 35
248 Set-Session:
249 Id=TUMnorO0SjHHS7D2uFcGlRYJ0Hd3eibwe0ogptoNMQuCYmCHfHAJcJlyvi
250 j8WoXDglTSOkctnmoBzl8W0NLSlcgSyZcmsAyoWs8y1Rn2ZlO2WBgoWrFIOqPa4
251 oB29dgs/ei6ieINZtmvXNCm2NUkWA==
252 Key=7eb219188339135ba51e8715f3900bfb974995e145d6e490e4addbbdb26f4bb4
253 Alg=HMAC-SHA256 Start=True Request=True Time=True Now=745531 Domain=example.com
254 Max-Age=31536000
256
Authenticated
258 In this case the server avoids the need to track per client state by
259 using a time based mechanism to avoid replay attacks and storing the
260 state associated with the client session as encrypted data within the
261 session identifier. The scope of the content binding is limited to
262 the start line and the timer to be used for replay attack prevention
263 has an offset 745531 seconds in the past.
265 Once the session has been established, the client MUST include a
266 Session header in subsequent HTTP requests made to the specified DNS
267 domains.
269 GET /status.php HTTP/1.1
270 Host: example.com
271 Cache-Control: no-store
272 Content-Type: application/x-www-form-urlencoded
273 Content-Length: 29
274 Session: Id=TUMnorO0SjHHS7D2uFcGlRYJ0Hd3eibwe0ogptoNMQuCYmCHfHAJcJlyvi
275 j8WoXDglTSOkctnmoBzl8W0NLSlcgSyZcmsAyoWs8y1Rn2ZlO2WBgoWrFIOqPa4
276 oB29dgs/ei6ieINZtmvXNCm2NUkWA==
277 Value=cjkMkfnnYP8JYWZAbRLvtpqImmOK3rsrOT1XcvAgHDk=;
278 Now=745533
280 In this case the session scope does not specify responses and so the
281 response does not require an Session header but a server MAY provide
282 one so as to specify updated values for the replay attack prevention
283 attributes Now and/or Count. Whenever a Session header is present
284 the Id and Value attributes MUST be specified and correct:
286 HTTP/1.1 201 OK
287 Content-Length: 35
288 Session:
289 Id=TUMnorO0SjHHS7D2uFcGlRYJ0Hd3eibwe0ogptoNMQuCYmCHfHAJcJlyvi
290 j8WoXDglTSOkctnmoBzl8W0NLSlcgSyZcmsAyoWs8y1Rn2ZlO2WBgoWrFIOqPa4
291 oB29dgs/ei6ieINZtmvXNCm2NUkWA==
292 Value=cjkMkfnnYP8JYWZAbRLvtpqImmOK3rsrOT1XcvAgHDk=;
293 Now=745532
295 Shield is Closed
297 In this particular instance the clock at the server is running behind
298 that of the client requiring the timer offset value to be decreased
299 by one second. To ensure that the replay attack protection values
300 only increase or stay the same, the client uses the last value of the
301 old time offset until the new time offset value has superceded it.
303 The Web Browser MAY terminate the session by simply deleting the
304 session context information from its store preventing reuse. A
305 client MAY inform the server that the session context is about to be
306 deleted by including a Session header with the Deleted attribute:
308 HEAD /status.php HTTP/1.1
309 Host: example.com
310 Session: Id=TUMnorO0SjHHS7D2uFcGlRYJ0Hd3eibwe0ogptoNMQuCYmCHfHAJcJlyvi
311 j8WoXDglTSOkctnmoBzl8W0NLSlcgSyZcmsAyoWs8y1Rn2ZlO2WBgoWrFIOqPa4
312 oB29dgs/ei6ieINZtmvXNCm2NUkWA==
313 Value=cjkMkfnnYP8JYWZAbRLvtpqImmOK3rsrOT1XcvAgHDk=;
314 Deleted
316 A server may inform the client that the session has been terminated
317 by including a Session header with the Deleted attribute in the
318 response.
320 1.3. Use in Web Services
322 Use of HTTP Session Managment simplifies implemenatation of Web
323 Services. Using the SOAP [TBS] approach a Web Service message is
324 encoded in XML [TBS], wrapped in a SOAP envelope and a WS-Security
325 [TBS] header with an XML Signature [TBS] attached. The whole package
326 is then attached to a HTTP message as a content payload.
328 This approach involves a considerable degree of complexity and in
329 most cases does nothing more than attach authentication data to a
330 message. Carrying the authentication value as a HTTP header
331 typically eliminates the need for the SOAP and WS-Security layers
332 entirely.
334 Use of session management in Web Services presents different
335 requirements and constraints. In the case of an entirely new Web
336 Service with no deployment history, there is no need to consider
337 support for legacy code at all, eliminating one of the principal
338 constraints governing use of new HTTP protocol features in Web
339 Browsers.
341 A single HTTP message MAY have multiple Session headers. This
342 facilitates support for multi-party transactions in which A submits a
343 transaction to B who countersigns it and passes it to C who is
344 required to chek that she has proof of agreement by both A and B.
346 Use of the Session header permits the developer to isolate integrity
347 and authentication checks to a single point of control, as is advised
348 by best security practice. The security monitor examines a HTTP
349 message, verifies that the required integrity data is present and
350 correct and only passes the payload on for processing by the Web
351 Service itself if and only if the verification checks have been
352 passed.
354 2. Session Context
356 The processing of the Session header is determined by the session
357 context which consists of a set of fixed attributes that remain
358 constant for the lifetime of the session and state attributes that
359 are updated as Session headers are generated and verified.
361 2.1. Fixed Session Context
363 The fixed session context elements are set when the session is
364 established and remain constant for the lifetime of the session. The
365 values specified can only be changed by establishing a new session
366 which MUST have a different session identifier.
368 2.1.1. Id: Identifier
370 The session identifier is a statistically unique sequence of binary
371 data which SHOULD be unique, MUST be statistically unique, SHOULD be
372 less than 512 octets in length and MUST NOT be longer than 4096
373 octets in length.
375 Servers MAY avoid the need to maintain per-session server side state
376 by encoding the some or all of the fixed session context parameters
377 in to the identifier. Servers MUST ensure that appropriate
378 cryptographic enhancements are employed to authenticate the sessikon
379 context and protect the confidentiality of the authentication key.
380 The scheme used to construct the session identifiers used in the
381 examples is described in Appendix A
383 2.1.2. MAC: Message Authentication Code Algorithm
385 The message authentication algorithm to be used to calculate the
386 authentication value.
388 HMAC construction [RFC2104]
390 HMAC-SHA256-128 HMAC using the SHA-1 algorithm with the output
391 truncated to the first 64 bits.
393 HMAC-SHA512-256 HMAC using the SHA-1 algorithm with the output
394 truncated to the first 256 bits.
396 HMAC-SHA2-256-128 HMAC using the SHA-2 algorithm with the output
397 truncated to the first 128 bits.
399 HMAC-SHA2-512-256 HMAC using the SHA-2 algorithm with the output
400 truncated to the first 256 bits.
402 CMAC Construction [RFC4493]
404 CMAC-AES128-64 The AES algorithm employed in CMAC mode with a 128
405 bit key and the output truncated to the first 64 bits.
407 CMAC-AES128 The AES algorithm employed in CMAC mode with a 128 bit
408 key and the entire output.
410 2.1.3. Key: Authentication Key
412 The cryptographic key to be used to calculate the authentication
413 value.
415 2.1.4. Scope Attributes
417 The scope attributes specify which parts of the message are
418 authenticated.
420 The scope is specified by the start, header and content attributes.
421 The order in which the scope attributes are specified in the HTTP
422 Set-Session header is immaterial. The scope is always constructed in
423 the same order as the elements occur in a HTTP message, i.e. start,
424 dummy headers and content.
426 Content: Boolean If set true, the specified scope includes the
427 message body. The content transfer encoding (e.g. chunked) is
428 ignored for the purpose of determining the content.
430 ContentDigest: Label If a message digest algorithm is specified the
431 authentication scope MAY be calculated indirectly by first
432 calculating a Message Digest value over the content and using the
433 resulting value in place of the actual content value to calculate
434 the Message Authentication Code value.
436 Start: Boolean If set true, the specified scope includes the message
437 start line. This being the request Line in the case of a request
438 and the status line in the case of a response.
440 2.1.5. Replay Attacks
442 Preventing replay attacks in HTTP requests and responses poses
443 considerably different challenges. Since a HTTP response is always
444 immediately preceded by a request, return of a request nonce is
445 sufficient to prevent a response replay attack. This approach is
446 stateless and does not require client or server to store state
447 information.
449 Since the HTTP protocol requires that certain methods be idempotent,
450 the HTTP protocol does not lend itself to preventing request replay
451 attacks in the same fashion. Request replay MAY be prevented by use
452 of counter techniques or mitigated by limiting request replay to a
453 particular time window.
455 2.1.5.1. Request Replay Attack
457 Two mechanisms for preventing or mitigating request replay attacks
458 are specified:
460 Counter: Boolean Counter based mechanisms are supported by the count
461 attribute. The value of a counter MUST increase for successive
462 transactions within the same transaction stream. Concurrency MAY
463 be supported by specifying multiple streams but this requires a
464 separate counter state to be maintained for each transaction
465 stream.
467 Time: Boolean Time based approaches are supported by the time
468 attribute. If the value of the time attribute falls within the
469 permitted acceptance window, the message MAY be accepted.
470 Otherwise the message MUST be rejected.
472 Using a time based approach avoids the need to maintain state at
473 either the client or server. The principal disadvantage of this
474 approach being that the mechanism only protects against a replay
475 attack within a specific time.
477 Another disadvantage to the time based approach is that it relies
478 on the sender and receiver maintaining a tollerably close time
479 synchronization over the duration of the transaction and for the
480 latency introduced by the communication path being tollerably
481 small.
483 Neither method is entirely satisfactory. The counter mechanism
484 requires that the client and server both maintain state and the time
485 based mechanism only prevents request replay attack outside a
486 specified time interval.
488 For Web Services that require a stronger assurance that request
489 replay attack cannot succeed (e.g. payment transactions) without
490 maintaining server side state, such controls should be provided by
491 the Web Service protocol rather than relying on the HTTP session
492 continuation mechanism. For example, the Web Services protocol might
493 define a two phase interaction in which the client requested a server
494 nonce in the first phase to be returned in the second phase.
496 2.1.5.2. Response Replay Attack
498 If a HTTP Session header in a request specifies a nonce value, the
499 corresponding Session header in the response (if present) MUST
500 specify the same nonce value.
502 2.1.6. Direction
504 A session MAY be defined to apply to requests only, responses only or
505 to both requests and responses.
507 Request: Boolean This session context applies to requests.
509 Response: Boolean This session context applies to responses.
511 2.1.7. TLS Binding (Fixed)
513 The TLS binding attribute specifies whether TLS channel binding is to
514 be used.
516 2.1.8. Domain: String
517 The DNS Domain(s) to which the session context applies. The syntax
518 and semantics of the Domain attribute are identical to those of the
519 Domain attribute of the Cookie header defined in [].
521 2.2. Session Context State Attributes
523 2.2.1. Expiry time: Max-Age
525 The time at which the session expires. To avoid the need for the
526 client or server to have access to a realtime clock, Set-Session and
527 Session headers specify the expiry time as the remaining lifetime of
528 the session from the instant the header is generated in seconds.
530 A server MAY update the value Max-Age value to extend the lifetime of
531 the session before expiry by specifying a new value for Max-Age in
532 the Session header.
534 2.2.2. Now: Time Offset (Time)
536 The Time Offset value is used to calculate the value of the Now
537 attribute in the session header and is only required when the Time
538 replay protection mechanism is in use.
540 To avoid the need for clients or servers to have access to a
541 reference time source, time values used to protect against replay
542 attack are specified relative to an arbitrary epoch start time
543 specified by the server. The Time Offset value is the difference
544 between the time epoch specified by the server and the local time
545 according to the machine. A server MAY use the same epoch start time
546 for all clients or use a different epoch for each one.
548 2.2.2.1. Now: Last Now (Time)
550 If the local clock at the client runs faster or slower than that of
551 the server, a timing discrepancy emerges over time. A client SHOULD
552 and a server MAY correct for such inaccuracies by noting the value of
553 the now attribute specified by the other party and adjusting the
554 local time offset value accordingly provided that the mechanism
555 employed to do so ensures that the values of the now attribute in a
556 HTTP message is never less than the value specified in a previous
557 header.
559 Recording the value of the last value of Now specified in a header
560 permits this condition to be met.
562 2.2.3. Count: Last Count (Count)
563 If counter based replay attack prevention is in use the client and
564 server MUST maintain a record of the last value of the counter for
565 each concurrent stream active within the session.
567 2.2.4. Nonce: Last Nonce (Nonce)
569 If nonce based replay attack prevention is in use, the parties MUST
570 maintain a record of the last nonce value so as to be able to return
571 it when necessary.
573 In most circumstances the nonce value is used immediately and need
574 not be stored.
576 3. Syntax
578 The Accept-Session, Set-Session and Session headers use the following
579 common syntax elements
581 Label [ alpha (alpha | '-')* ]
583 Binary [Base 64 encoding of a binary value]
585 Offer [ "Optional" | "Required" | "Refused" ]
587 DTime [Decimal time value from current time]
589 Decimal [Decimal numeric value]
591 3.1. Accept-Session Header
593 The Accept-Session header is used to negotiate the establishment of
594 an authentication context. When used in a request the Accept-Session
595 header specifies a set of acceptable parameters for the session
596 context.
598 MAC=[Label(,Label)*] The message authentication algorithms the
599 client is willing to support.
601 Content=[Offer] Offers or requires the inclusion of the message
602 content in the authentication scope.
604 ContentDigest=[Offer] Offers or requires the inclusion of the
605 message content by means of a content digest in the authentication
606 scope.
608 Start=[Offer] Offers or requires the inclusion of the message start
609 line in the authentication scope.
611 Request=[Offer] Offers or requires the use of a Session header in a
612 request message.
614 Response=[Offer] Offers or requires the use of a Session header in a
615 response message.
617 TLSU=[Offer] Offers or requires the use of tls-unique TLS chanel
618 binding as specified in [RFC5929].
620 TLSE=[Offer] Offers or requires the use of tls-server-end-point TLS
621 chanel binding as specified in [RFC5929].
623 Nonce=[Offer] Offers or requires the use of the nonce response
624 replay attack prevention mechanism.
626 Counter=[Offer] Offers or requires the use of the counter request
627 replay attack prevention mechanism.
629 Time=[Optional | Required] Offers or requires the use of the time
630 request replay attack prevention mechanism.
632 When used by the client to offer the use of an authentication
633 session, all header attributes are optional. Note however that even
634 though it is permissable for a client to offer an empty Accept-
635 Session header, doing so does not allow a valid session context to be
636 established as the server is required to specify at least an
637 authentication scope and MAC algorithm from amongst those offered by
638 the client.
640 3.2. Set-Session Header
642 The Set-Session Header is specified in a response to accept an offer
643 of using the session continuation mechanism made by specifing accept-
644 session in the corresponding request.
646 The features specified in the Set-Session header MUST be consistent
647 with the features offered in the corresponding request.
649 Id=[Binary] The session context identifier in base64 encoding.
651 Key=[Binary] The cryptographic key to be used to calculate the
652 authentication value in base64 encoding.
654 MAC=[Label] The message authentication algorithm to be used to
655 calculate the authentication value as defined in [RFC5698] .
657 Content Specifies the inclusion of the message content in the
658 authentication scope.
660 ContentDigest Specifies the inclusion of the message content by
661 means of a content digest in the authentication scope.
663 Start Specifies the inclusion of the message start line in the
664 authentication scope.
666 Request Specifies the use of a Session header in a request message.
668 Response Specifies the use of a Session header in a response
669 message.
671 TLSBinging Specifies the use of TLS Binding [Need to think this
672 through further]
674 Counter=[Decimal] Specifies the use of the counter replay attack
675 prevention mechanism. The value of the attribute specifies the
676 maximum number of permitted streams.
678 Time=[NTime] Specifies the use of the time replay attack prevention
679 mechanism and the current value of the time value in seconds.
681 Servers SHOULD NOT use a time offset from a fixed epoch (e.g. 32
682 bit UNIX epoch).
684 Max-Age=[NTime] Specifies the number of seconds in which the session
685 parameters expire measured from the time at which the request was
686 issued.
688 A Set-Session header MUST contain the following elements:
690 Id
692 Key
694 MAC
696 At least one Scope attribute offered by the client
698 At least one direction attribute
700 A Max-Age value
702 3.3. Session Header
704 The Session header has the tag 'Session' and takes a sequence of
705 attribute values as follows:
707 [Insert ABNF here]
708 The session context identifier as in base64 encoding.
710 3.3.1. Value=[Binary] (required)
712 The value attribute specifies the value resulting from applying the
713 authentication context and nonce (if present) to the specified scope.
715 3.3.2. Nonce=[Binary]
717 The nonce attribute MAY be specified in a request. If a request
718 specifies a nonce attribute, the corresponding response MUST specify
719 a nonce attribute with the same value.
721 3.3.3. Stream=[Decimal]
723 The Stream attribute MUST NOT be specified in a request unless the
724 counter attribute is specified in the session context and the value
725 of the stream count is less than the number of permitted streams.
727 3.3.3.1. Count=[Decimal]
729 The Count attribute MUST NOT be specified in a request unless the
730 counter attribute is specified in the session context. The value of
731 the count attribute MUST be greater than the value of the count
732 attribute in all previous requests under the specified session with
733 the same stream attribute.
735 3.3.3.2. Time=[NTime]
737 Specifies a time value to be used in combination with the specified
738 authentication context. The format of the time value is determined
739 by the authentication context.
741 3.3.3.3. Attribute tlsu=[value]
743 Specifies the TLS unique channel binding as specified in [RFC5929].
745 3.3.3.4. Attribute tlss=[value]
747 Specifies the TLS server end point channel binding as specified in
748 [RFC5929].
750 3.3.4. Preparing the Input to the Authentication Algorithm
752 [Should specify how the content scope is assembles and how the replay
753 attack attributes are included within it.]
755 4. Processing
757 4.1. Calculating the Authentication Value
759 The input to the MAC algorithm is the concatenation of the following
760 values.
762 The Start Line Is included if and only if the value of the start
763 attribute of the session context is true.
765 The Canonical HTTP Headers Are always included.
767 The Message Content Is included if and only if the value of the
768 content attribute of the session context is true.
770 4.1.1. Start line
772 The Start line is the HTTP start line including the final CRLF.
774 Example:
776 4.1.2. Canonical Headers
778 The canonical form of the header(s) specified for inclusion in the
779 authentication scope by the session context sorted into alphabetical
780 order. At present only the Session header is specified and MUST
781 always be included.
783 The canonical Session header contains all the attributes of the
784 Session header to be added to the HTTP message with the exception of
785 the Value attribute. Attributes MUST be specified in alphabetical
786 order.
788 Example:
790 4.1.3. Message Content
792 If the Content-Digest parameter of the session context is empty the
793 Message content value is the actual value of the message content
794 ignoring any transfer encoding but after any content-encoding has
795 taken place.
797 If the Content-Digest parameter of the session context specifies at
798 least one Message Digest algorithm, the sender MAY chose to calculate
799 the authentication value over the actual value of the content as
800 specified above or first apply one of the specified message digest
801 algorithms to the actual value of the message content as specified
802 above and then calculate the authentication value over the resulting
803 digest value.
805 Example:
807 4.2. Generating a Session Header
809 Generating a Session Header requires the following steps to be
810 performed:
812 The Session header parameters are calculated according to the
813 session context.
815 If necessary, the session context is updated to reflect new values
816 of relevant replay attack prevention attributes.
818 The authentication value is calculated over the specified scope.
820 The Session header is added to the HTTP headers.
822 4.3. Verifying a HTTP Message under a Session Context
824 Verifying messages follows the same approach as generation. The
825 verifier calculates the authentication value over the input values as
826 specified in the session context. If the resulting authentication
827 value matches that specified by the sender, the authentication
828 succeeds and fails otherwise.
830 5. Security Considerations
832 5.1. Data outside the specified scope is not authenticated
834 The integrity check only extends to the portions of the message that
835 are within the specified scope.
837 5.2. Truncated Hash Algorithms
839 If the authentication context permits the use of a truncated MAC, it
840 MUST specify the minimum length of the MAC after truncation and
841 verifiers MUST reject MAC values shorter than that length as invalid.
843 5.3. Randomness of Secret Keys and nonces
844 The security of any cryptographic protocol relies on the difficulty
845 of guessing secret keys. Secret keys and nonces SHOULD be generated
846 using a mechanism that ensures that the range of possible values is
847 sufficiently large to prevent 'brute force' guessing attacks. For
848 more information see [RFC4086].
850 5.4. Weak Ciphers
852 Specification of the cryptographic algorithms used to construct the
853 Integrity header value is implicit in the authentication context
854 identifier and thus outside the scope of this specification.
856 6. IANA Considerations
858 Add the 'Accept-Session', 'Set-Session' and 'Session' headers to the
859 list of provisional HTTP headers.
861 Add the HMAC algorithm entries to the RFC 5698 regitry http://
862 www.iana.org/assignments/dssc/dssc.xml
864 [Upgrade if/when this becomes an RFC]
866 Create a registry for Session Header attributes. The initial
867 contents of the registry to be:
869 [Stuff from rest of document.]
871 7. References
873 7.1. Normative References
875 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
876 Hashing for Message Authentication", RFC 2104, February
877 1997.
879 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
880 Requirement Levels", BCP 14, RFC 2119, March 1997.
882 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
883 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
884 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
886 [RFC2965] Kristol, D. M. and L. Montulli, "HTTP State Management
887 Mechanism", RFC 2965, October 2000.
889 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness
890 Requirements for Security", BCP 106, RFC 4086, June 2005.
892 [RFC4493] Song, JH., Poovendran, R., Lee, J., and T. Iwata, "The
893 AES-CMAC Algorithm", RFC 4493, June 2006.
895 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
896 (TLS) Protocol Version 1.2", RFC 5246, August 2008.
898 [RFC5698] Kunz, T., Okunick, S., and U. Pordesch, "Data Structure
899 for the Security Suitability of Cryptographic Algorithms
900 (DSSC)", RFC 5698, November 2009.
902 [RFC5929] Altman, J., Williams, N., and L. Zhu, "Channel Bindings
903 for TLS", RFC 5929, July 2010.
905 7.2. Non Normative References
907 [BEAST] , "TBS", , , .
909 [CRIME] , "TBS", , , .
911 [RFC3275] Eastlake, D., Reagle, J., and D. Solo, "(Extensible Markup
912 Language) XML-Signature Syntax and Processing", RFC 3275,
913 March 2002.
915 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
916 Kerberos Network Authentication Service (V5)", RFC 4120,
917 July 2005.
919 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
920 RFC 5652, September 2009.
922 [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265,
923 April 2011.
925 Appendix A. Session Identifier Encoding
927 Author's Address
929 Phillip Hallam-Baker
930 Comodo Group Inc.
932 Email: philliph@comodo.com