Transcript Document 7301719

PANA Issues and Resolutions
draft-ietf-pana-pana-17.txt
draft-ietf-pana-framework-09.txt
Yoshihiro Ohba
Alper Yegin
7/24/2007
IETF69 PANA WG
1
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
7/24/2007
IETF69 PANA WG
2
Lars Eggert’s Comment 1
• Issue: What must the PaC do when it receives the PANAAuth-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. "
7/24/2007
IETF69 PANA WG
3
Lars Eggert’s 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).
7/24/2007
IETF69 PANA WG
4
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/
7/24/2007
IETF69 PANA WG
5
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/24/2007
IETF69 PANA WG
6
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
"
7/24/2007
IETF69 PANA WG
7
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?
7/24/2007
IETF69 PANA WG
8
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?
7/24/2007
IETF69 PANA WG
9
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.”
7/24/2007
IETF69 PANA WG
10
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 2nd paragraph in Section 11.2 (the paragraph has the
warning on use of Algorithm AVP in the initial PSR/PSA
exchange)
7/24/2007
IETF69 PANA WG
11
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.”
7/24/2007
IETF69 PANA WG
12
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?
7/24/2007
IETF69 PANA WG
13
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.”
7/24/2007
IETF69 PANA WG
14
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
7/24/2007
IETF69 PANA WG
15
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 panaframework
7/24/2007
IETF69 PANA WG
16
Thank you!
7/24/2007
IETF69 PANA WG
17