eap Mailing List: RE: Basic facts about EAP

[Alper Yegin (alper.yegin]

Bernard,

Thank you for the elaborate response.

I understand that from EAP peer's perspective, there is only the
"authenticator." Though that is a step towards having a 2-party
protocol, the overall design has all the characteristics of a protocol
that has distinct 3 elements -- with the authenticator processing
(reading) and even generating and terminating EAP messages. (And at
least the other 2 are aware of what's going on). Going back to your
earlier TCP and IP routers example, this is way beyond what TCP expects
(or, defines) for IP routers to do.

This may all boil down to some semantics discussion. Is this a 2-party
protocol with a well-defined way to implement it using 3 elements? Or, a
3-party protocol that can be implemented as 2 parties? Or, a 3-party
protocol that one element sees the other two as one? In any case, adding
more parties to this design needs careful consideration.

More comments inlined below. 

> > 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.  

Is this aspect only applicable to the EAP peer? I think the
Authentication Server would know there is a middle man (authenticator).
Otherwise, it would be confused about the Response messages it gets for
the Requests sent by the authenticator.

> 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.

The text and even the diagrams in RFC3748 seem to indicate the "lower
layer" is run between the peer and authenticator. So, it does not really
cover RADIUS/Diameter.... Is that the intended use of this term? [This
is just a side question I've had before...]

> > - 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.

I may have missed this in any of the specifications (the termination on
the authenticator). But I have seen explicit mention of NAS forwarding
the Response/ID to the authentication server in RFC 3579 (Section 2.1).

> > - 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.

To me, this looks like an IP router peeking into the TCP header to drop
packets.

> > - 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.

I've had a comment on this above.

> > - It handles retransmissions and it can re-generate loss packets.
> 
> This is a responsibility that goes with forwarding EAP packets.

I think for a truly 2 party "EAP protocol", it should have been the
responsibility of the originator of the EAP message.

> > 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.

OK, that's what I was trying to get at. So, being in compliance with
that list is necessary but not sufficient to design a RFC3748-compliant
EAP lower layer.

> 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.

Actually, that's where I was going to get at... If the "EAP peer" does
not know about the separation of authenticator from the EAP server, than
for it to be talking about "a lying NAS" is strange. But your solution I
think handles this. But I guess we need some standard facilities in the
EAP that tells an EAP method/peer/layer to pass down a blob.

> 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.

Or, the other approach is to tell people to treat "AAA" as a generic
term, and not another name for "RADIUS" :-) Though this may be harder...

> 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.

Regards

Alper