On Sat, Dec 10, 2011 at 7:19 PM, abfab issue tracker <[email protected]> wrote: > #19: Setion 1.4 - Overview - > > a) I think you might need to have a step 2a - Client Application creates > a channel to the RP. This is not done by the GSS-EAP mechanism as I had > originally assumed. Let's make it clear additionally that fact will be > needed in order to setup the channel binding at a later time. Note that > at some point there will need to be a discussion of the properties of this > channel. It should also be noted that the type of channel used > potentially provide different issues.
See my other reply, from yesterday, regarding channels. The TLS channel is optional, not required. True, there cannot be channel binding if there's no channel to bind to, but an application that doesn't do channel binding will presumably be using GSS per-message tokens, thus using GSS itself as a channel. As to desired properties of channels, RFC5056 should suffice. In practice the channel will always be TLS, thus also needed is RFC5929. > b) in step 5 either /forward a RADIUS request/ or /forward RADIUS > requests/. AAA ignorance - would message be better than request to avoid > confusion between RADISU request and GSS/EAP request? We should use "security context token", or just "token" to refer to GSS messages in this section. We definitely need to be careful to not confused terminology. Nico -- _______________________________________________ abfab mailing list [email protected] https://www.ietf.org/mailman/listinfo/abfab
