Skip to main content

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

Yes

(Mark Townsley)

No Objection

(Dan Romascanu)
(David Ward)
(Jon Peterson)
(Lisa Dusseault)
(Magnus Westerlund)
(Ron Bonica)
(Ross Callon)
(Tim Polk)

Abstain

(Russ Housley)

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

Lars Eggert No Objection

Comment (2007-06-20)
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

(Jari Arkko; former steering group member) Yes

Yes (2007-06-21)
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; former steering group member) (was Discuss, Yes) Yes

Yes ()

                            

(Chris Newman; former steering group member) No Objection

No Objection (2007-09-20)
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.

(Dan Romascanu; former steering group member) (was Discuss) No Objection

No Objection ()

                            

(David Ward; former steering group member) No Objection

No Objection ()

                            

(Jon Peterson; former steering group member) No Objection

No Objection ()

                            

(Lisa Dusseault; former steering group member) No Objection

No Objection ()

                            

(Magnus Westerlund; former steering group member) (was Discuss) No Objection

No Objection ()

                            

(Ron Bonica; former steering group member) No Objection

No Objection ()

                            

(Ross Callon; former steering group member) No Objection

No Objection ()

                            

(Sam Hartman; former steering group member) (was Discuss) No Objection

No Objection (2007-06-21)
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.

(Tim Polk; former steering group member) (was No Record, No Objection) No Objection

No Objection ()

                            

(Russ Housley; former steering group member) Abstain

Abstain ()