Subject: RE: [AAA-WG]: [Issue] EAP Support issues

From: Jacques Caron <[email-masked]>
Date: Mon, 18 Jun 2001 16:46:28 +0200

At 16:42 18/06/01, [email-masked] wrote:
>   If an EAP Request is encapsulated within an Access-Accept or
>    Access-Reject, then the NAS MUST relay the encapsulated EAP
>    Request to the peer. The NAS MUST retransmit the EAP Request
>    to the peer until a Response packet with the same Identifier is
>    received or an optional retry counter expires. The NAS MUST NOT
>    send the received Response packet to the AAA server but it MUST
>    discard the Response packet. On receipt of the Response packet,
>    the NAS MAY manufacture an EAP-Success or an EAP-Failure (depending
>    on the Diameter message type) and send it to the peer.

This is contrary to IEEE 802.1X, which states that as soon as an Accept or 
Reject is received (whether it contains an EAP packet or not), a "canned" 
EAP Success or Failure should be sent to the peer.

Jacques.

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 19 Jun 2001 23:17:04 -0700 (PDT)

Some more discussion on EAP issues. One question (which is really an EAP
issue) is whether it is possible to authentication with several EAP
methods, one after another, and if so, how this is done in AAA. 

1. Serial reauths. With this technique, you do one EAP auth, send an EAP
success, and then do another one. The re-auth can be NAS initiated, or
server initiated. If NAS initiated, you need a way for the AAA server to
tell the NAS "reauthenticate right away!". It has been suggested that this
can be accomplished within RADIUS by setting Session-Time=0 and
Termination-Action=Radius-Request. If server initiated (Diameter can do
this, but RADIUS can't), then the server can send a Challenge to the NAS
with an encapsulated EAP-Message attribute to start the next auth. 
The question with serial reauths is whether an EAP-Success can be
encapsulated in a Challenge packet so that the NAS won't let the user have
acess until the last auth Accept/EAP-Success is sent. Assuming that the
re-auth is driven correctly (by NAS with Session-Time=0 or by
server),allowing this might not be so bad after all. What do people think?

2. Multiple auths with one EAP-Success. It's been pointed out that an EAP
conversation already involves multiple methods (Identity, MD5, etc.). So
why can't the AAA server not send the EAP-Success, and start another EAP
type instead? To the NAS this looks like one conversation, it won't be
looking at the changing EAP types. When the last auth completes, an
EAP-Success is sent. This technique requires no changes to AAA; but if we
think this functionality is useful/necessary it might be worth pointing
out that it can be done. I think that in some respects it is cleaner than
method #1: the client is not fooled into thinking it has network access
when it doesn't. 

Additional issue:
* Is it possible to send Key attributes in an Access-Challenge so as to
turn on encryption in the middle of an authentication conversation? I vote
no on this since at least in PPP, you can't do ECP until you've finished
LCP. If you want this, you can finish one auth, send a Success and keys,
then do re-auth. So I think it's not necessary.