See SP 800-63 B for normative requirements.
Session management comprises a number of mechanisms that are used following authentication to maintain continuity of state for a subscriber. Strength of session management procedures is as important as authentication, since the ability to hijack a session is as damaging as an authentication failure.
Sessions have well-defined maximum lifetimes. This lifetime can be extended through the reauthentication procedures outlined in Section 7.2 provided that reauthentication occurs before the previous session has expired.
A session is maintained by a secret shared between the subscriber and host (CSP or RP). The host generates a random secret, and sends it to the subscriber over the authenticated protected channel used for subscriber authentication. It is very important that the secret not be guessable by an attacker; for this reason, the secret needs to have sufficient entropy to resist guessing attacks and needs to be generated by an approved random bit generator. Other methods for session secret leakage also need to be avoided, including possible extraction from log files if it is included as a URL parameter.
Browser cookies are by far the most common mechanism for session management. A number of requirements are given in this section to ensure that they are used in a secure manner, such as that they only be accessible in secure (HTTPS) sessions, so that they can’t be intercepted in transit by an attacker and that they be inaccessible from (perhaps rogue) JavaScript.
Expiration of cookies used as session bindings depends on how long the CSP will accept the cookie as valid, which is determined by the reauthentication periods at each AAL. Cookies also have an expiration time, which primarily functions to allow the browser to discard cookies that will no longer work. This expiration time should be set slightly longer than the reauthentication period, and their expiration should be reset when reauthentication occurs.
Reauthentication is the process by which the CSP reconfirms that a session is still under the control of the subscriber. Reauthentication occurs periodically depending on the AAL associated with the session and whether the session has actively been in use. It mitigates the risk that the authenticated endpoint leaves the subscriber’s control and falls into the hands of an attacker. Even though session secrets are only a single factor, and two factors are required at AAL2 and AAL3, the short-term nature of these secrets and the requirement that they be sent only over an authenticated protected session mitigates the risk of compromise.
Reauthentication times are considerably shorter for sessions that are idle (without subscriber activity). This is because there is a greater risk of endpoint hijacking when there is no subscriber activity, e.g., when the subscriber goes to lunch. Session idle time is measured from the last user interaction with that specific session; other activity on the endpoint (e.g., user interaction with a different browser window or tab, or different application) does not reset the idle timer.
At AAL2 and above, reauthentication requires use of either a memorized secret or biometric associated with a physical authenticator. While possibly inconvenient, it is important to establish the presence of the subscriber, rather than a physical authenticator that may have been left at the endpoint. At AAL1, any authenticator may be used, but in practice that will usually be a memorized secret.
As noted, prior to reauthentication time it is acceptable for the RP to display a warning, such as “reauthentication will be required in 5 minutes” or “this session appears to be idle: reauthentication will be required in 30 seconds if there is no activity” to avoid unpleasant surprises for the subscriber.
Federated authentication presents a new reauthentication issue: both the CSP (functioning as IdP) and RP may maintain reauthentication time. In most cases, it is the RP’s reauthentication time that governs the timeout. If the IdP asserts the subscriber’s identity to an RP based on an earlier authentication (which must have occurred within the reauthentication time), the IdP should assert the time of authentication and maximum authentication age to the RP, so that it can base its reauthentication timer on that information.