Subject: RE: [AAA-WG]: Another proposed change to Diameter NASREQ (EAP rou ndtrips)

From: [email-masked]
Date: Mon, 28 May 2001 12:36:52 +0300

Hello Bernard,

> RFC 2284  indicates that EAP Success and EAP Failure message are
> unacknolwedged. Therefore there is no way for an EAP Response 
> to be sent
> after that. 

I didn't mean that. My intention was to fix the fact that
an EAP-Success packet cannot contain any data by sending
that data in an EAP-Request. There could be better ways to 
fix this, such as issuing RFC2284bis which would support 
acknowledged EAP Success with encapsulated data.

Consider the following snippet of an EAP authentication: 

Peer            NAS         AAA Server
...

EAP-Response/X
--------------->  DER: EAP-Response/X
                  --------------->

                           The response is OK, and the peer
                           has been authenticated. Now the AAA 
                           needs to transmit session key data or 
                           other "auxiliary" data to the peer 
                           within an EAP-Request:

                  DEI: EAP-Request/X
 EAP-Request/X   <---------------
<---------------

EAP-Response/X (empty)
--------------->  DER: EAP-Response/X (empty)
                  --------------->

                  DEA: EAP-Success
 EAP-Success     <---------------
<---------------

Here the last EAP-response is empty (it is just an acknowledgement)
and the last NAS-AAA-NAS roundtrip is unnecessary and it could 
be avoided if the session key or other auxiliary data could be 
included in the EAP-Success. If we don't want to change EAP, then we 
could fix this by encapsulating an EAP-Request in a DEA message:

Peer            NAS         AAA Server
...

EAP-Response/X
--------------->  DER: EAP-Response/X
                  --------------->

                           The response is OK, and the peer
                           has been authenticated. Now the AAA 
                           needs to transmit session key data or 
                           other "auxiliary" data to the peer 
                           within an EAP-Request:

                  DEA: EAP-Request/X
 EAP-Request/X   <---------------
<---------------

EAP-Response/X (empty)
--------------->  
                  
 EAP-Success     
<---------------

> My answer to the situations where an EAP message isn't present, or
> disagrees with the Accept or Reject is for the NAS to *manufacture* an
> EAP-Success or Failure message rather than passing through 
> what is in the
> encapsulated EAP message. 

In this case, the NAS should first pass through the encapsulated
EAP message and then manufacture an EAP-Success after receiving
the last (empty) EAP-Response. The NAS knows it must do this because
the Diameter message (DEA) indicates success but encapsulates
an EAP-Request.

If the working group feels that this is something we want to do,
then I agree with you that we should try to fix this for
Radius too and issue an RFC 2869bis.

The fix I proposed for Diameter isn't "backward compatible" but 
the NAS needs to know this feature in order for things to 
work at all. I assume this wouldn't be a problem in Diameter as 
it isn't an existing (deployed) protocol, but such a requirement
would cause problems with Radius. So we may be able to do this
smarter in Diameter.

I think the three items listed in your e-mail below
are very relevant to the evolution of EAP. This optimization 
I'm proposing is related to the first item -- how to pass both
indication of success and some data to the peer
in a single AAA message. This EAP packet should be ack'ed so 
that the data is always delivered to the peer.

Regards,
Henry

> -----Original Message-----
> From: ext Bernard Aboba [mailto:[email-masked]]
> Sent: 27. May 2001 21:29
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: Re: [AAA-WG]: RE: Diameter Proposed Changes
> 
> 
> I think we are actually getting into some murky areas of RFC 
> 2869 here,
> and the solution is *not* to specify behavior for Diameter 
> alone, but to
> figure out what should happen and issue an RFC 2869bis, then 
> have Diameter
> inherit the correct behavior. 
> 
> 1. If a AAA server an Accept message with an EAP-Message inside not
> corresponding to a Failure or Success, this implies that the 
> user is to be
> let on. For PPP, RFC 2284 indicates that the peer is to be 
> able to discern
> Failure or Success by alternate methods (seeing NCP packets as an
> indication of Success, receipt of an LCP-Terminate as an alternate
> indication of Failure). For 802.1X, these alternate mechanisms are not
> available so that a manufactured EAP-Success or EAP-Failure 
> packet is sent
> instead. Note that this implies that the last encapsulated packet will
> actually not be sent to the peer. So in general, it seems to me that
> AAA servers terminating a AAA exchange this way will not be 
> obtaining a
> guaranteed result. 
> 
> 2. Sending an EAP-Response after an EAP-Sucess message is 
> illegal under
> RFC 2284, since Success messages are not ACK'd. This is what 
> leads to the
> need for "alternate" indication methods in RFC 2284, and the issues
> described in #1. 
> 
> 3. EAP authentication does *not* terminate on receipt of an
> encapsulated EAP-Success/Failure message from the AAA server, 
> but rather
> on receipt of an Accept/Reject indication. So if an 
> EAP-Success/Failiure 
> message is encapsulated in a Challenge rather than an Accept/Reject
> message, then authentication could continue, enabling more 
> than one EAP
> method to be used for a given session. However, it is not clear to
> me how the two auth methods would be bridged within AAA, 
> since there is no
> EAP-Response to be sent back to the AAA server as described above. The
> situation would be different if the other side initiated the 
> second EAP
> conversation, since then the packet sent after an EAP-Success 
> would be an
> EAP-Request.
> 
> 
> 
> 
>