V1.3 Session Management Architecture - Section Text Proposal

[ryarmst]

Simplified proposal for V1.3 section text:

Session management mechanisms provide applications the capability to correlate user and device interactions over time even using otherwise stateless communication protocols. Modern applications may utilize multiple session identifiers or tokens with distinct characteristics and purpose. There is no single pattern that suits all applications. As such, session management systems must be designed with consideration for the relevant strengths and weaknesses in conjunction with the expected use cases of the application and intended level of security assurance. A secure session management system is one that optimally prevents attackers from obtaining, utilizing, or otherwise abusing a victim's session.

[jmanico]

Very solid text, thank you!

[tghosth]

Session management mechanisms give applications the ability to correlate user and device interactions over time, even when using otherwise stateless communication protocols. Modern applications may utilize multiple session identifiers or tokens with distinct characteristics and purpose. There is no single pattern that suits all applications.

As such, session management systems must be designed with consideration for the relevant strengths and weaknesses in conjunction with the expected use cases of the application and intended level of security assurance. A secure session management system is one that optimally prevents attackers from obtaining, utilizing, or otherwise abusing a victim's session.

I made minor changes but otherwise looks good :)

[elarlang]

This seems to suite more for V3 paragraph text, not section text for V1.3

V1.3 is "Session Management Documentation" and should carry points like:

• Each application is unique and therefore it's complicated to give universal boundaries and limits that fits all, therefor there must be risk analysis and documented security decisions for the session handling, that is pre-condition for implementing and testing
• Whatever mechanism is chosen (stateful or "stateless", the analysis must be done and documented, that the chosen solution is able to satisfy all related security requirements

Worth keeping in mind, that most likely we move V1.3 as the first chapter into V3 in the future.

[ryarmst]

My thought with the current structure (V1.3 separate from V3) is that it makes sense to introduce some session management concepts. I do think it would be easier to structure and separate out documentation-specific paragraph text if the V1.3 section was added to chapter V3. As it is, how about the following reformation for V1.3 (essentially combining both of your previous comments):

Session management mechanisms give applications the ability to correlate user and device interactions over time, even when using otherwise stateless communication protocols. Modern applications may utilize multiple session identifiers or tokens with distinct characteristics and purpose. A secure session management system is one that optimally prevents attackers from obtaining, utilizing, or otherwise abusing a victim's session.

There is no single pattern that suits all applications. Therefore, it is infeasible to define universal boundaries and limits that suit all cases. A risk analysis with documented security decisions related to session handling must be conducted as a prerequisite to implementation and testing. This ensures that the session management system is tailored to the specific requirements of the application. Regardless of whether a stateful or "stateless" session mechanism is chosen, analysis must be complete and documented to demonstrate that the selected solution is capable of satisfying all relevant security requirements.

[elarlang]

At this stage it is important to collect the points in, we can rearrange pieces later if needed. I think at the moment is more important to move fast than overthinking the wording here.

Let's PR it in.