Client Session Phase

When a client receives the TLS protected _X-S-Armorheader from the server, it de- codes and stores the parameters for the session.

When any data is stored by the client for the purposes of a Session Armor session, it is keyed by the fully qualified domain name of the server that sent the response. Thus, unlike cookies, a subdomain may not store a Session Armor token for a parent domain. This prevents the “Cookie Stuffing” vulnerability, in which a rouge subdomain overwrites cookies for a parent domain in a malicious fashion. In doing so this enables a variant of the Session Fixation attack, and other more benign issues related to cookie overwriting, all of which are mitigated by Session Armor.

It is recommended that built-in language support is used for storing and decoding bit- vectors, as many CPU architectures feature an instruction that can be used for quickly finding the most-significant set bit in a word.

The values of _s,_IV, and_tagare each components of the opaque token containing the encrypted Session ID. They are stored by the client without modification._Khis also stored without modification.

The value of _h, the bitmask indicating which HMAC algorithm will be used for the session, is stored without modification, and may also be stored in another form such as a string or function reference. The requirement is that this value can be used by the client to quickly determine which HMAC algorithm to use for authenticating requests to a given

domain.

The values of _ah, and _eahare the bitmasks indicating which request fields are to be authenticated, and are stored without modification. They may also be stored in an un- packed fashion. The strings contained in_eahare stored unmodified as the unpacked form of_eah. The requirement here is that the client can quickly determine which fields must be authenticated by the HMAC.

If the first bit of _ahis 1 and_{n c}is not present, or if _{n c}is present and the first bit of ah is 0, then an error is thrown and the session data for this domain is discarded. This should be silent to the user, who is prompted by the server to authenticate again upon subsequent requests. Recall that these setup actions should only be performed on a secure response with a new Session ID from the server, to prevent denial of service attacks against the client. If _{n c} is present, then the first bit of _ah is checked. If it is 1, indicating that nonce- based replay preventions is to be used, then_{n c}is stored in a way that allows it to be easily retrieved and incremented on subsequent requests.

Client authentication of requests

For each request, the client computes the following HMAC. Example input to the HMAC, with output, can be seen in fig. 5.4.

c : HMAC(Kh, [n] | "+" | t | lt |

ah_val0 | [ah_val1 | ah_val2 ...] | eah_val0[, eah_val1, eah_val2 ...] | path |

request body OR "")

The value of _nis the current value of the nonce counter, included if the first bit of _ah for this session is 1.

HMAC(0x3283416f2060c83f154ea762b20559ef,2736056|+|15057731 23|1505773123|127.0.0.1|Mozilla/5.0 (Macintosh; Intel Mac OS X 10 12 5) AppleWebKit/537.36 (KHTML, like Gecko) Chr ome/52.0.2743.116 Safari/537.36|text/html,application/xhtm l+xml,application/xml;q=0.9,image/webp,*/*;q=0.8|gzip, def late, sdch, br|en-US,en;q=0.8|https://127.0.0.1:8000/login ?next=/|/|) 0x1edd6cbd9c2b76b7db7ca2f16d722d079aa3ed5bea46f3de68bef92c f5e7618ed235e728ffb972d7b0c625f7302778b98e447341a85a2caf65 4ce9918ef09b29

Figure 5.4: Example HMAC input and output, with key and output encoded in hexadecimal notation. SHA-512 is in use

The “₊” between_nand the rest of the parameters is the single character ‘₊’. It is always included. This is used to distinguish the nonce from the request expiration timestamp in the server-side implementation. That is, when absolute replay prevention is not being used, the string being authenticated begins with ‘₊’.

The value of _tis the request expiration timestamp in Unix epoch time. It is the final second for which the request is valid. The recommended value is 4 minutes after the re- quest time given the expected time-to-live of TCP traffic. The value of_ltis the Unix epoch timestamp of the time at which the last request was sent. It is used by the server to deter- mine if the session should be invalidated due to inactivity. It is included in the HMAC so that a man-in-the-middle cannot invalidate the session by setting_ltto a value far in the past.

The value of _his the HMAC algorithm bitmask, with the chosen bit set. The value of ah val0 ∣ [ah val1 ∣ ah val2 ...]are the values of the headers to be authenticated in the order of the_ahbitmask.

The value of _{eah val0[, eah val1, eah val2 ...]} are the extra headers to be authenticated, as comma separated strings, in the order of the strings included in_eah.

The value of _pathis the value of the_HTTP path being requested, e.g. _/or_/user- s/list?sort=lastname. It is always included. The value of _{request body}is the full body of the request. For example, if the request was a POST request and included post data, this would be the full post data beginning at the first byte after the_{<CR><LF><CR><LF>} sequence following the last HTTP header.

After computing the HMAC, n c is incremented by 1. The client then sends the follow- ing data to the server in an X-S-Armor header. An example of this header can be seen in encoded and un-encoded form in fig. 5.5, with fields encoded in hexadecimal and binary as appropriate.

c: Client HMAC result t: The time of the request lt: Last request time iv: Initialization vector tag: AEAD tag

h: Chosen HMAC algo bitmask ah: Authenticated headers bitmask

eah: List of extra headers to authenticate

(optional) [n]: Nonce value for replay prevention