Dan Romascanu wrote: >> > 1. It would be useful to include some considerations whether the authors >> > consider useful / possible / allowed that the mechanism (extended token >> > lengths) presented in this document can be used for other purposed than >> > the by-design the use case (avoiding per-request state). >> >> The last paragraph in Section 1 says: >> >> While the use case (avoiding per-request state) and the mechanism >> (extended token lengths) presented in this document are closely >> related, both can be used independently of each other: Some >> implementations may be able to fit their state in just 8 bytes; some >> implementations may have other use cases for extended token lengths. >> >> Does that solve your issue? > > Actually this is exactly the paragraph that triggered my concern. Does 'using > independently' mean that you encourage or do not care implementations in the > future dealing with other use cases? If the answer is yes, maybe the current > text is fine. If the answer is 'rather not' than a discussion would be > welcome.
The paragraph is intended to give permission that extended token lengths may be used for other purposes than avoiding per-request state. Of course, these will need security considerations etc., but those are out of this document's scope. >> > > The use of encryption, integrity protection, and replay protection of >> > serialized state is recommended in general, unless a careful analysis >> > of any potential attacks to security and privacy is performed. AES- >> > CCM with a 64 bit tag is recommended, combined with a sequence number >> > and a replay window. Where encryption is not needed, HMAC-SHA-256, >> > combined with a sequence number and a replay window, may be used. >> > >> > A few issues with this paragraph. Why are not 'recommended' and 'may' >> > capitalized? The formulation 'is recommended in general' seems odd, and >> > the rest of the sentence does not clarify. What does 'a careful analysis >> > of any >> > potential attacks' mean? Who is supposed to perform this analysis and who >> > can ensure it is 'careful enough' at any given point in time for any >> > potential >> > attacks? >> >> AFAIK, the Security Considerations section is supposed to discuss >> security-related issues that users need to be aware of, but not make >> normative statements. So all the normative requirements are in Section 3.1. >> (Where 'users' in this case are implementations and specifications that >> decide to make use of this implementation strategy in clients.) >> >> Overall, it's a bit difficult to make normative requirements here, because >> these are usually about the interoperability e.g. of a client and a server. >> But in this case, the client only needs to interoperate with itself (it >> needs to accept a token that it created itself) and the only real >> requirement is that "client implementations MUST NOT be vulnerable to >> maliciously crafted tokens". The meaning of "vulnerable" and "malicious" >> here depends a lot on the application/deployment-specific context; the >> document can really just highlight some potential issues that users should >> take into consideration. >> >> I'm open to concrete suggestions for text improvements, though. > > I believe that I understood the point that you are making. If I am to suggest > text improvements, I would: > > - s/recommended in general/recommended/ > - clarify, maybe in this very words that "the requirement is that client > implementations must not be vulnerable to maliciously crafted tokens" I've made these two changes in the Security Considerations section and also tried to improve clarity in section 3.1. I will submit a -06 shortly. Thanks! Klaus _______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
