On Wed, Oct 5, 2011 at 6:08 PM, Luke Howard <[email protected]> wrote: >> a) there are no sequencing problems, since RFC4121 can handle >> out-of-sequence tokens; > > Hmm. I'm not convinced that this wouldn't have created other problems, I need > to think about it some more.
Well, if you can guarantee that all per-msg tokens will have been processed by the time you're ready to handle the app's tokens... Ah, now I understand Sam's comment about PROT_READY. >> b) you could create separate "contexts" for internal each use of >> RFC4121, with different keys in each case, all derived from the EAP >> keys. > > Yes, this would have worked, although using usage numbers and 3961 is a > little easier from an implementation perspective (you only have one derived > key to manage). Yes, which is why I agree with the proposal :) >> Now, RFC4121 is going to require RFC3961/2 anyways, so using RFC3961/2 >> directly in this part of GSS-EAP is hardly a burden -- unless you have >> an API to the first but not the second... > > > Well, there is an API for RFC4121. But there's no clear way to manufacture a > context purely in order to use its cryptographic services. (e.g. you could > import a fake context, but you'd have to understand its contents, which are > implementation dependent.) So I think it's 6 of one, half a dozen the other. We ought to define a subset of RFC4121 exported sec contexts for the purpose of using it as a per-msg token library! :) Nico -- _______________________________________________ abfab mailing list [email protected] https://www.ietf.org/mailman/listinfo/abfab
