Subject: RE: Comments on draft-ietf-pppext-eap-srp-01.txt

From: [email-masked]
Date: Thu, 12 Apr 2001 11:01:54 +0300

> From: ext Bernard Aboba [mailto:[email-masked]]

> In other words, according to RFC 2284, an EAP Success packet MUST
> NOT contain a type field or data. This is a result of the lack of
> ACK'ing, as described above. Given that EAP Success messages
> conforming to RFC 2284 do not contain data, existing implementations
> will typically not pass anything contained beyond the length field
> to the EAP method. There are also NAS devices that will not forward
> such packets on to the client.
> 
> My recommendation is to add an additional round-trip to the protocol
> and use the RFC 2284-defined EAP Success message. As much as I
> would love to fix RFC 2284 to permit this usage, I think
> that this would also require addressing the lack of ACKs for
> Success and Failure messages, which would create a backward
> compatiblity problem, so I can't see a way to make this work.

I guess this additional round-trip means that the last EAP-Response 
the client sends doesn't contain any actual data but it is just 
an acknowledgement.

Could we avoid the additional NAS-AAA-NAS round-trip by making the AAA
server 
indicate success already in the AAA message that contains the last
EAP-Request?
For example, the AAA server could include an attribute that tells the NAS
device
"if you recognize this attribute, you can consider the authentication
to be accepted". Hence, the NAS box could compose the EAP Success
packet to the client itself after getting the last EAP-Response fron the
client.

If the NAS doesn't recognize the new attribute, then things will still
work but an extra round-trip is required. So this fix would be backward
compatible.

Do you think this could work? It would be very nice to have some 
solution to avoid these extra roundtrips in EAP.

Regards,
Henry

---

From: James Carlson <[email-masked]>
Date: Thu, 12 Apr 2001 08:22:18 -0400 (EDT)

> the client sends doesn't contain any actual data but it is just 

Yes.  The last EAP Request would have the M2 value, and the last EAP
Response would be empty.

> Could we avoid the additional NAS-AAA-NAS round-trip by making the
> AAA server indicate success already in the AAA message that contains
> the last EAP-Request?

One could reasonably assert that sending the last EAP Request (at
least for EAP SRP SHA-1; where M2 is sent to the authenticatee) itself
indicates success as far as the AAA system is concerned.

Since I don't have a defined AAA usage (and the usage there has some
interesting twists; such as the bother with the shared encryption
key), I'm a little confused by the question.  I don't see where
there's an implication that the last empty EAP Response needs to go to
a AAA server for any sort of validation.

> For example, the AAA server could include an attribute that tells
> the NAS device "if you recognize this attribute, you can consider
> the authentication to be accepted". Hence, the NAS box could compose
> the EAP Success packet to the client itself after getting the last
> EAP-Response fron the client.

I see no reason that can't be part of the definition of the AAA
interface for this protocol, if one were defined.

> solution to avoid these extra roundtrips in EAP.

I'm not sure why the extra authentication messages are considered to
be a problem, but the solution you've suggested makes sense to me.
(That itself might not be a good thing .... ;-})

-- 
James Carlson, Internet Engineering       <[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