Subject: [eap] EAP "v2" backwards compatibility

From: [email-masked] (Jacques Caron)
Date: Sun, 24 Feb 2002 11:18:30 +0100

Hi,

Some possibilities if EAP "v2" (e.g. with ACK'd success/failure) is 
different enough from the current EAP that backwards compatibility is an 
issue...

* Add a special "EAP version" method. The conversation would then look like:

Cl <- NAS        EAP Request/Identity
Cl -> NAS        EAP Response/Identity
       NAS -> AAA AAA Auth request Username=Identity
       NAS <- AAA AAA Auth Challenge EAP=Request/Version
Cl <- NAS        EAP Request/Version
Cl -> NAS        EAP Response/Version
       NAS -> AAA AAA Auth request Username=Identity, EAP=Response/Version
[... usual EAP Request/Response roundtrips...]
       NAS <- AAA AAA Auth Challenge EAP=Success
Cl <- NAS        EAP Success
Cl -> NAS        EAP Success ACK (in whatever form it may take)
       NAS -> AAA AAA Auth Request Username=Identity, EAP=Success ACK
       NAS <- AAA AAA Auth Accept EAP=Success
Cl <- NAS        EAP Success (completely redundant just to avoid changes to 
NAS)

If the Client is RFC2284, then it will respond to Request/Version with a 
Response/NAK, so the server and/or NAS know not to expect an ACK for 
Success, and do it the "old" way:

Cl <- NAS        EAP Request/Identity
Cl -> NAS        EAP Response/Identity
       NAS -> AAA AAA Auth request Username=Identity
       NAS <- AAA AAA Auth Challenge EAP=Request/Version
Cl <- NAS        EAP Request/Version
Cl -> NAS        EAP Response/NAK
       NAS -> AAA AAA Auth request Username=Identity, EAP=Response/NAK
[... usual EAP Request/Response roundtrips...]
       NAS <- AAA AAA Auth Accept EAP=Success
Cl <- NAS        EAP Success

If the client is EAPv2 and not the server, the client won't receive the 
Request/Version packet, and will know that no ACK is needed for Success (or 
might decide it doesn't want to authenticate):

Cl <- NAS        EAP Request/Identity
Cl -> NAS        EAP Response/Identity
       NAS -> AAA AAA Auth request Username=Identity
[... usual EAP Request/Response roundtrips...]
       NAS <- AAA AAA Auth Accept EAP=Success
Cl <- NAS        EAP Success

Issue: do NASes currently transmit EAP messages in AAA Challenge requests 
transparently (including Success)? Similarly, will they take any answer and 
send it to the server without trying to interpret it? If that's not the 
case, then in the first scenario, success and success ACK might need to 
look like EAP methods:

Cl <- NAS        EAP Request/Identity
Cl -> NAS        EAP Response/Identity
       NAS -> AAA AAA Auth request Username=Identity
       NAS <- AAA AAA Auth Challenge EAP=Request/Version
Cl <- NAS        EAP Request/Version
Cl -> NAS        EAP Response/Version
       NAS -> AAA AAA Auth request Username=Identity, EAP=Response/Version
[... usual EAP Request/Response roundtrips...]
       NAS <- AAA AAA Auth Challenge EAP=Request/Success
Cl <- NAS        EAP Request/Success
Cl -> NAS        EAP Response/Success ACK
       NAS -> AAA AAA Auth Request Username=Identity, EAP=Response/Success ACK
       NAS <- AAA AAA Auth Accept EAP=Success
Cl <- NAS        EAP Success (completely redundant)

Of course, Request/Version and Request/Success might be sub-types of one 
single method (as well as Request/Failure and any others in the same vein).

In this scenario, only clients and AAA servers would need to be modified.

* Use a different encapsulation, i.e. a different PPP/Ethernet frame type

This requires changes to both clients and NASes (and AAA servers, most 
probably), which would support rfc2284 and EAPv2 on different frame types. 
A bit of a waste, but if EAPv2 becomes significantly different from 
rfc2284, it might be needed. In short, this is a "wipe the board and start 
again" approach :-(

* Encapsulate EAPv2 within an EAP method

Here, EAPv2 packets would be encapsulated within regular EAP Request and 
Response packets, with a specific "EAPv2" method. For instance:

Cl <- NAS        EAP Request/Identity
Cl -> NAS        EAP Response/Identity
       NAS -> AAA AAA Auth request Username=Identity
       NAS <- AAA AAA Auth Challenge EAP=Request/Version
Cl <- NAS        EAP Request/EAPv2/Request/method
Cl -> NAS        EAP Response/EAPv2/Response/method
       NAS -> AAA AAA Auth request Username=Identity, 
EAP=Response/EAPv2/Response/method
[... further EAP Request/Response/EAPv2 roundtrips...]
       NAS <- AAA AAA Auth Challenge EAP=Request/EAPv2/Success
Cl <- NAS        EAP Request/EAPv2/Success
Cl -> NAS        EAP Response/EAPv2/Success ACK
       NAS -> AAA AAA Auth Request Username=Identity, 
EAP=Response/EAPv2/Success ACK
       NAS <- AAA AAA Auth Accept EAP=Success
Cl <- NAS        EAP Success (completely redundant)

This adds a bit of overhead to each packet, but it gives a lot more 
flexibility to EAPv2 (similar to what would be achieved with a whole new 
frame type as above), but doesn't require any changes to NASes. This might 
be needed if ever EAPv2 added any form of protection to the EAP packets 
themselves, for instance.

The drawback compared to the method above is that the Identity exchange is 
still unchanged (and hence unprotected), since the EAPv2 thing only happens 
once the AAA server is involved.

Comments welcome...

Jacques.

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