5.1 Session Bindings

A session occurs between the software (i.e., the session subject) that a subscriber is running (e.g., browser, application, operating system) and the RP or CSP that the subscriber is accessing (i.e., the session host). A session secret SHALL be shared between the subscriber’s software and the accessed service. This secret binds the two ends of the session and allows the subscriber to continue using the service over time. The secret SHALL be directly presented by the subscriber’s software, or possession of the secret SHALL be proven using a cryptographic mechanism.

The continuity of authenticated sessions SHALL be based on the possession of a session secret that is issued by the session host at the time of authentication and optionally refreshed during the session. The nature of a session depends on the application, such as:

Session secrets that are used as bearer tokens for session management SHOULD NOT be persistent (i.e., retained across a restart of the associated application or a reboot of the host device) because they are tied to specific sessions that a restart or reboot would end. Cookies and similar “remember my browser” features SHALL NOT be used instead of authentication except as provided for reauthentication at AAL2 in Sec. 2.2.3 when the inactivity limit has been exceeded but the time limit has not.

Some technologies (e.g., the emerging device bound session credentials specification [DBSC]) mitigate the risk of theft of session secrets by using cryptographic protocols that prove the possession of a session secret rather than using them as bearer tokens. These technologies might additionally store and use these session secrets in protected keystores to reduce the risk of exfiltration by malware. Session secrets used with such proof of possession techniques MAY persist. However, RPs and CSPs SHALL ensure that the session lifetime limits described in Sec. 2.2.3 are enforced even when a knowledge of the session secret is demonstrated.

The secret used for session binding SHALL be generated by the session host in direct response to an authentication event. A session SHOULD inherit the AAL properties of the authentication event that triggered its creation. A session MAY be considered at a lower AAL than the authentication event but SHALL NOT be considered at a higher AAL than the authentication event.

The secrets used for session binding SHALL meet all of the following requirements:

In addition, the secrets used for session binding SHOULD be erased on the subscriber endpoint when they log out or when the secret is deemed to have expired. They SHOULD NOT be placed in insecure locations (e.g., HTML5 Local Storage) due to the potential exposure of local storage to cross-site scripting (XSS) attacks.

Following authentication, authenticated sessions SHALL NOT fall back to an insecure transport (e.g., from https to http).

POST/PUT content SHALL contain a session identifier that the RP SHALL verify to protect against cross-site request forgery (CSRF).

Several mechanisms exist for managing a session over time. The following sections give different examples, additional requirements, and considerations for each example technology. Additional informative guidance is available in the Open Worldwide Application Security Project (OWASP) Session Management Cheat Sheet [OWASP-session].

Sessions SHOULD provide a readily accessible mechanism for subscribers to terminate (i.e., log off) their session when their interaction is complete. Session logoff gives the subscriber additional confidence and control over the security of their session, particularly if the endpoint might be accessible to others.

1. Yleiskatsaus

1.1 Viittaukset

1.2 Tunnistetut vaatimukset

1.3 Liittyvät säädökset

2. Tunnistetut vaatimukset

3. Liittyvät säädökset

• NIST -

  EN: Publications of the National Institute of Standards and Technology (NIST), U.S. Department of Commerce, https://www.nist.gov/, from their electronic versions (OSCAL; SP 800-63-4 from its HTML version, https://pages.nist.gov/800-63-4/). Works of NIST employees are not subject to copyright protection in the United States (17 U.S.C. § 105); the OSCAL content is dedicated to the public domain worldwide (CC0 1.0); outside the United States NIST grants the right to reprint its technical series publications in all formats (NIST copyright statement). Republished courtesy of the National Institute of Standards and Technology; each document names its citation. Divided into sections and converted into the GRCA format, the wording unchanged. Only the versions published by NIST are authoritative.

  DE: Veröffentlichungen des National Institute of Standards and Technology (NIST), U.S. Department of Commerce, https://www.nist.gov/, aus ihren elektronischen Fassungen (OSCAL; SP 800-63-4 aus ihrer HTML-Fassung, https://pages.nist.gov/800-63-4/). Werke von NIST-Beschäftigten sind in den USA urheberrechtlich nicht geschützt (17 U.S.C. § 105); die OSCAL-Inhalte sind weltweit gemeinfrei gestellt (CC0 1.0); außerhalb der USA räumt das NIST das Recht ein, seine Technical-Series-Publikationen in allen Formaten neu zu veröffentlichen (Copyright-Hinweis des NIST). „Republished courtesy of the National Institute of Standards and Technology“; jedes Dokument nennt seine Zitierangabe. In Abschnitte aufgeteilt und in das GRCA-Format umgewandelt, der Wortlaut unverändert. Maßgeblich sind allein die vom NIST veröffentlichten Fassungen.