1. 7/24/2007IETF69 PANA WG1 PANA Issues and Resolutions draft-ietf-pana-pana-17.txt draft-ietf-pana-framework-09.txt Yoshihiro Ohba Alper Yegin

2. 7/24/2007IETF69 PANA WG2 Jari Arkko’s Comment Nit: In pana-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 Resolution: Replacing the references with RFC 3748

3. 7/24/2007IETF69 PANA WG3 Lars Eggert’s Comment 1 Issue: 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? Resolution: Add text (blue-colored one) to Section 4.1 to describe the behavior to cover the case: –"When the PaC receives the initial PANA-Auth-Request message from a PAA, it responds with a PANA-Auth-Answer message, if it wishes to continue the PANA session. Otherwise, it silently discards the PANA-Auth-Request message. "

4. 7/24/2007IETF69 PANA WG4 Lars Eggert’s Comment 2 Issues on 2 nd paragraph of Section 6.1 –"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. Resolution: Revise the paragraph as follows (blue colored text is added) For any PANA message sent from the peer that has initiated the PANA session, the UDP source port is set to any number on which the peer can receive incoming PANA messages and the destination port is set to the assigned PANA port number (to be assigned by IANA). For any PANA message sent from the other peer, the source port is set to the assigned PANA port number (to be assigned by IANA) and the destination port is copied from the source port of the last received message. In case both the PaC and PAA initiates the session (i.e., PANA-Client-Initiation and unsolicited PANA-Auth-Request messages cross each other), then the PaC is identified as the initiator. All PANA peers MUST listen on the assigned PANA port number (to be assigned by IANA).

5. 7/24/2007IETF69 PANA WG5 Lars Eggert’s Comment 3 Issue: Section 7., paragraph 7: message-name = PANA-name ABNF warning: rule “message-name” previously referred to as “Message-Name” Resolution: s/message-name/Message-Name/

6. 7/24/2007IETF69 PANA WG6 Magnus Westerlund’s Comment 1 Issue: What language is used to provide the declarations present in section 7.2 to 7.7? A reference to the definition of this language is required. Resolution: Change the following text in Section 7: "PANA message definitions include a corresponding ABNF [RFC4234] specification, which is used to define the AVPs for that PANA message type, and whether or not each AVP is Mandatory. The following format is used in the definition:" to: "The language used for PANA message definitions (i.e., AVPs for that PANA message type, and whether or not each AVP is Mandatory) in Sections 7.1 through 7.7 is defined using ABNF [RFC4234] as follows:” Also, added extra rules on white spacing and line breaks in the language definition

7. 7/24/2007IETF69 PANA WG7 Magnus Westerlund’s Comment 2 Issue: Section 9. There is unclarity on if IRT is absolute time value or an amount of time. Based on the formulas the later, but that is not clear in the text definitions. Also the definition of RT is a bit of. RT is the amount of time from the previous transmission, while the initial definition may mislead one to think it is an absolute time. Resolution: Change Section 9 as follows: " RT Retransmission timeout from the previous (re)transmission IRT Base value for RT for the initial retransmission " RT for the first message retransmission is based on IRT: RT = IRT + RAND*IRT "

8. 7/24/2007IETF69 PANA WG8 Sam Hartman’s Comment 1: Version Negotiation Issue: How a pair of PANA nodes can negotiate on a single version Alternative approaches: –Alternative 1: Add “version unsupported” error indication Issue: There is no PANA error message any more (it was removed entirely from the spec to deal with error indication DoS attack) –Alternative 2: Try multiple versions sequentially or in parallel Issue: Not so much efficient –Alternative 3: Remove Version field Issue: What to do when a new version is defined? Resolution?

9. 7/24/2007IETF69 PANA WG9 Sam Hartman’s Comment 2: IP address re-configuration Issue: Should PANA define one bit to indicate IP address re-configuration is needed after successful PANA authentication? Resolution?

