Subject: [eap] Re: EAP "v2" backwards compatibility

From: [email-masked] (Bernard Aboba)
Date: Sun, 24 Feb 2002 09:54:06 -0800 (PST)

Jacques --

Thanks for characterizing the alternatives. As I see it, there are several
fairly important areas of functionality addition that are under
consideration. These include cryptographic protection of EAP, Vendor
specific support, and Type space expansion. In looking at the
alternatives, it might be useful to include thinking about their impact on
the possible functionality additions. So far, the thinking seems to be to
support cryptographic protection, Vendor-specific and Type space expansion
via allocation of new EAP Method Types, but that might not necessarily be
the best choice. 

Would you be willing to write up your analysis in the form of a draft for
presentation during the EAP BOF at IETF 53?

Comments below. 

>  Cl <- NAS EAP Request/Version 
>  Cl -> NAS EAP Response/Version 

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

Interesting. So with this alternative *one* new EAP method would be used
for negotiation of "optional" features. Presumably this new "capabilities
negotiation" method could handle negotiation of multiple capabilities all
in one shot.  

> Issue: do NASes currently transmit EAP messages in AAA Challenge requests 
> transparently (including Success)? 

According to RFC 2869, a Challenge is an indication of a continuing
conversation, and does not terminate the AAA exchange. However, if the
Challenge message were to include a Success which isn't ACK'd, then it's
not clear how the conversation could continue after that. If the Success
were ACK'd then this wouldn't be an issue. 

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

Depends on whether the negotiated capabilities can solely be provided by
the AAA server and client without NAS knowledge. I think that ACK'ing of
EAP Success may not fit into this category, since presumably the NAS needs
to retransmit a Success that isn't ACK'd, assuming that the feature has
been negotiated between AAA server and client. I think this means that a
NAS would need to have specific knowledge of the negotiation of an ACK'd
"Success/Failure" capability, no?

> * Use a different encapsulation, i.e. a different PPP/Ethernet frame type
> 
> 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 :-(

Yes. 

> * Encapsulate EAPv2 within an EAP method

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

Interesting. This one offers more NAS independence than the first
proposal, I think. I think it also implies that additional features are
negotiated as a set. This make it harder to roll out individual
improvements (e.g. Protection w/o ACK'ing or Type Expansion). But on the
other hand, it might make it more likely that the entire set of
improvements might be adopted as a unit. 

One of the complications of figuring out how to provide additional EAP
Types is that if handled through a separate EAP method, you could never
guarantee that an EAP implementation would support the expanded Types. 

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

Yes -- though the Identity required need only be a realm so as to route
the exchange to the correct AAA server.

---

From: [email-masked] (Jacques Caron)
Date: Mon, 25 Feb 2002 10:16:07 +0100

Hi Bernard,

>presentation during the EAP BOF at IETF 53?

I can write a draft, but IETF 53 is clearly not in my budget, so somebody 
else will need to present it (I can prepare slides for that if needed) :-(

>negotiation" method could handle negotiation of multiple capabilities all

Of course. I think the "Version" method would at least include some form of 
version number (in both directions) and a bitmap of features supported (or 
maybe even required).

>were ACK'd then this wouldn't be an issue.

Hence, I do not know how various implementations on the field handle 
different combinations of AAA answers and EAP packets. We already know of 
the problem of accept/success vs accept/failure vs reject/success vs 
reject/failure (which 802.1X addresses by ignoring the EAP packet, and 
sending a "canned" EAP packet based on the AAA response code), but I have 
no idea about what different implementations would do if they found a 
success packet in a challenge, for instance.

>"Success/Failure" capability, no?

If you look at the end of the last scenario:

       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)

There are two types of "success" messages. One (the first four lines above) 
which is hidden within a Request (and the response is the ack), and the 
other one (the last two lines) which is there just for backwards 
compatibility. In the last one, the important part is really the AAA -> NAS 
Auth Accept (which tells the NAS the important this: yes, you are allowed 
to let this guy access the network), the EAP success message itself is just 
there for fun. Of course, if the NAS knows this is no longer necessary, it 
does not need to send it.

>improvements might be adopted as a unit.

The EAPv2 method might start with some capabilities negotiation too.

>guarantee that an EAP implementation would support the expanded Types.

I don't see the problem? If the client does not support the EAPv2 method, 
then it will NAK it. If the client does not support a specific method 
encapsulated within the EAPv2 method, it will NAK it too (but this time the 
NAK will be EAPv2 encapsulated).

>the exchange to the correct AAA server.

Totally.

Jacques.

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