Subject: draft-engelstad-pana-eap-over-ip-01.txt

From: Jacques Caron <[email-masked]>
Date: Fri, 08 Feb 2002 00:24:51 +0100

Hi Paal,

A quick idea that came to me the other night...

You might want to add something in the encapsulation of EAP in UDP that 
allows some information about the specific connection that is trying to be 
authenticated.

This might include layer (e.g. L2 vs application), protocol, and source port.

This would allow:
- to add some security to the EAP/UDP client (e.g. accept only connection 
(L2) authentication requests from a "local" box, on the same subnet that 
the interface the auth is received on)
- for (interim) application-level authentication to allow proxies and NAT 
boxes to associate the EAP/UDP request with a specific connection, and 
hence a specific client.

Let's say for instance that an HTTP server wants to EAP authenticate an 
HTTP client, and EAP over HTTP is not available (on the client). The server 
sends an EAP over UDP request to the IP of the client (or what it thinks is 
the client, it may be a proxy). This packet would include some information 
like "TCP from port xxx" (the source port of the HTTP request).

If this gets to the client directly, then the client can answer no problem 
(and it will know what the authentication is for, and can present that to 
the user, eventually).

If this gets to a proxy or NAT box, the box can then look up what 
connection is currently active from TCP port xxx, and trace it back to the 
real client, and then act as a gateway between the two.

Please note that I still believe the whole EAP/UDP thing is only an interim 
measure, but if it's done, it should at least be generalized as much as 
possible.

Jacques.

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