Subject: Re: [eap] Basic facts about EAP

From: Yoshihiro Ohba <[email-masked]>
Date: Sun, 01 May 2005 22:59:59 -0400

I have some comments.  Please see below.

On Sat, Apr 30, 2005 at 03:30:14PM -0700, Bernard Aboba wrote:
> > 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.

I am not sure if using an EAP method to carry the NAS-ID or port-ID
for Channel Bindings is really a good idea as it would actually make
the EAP method media-dependent while it would make EAP media
independent.

I have another way of channel bindings in my mind as follows.

- Let each EAP lower-layer identify the parameters that need channel
bindings.

- Let the identified channel binding parameters be carried from the EAP
authenticator to the EAP server outside the EAP layer or the EAP
method layer.  When a AAA protocol is used between the authenticator
and server, the channel binding parameters should be carried in the
AAA protocol.

- Let the EAP server use the obtained channel binding parameters to
derive a AAA-Key (or a better name for it) from the MSK.  The
following algorithm proposd by Jesse Walker is a good example of how
to do that:

     AAA-Key := kdf(MSK, NAS-ID)

I'd extend the algorithm something like:

     AAA-Key := kdf(MSK, channel-binding-parameters)

['channel-binding-parameters' include NAS-ID and maybe other
parameters as well.]

- When the possession of the AAA-Key is cryptographically verified by
the peer and authenticator within the EAP lower-layer or a secure
association protocol, channel bindings and verification of the
posession of the AAA-Key come together.

BTW, I have been thinking that EAP runs between EAP peer and EAP
authenticator, while EAP methods run between EAP peer and EAP server.
I mean that when pass-through authenticator is used, the backend EAP
authenticator on the EAP server is taking some task of the EAP
authenticator such as generation of EAP Requests (but it does not do
timer-based retransmission of EAP requests), but the EAP peer always
see its immediate authenticator (i.e., the pass-through authenticator
in this case) as its authenticator.  Am I wrong?

Regards,

Yoshihiro Ohba

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

---

From: Jari Arkko <[email-masked]>
Date: Mon, 02 May 2005 10:19:24 +0300

Hi Yoshihiro,

>(snip)
Yes, this is another approach to doing the bindings. I believe
we discussed this at some earlier time on the list. One problem
that was identified back then was that the set of parameters would
have to be pretty well specified so that everyone could actually
calculate the same key. If someone suddenly came up with a
new parameter (say, SSIDng) that somehow needed to be bound,
parties would have trouble getting to the same key.

The other approach is transporting opaque objects over EAP.
I don't necessarily think this makes either EAP or EAP method
layer media dependent. But certainly there has to be someone
in charge who can interpret the objects and check the binding.
Typically this would be the AAA server authorization logic. It
seems almost inevitable that if there's channel binding support,
then that part needs to know about it...

--Jari

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 2 May 2005 01:00:05 -0700 (PDT)

> the EAP method media-dependent while it would make EAP media

If the Channel Bindings are treated as opaque blobs, and are represented
as media-independent attributes, I don't think this creates a media dependency.

For example, NAS-Identifier, Called-Station-Id and Calling-Station-ID are
all media independent.

At least the way Channel Bindings are described in RFC 3748, Section 7.15,
it seems like the idea is to export the Bindings for verification by the
lower layer.

This seems like something that needs more explanation, though.  I will
file an issue on it and try to post some text to the list.
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: Yoshihiro Ohba <[email-masked]>
Date: Mon, 02 May 2005 09:55:03 -0400

Hi Jari,

> parties would have trouble getting to the same key.

Yes, the channel binding parameters would have to be pretty well
specified between the EAP peer and authenticator.  My point is that
this does not necessarily mean that using EAP method as the carrier of
the parameters is a better way.

> then that part needs to know about it...

Given that the channel binding parameters would have to be pretty well
specified between the EAP peer and authenticator, the authenticator
can send the opaque objects to the EAP server via a AAA protocol
(e.g., a channel-binding attribute/AVP).  The EAP server will be able
to calculate the AAA-Key without necessarily knowing the semantics of
the opaque objects.  What do you think?

Yoshihiro Ohba

---

