Subject: Simple PANA protocol

From: <[email-masked]>
Date: Mon, 3 Feb 2003 11:10:01 +0200

Hi,

I had some discussions with Dan Forsberg, and based on those
we sketched what might be called the "Simple PANA Protocol"
(or alternatively, EAP-over-UDP + some extra stuff). 

Here's a short proposal how the thing could work. 

- PaC-PAA communication uses UDP with a well-known port number (or
  numbers, like DHCP) at both ends. If the PaC starts the conversation
  (after it gets an IP address, for instance), it discovers the PAA by
  sending a packet to a well-known multicast IP address (Alternatively,
  we could use an "anycast" IP address like RFC 3068).

  If the client attempts to send packets which are then blocked, the
  conversation can also be started by PAA (or enforcement point) by
  sending a packet (Type=AuthenticationRequest) to the well-known port
  number (after which the client uses the discovery mechanism). This is
  also used to request reauthentication.

- After this, the PAA and PaC exchange EAP payloads. Depending on
  situation different EAP methods could be used. In some kind of
  broadband/ADSL/cable home connection, typical example would be
  MSCHAPv2 or PEAP-MSCHAPv2 (note: all references to PEAP assume that
  the tunneling-MITM-problem has been dealt by fixing PEAP to use 
  the keys generated by the inner methods). If the client has a 
  certificate, EAP-TLS could be used.

- If the EAP conversation ends successfully, both ends now have a key
  (if the PAA used e.g. RADIUS to pass the EAP payloads to a back-end
  server, then it receives the key from the RADIUS server, as usually in
  EAP. Note that it is not required to use RADIUS.). From this key, 
  two keys are derived: PANA conversation key, and a keying material
  for other protocols.

- Next, PaC and PAA bind the PANA conversation key to the context,
  e.g. by calculating HMAC-SHA1 over some relevant information and
  sending these to each other (this relevant information includes at
  least nonces generated by both parties, and perhaps the IP addresses).
  This conversation is not EAP anymore, and it is not passed to any
  back-end RADIUS server.

- Now the PANA conversation is done. Exactly how the rest of the
  traffic is protected is beyond the scope.

  The "keying material for other protocols" can be used for some 
  specific purpose outside the PANA scope (such as shared secret 
  for IKE, or some link-layer encryption), and it can be expanded to 
  multiple keys with some key hierarchy, if required.

  A more likely possibility is that the box connecting the user 
  to the network (cable/ADSL/access point/whatever) is responsible
  for allocating IP addresses (using e.g. DHCP), and can at least
  prevent address spoofing by other users. Thus more cryptography 
  is not required.

Notes:
- The PANA header after UDP handles includes at least a type field
  (discovery, eap, key-stuff-at-the-end), and a field for sequencing
  EAP packets. I haven't yet considered who is responsible for
  retransmissions, etc., 
- In this protocol, I consider, for instance, PEAP-MSCHAPv2 to be just 
  one EAP method from PANA's point of view (if it does some kind of 
  tunneling internally, we don't need to care about that).
- Depending on the environment, not all EAP methods might be suitable  
  (e.g. those which don't do mutual authentication and don't produce
  keys). I don't think this is a problem in practise.
- Some EAP methods do not protect the client identity (but e.g. 
  PEAP-MSCHAPv2 does).

Quite obviously, this is just a sketch how this might work, and 
certainly e.g. the "key-stuff-at-the-end" part requires some
clarification. 

The guiding idea is that "simpler protocols tend to be 
more secure in practise", but I don't know if made it too simple :-) 

Best regards,
Pasi