Subject: Re: [eap] Strawman -10

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 31 Jan 2006 17:33:58 -0500

On Tue, Jan 31, 2006 at 02:01:26PM -0800, Salowey, Joe wrote:
> 
> > For example, the lower layer could be allowed to obtain the 
> > EMSK but be 
> > prohibited from transporting it or using it directly.
> > 
> > The difference is subtle, but potentially important for 
> > issues such as 
> > crypto-agility.  Allowing the lower layer to obtain the EMSK 
> > enables the 
> > lower layer to negotiate the PRFs used in AMSK generation, 
> > whereas this is 
> > not possible if AMSK generation is handled in the EAP layer.  It also 
> > maintains backward compatibility so that a lower layer using 
> > the AMSK can be 
> > introduced without requiring changes to existing EAP implementations.
> > 
> > As long as the EAP peer does not need to be aware of whether the 
> > authenticator is configured in standalone or pass-through 
> > mode, I think that 
> > the requirements of mode independence have been met.
> 
> [Joe] This worries me.  It ties the key derivation to the lower layer,
> which could be problematic.  A goal of the EMSK to AMSK derivation is to
> contain the problem of a misbehaving lower layer to the lower layer
> itself.  A lower layer that determines the key derivation algorithm
> conflicts with this goal.  What happens if there are multiple AMSKs
> being derived for different purposes? Who decides the KDF?   
> 
> I think I would prefer to see a default KDF specified with the
> capability of an EAP method to override it with a KDF of its own.  

The channel-binding draft allows KDF to be provided by an EAP method
while still satisfying the requirements of mode independence.

Yoshihiro Ohba

> 
> _________________________________________________________________
> To unsubscribe or modify your subscription options, please visit:
> http://lists.frascone.com/mailman/listinfo/eap
> 
> Arhives: http://lists.frascone.com/pipermail/eap
> 
> 
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/eap

Arhives: http://lists.frascone.com/pipermail/eap

---

From: "Bernard Aboba" <[email-masked]>
Date: Wed, 01 Feb 2006 09:44:59 -0800

>while still satisfying the requirements of mode independence.

Do we really want to require EAP methods to support KDFs in order to enable 
the lower layer to generate keys from the EMSK?  That would mean that 
existing EAP methods wouldn't be usable on some lower layers.   One of the 
major advantages of EAP is the ability to support many lower layers.

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 01 Feb 2006 15:02:46 -0500

> major advantages of EAP is the ability to support many lower layers.

It would be possible to define a particular hash algorithm as the
default algorithm for prf+ in draft-ohba-eap-channel-binding for
existing EAP methods.

On the other hand, EAP methods would still need to have a
functionality to negotiate on use of Channel Binding if Channel
Binding is defined an optional functionality.  Or do you expect lower
layers to negotiate on use of Channel Binding in which case Channel
Binding would not be usable for already deployed NASes?

Yoshihiro Ohba

---

From: "Bernard Aboba" <[email-masked]>
Date: Wed, 01 Feb 2006 12:15:53 -0800

>Binding would not be usable for already deployed NASes?

A lower layer can include the use of Channel Bindings in computation of 
keys.  One example of this is IEEE 802.11r, which includes channel binding 
parameters in the computation of keys at various levels (PMK-R0, PMK-R1, 
etc.).  At each level of the key hierarchy, different channel binding 
parameters are mixed in.  The end result is that the same PTKs cannot be 
derived without agreement on the Channel Binding parameters between the EAP 
peer and server. Note that IEEE 802.11r does not mix the Channel Bindings 
into the key transported from AAA server to authenticator; it does the 
mixing *afterwards*.   The advantage of this is that code on the AAA server 
does not need to change to support Channel Bindings, and neither do the EAP 
methods need to change.

The negotiation of the channel binding functionality can also occur in the 
lower layer.  For example, in IEEE 802.11 different things are done in 11r 
vs. 11i.

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 01 Feb 2006 15:40:38 -0500

> lower layer.  For example, in IEEE 802.11 different things are done in 11r 

What problem is being solved by so called "channel binding" in IEEE
802.11r?  If AP is lying to both STA and AAA server, then how can STA
detect it?  Also what do you mean by "agreement on the Channel Binding
parameters between the EAP peer and server"?

Regards,
Yoshihiro Ohba

---

From: Jari Arkko <[email-masked]>
Date: Tue, 07 Feb 2006 15:55:20 +0200

Bernard Aboba wrote:

> Do we really want to require EAP methods to support KDFs in order to 
> enable the lower layer to generate keys from the EMSK?  That would 
> mean that existing EAP methods wouldn't be usable on some lower 
> layers.   One of the major advantages of EAP is the ability to support 
> many lower layers.

What Joe proposes does not lead to that problem. He said "default + optional
negotiation ability in methods".

Also, lower layer usage of EAP keys != EMSK usage. All current link layers
use MSK. If the link layers want to do link-layer specific things, they 
already
can. Why would we want to introduce another quantity to do the same thing?

--Jari

---

From: Jari Arkko <[email-masked]>
Date: Tue, 07 Feb 2006 16:01:41 +0200

>capability of an EAP method to override it with a KDF of its own.  
I share these concerns, and would also like to see the
default scheme rather than move EMSK to the lower
layers.

The problem with the lower layer usage of EMSK is that
we know that its quite likely there will be some link layer
which gets the key generation wrong. At that point, the
EMSK is compromised for other link layers, too.

