eap Mailing List: Re: Re: Channel Binding

[Jari Arkko (jari.arkko]

Bernard Aboba wrote:

> > Key-derivation based channel binding solution should be
> > specified as an extension to EAP keying framework.
> >    
>
> A question: is this an EAP issue or a AAA and lower layer issue?
>
> > From an EAP point of view, the EAP method passes down the exported
> parameters to the lower layer.
>
> The lower layer then can compute any required keying material from the
> exported parameters and the Channel Bindings.
>
> The same is true on the AAA server, which operates as an EAP lower layer
> on the server side.
>
> So as far as I can see, no changes are needed to EAP, EAP methods, or the
> EAP key management framework in order to support Yoshi's proposal.
>
> All that is required is a specification for how the AAA client requests
> the mixed key and how it is transported.  Presumably such a key cannot be
> transported in the Diameter EAP-Master-Session-Key attribute or in
> the RFC 2548 attributes since it is not an MSK.
>
> Of course, such a AAA specification would not be useful unless a lower
> layer were to exist that would use it, so you'd need a lower layer
> specification as well.
>
> However, as far as I can see, no EAP key management extension is
> required here.
>  
This may well be true. However, I think Yoshi (and others
also) are probably thinking of this in terms of overall
impacts in specifications and products. Its reasonable
to assume that there'd be a document describing such
functionality, for instance, plus documents describing
the changes necessary to link layers and AAA protocols.

You could also argue that EAP key management spec
should say something about channel bindings (as it
already does), because its in charge of the system
level security aspects. But in Paris we seemed to have
consensus that we're not taking the key binding
approach to the document as _the_ way of doing
EAP keying. This implies that whatever we do (methods
or extensions to eap/aaa keying) they are optional
extensions.

--Jari