When the server receives a client request that includes theckey in the Session Armor header, the server knows that the request is for an already established session rather than a new session. At this point, the server must validate the request.
First sis decrypted using the server secret, k, along with theIV and tag provided in the client header. During GCM mode decryption, thetag is used to authenticates automatically. This provides the server with three things: an HMAC key, a Session ID, and a Session Expiration Time.
X-S-Armor: c:0x1edd6cbd9c2b76b7db7ca2f16d722d079aa3ed5bea46 f3de68bef92cf5e7618ed235e728ffb972d7b0c625f7302778b98e447341 a85a2caf654ce9918ef09b29;t:1505773113;lt:1505773123,iv:0x59B FFC5E538F5DDF43107792;tag:0xF0852356E9B2F6463961639B349824F2 ;kh:0x3283416f2060c83f154ea762b20559ef;h:0b0000000100000100; ah:0b00000011000011010111001111101111;eah:X-Client-App-Versi on,X-Legacy-App;n:2736056 X-S-Armor: c:Ht1svZwrdrfbfKLxbXItB5qj7VvqRvPeaL75LPXnYY7SNe co/7ly17DGJfcwJ3i5jkRzQahaLK9lTOmRjvCbKQ==;t:WcBGOQ==;lt:WcB GQw==,iv:Wb/8XlOPXd9DEHeS;tag:8IUjVumy9kY5YWObNJgk8g==;kh:Mo NBbyBgyD8VTqdisgVZ7w==;h:AQQ=;ah:Aw1z7w==;eah:WC1DbGllbnQtQX BwLVZlcnNpb24sWC1MZWdhY3ktQXBw;n:Kb+4
Figure 5.5: Client header for one request in un-encoded and base64 notation
The value of t, the Session Expiration Time, is immediately compared against the cur- rent time to determine if the session has expired. If it has, the request should continue to be processed by the application with no Session ID attached. This treats the request as unauthenticated for the given endpoint. The response must include the Session Armor invalidation token as described in section section 5.5.
When performing session invalidation in this way, it may seem necessary to recompute session expiry (and necessarily recompute the HMAC in order to validate the values oft andth) as part of a hook atresponse time in addition to when it was computed at request time. This would be the case if requests are not mutable or some other request-specific auxiliary storage mechanism is not available, and a hit to performance would result. How- ever, a good solution is to mark the request as expired by adding the headerX-S-Armor- Invalidate. The response hook can check for this header and invalidate the session. Note well that thisX-S-Armor-Invalidate header is meaningless to the client! Sec- tion section 5.5 describes an HMAC procedure for invalidation of the session that prevents denial of service.
Next, it is important that the server authenticate the remaining header values before proceeding to use them. By usingh,ah,eah, and the request headers and body the server reconstructs the input to the HMAC. The server has decryptedKh, the HMAC key, and uses the algorithm indicated byh. The request is only accepted as valid if the client’s value cmatches exactly the result of the HMAC computation. This simultaneously validates the request data, the request’s expiration time, and the value of the nonce counter. If the value of cdoes not match, the request is rejected.
Rejecting the request means that the server returns a 403 response or redirects the request to the login page, whichever behavior the web application would have employed with an invalid Cookie-based session. The server must not invalidate the session. A request may be rejected for a number of reasons, not all of which require that the server discard the investment in the setup phase. For example, in especially congested network conditions, a request might be received more than four minutes after it was sent, resulting in an expired request being received by the server for innocuous reasons.
Oncetandlthave known good values, they are used by the server to determine if the session should be expired due to inactivity. This is a way to perform an inactivity timeout with no server-side state, made possible by the fact that the client can authenticate any data for use by the server, including its last request time. This feature is depicted in fig. 5.6
Next, the session expiration time,t, is compared against the current time to determine if the request has expired. This is “time-based replay prevention”. If nis present, then the server performs the following operations for “nonce-based replay prevention”. This is absolute replay prevention. First, we describe some prerequisites. The server uses a persistent storage medium to retrieve the most recently seen nonce. This medium should be keyed by the Session ID and shared by all servers. A good place to store these values might be a shared cache with a cache timeout configurable to infinity. A bitmask indicating all recently seen nonces should also be stored per Session ID. These arenrandnb, the recent
nonce and the nonce bitmask. It is recommended that the bit-length ofnbbe the word size of the server’s CPU for optimal performance, and it must be at least 32 bits. This allows for up to 32 in-flight requests from the same session, and 64 or more if a larger bit-vector is used. The following procedure is used to determine if a nonce should be accepted. Each of these cases is illustrated in fig. 5.7.
1. nr andnbare retrieved from the storage medium.
2. The client’s nonce is now evaluated, which we now callnc. First,nr− ncis computed.
If it is greater thanlength(nb)then the nonce is too old. It has “fallen off the end” of the bitmask, and the request is immediately rejected.
3. If it is greater than or equal to 0, then the bitmask is checked to determine if the nonce has been seen before, by shifting an LSB to the left bynr− ncand performing
a bitwise-and. If the target bit is set to 0, then the request proceeds with a response and that bit is set to 1 in nb. If the bit is set to 1, then the request is rejected as a repeated request.
4. If it is less than 0, this means that nc is the most recently seen nonce. nr is set to nc and nb is shifted by this offset so that the first bit would correspond tonr. The request proceeds with a response.
The The bitmasknb is being used here as a compact storage mechanism the most re- cently seen nonces. If a request is ever rejected by nonce replay, it is important to delete the stored values ofnrandnbso that they are not incorrectly used to reject requests when a new session is established.
A valid request means that the server attaches the Session ID in the request’sCookie: header, using the Session ID cookie name expected by the web application. This cookie is set only on theserver backend for the purposes of identifying the client using the existing
X-S-Armor: i:HMAC(0x3283416f2060c83f154ea762b20559ef, Ses- sion Expired)
X-S-Armor: i:ZRTDgPPvu/DBtdE/47IA0r4yhJfzix8vsIHXzXcP2896Fq 1KwwbhBHuuQWCqrnLiJ/OezAeGWs+BcJz/B+GKIQ==
Figure 5.8: Invalidation header first showing parameters and then HMAC result.
session management and permissions system. A corresponding Set Cookie: header must not be sent to the client.