On Wed, Sep 27, 2006 at 11:04:30AM +0200, Mark Townsley wrote: > > I'm copying Donald, as one of the authors of RFC 4086 for advice here. > Donald, this is in regard to draft-ietf-pana-pana-12.txt > > This recommendation on selection of the Cookie: > > > In order to do that, the cookie MUST be computed in such a way that > > it does not require any per-session state maintenance on the PAA in > > order to verify the cookie returned in the PANA-Start-Answer message. > > The handshake phase that takes advantage of cookies is called > > "stateless handshake". The exact algorithms and syntax used by the > > PAA to generate cookies does not affect interoperability and hence is > > not specified here. > > Seems to be in conflict with: > > > > The Cookie AVP (AVP Code 3) is used for carrying a random value > > generated by the PAA according to [RFC4086].
I think what we are trying to mention in the two part is that we don't specify detailed cookie generation algorithm using a randam value while generating a random value should follow RFC 4086. > > > Seen elsewhere in the document. > > First, there is obvious conflict in that the document says there is no > recommendation on algorithms in one place, but refers to RFC 4086 in > another (which clearly does have algorithms to recommend). But more > importantly, it seems that you are placing requirements on the > randomness of the cookie value by referencing RFC4086 (which is a good > thing) while at the same time mandating (with a MUST, no less) specific > implementation requirements with respect to state at the PAA. I'm not > sure thatit is even possible to state that the PAA MUST somehow be able > to verify that it generated a cookie, without state, and still be in > keeping with RFC 4086 requirements (this is where I would like Donald to > give advice). You are absolutely right that it's not possible for PAA to do cookie validation without any state, but it does not require *per-session* state maintenance. A per-request, small state (not containing full PANA session attributes) should suffice for cookie validation. > > Also, if you are going to reference RFC 4086, I believe you need to > define what kind of random number you are looking for. To wit, I think > you are looking for a "Cryptographically Random" value, as you are > trying to protect against blind guessing attacks here. Yes. How about revising the latter part to: " The Cookie AVP (AVP Code 3) is used for carrying a value that is generated by the PAA from a cryptographically random value. Although the exact algorithms and syntax used by the PAA to generating a cookie value is not specified in this document, randomness of the cryptographically random values should meet the requirements described in [RFC4086]. " > > Finally, if keeping state at the PAA isn't a big deal for a specific > implementation, why include this kind of MUST? I think you are getting > too deep into implementation details with normative language. I think keeping per-session state at the PAA is a big deal in some environment and that is why stateless handshake is supported. On the other hand, I agree that this MUST may be too much. We can revise the former part something like: " In order to do that, it is expected that the cookie be computed in such a way that ... " Yoshihiro Ohba > > - Mark > > > _______________________________________________ > Pana mailing list > [email protected] > https://www1.ietf.org/mailman/listinfo/pana _______________________________________________ Pana mailing list [email protected] https://www1.ietf.org/mailman/listinfo/pana
