Protocol for Carrying Authentication for Network Access (PANA)
RFC 5191

Note: This ballot was opened for revision 18 and is now closed.

(Jari Arkko) Yes

Comment (2007-06-21 for -)
No email
send info
Great work, guys. This is much simpler than what we had
in the initial version.

Nit: In -framework, Section 2:

   When cryptographic access control is used, a secure association
   protocol (e.g., [RFC2409], [RFC4306], [802.11i]) needs to run
   between the PaC and EP.

I would suggest deleting the references or replacing them with
a reference to RFC 3748 or an informational reference to eap-keying.
The reason is to avoid any possibility of misunderstanding
whether PANA works out-of-the-box with, say 802.11i SAP.

(Mark Townsley) (was Discuss, Yes) Yes

(Ron Bonica) No Objection

(Ross Callon) No Objection

(Lisa Dusseault) No Objection

(Lars Eggert) No Objection

Comment (2007-06-20 for -)
No email
send info
Section 4.1., paragraph 12:
>    It is possible that both the PAA and the PaC initiate the PANA
>    session at the same time, i.e., the PAA unsolicitedly sends the
>    initial PANA-Auth-Request message while the PaC sends a
>    PANA-Client-Initiation message.  To resolve the race condition, the
>    PAA MUST silently discard the PANA-Client-Initiation message received
>    from the PaC after it has sent the initial PANA-Auth-Request message.

  And what must the PaC do when it receives the PANA-Auth-Request from
  the PAA that it didn't expect to get in response to its
  PANA-Client-Initiation message?

Section 6.1., paragraph 2:

>    For any PANA message sent from the peer that has initiated the PANA
>    session, the UDP source port is set to any number and the destination
>    port is set to the assigned PANA port number (to be assigned by
>    IANA).

  "source port is set to any number" - it'd probably be good if the node
  were able to receive packets sent to that port.

  Also, to make this work, you need to also require that all peers
  listen on the PANA port.

Section 7., paragraph 7:
>    message-name     = PANA-name

  ABNF warning: rule message-name previously referred to as Message-Name

(Sam Hartman) (was Discuss) No Objection

Comment (2007-06-21)
No email
send info
The PANA protocol document says that the derivation of keys for use in
setting up or binding to link or layer 3 security is out of scope.
That's fine and probably even a good idea.  however there needs to be
a single document that specifies this derivation that all the uses of
the PANA SA end up referring to.  IT would be inappropriate for the
PANA IPsec document to use one method and say a method to set up
preshared secrets for 802.11I to use another mechanism that might
interact badly with the ipsec mechanism.

(Chris Newman) No Objection

Comment (2007-09-20)
No email
send info
It might be wise to change occurrences of CFWS in the formal ABNF to:
   "[CRLF WSP] *WSP"
In order to avoid whitespace-only blank lines.  While this is not
particularly important for a formal language (as opposed to a machine
parsed language), that may better reflect how it will be used.

(Jon Peterson) No Objection

(Tim Polk) (was No Record, No Objection) No Objection

(Dan Romascanu) (was Discuss) No Objection

(David Ward) No Objection

Magnus Westerlund (was Discuss) No Objection

(Russ Housley) Abstain