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

From: Paal Engelstad <[email-masked]>
Date: Fri, 8 Feb 2002 3:07:23 +0100

Jaques,

This is a great idea you are bringing forward. I got most of it. I think that the device identifier in the requirement draft was intended to be a data object carrying just this kind of information. 

But untill now people have talked about that object being carried either implicitly in the packet header (which is a layering violation I don't like) or within the EAP payload (which may not be possible with some existing EAP methods).

I had hoped to piggyback this information on the user identifier in the payload (that is "redefining" the format of a user identifyer in the PANA context. The integrity of the device identifier would then be protected.

I think the information that you convey would need to be integrity protected. Wouldn't it?

Did I translate your ideas into my own terminology, or did I miss your point?

I think the ussue you are raising about how to convey this information represents an important design desision that the WG eventually will have to discuss.

The whole concept is not yet clear in my mind though, but if you get this clearer in YOUR mind (or get other ideas of how to move the EAPoIP draft in what you think is the right direction) I would appreciate to hear about it. I am currently revising the document.

Thanks a lot,
Paal

> 
> Fra: Jacques Caron <[email-masked]>
> Dato: 2002/02/08 Fri AM 12:24:51 CET
> Til: Paal Engelstad <[email-masked]>
> CC: [email-masked]
> Tema: draft-engelstad-pana-eap-over-ip-01.txt
> 
> 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
> 
>