Subject: [eap] Notification survey

From: [email-masked] (Bernard Aboba)
Date: Wed, 2 Oct 2002 12:22:42 -0700 (PDT)

In the EAP Design team meeting today, we discussed the use of EAP
Notification. The question arose as to what people are using this for
today, and why. If you have implemented EAP Notification in your method
(or your EAP implementation), can you let us know:

a. Whether you are using Notification as part of the method (e.g.
Notification Request is delivered to the method)

b. Whether you allow Notification to be sent at any time (in the middle of
a method exchange)

c. Whether Notification results in a state change within the EAP state
machine or not

d. Whether you would be affected if EAP Notification were to be eliminated
or deprecated, and why this would be bad (or good)

---

From: [email-masked] (Jacques Caron)
Date: Wed, 02 Oct 2002 23:02:10 +0200

Hi,

I don't use it (yet), but:

a. I definitely believe a method on the client side shouldn't expect any 
such messages (there should be a generic method handler for it that will 
just display the message to the user - a bit like there should be a generic 
identity method handler that just returns the identity).

b. It should be possible to possible to send this nearly at any time:
- there should be only one outstanding request (i.e. not possible to send a 
Notification request just after some other method request before the 
response came back)
- at the very least it should be possible to use it between two requests 
from different methods, not necessarily in the middle of the exchanges of 
one given method.

c. Receiving a Notification request should prompt a Notification response, 
and then return to the same state. If the message is displayed via some 
kind of alert/dialog box (that requires user action), the question of 
whether the response is sent immediately or once the user acknowledges the 
dialog box remains open (in that last case there would be an intermediate 
state, I guess).

d. I believe it's useful to be able to send clear-text messages to the 
client, in the following (non-exhaustive list of) cases:
- an authentication method failed, and the method wants to give the user 
more information about why
- a method (maybe not an authentication one, more an authorization one) got 
a NAK back, and the method wants to tell something to the user anyway (e.g. 
connection cost)
Of course the problem of the authenticity of the message is present, but 
that's a more general problem of EAP messages...
An important point is that one should just not consider that the message 
will actually be seen and/or interpreted by anyone, it's purely informative.

Just my 0.02 EUR.

Jacques.

At 21:22 02/10/2002, Bernard Aboba wrote:
>_______________________________________________
>eap mailing list
>[email-masked]
>http://mail.frascone.com/mailman/listinfo/eap

-- Jacques Caron, IP Sector Technologies
    Join the discussion on public WLAN open global roaming:
    http://lists.ipsector.com/listinfo/openroaming

---

From: [email-masked] (Preeti Vinayakray)
Date: Thu, 03 Oct 2002 13:00:01 +0300

Hello:

Following ans. relevant to my EAP implementation

> Notification Request is delivered to the method)

Yes,  it is used as a part of the method

> b. Whether you allow Notification to be sent at any time (in the middle of

No,

> c. Whether Notification results in a state change within the EAP state

No

> or deprecated, and why this would be bad (or good)

This very much depends on how implementation is done. In terms of my
implementation I consider it is 'good 'as a part of methods I have
supported,  But it does not change any state info for client/peer. It just
provides some line display. So elemination of this not going to affect.

-Preeti

---

From: [email-masked] (James Carlson)
Date: Fri, 4 Oct 2002 13:52:48 -0400

> (or your EAP implementation), can you let us know:

I have this implementation:

	ftp://playground.sun.com/pub/eap/index.html

and I'm working on updating it and integrating it into 'pppd' (since
I'm now one of the maintainers of that software) for the next release.

> Notification Request is delivered to the method)

No, it's not part of the method.

> b. Whether you allow Notification to be sent at any time (in the middle of

Sure.

> c. Whether Notification results in a state change within the EAP state

No.  Nothing in the RFC describes it being used that way ...

> or deprecated, and why this would be bad (or good)

I wouldn't be affected.  I never send them, and I just log them if
received (and of course send ack).

I don't think it would be good to remove this message.  I like having
a "I think this is interesting for you to log" message for debug and
deployment reasons.  If, however, we fixed 'Success' and 'Failure' to
be able to include a debug text message (as I think they ought to have
from the start), then I'd be somewhat happier with losing
Notification.  (Not perfect, but good enough.)

(I also think that the possible i18n concerns and the spamming
concerns are misplaced -- the receiver can do anything it likes with
these, including discarding the text.)

-- 
James Carlson, Solaris Networking         <[email-masked]>
SUN Microsystems / 1 Network Drive         71.234W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.497N   Fax +1 781 442 1677