Subject: [eap] Re: Channel Binding

From: Bernard Aboba <[email-masked]>
Date: Sat, 13 Aug 2005 14:22:43 -0700 (PDT)

> 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.
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: Jari Arkko <[email-masked]>
Date: Thu, 25 Aug 2005 14:40:24 +0300

>However, as far as I can see, no EAP key management extension is
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

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 25 Aug 2005 07:15:21 -0700 (PDT)

> the changes necessary to link layers and AAA protocols.

Definitely.  I'm just saying that Yoshi's extension does not add a 
completely different EAP/AAA mode of operation in the way that Pre-emptive 
Keying or Key-Request do.  It is just changing the root of the lower layer 
key hierarchy that is transported between the AAA server and the NAS.  
The major impact of this in terms of architecture is to introduce a media 
dependency into the AAA server which now has to compute the key 
differently depending on which media EAP is running over.  However, the 
proposal does not introduce a media dependency into EAP methods. 

From an EAP Key Management Framework point of view, the major issue is 
therefore whether transport of keying material from the AAA server to the 
NAS is required to be media independent. 

> or extensions to eap/aaa keying) they are optional

Perhaps the right way to do this is to describe the effects of different 
approaches on the architecture.  For example, the exiting mechanism 
requires changes to EAP methods but not to the AAA server;  Yoshi's 
proposal requires changes on the AAA server, but not to methods. 
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 25 Aug 2005 18:36:24 -0400

> proposal requires changes on the AAA server, but not to methods. 

Question: What functionality is part of AAA server here?  If EAP
server implementation is also part of AAA server, I'd say both
mechanism requires some changes on the AAA server.

Yoshihiro Ohba

---

From: Jari Arkko <[email-masked]>
Date: Fri, 26 Aug 2005 08:29:31 +0300

>mechanism requires some changes on the AAA server.
It seems that AAA server (the box, not a layer) is going to be impacted
in any case, as is the client. What we can talk about is whether the
NAS is impacted or not.

--Jari