Subject: [eap] Some questions about EAP Notifications

From: Bernard Aboba <[email-masked]>
Date: Tue, 15 Feb 2005 11:42:45 -0800 (PST)

I've received several questions recently from EAP implementors:

* Is it legal to send an EAP Notification as the first message in an EAP
exchange? (e.g. before EAP-Request/Identity or an EAP-Request for an
authentication method)

* Is it legal to send an EAP Notification in response to an
EAP-Response/Identity?

* After negotiation of an EAP authentication method is confirmed (e.g. an
EAP-Response with Type=X has been sent in response to an EAP-Request with
Type=X) is it possible to send an EAP Notification if the method
negotiated forbids notifications?  (e.g. can a Notification be sent after
the method completes,  instead of Success/Failure).

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

---

From: Jari Arkko <[email-masked]>
Date: Wed, 16 Feb 2005 15:35:37 +0200

Hi Bernard,

> exchange? (e.g. before EAP-Request/Identity or an EAP-Request for an

I think so. See Section 5.2 of RFC 3748 (emphasis
added):

    An authenticator MAY send a Notification Request to
    the peer *at any time* when there is no outstanding
    Request, prior to completion of an EAP authentication
    method.

Page 8 of draft-ietf-eap-statemachine-05.pdf seems to
confirm this, because allowNotifications is initialized
to TRUE.

> * Is it legal to send an EAP Notification in response to an

I think so. See Section 5.1 of RFC 3748:

    The Notification Request MAY be used to indicate an invalid
    authentication attempt prior to transmitting a new Identity
    Request (optionally, the failure MAY be indicated within
    the message of the new Identity Request itself).

(The last part of this text is funny, however, because we have
no bit in the Identity Request to indicate such things. I think
the text means that the mere reception of a new Identity
Request means that previous identity was invalid or insufficient.)

> the method completes,  instead of Success/Failure).

The answer that I found to this seems partial, but
it is at least clear that if the method forbids notifications
then the peer can't respond to them. By implication,
if the server sends notifications then it will have to
wait for the response and the process ends up in a timeout.

Section 5.2 of RFC 3748:

    The peer MUST respond to a Notification Request with a
    Notification Response unless the EAP authentication
    method specification prohibits the use of Notification
    messages.

--Jari

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 16 Feb 2005 06:36:14 -0800 (PST)

> Request means that previous identity was invalid or insufficient.)

Yes.  However, since both the EAP-Request/Identity and Notification can be
used to send a notice there is some overlap.  However, the
EAP-Request/Identity can also be used for Network Selection, so I guess
that might not leave enough space for a longer message.

> wait for the response and the process ends up in a timeout.

Yes.

---

From: Jari Arkko <[email-masked]>
Date: Wed, 16 Feb 2005 16:38:34 +0200

>>wait for the response and the process ends up in a timeout.

The part of that I did not find an answer to is when
the method's prohibition "ends", does it extend to
the Success/Failure, or only during its own run.

--Jari

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 16 Feb 2005 06:48:39 -0800 (PST)

> the Success/Failure, or only during its own run.

Section 2.1:

   An EAP conversation MAY utilize a sequence of methods.  A common
   example of this is an Identity request followed by a single EAP
   authentication method such as an MD5-Challenge.  However, the peer
   and authenticator MUST utilize only one authentication method (Type 4
   or greater) within an EAP conversation, after which the authenticator
   MUST send a Success or Failure packet.

So I conclude that if the method doesn't permit Notifications, then once
the method proposal is accepted, no Notifications are allowed from that
point forward.
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: Jari Arkko <[email-masked]>
Date: Wed, 16 Feb 2005 16:49:36 +0200

> the method proposal is accepted, no Notifications are allowed from that

Ok, good!

--Jari