Subject: RE: [eap] EAP-AKA review

From: <[email-masked]>
Date: Tue, 12 Oct 2004 12:12:24 +0300

Yoshihiro, Jari,

First of all, many thanks to Yoshihiro for reviewing EAP-AKA!

Please see my comment below.

> > The following text in section 9.6 made me come up with the 
> comment on
> > EAP Notification:
> > 
> > "
> >    Because EAP-AKA is not a tunneling method, 
> EAP-Request/Notification,
> >    EAP-Response/Notification, EAP-Success or EAP-Failure 
> packets are not
> >    confidential, integrity protected or replay protected. 
> On physically
> >    insecure networks, this may enable an attacker to mount denial of
> >    service attacks by spoofing these packets. As discussed 
> in Section
> >    4.4, the peer will only accept EAP-Success after successful
> >    authentication. Hence, the attacker cannot force the 
> peer to believe
> >    successful authentication has occurred when mutual authentication
> >    failed or has not happened yet.
> >                                                             
>                     
> >    The security considerations of EAP-AKA result 
> indications are covered
> >    in Section 9.8
> >                                                             
>                     
> >    An eavesdropper will see the EAP Notification, EAP_Success and
> >    EAP-Failure packets sent in the clear. With EAP-AKA, confidential
> >    information MUST NOT be transmitted in EAP Notification packets.
> > "
> > 
> > The text seems to indicate that there is some case in which EAP
> > Notification packets are sent in EAP-AKA, but I failed to find some
> > text that explains when they are sent besides AKA-Notification
> > packets.
> 
> Ah, I see the problem now. I don't think the intention was to
> allow EAP Notifications in any sense disallowed by RFC 3748.
> Perhaps we could delete the Notification parts from the above,
> or add a statement that the draft does not specify that they
> should be used and that if they are used they should be used
> according to RFC 3748. Henry?

The definition of the integrity protection security claim in RFC 3748 
says that "When making this claim, a method specification MUST describe the EAP 
packets and fields within the EAP packet that are protected."
There is similar language for other security claims, too.

The text in Section 9.6 discusses which EAP packets are protected,
and EAP Notifications are only mentioned in order to make it clear
that EAP-AKA does not protect them. Of course it is possible to 
specify the scope of protection without mentioning EAP Notifications
at all. So I think we could remove all discussion about EAP Notifications.
I could not find anything in RFC 3748 that would require the method
specification to state whether EAP Notifications are protected.

Best regards,
Henry
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: Jari Arkko <[email-masked]>
Date: Tue, 12 Oct 2004 13:13:32 +0300

Hi Henry,

> There is similar language for other security claims, too.

That's right, I forgot that.

> that EAP-AKA does not protect them.

That seems appropriate. Perhaps we just need to clarify that
EAP-AKA does not specify notifications need to be used, but
if they are used they should be used according to RFC 3748.
EAP-AKA does not need to prohibit Notifications, as far as
I can determine.

--Jari

---

From: Jari Arkko <[email-masked]>
Date: Tue, 12 Oct 2004 13:25:04 +0300

Hi Henry,

I'm opening another thread as there's part of this issue

> 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

---

From: Yoshihiro Ohba <[email-masked]>
Date: Mon, 11 Oct 2004 21:32:06 -0400

> EAP-AKA does not need to prohibit Notifications, as far as

RFC 3748 does not specify when to send an EAP-Request/Notification.
If EAP-AKA allows EAP Notification, but does not specify when to sent,
there is no specification so far that defines when to send an
EAP-Request/Notification during EAP-AKA.  It seems that there are two
choices:

(a) Have an explicit text saying that EAP-AKA does not prohibit EAP
Notification but it is out of the scope of the document as to when an
EAP-Request/Notification is sent within EAP-AKA.

(b) Just prohibit EAP Notifications during EAP-AKA.

My personal preference is (b) for simplicity unless there is specific
reason to allow EAP Notification during EAP-AKA in addition to
AKA-Notifications.

What do you think?

Yoshihiro Ohba