eap Mailing List: EAP Notification MICs in RFC 3748 (Was: Re: [eap] EAP-AKA review)

[Jari Arkko (jari.arkko]

Hi Henry,

I'm opening another thread as there's part of this issue
that does not relate directly to EAP AKA. You said:

> I could not find anything in RFC 3748 that would require the method
> specification to state whether EAP Notifications are protected.

No, but there's in fact a note that identity and notification
contents could be useful to protect. See Section 7.5:

   Since EAP messages of Types Identity, Notification, and Nak do not
   include their own MIC, it may be desirable for the EAP method MIC to
   cover information contained within these messages, as well as the
   header of each EAP message.

Many methods cover these only partially, if at all. This isn't
a problem for RFC 3748 compliance, as "may be desirable" is not
a requirement. However, having thought about this in a few different
contexts of the last couple of weeks, I'm not so sure any more
if such protection is "desirable" at all. Here's a couple of
question marks that extensive coverage of MICs could bring up:

o  Given that EAP may be implemented in a three party configuration,
   I'm not sure if the contents or even number of EAP Identity
   messages is clear to all parties; an authenticator could do
   an identity requery before it ships the result and the rest of
   the authentication to a backend server.

o  Similarly, what if the authenticator sent a Notification saying
   "unknown realm" and then proceeded with a new EAP Identity Request
   before it gives the rest of the process to the backend server?
   How would the backend server know that such Notifications had
   been sent? (Or have those Notifications been prohibited somewhere?)

--Jari