Subject: Re: ipsra-pic compared to EAPoUDP

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

Hi Paal,

At 23:30 07/02/2002, Paal Engelstad wrote:
>IMO, the PANA protocol will be a lightweight protocol designed for a 
>particular task, reflected in our req. document (roaming/fast handoffs -- 
>re-authentication -- hooks for access control besides IPsec AH -- 
>disconnect, etc. etc.)
>
>I don't expect ending up with a solution running EAP-messages within 
>ISAKMP. - And then invent EAP-methods that will fullfill our requirements? 
>Well...
>
>I think we are looking for a far less complex solution.
>
>IMO, we are not going to invent new authentication methods. We MAY add 
>additional requirements to existing methods, but that won't comprise the 
>security of the method.
>
>I have been thinking more along the lines of say MD-5 Challenge/Response 
>(or something similar) for re-authentication, SRP for host-initiated 
>authentication, etc...
>
>Example:
>
>- Why wouldn't SRP do, for example? It is clearly defined, and it allows 
>diffent
>message formats. Thus, we may create a simple solution with only 4 messages.
>
>I think the DH-channel allows for user-passwords. The prize for this is of 
>course processing overhead, though.
>
>It is not yet clear in my mind, though, so I appreciate any comments that 
>can make things clearer.

You're frightening me, there. It looks like you want to invent new 
authentication protocols, when everybody is moving towards EAP, which is 
supported over PPP, Ethernet, and more to come for the front-end, and over 
RADIUS and Diamater for the back-end.

I clearly think that any solution would involve EAP, and is only a matter 
of encapsulation and associated local security mechanisms. Any other 
solution would require yet another set of back-end protocols, no 
compatibility with EAP/PPP or 802.1x, probably no extensibility, and no 
interworking with other authentication systems (e.g. EAP SIM and EAP AKA 
allow interworking with GSM and UMTS authentication systems, where you just 
need a gateway to convert back and forth between RADIUS and whatever the 
GSM authentication system is called).

The EAP methods clearly shouldn't be there to fulfill this workgroup's 
requirements, only the requirement of specific scenarios based on the 
client, the home server, and the expected access technologies. Indeed, EAP 
SRP will probably the most appropriate solution to most situations, no need 
to re-invent another SRP encapsulation.

Personally, I would even add carrying EAP as a requirement, either 
directly, or indirectly (compatibility with existing back-end AAA 
mechanisms and extensibility should pretty much force anybody to use it).

Jacques.

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

---

From: Paal Engelstad <[email-masked]>
Date: Fri, 8 Feb 2002 2:48:49 +0100

Hi Jacques,

I generally agree with you (-if I have understood you correctly).

Comments below,

> 
> Fra: Jacques Caron <[email-masked]>
> Dato: 2002/02/08 Fri AM 12:19:19 CET
> Til: Paal Engelstad <[email-masked]>
> CC: John Schnizlein <[email-masked]>, [email-masked]
> Tema: Re: ipsra-pic compared to EAPoUDP
> 
> Hi Paal,
> 

Do not let me frighten you. You should rely on the requirements document. That is the document we are going to work after. It explicitly says we shall not invent new methods.

Please, take a brief look at the EAPoIP document. It is simply a wrapper. Wrapping EAP payloads. The schemes is only explaing how entities MAY inter-operate.

Let us see if we can take existing PPP EAP messages, wrap it in UDP, and send it. Give us a chance to check if it may work!

I would not call that inventing new methods, it is more like inventing a new carrier that can replace PPP.

Thanks,
Paal