From: Jari Arkko <[email-masked]>
Date: Mon, 02 May 2005 20:59:50 +0300

>the opaque objects.  What do you think?
Sure. In fact, we are mostly doing this already... almost all
information that
one can think of as being a channel property already has an associated
AAA attribute.

But I was more worried about how the peer and the AAA server can be in
sync about the parameters to be used. If they don't communicate over
EAP, this leaves only full one-time specification as an option. If they
communicate (as in various drafts that propose to do channel binding),
then the set of parameters can evolve.

--Jari

---

From: Yoshihiro Ohba <[email-masked]>
Date: Mon, 02 May 2005 12:18:14 -0400

> as media-independent attributes, I don't think this creates a media dependency.

When I was talking about channel bindings are treated via EAP methods,
I was referring to draft-arkko-eap-service-identity-auth-01.txt.  It
defines several IEEE 802.11 specific parameters such as BSSID and SSID
with assigning Parameters Identifiers for them.  I see this
media-dependent.  This I-D may be updated to support truely opaque
blobs, but I will still see an issue if all EAP methods that are
capable of deriving an MSK needs to carry the opaque blobs.

Regards,
Yoshihiro Ohba

---

From: Yoshihiro Ohba <[email-masked]>
Date: Mon, 02 May 2005 13:34:56 -0400

> then the set of parameters can evolve.

I don't really think that the peer and the AAA server need to be
syncronized about the exact parameters (that's why opaque blob can be
used for channel bindings), while I do think that the peer and the
authenticator (NAS) need to be synchronized about them.  

Also, I think that the peer and the authenticator need to be
synchronized about the parameters even in the case of stand-alone
authenticator (i.e., no AAA protocol) in order to avoid MiTM in
between.  In this case, the EAP lower-layer is surely able to bind the
AAA-Key to the parameters (binding based on using the parameters in
the key derivation algorithm) without carrying the parameters in the
EAP method.  I think we should use the same way of binding regardless
of whether there is a pass-through authenticator or not.  Otherwise,
if we use one channel binding method for the stand-alone authenticator
case and another channel binding method for the backend authenticator
case, it would not make the pass-through authenticator transparent to
the EAP peer.

Yoshihiro Ohba

---

From: Alper Yegin <[email-masked]>
Date: Mon, 02 May 2005 15:56:23 -0700

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. 

> 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

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

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

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

> server, so it both generates the Request and terminates the Response.

I've had a comment on this above.

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

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

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.

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

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

> like this is incompatible with the EAP "pass-through" and "two party"

Regards

Alper

---

From: Jari Arkko <[email-masked]>
Date: Tue, 03 May 2005 15:22:23 +0300

Hi Yoshihiro,

>case, it would not make the pass-through authenticator transparent to
I wonder if we are talking about the same thing here. I agree with
what you say is needed, but it seems like the above is more like the
secure capabilities negotiation requirement that we have placed on
the Secure Association Protocol.

As others have pointed out, the term channel binding may not be
the best choice. But at least the way it is defined in RFC 3748 and
the keying draft it seems to talk about an ability to match two
independent sources of information to each other:

Using such a protected exchange, it is possible to match the channel
properties provided by the authenticator via out-of-band mechanisms
against those exchanged within the EAP method. Where discrepancies
are found, these SHOULD be logged; additional actions MAY also be
taken, such as denying access.

To me this implies that we can't get this type of channel binding
without exchanging information on all sides of the peer - auth - server
triangle.

But perhaps we are talking about who should make the final
check, is it the peer, authenticator, server, or all of them. I've
been assuming it would be either the peer or the server, or
possibly both of them. What you have said has lead me to
reconsider this a bit. Perhaps all of the parties have an interest
in making sure the others are not fooling them.

--Jari

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 03 May 2005 09:17:51 -0400

Hi Jari,

> the Secure Association Protocol.

It looks like so.  In fact, I am currently thinking that (so-called)
channel binding should be part of secure association.

> without exchanging information on all sides of the peer - auth - server

Yes.

> check, is it the peer, authenticator, server, or all of them. 

I think this is a good catch of the essentials.

> I've

Thank you,

Yoshihiro Ohba