At a high level, we have currently two quantities, the MSK
and the EMSK. The MSK is being used by lower layers, whereas
the EMSK is not. We are thinking of possible applications
of EMSK. But I would caution freeing up its use to lower
layers. This is the only remaining quantity that we have
left in EAP, and there's no going back from that decision
if we take it. In a sense, what I understand the strawman
says is that EMSK would become similar to MSK, but have
stricter requirements (e.g., no direct use). [If we really
wanted to get a MSK++ we could define MSK++ = prf(EMSK),
but I'm not sure its worth the trouble.]

--Jari

---

From: "Bernard Aboba" <[email-masked]>
Date: Tue, 07 Feb 2006 06:40:20 -0800

>EMSK is compromised for other link layers, too.

What other link layers?  The document talks about "the lower layer" 
throughout, not multiple lower layers.

---

From: "Bernard Aboba" <[email-masked]>
Date: Tue, 07 Feb 2006 06:58:07 -0800

>What Joe proposes does not lead to that problem. He said "default + 
>optional negotiation ability in methods".

Are we saying that the EAP method would negotiate the KDF to be used by the 
EAP layer in generating AMSKs?  Wouldn't this require EAP methods to be 
aware of what KDFs are supported by the EAP layer?  What if an EAP method 
didn't support KDF negotiation and yet the default KDF is not legal for use 
in a given environment?  I ask because HMAC-SHA1 (on which the default KDF 
is based) may be phased out by NIST.

The original thread was actually discussing Yoshi's proposal, I think.  In 
that proposal, the MSK is not replicated to the authenticator.  Instead, a 
new "Channel Binding" key is replicated instead.  Presumably the use of the 
"Channel Binding" key is negotiated by the lower layer, so that it is 
generated from the MSK on both the EAP peer and server.  However, this 
implies that the key state will not be identical in the pass-through and 
standalone cases, since the authenticator would obtain the MSK in the 
standalone case and generate the "Channel Binding" key from it, whereas in 
the pass-through case it would only obtain the Channel Binding key.

Is the MSK *always* replicated to the authenticator?  Or can the 
authenticator ask for another key to be replicated instead?  This would 
imply that AAA servers would need to be modified to support this.

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 07 Feb 2006 12:32:30 -0500

On Tue, Feb 07, 2006 at 06:58:07AM -0800, Bernard Aboba wrote:
> >enable the lower layer to generate keys from the EMSK?  That would mean 
> >that existing EAP methods wouldn't be usable on some lower layers.   One 
> >of the major advantages of EAP is the ability to support many lower layers.
> >
> aware of what KDFs are supported by the EAP layer?  

Yes, this is true.

> What if an EAP method 

In draft-ohba-eap-channel-binding-00.txt, the use of the "Channel
Binding" key does not need to be negotiated by the lower layer.
Instead, the negotiation is required by EAP method.

> the pass-through case it would only obtain the Channel Binding key.

I would mention that the final key state is identical in the
pass-through and standalone cases.  This is similar to how EMSK/AMSK
is supposed to be maintained in the EAP keying framework, isn't it?

> 
> Is the MSK *always* replicated to the authenticator?  

The negotiation on the use of "Channel Binding" key by EAP method will
determine which key is used.

> Or can the 
> authenticator ask for another key to be replicated instead?  

I don't expect it at least when "Channel Binding" key is applied to
MSK branch.  When "Channel Binding" key is applied to EMSK branch, I
don't know what authenticator should behave, because I don't know
(yet) how EMSK is going to be used :)

> This would 

Yoshihiro Ohba

---

From: "Bernard Aboba" <[email-masked]>
Date: Tue, 07 Feb 2006 14:49:13 -0800

>Instead, the negotiation is required by EAP method.

How does the EAP method know whether the link layer is doing "Channel 
Binding" EAP key deriviation or not?  EAP methods are typically link layer 
agnostic, so the keys are computed the same way regardless of media.  Or are 
we saying that the method needs to be able to take the Channel Bindings into 
account in computation of the MSK?  If so, how does it know what Channel 
Bindings are to be used to compute keys with which link layers?  The Channel 
Bindings may not be the same for every link layer.

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 07 Feb 2006 19:42:51 -0500

On Tue, Feb 07, 2006 at 02:49:13PM -0800, Bernard Aboba wrote:
> agnostic, so the keys are computed the same way regardless of media.  Or 
> are we saying that the method needs to be able to take the Channel Bindings 
> into account in computation of the MSK?  If so, how does it know what 
> Channel Bindings are to be used to compute keys with which link layers?  
> The Channel Bindings may not be the same for every link layer.
> 
> 

- The EAP peer can directly obtain "Channel Binding" parameter from
lower layer if the lower layer supports "Channel Binding".

- The EAP server is expected to obtain "Channel Binding" parameter
from NAS or authentication server where it resides depending on
whether the mode is standalone or pass-through, respectively.  It is
assumed that the authentication server is pre-configured with "Channel
Binding" parameter for each EAP authenticator whose lower layer
supports "Channel Binding".  To address potential scalability issue
with this, several variants such hiearchical "Channel Binding" as well
as transferring master "Channel Binding" key are defined in the draft.

- The "Channel Binding" key is computed the same way regardless of
media, provided that "Channel Binding" parameter is treated as an
opaque blob.

Yoshihiro Ohba