Subject: [eap] EAP Notification Survey Results

From: [email-masked] (Bernard Aboba)
Date: Sat, 5 Oct 2002 09:17:23 -0700 (PDT)

Based on the survey results (see below), I would like to propose the
following conclusions. Comments welcome.

a. EAP Notification Requests may be sent at any time by the authenticator.
   For example, they may arrive in the middle of a method exchange. An
   EAP Notification Request cannot be NAK'd.
b. An EAP Notification Response MUST be sent by the peer in response to
   an EAP Notification Request. The Response is sent automatically by
   the peer and confirms receipt, but does not indicate whether the user
   took any action in response to the message, or even whether the message
   was displayed to the user at all (e.g. it may be consumed by an
   embedded device).
c. EAP Notification Requests SHOULD be displayed or logged by the peer.
   It cannot be assumed that Notification Requests are available for
   processing by the running method.
d. EAP Notification Requests or Responses do not result in a state
   change.
e. EAP Notification is *not* an error indication.

Below find the original survey and posted responses.

Date: Wed, 2 Oct 2002 12:22:42 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: [eap] Notification survey

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)

--__--__--

Date: Wed, 02 Oct 2002 23:02:10 +0200
To: Bernard Aboba <[email-masked]>
From: Jacques Caron <[email-masked]>
Subject: Re: [eap] Notification survey
Cc: [email-masked]

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.

--__--__--

Date: Thu, 03 Oct 2002 13:00:01 +0300
From: Preeti Vinayakray <[email-masked]>
Organization: Nokia Research Centere
To: ext Bernard Aboba <[email-masked]>
CC: [email-masked]
Subject: Re: [eap] Notification survey

Hello:

Following ans. relevant to my EAP implementation

ext Bernard Aboba wrote:

> 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)
>

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
> a method exchange)
>

No,

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

No

>
> d. Whether you would be affected if EAP Notification were to be eliminated
> 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]  Fri Oct  4 09:53:16 2002
To: Bernard Aboba <[email-masked]>
Subject: Re: [eap] Notification survey

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.

> a. Whether you are using Notification as part of the method (e.g.
> 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
> a method exchange)

Sure.

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

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

> d. Whether you would be affected if EAP Notification were to be eliminated
> 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

Date: Thu, 3 Oct 2002 09:54:36 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: [eap] RE: Notification survey

For what it's worth,  here are some details on how Windows implements
Notification:

- EAP-Notification is out-of-band. The EAP layer automatically sends a
Notification Response; the Notification Request is not passed to the
currently running method.

- EAP-Notification can be sent at any time. There are no checks done when
the EAP-Notification arrives.

- Since EAP-Notification is not passed to the method, it does not result
in a state change.

- EAP Notification does not have support for internationalization. The
lack of language support means that there is no easy way to display a
message to the user in a language that they can be guaranteed to
understand.

- EAP-Notification does not result in a display to the user at present.

--__--__--