Subject: Re: ipsra-pic compared to EAPoUDP

From: Paal Engelstad <[email-masked]>
Date: Thu, 7 Feb 2002 23:30:11 +0100

John,

"EAPoUDP" is fine.

Comments inline.
 
> Fra: John Schnizlein <[email-masked]>
> Dato: 2002/02/07 Thu PM 10:18:27 CET
> Til: [email-masked]
> Tema: ipsra-pic compared to EAPoUDP
> 
> I don't understand the motivation for creating a new protocol to do a
> subset of what is already further along the standards process. The
> security analysis that would be required before PANA could advance has
> already been done for pic by the relevant WG. Once the issues that come
> up in a security analysis are resolved, it is possible that the result
> would be comparable to pic.
 
> Both pic and EAPoIP (actually EAPoUDP) use EAP with UDP for transport.

Yes, many protocols do ;-)

> The AS defined in pic looks the same as the PAA, with the exception
> that the AS explicitly supports use of the Internet Standard AAA back-end.
> 
> Once the authentication is performed, and the client obtains the credential,
> there is no reason that pic could not be used for anything PANA could be
> used for - it need not be used exclusively to establish an IPsec SA.

I think it may work as the initial authentication method, but I am not convinced it represents a solution we would find aceptable.

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.

Paal

> 
> Other contributors have indicated that the client's initial discovery of
> the address of the AS (aka PAA) would likely be through DHCP, because
> of the difficulty of resolving a more general discovery process.
> 
> Excerpts from the relevant drafts:
> 
>  From draft-ietf-ipsra-pic-04.txt:            
>    This document presents a method to bootstrap IPSec authentication via an 
>    "Authentication Server" (AS) and legacy user authentication (e.g., 
>    RADIUS). The client machine communicates with the AS using a key exchange 
>    protocol where only the server is authenticated, and the derived keys are 
>    used to protect the legacy user authentication. Once the user is 
>    authenticated, the client machine obtains credentials from the AS that 
>    can be later used to authenticate the client in a standard IKE exchange 
> 
>  From draft-engelstad-pana-eap-over-ip-01.txt:
>         EAPoIP MAY initially be used to establish a local security
>         association (e.g. in terms of a session key) between a host and a
>         PAA...
> 
>         EAPoIP is essentially a variation of the Extensible Authentication
>         Protocol (PPP EAP) [2]...
> 
>         EAPoIP need to use a transport protocol. Since EAPoIP is basically a
>         client/server protocol, and since the PANA WG is opting for a
>         lightweight solution, UDP is proposed. 
> 
> At 03:36 PM 2/7/2002, Paal Engelstad wrote:
> >John,
> >
> >> so that PANA would be extra in those cases. For other cases, would not
> >> EAP over UDP, which is already in last call in the ipsra WG, suffice? 
> >> [draft-ietf-ipsra-pic-04.txt]
> >
> >We do not need anything this complex. The only thing we need IMO is what EAPoP provides:
> >
> >- An EAP-like message wrapper, and 
> >
> >- 4 Mandatory Request/Response types:
> >
> >  - NAK
> >  - Host-initiated Initial Authentication
> >  - Server-initiated Initial Authentication
> >  - Re-Authentication
> >  - Disconnect Notification
> >
> >Modular approach. Lightweigt. Easy to deal with. Easy to specify.
> >
> >See the draft EAPoIP-draft. 
> >
> >Paal
> 
>

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 12 Feb 2002 22:19:08 +0100 (CET)

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

Wouldn't that depend on the threat analysis for PANA resulting in security
requirements for PANA?

If those requirements end up saying that PANA needs to run over secure channel
for whatever reason than doing what PIC does (IKE phase 1 which is essentially
a DH exchange and then EAP on top of that) *might* be a reasonable piece
of the puzzle.

IMHO dismissing solutions before the requirements are finished might be
premature.

  Erik