PANA%20Issues%20and%20Resolutions%20draft-ietf-pana-pana-17.txt%20draft-ietf-pana-framework-09.txt

1
PANA Issues and Resolutionsdraft-ietf-pana-pana-1
7.txtdraft-ietf-pana-framework-09.txt

• Yoshihiro Ohba
• Alper Yegin

2
Jari Arkkos 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
Lars Eggerts 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
Lars Eggerts Comment 2

• Issues on 2nd 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
Lars Eggerts 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
Magnus Westerlunds 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
Magnus Westerlunds 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 RANDIRT
• "

8
Sam Hartmans Comment 1Version 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
Sam Hartmans Comment 2IP address
re-configuration

• Issue Should PANA define one bit to indicate IP
  address re-configuration is needed after
  successful PANA authentication?
• Resolution?

10
Sam Hartmans 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
Sam Hartmans 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 2nd paragraph in Section 11.2 (the
  paragraph has the warning on use of Algorithm AVP
  in the initial PSR/PSA exchange)

12
Sam Hartmans 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
Sam Hartmans 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
Sam Hartmans 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
Sam Hartmans 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
Dan Romascanus Comment

• Issue pana-snmp draft is mentioned but its
  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
Thank you!