10. 7/24/2007IETF69 PANA WG10 Sam Hartman’s Comment 3 Issue: It seems that the mandatory to implement behavior from the protocol document is support for integrity of PANA messages using EAP methods that produce MSKs but no mandatory to implement support for link security either at layer 2 or 3. If so, please make this clear in the framework document. Resolution: Add the following text in Introduction section: “While mandatory to implement behavior for a PANA deployment is the integrity of PANA messages when the EAP method produces MSK, there is no mandatory to implement support for network security either at the link-layer or network-layer.”

11. 7/24/2007IETF69 PANA WG11 Sam Hartman’s Comment 4 Issue: It is better to allow algorithm negotiation –The negotiation needs to protected afterwards once a key is established Resolution: Define algorithm negotiation mechanism –Separate Algorithm AVP into two AVPS Integrity-Algorithm AVP and PRF-Algorithm AVP –Negotiate it during the initial PAR/PAN exchange (i.e., the exchange with S-bit is set) –Protect the negotiation by including the initial PAR/PAN messages into the PANA_AUTH_KEY computation –Remove the 2 nd paragraph in Section 11.2 (the paragraph has the warning on use of Algorithm AVP in the initial PSR/PSA exchange)

12. 7/24/2007IETF69 PANA WG12 Sam Hartman’s Comment 5 Issue: Section 5.5 of the protocol document should include a rule that messages expected to have an auth attribute but which do not do so MUST be discarded. You need to specify which messages are expected to have auth attributes (presumably all of them after a completed authentication with an EAP method that generates an MSK). Resolution: Change the following text in Section 5.5: –“When an AUTH AVP is included, the AVP value matches the hash value computed against the received message.” To: –“Once the PANA authentication succeeds using a key-generating EAP method, the PANA-Auth-Request message that carries the EAP Success and any subsequent message in that session contain an AUTH AVP. The AVP value matches the hash value computed against the received message.”

13. 7/24/2007IETF69 PANA WG13 Sam Hartman’s Comment 6 Issues: –Concern on pana-pana security consideration section that physical security (e.g., DSL) provides protection of confidentiality and spoofing A better way to state this is that the environment provides adequate protection against spoofing and confidentiality based on the operational needs of the environment –Concern on the blanket claim that if a link does not provide security then security is required at a higher layer PANA integrity protection is required, but for example I don't see why data origin authentication or connectionless integrity is required for most Internet traffic Rework on the security considerations section to talk a lot more about tradeoffs and a lot less about hard requirements. Some hard requirements are probably still necessary Resolution?

14. 7/24/2007IETF69 PANA WG14 Sam Hartman’s Comment 7 Issue: I am uncomfortable with the recommendation of EAP methods like MD5 even when link security is available. Can you please work with the EAP and EMU working groups and see if they support this recommendation in the framework document? Resolution: Remove the following sentence from Section 4 of pana-framework draft “For example, weak authentication methods, such as EAP-MD5, may be used for such networks but not for the others.”

15. 7/24/2007IETF69 PANA WG15 Sam Hartman’s Comment 8 Issue: –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 –There needs to be a single document that specifies this derivation that all the uses of the PANA SA end up referring to Resolution –Define a separate document for key derivation for lower-layer ciphers

16. 7/24/2007IETF69 PANA WG16 Dan Romascanu’s Comment Issue: pana-snmp draft is mentioned but it’s status is Dead –Does the WG still considers pana-snmp part of the framework? –If so, the draft needs to be resuscitated and reviewed by the SNMP experts in order to validate its usage Discussion: –Similar to PaC-EP protocol PAA-EP protocol mostly dependent on each deployment WiMAX uses R6, some WiFi uses CAPWAP, some ADSL would be using ANCP, etc. Resolution: Informatively list possible protocols (excluding SNMP) for PAA-EP protocol part in pana- framework

17. 7/24/2007IETF69 PANA WG17 Thank you!