Where to move or what to do with V3.5 section (tokens section in session management chapter) #2384
Comments
|
My order of preference:
|
tghosth
added
1) Discussion ongoing
|
I do not have a strong opinion here as I do not see a clear obvious location. Option 3 - @elarlang I have agreed with your point that many of these requirements are fundamentally validation issues and that V5 logically makes sense, but I don't think anyone looking at the ASVS for the first time would expect to find it there. Option 1 - The more I think about this option, the more it seems reasonable especially thinking about implementation and testing. @tghosth I do think if it moves, there ought to be guidance text in V3 for those who expect to find it there. |
|
Would including "Cryptographically Secured Tokens" as a section of "V6 Cryptography" be weird? |
Yes, for entire section it is weird. I would like to get out everything from V6 that is not a clear crypto problem or the "main problem to solve" is not a crypto problem. For that discussion we have #2375 (comment) |
|
Making the "Option 1" more clear. VX.1 Token source and intgrityBefore validating the token content there is a need to verify, whether the token is initiated by a trusted party and if it is not tampered.
Related open issues:
VX.2 Accepting stateless token contentBefore accepting the token content there is a need to validate if the token is in a valid time window and meant to be used for the given service and for a given purpose to avoid cross-usage over different services and token types from the same issuer. Specific requirements for OAuth and OIDC are covered in the dedicated chapter.
Related open issues:
|
|
Hard to choose! I think option 1 is worth a try, sounds logical to have things closely related to APIs and Web Services together. I will try to explain how I reason about it. If we do option 1 (or 2), then you could look at ASVS chapters as 3 main tracks: Track 1, if your focus is a "classic" web application where users login, then it seems logical to look in V2 for user authentication, V3 to deal with user sessions, V4 for authorization and then V5, V6, V7... etc for more validation things that applies to your application. Track 2, if your focus is integration APIs (service-to-service), you can basically skip V2 and V3 and start with V13 for general API and Web Services verifications, V14.7 for authenticating the service/client, then the new "cryptographically secured tokens" chapter (perhaps V15) for authenticating requests to the API , and then V4 and V5, V6, V7... etc. Track 3, if the application use OAuth/OIDC, both tracks 1 and 2 apply, together with V51. I'm not sure if it is good to think this way, but it is one way to look at how to organize ASVS chapters! |
Yes, the thing is that this does not feed neatly in "authentication" nor in "authorization" (because it can be both). On the other hand, these considerations overlaps greatly with certificate validation requirements (because a JWT token, a SAML token and a X.509 certificate are basically the same thing and JWT or CWT are sometimes used as certificates. That being said maybe option 1 (a "Cryptographically Secured Tokens" chapter) would be fine. This chapter might be expanded later on to cover (if need be):
|
|
At the moment "Option 1" seems the way to go, but I think we should get the understanding of the topic and focus aligned first. Tokens are just a format for delivering a message between parties - it's just a technology, it is not tied to authentication, authorization, or session management. It is a separate thing often used to provide other functionalities. So the separate chapter serves that goal. A thing that bothers me is the discussions here are too cryptography-oriented. Cryptography is used to provide the confidence for separate parties, that the token came from a trusted party and is not tampered with. It is the important corner-stone for this, but at the same time - that is it. It is just one important part of the topic, but it is not the topic. Validating the source and integrity gives the possibility to not keep the state for that information and that is why the rest of the world calls it stateless. Why this term is not good for us, is still not clear to me. The point for the token is to be stateless - cryptography is just a solution to make it happen. I don't think it deserves the name for that. All this crypto part is important only for those few requirements that handle the source and integrity, as displayed in #2384 (comment) in section V1.X. After those checks, there is a need to validate the token's meta info, and then it is possible to validate and use the token's content. That means we should not carry the crypto requirement forward to other requirements, as it is already checked as a pre-condition. We have had this discussion also in some other issues #2182 (comment). |
|
Ok, I support Option 1. It sounds like the chapter heading would be something like "Stateless Tokens". As discussed with Elar, the goal is to be stateless and "cryptography" is just the mechanism to achieve this. |
|
Before I go for the PR, I would like to get "pong" from @randomstuff @ryarmst and @TobiasAhnoff . Any strong arguments against this direction? |
|
I support Option 1, but I think "stateless" is worth discussing some more...should we do that here before we decide on Option 1? Or should it be part of a new issue for title and chapter text (given the new Option 1 chapter)? There are some things about "stateless" that I feel are not clear to me, but I need some more time to be able to write something that is good input for the discussion :) |
|
Option 1 sounds nice but actually I thinking restricting to stateless tokens as opposed to tokens in general might be problematic as many requirements might apply to stateful/opaque tokens as well? |
This issue is about (re)structuring the current V3.5 content, so this issue here suits well.
Yes, that is true and the main question here is, how to set the focus or priority for the chapter. If the focus is for crypto, then I can understand and agree with your previous question, that crypto-related requirements may belong to V6. For me, the topic here is stateless information transfer between services. At the same time, if we watch requirements we have at the moment in V3.5, only 3 of them are about crypto, the rest (at the moment also 3) are about token content/metainfo validation.
If we could call it "Token Security" or something like that, for me it feels too vague. But at the end, it is just a question how we set the logical scope for the structure and what kind of requirements are suitable for that. In short, I repeat my current position - the topic I want to cover here is stateless information change between services (in a way, for stateful we have V3), crypto is important part for provide integrity check, but it is not the main topic. |
This is not the case in many applications I have seen where this content (existing requirements) would apply (either not fully stateless, or not for collaboration of different services). To give a counterexample, 3.5.3 and 3.5.5 could (and perhaps should) apply to tokens that use stateful session (or other) identifiers, but are secured with a signature. Other requirements could apply as well and I am sure there are many scenarios where some state information is captured in tokens and some is stored by some server. I think "Token Security" is a fine option, but I do agree that it is vague (hence the use of Cryptographically Secured Token). If the emphasis on cyrptography is at issue, what if we modified the definition to just "Secured Token"? There is existing terminology that is similar (like OAuth's Self-Encoded Tokens), but IMO it fails to capture the diversity of implementations that I think we ought to have requirements for. Ultimately, however, as long as the terminology is defined and consistently used, I am less concerned about what naming is chosen. We have this challenge precisely because there is no clear precedent in the industry (mostly just confusion - see the previous debates over "stateless"), so as I have mentioned before, I think ASVS has the opportunity to set a more clear standard. |
Important is to keep in mind that we don't talk about sessions here. Crypto provides the possibility to have the information stateless. If someone uses the same method for stateful token or opaque string, it does not make the concept of stateless token invalid. |
|
You can all throw in (here, or in slack) scenarios that you feel are not covered by current proposal AND are covered now. The goal is to have everything covered without any confusion. |
|
I think "Token Security" or something else with Token is good, like "Token Management" or "Token Request Authentication". I also think it would be logical if the Session chapter had the same kind of title ("Session Management", "Session Security" or "Session Request Authentication". The way I see it is that first you have either "User Authentication" (V2) or "Service Authentication" (V14.7). Then, depending on application requirements, you can do authentication on every request (not good for human users, but might be fine for services) or authenticate requests using either a session (V3) or a token (new chapter). The session chapter contains all requirements that are expected when managing a session, like creation, termination, inactivity timeouts etc. The token chapter contains all requirements that are expected when managing a token, like validation, expiration etc. This works but perhaps gets somewhat confusing...since both sessions and tokens can be regarded as "stateless" or "stateful" solutions. A session can have only the session id in a client-side cookie or custom header, and a token, in example an OAuth reference token, can be just a secure random string providing access to some server-side "state" (the token claims/properties). While a JWT typically has no state on the server-side that needs to be shared between all server instances (except perhaps key material needed to validate the token), and you can also have a session without any server-side state. An example of this is .NET, where you by default get an encrypted cookie (or set of cookies) containing e g a GUID, session data (claims) and maybe even access and refresh tokens (if also using OAuth/OIDC). This session mechanism is "stateless", since (just as for a JWT) the only thing that need to be shared between server instances (to authenticate requests and provide information needed for authorization) is the key material (all client-side state/stateless session/tokens need to be integrity protected in some way). The main difference is where state is stored and if it is expected to behave as a "session" or as a "token", e g if there are requirements on termination. A "stateless" solutions can´t be terminated like a "stateful" one (a good example is OAuth access-tokens, when using reference-tokens they can be revoked instantly, while JWTs are valid until they expire). So maybe one way to see it is to have one chapter for "Authentication of requests with server-side state" and one for "Authentication of requests with client-side state (a k a stateless)"? This might be explained in chapter text and titles can still be "Session Security" and "Token Security", since we often associate server-side state with "sessions" and client-side (stateless) with the term "token". Or, we can have titles that reflect this, perhaps something like "Server-side State Security" and "Client-side State Security", but I think I still prefer "Session Security/Management" and "Token Security/Management" (and having chapter text that explains "stateless" and how the two chapters relates to each other) This might be a good idea or not...I have not had time to analyze how something like this would affect current requirements and organization, perhaps not that much, perhaps mostly chapter texts and where things are put... This is a hard one! |
|
Having read the above, I see the challenge of the term "stateless" and the challenge of the term "cryptographically secured". Maybe an alternative heading could be "Trusted Tokens". I don't think this is an industry term but I think it captures the whole point here which is that we are relying on values included in the token. |
|
Please give me some more hour(s) to prepare the points. Meanwhile I recommend to read the issue content written so far - scope: (stateless) tokens only. No session management or other functionality involved. |
|
Sometimes I feel like my comments are not reaching GitHub. For example, explaining, that the topic here is not about session management (#2384 (comment), #2384 (comment)) So I make my points referenceable.
My first preference is to solve "Point 10" - revert the scope change for crypto-related requirements to be stateless tokens oriented. Actually, the question is - are they by content wide enough to be valid outside of the stateless tokens section or it is just the attitude towards them? E. g. the validation question - are those ready to be moved to V6 as they are? If it creates a gap or not covered area, it should be considered to have a separate more general requirement into V6 to cover that - as we have more general requirement in current V3.5 to have abstract requirements and specific requirements in the OAuth section to cover the special need. This proposal satisfies: Point 5, Point 14, Point 15 If the first preference is "voted against"
This does not satisfy points:
In summary, I find it to be not aligned (filtered) that I need to explain the scope for the section that was conflicted with a questionable move. And now there seems to be an attitude that everything else must be aligned with the questionable move going against many listed points (e.g. 2, 3, 5, 9, 14, 16). |
Agree
I think the point was made above that (right or wrong) you could have a system that uses "stateless tokens" but also relies on some sort of server side state (I am not using the word session here). This is why I suggested that maybe the word "stateless" is not 100% accurate despite being industry accepted and that trusted token might more accurately represent the situation. Again not session management specific.
3.5.3 and 3.5.5 explicitly refer to tokens, I am not sure what here would be considered "wider than stateless tokens". Do you mean that these requirements were expanded to not just be relevant to "session management" but trusted tokens in general?
Agree
I don't think there is significant conflict here, I think it is just a subtle terminology question about what stateless means, as noted in my response to Point 3.
I think there is a terminology thing here. Broadly speaking, I think that the new chapter should cover a situation where we rely on the contents of the token to make security sensitive decisions. The alternative is that the token or whatever is just an ID which is used to look something up at the back end.
I think that Server-side State != Session but given my response to Point 20 we could side-step the issue by not referring to "state" in the name of the chapter.
I don't really understand what you are proposing here. From reading the comments, I think we all agree that these requirements can be moved to a dedicated section and there is just some discussion on the specific scope and definition. In summary, I think we need to create a new chapter and move the token requirements over. I think we can argue about the specifics afterwards. I think your arguments above support my suggestion to refer to them as Trusted Tokens :) |
|
@elarlang if you feel this still needs discussion, I think we need to get a call together next week. |
I also responded to that above, that if you use content from stateless token to keep the state, does not make the concept of stateless token invalid and it does not change anything of the process of validating it. In other words, does not change the scope of this issue/chapter.
Examples from this thread:
|
There has been discussions here and there, what to do with V3.5 section. Mostly I have opened the topic in
Problem to solve: stateless tokens or "cryptographically secured tokens" as those are named now in requirements, are a wider topic and are not limited to sessions. Additionally, using stateless tokens for session management causes many new challenges for achieving the expected solution to fulfill security requirements.
Options are:
The text was updated successfully, but these errors were encountered: