Subject: ipsra-pic compared to EAPoUDP

From: John Schnizlein <[email-masked]>
Date: Thu, 07 Feb 2002 16:18:27 -0500

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

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:12:52 +0100 (CET)

> would be comparable to pic.

It is definitely worth-while to understand PIC and how it might
fit the PANA requirements (re-use is a good thing).

Having read the PIC spec it seems like PIC could be use to
hand out some key and periodic communication using that key
would serve as a re-authentication and lack of such re-authentication would
be an implicit disconnect.

My 2 cents,

   Erik