Subject: [eap] Protocol used by both sides

From: Bernard Aboba <[email-masked]>
Date: Tue, 11 May 2004 21:35:35 -0700 (PDT)

A question has arisen in IEEE 802.11i about the meaning of the phrase
"protocol both executed" in the recommended resolution of Issue 224.

Some questions:

a. Does this refer to the EAP Type used by both sides?  Most current
   EAP methods do not include the Type field in MICs, so they do
   not verify this.

b. If we are talking about a protocol inside the EAP method, does this
   apply to protocol version numbers and other such state?

c. Can the text proposed in Issue 224 be operationalized? That is,
   is the text specific enough to make a judgement on whether a
   method satisfies the conditions?
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: Jari Arkko <[email-masked]>
Date: Tue, 18 May 2004 13:56:45 +0300

>    EAP methods do not include the Type field in MICs, so they do

Some older methods don't even generate keys, so those would not
include the EAP Type or anything else for that matter. Looking
at key generating methods, some do not take EAP Type into account
(e.g., EAP TLS) and some do (e.g., EAP AKA).

I think it would be prudent to include the context information
in new protocol designs. However, you might question whether
its necessary to include the EAP Type, if the formulas for
different methods are different? OTOH, this may not always
be the case. For instance, if EAP TLS does not include the
EAP Type in cryptographic protection, does it mean that EAP
TLS and another, new, TLS-based method could be switched
without the endpoints realizing this?

Also, even if method 1 and method 2 have a MIC
for the EAP Type, it does *not* guarantee that you
couldn't switch methods. Lets assume the two methods
calculate their MICs as follows:

    method_1_MIC = MAC_K(EAP Type | ... | Parameter 1)
    method_2_MIC = MAC_K(Parameter 2 | ... | EAP_Type)

where Parameter i is whatever other data that gets
included in the MIC. Now, we can substitute method 2
for method 1 as long as we set Parameter 1 = method 2's
EAP Type number and Parameter 2 = method 1's EAP Type
number. In order to avoid this, there would have to
be either (a) a common formula on what data methods
include in their MICs, or (b) include EAP Type in the
key derivation of AAA-Key. Both alternatives have a
number of problems, so it seems that we can't make
this bullet proof. An approch similar to channel
bindings might work better in this context.

Finally, executed EAP Type is just one part of the
"context" around an authentication method. You could
argue that we should also specify whether lower layer
and its properties should be included. But then we are
again in the realm of channel bindings, which we earlier
agreed should not be mandatory now, due to lack of
support in methods.

>    apply to protocol version numbers and other such state?

I think it should -- if the protocol in question has version
numbers. However, even this question is more complicated
than at first appears, so it may be hard to write down the
specific requirement. The use of extension AVPs under the
basic MICs should also be OK in addition to an explicit
version number.

>    method satisfies the conditions?

I think we can improve the text. I guess the question is
if we'll end up in the same situation as we did earlier
with PRIs, i.e., we gradually realize that we can't make the
text (or the scheme) bullet proof.

--Jari