eap Mailing List: Re: RE: channel binding

[Nicolas Williams (Nicolas.Williams]

You are correct about this: given an EAP method that provides keying but
not channel (or cryptographic) bindings it should be possible to provide
those elsewhere.

RFC3748 speaks of "a protected exchange of channel properties," but I
don't see how working these properties into key derivation departs from
the spirit of the RFC3748 description.

I.e., I don't see how what you propose is fundamentally new in regards
to EAP channel binding -- what's new in what you propose is to add
components that provide features missing from methods.

I can't help but be reminded of the stackable pseudo-mechanism notion
that we're working on in the GSS-API context at the KITTEN WG.  That is,
I think it's a good idea -- I would, of course, since I've been
promoting idea of GSS stackable and composite mechanisms ;)

I don't necessarily agree that all methods should be simplified by not
providing optional features that can be provided via composite methods.

But thinking of the SECMECH BoF GUAM proposal I do agree that the core
of a mechanism could/can/should indeed be specified such that it
provides only the fundamental properties needed and the rest of the EAP
or GSS semantics can then be provided by inclusion or elsewhere.

Nico
--