Protocol for Carrying Authentication for Network Access (PANA)
RFC 5191
Yes
No Objection
Abstain
Note: This ballot was opened for revision 18 and is now closed.
Lars Eggert No Objection
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
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
(Chris Newman; former steering group member) No Objection
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
(David Ward; former steering group member) No Objection
(Jon Peterson; former steering group member) No Objection
(Lisa Dusseault; former steering group member) No Objection
(Magnus Westerlund; former steering group member) (was Discuss) No Objection
(Ron Bonica; former steering group member) No Objection
(Ross Callon; former steering group member) No Objection
(Sam Hartman; former steering group member) (was Discuss) No Objection
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
(Russ Housley; former steering group member) Abstain