eap Mailing List: RE: Basic facts about EAP

[Bernard Aboba (aboba]

> I agree to that if we are talking about the "EAP method layer". But if
> we look at the "EAP layer" I see a third entity called "pass through
> authenticator" that has a specific role at the EAP layer.

RFC 3748 requires that EAP operate the same way whether the authenticator
is operating in "pass-through" mode or not.  This is perhaps the single
most important invariant within EAP.  In the process of developing RFC
3748, the WG examinec ases where the protocol operated differently in
"pass-through" mode, and corrections were made so as to allow the protocol
to be invariant.  An example of this was the inability to handle silent
drop on the EAP server side in "pass-through" mode.  This was fixed in RFC
3579.

One of the reasons why the EAP Key Management framework document may be so
confusing to people is that it does not stress this point enough.  EAP key
management behavior MUST be the same whether the authenticator is in
"pass-through mode" or not, and many of the properties of the EAP
key management architecture can be derived from this fundamental
assumption.

As an example:

The behavior of EAP methods and the EAP layer is the same in any
configuration.  For example, as discussed at IETF 62, the EAP layer does
not cache parameters exported by EAP methods, but passes these
parameters down to the lower layer.  On the EAP server the lower layer may
be AAA (in pass-through), or it may be a link layer or IP.  However, the
operation of the protocol MUST be identical in both cases.

> - It reads the EAP method payload to determine AAA routing (reading the
> client ID).

The EAP layer is unaware of EAP method payloads, so the only way for it to
become aware of EAP method-specific identities is if this is exported by
the EAP method itself.  In addition to the MSK, EMSK and IV, EAP methods
may export the peer-ID, server-ID, method-ID and key-lifetime.  So the way
to think about AAA routing behavior is that the authenticator terminates
the Identity Request/Response conversation and therefore receives the
peer-ID from the Identity method, which it subsequently inserts in the
User-Name attribute in AAA, subsequently used for routing.  However, the
EAP authenticator does *not* handle AAA routing itself.

> - It reads the EAP code for sanity check. If it receives an EAP request
> that it should not, it can drop the EAP packet.

In "pass-through" mode the authenticator does handle forwarding between
lower layers, and RFC 3748 does indicate that this includes a
responsibility for checking the Code, Identifier and Length fields.

> - It can generate an EAP Identity Request.

For the Identity Request/Response, the authenticator acts as the EAP
server, so it both generates the Request and terminates the Response.

> - It handles retransmissions and it can re-generate loss packets.

This is a responsibility that goes with forwarding EAP packets.

> My personal reading of Section 3.1 is these are necessary but not
> sufficient requirements for EAP lower layer designers. I don't expect
> this to be an all comprehensive list. But imo, designing an
> RFC3748-compliant EAP lower layer requires factoring in additional
> aspects of the EAP specs, such as channel binding and secure
> association, which are not covered in that list.

Yes, RFC 3748 does not provide a complete list of lower layer
responsibilities.

The way to think about Channel Bindings is that these represent additional
parameters exported/imported by the lower layer to/from the EAP method and
EAP. For example, the channel bindings provided by the NAS to the AAA server are
imported by the EAP method (e.g. NAS-Identifier, Called-Station-Id,
Calling-Station-Id).  These are treated like opaque blobs and therefore do
not introduce media dependence to the EAP method, which may transmit them
from EAP server to EAP peer.  The method then exports the Channel Bindings
to the EAP layer, which passes them down to the lower layer.  The lower
layer on the peer can then verify whether the exported Channel Bindings
match those it has received from the authenticator.

Note that additional obligations arise when the lower layer caches
parameters from the EAP method/EAP layer.  For example, one of the security
requirements is session key freshness. Were parameters not to be cached
by the lower layer, and a new EAP exchange is completed for each
session, then this can be satisfied if the EAP method itself guarantees
freshness.  However once caching and reuse is introduced this is no longer
sufficient and therefore the SAP needs to introduce its own freshness
guarantee.


> This is a good example. I think the EAP peer should know the NAS ID
> (head), and know the connected port IDs (hands connected to the same
> head).

The NAS-ID and port-ID may be imported within the EAP method via
Channel-Bindings, but they are treated as opaque blobs, so that the EAP
method or EAP layers don't really "know" them.  However, the lower layer
does.  One way to understand this is that because EAP runs between the
peer and server and operates the same way in "pass-through" as where EAP
terminates on the authenticator, the NAS-ID or port-ID is not really
relevant to EAP methods or the EAP layer.

However, it is *very* relevant to the lower layer because the NAS-ID
determines the scope of use of the keying material provided by EAP methods
(MSK, EMSK, IV).  Since the lower layer handles caching, it cares
about key scope.

> This does not mean sending the AAA-Key to the ports, right? The ports
> may be on separate nodes (like in AC-AP separation in WiFi).

We have already had a suggestion that the term "AAA-Key" was a bad choice,
and I think this may have contributed to some of the confusion we are
seeing.  "Pass-through" invariance requires that EAP operate the same way
whether AAA is in use or not, so I think this criticism is quite valid.

The way to think about it is that the EAP method exports the parameters
(MSK, EMSK, IV, peer-ID, server-ID, method-ID, key-lifetime,
channel-bindings), and the EAP layer passes this down to the lower layer.

The EAP peer does not care what "mode" the authenticator is operating in;
it is the responsibility of AAA to make sure that this invariant is
maintained.

So perhaps a better way to describe what actually happens is that the
lower layer derives its key hierarchy from the MSK and EMSK and that it is
the job of AAA to make sure that this key hierarchy is present on both the
peer and authenticator.

For example, in 802.11i the key hierarchy is derived from the PMK (part of
the MSK), and therefore AAA takes responsibility for ensuring that the MSK
is replicated in "pass-through" mode so that the EAP peer doesn't need to
be aware of the mode on the authenticator.

Note that this illusion would be shattered were the peer to determine its
key hierarchy from the EMSK since current AAA implementations do not
replicate that parameter.

One way to understand some of the issues that arise with key management
extensions is to ask the question:

"Does this extension function without pass-through?"

For example, if the EAP server is present on the authenticator, the
completion of an EAP conversation cannot cause keys to exist on another
authenticator, without fundamentally changing the nature of EAP as a
two-party protocol.  Therefore any "extension" that proposes something
like this is incompatible with the EAP "pass-through" and "two party"
invariants.