eap Mailing List: Re: hopefully final changes for draft-ietf-eap-keying]

[Bernard_Aboba (Bernard_Aboba]

> >   EAP is a 2 party protocol. In practice it looks like there
> > are 3 parties because there's an EAP peer, and EAP authenticator
> > and an EAP server but, as I am repeatedly told, the EAP server
> > and EAP authenticator are logically one and any division between
> > the two is solely for scaling and performance. And in any event
> > channel binding can bind the NAS-Id of the authenticator into
> > the key derived by the EAP peer and EAP server to address any
> > issues arising from the introduction of a virtual 3rd party.

Section 1.6.1 (Mode Independence) goes into this.  From the point of
view of the EAP peer, it has no idea whether the EAP authenticator is
operating in "pass through" mode or not, and it does not care --
since only the identity of the EAP server matters.

> >   If you want to start sharing keys between authenticators
> > then you REALLY have a 3 party protocol: 1) EAP peer; 2) EAP
> > server-cum-authenticator running a key derivation function;
> > and 3) another authenticator being the recipient of the output
> > of the key derivation function.

Sharing EAP keying material does indeed change the EAP model from that of a 
2
party protocol to 3 (or more) parties.    This is prohibited by the
text in Section 2:

  EAP keying material provided to a lower layer MUST NOT be transported
  to another entity.  For example, EAP keying material passed down to
  the EAP peer lower layer MUST NOT leave the peer;  EAP keying
  material passed down or transported to the EAP authenticator lower
  layer MUST NOT leave the authenticator.

With respect to sharing of Transient Session Keys (TSKs), here is what 
Section 1.5 says:

  The goal of the EAP conversation is to derive fresh session keys
  between the EAP peer and authenticator that are known only to those
  parties, and for both the EAP peer and authenticator to demonstrate
  that they are authorized to perform their roles either by each other
  or by a trusted third party (the backend authentication server).

If TSKs are shared, clearly they will not be known only by the peer and 
authenticator.

So I think that the document is relatively clear about sharing of EAP keying 
material and
TSKs in other places.   So the question is about sharing of keys 
intermediate between
the EAP keying material (MSK/EMSK) and TSKs.

RFC 4962 Section 3, which is quoted in this section, contains quite a bit of 
text relating to this issue.
As I read it, it does not provide a blanket exemption from requirements 
based on use of a key
derivation function;  there are implementations and uses of key derivation 
functions that would
meet the requirements (such as IEEE 802.11r) and there are others that will 
not.