Download presentation
Presentation is loading. Please wait.
1
Open issues with PANA Protocol
IETF59 Yoshihiro Ohba/Basavaraj Patil
2
Issue 52: Details of double authentication
Issues: It is not clear whether NAP/ISP separate authentication is actually supported or not Some AVPs are not needed in the first PBR Device-Id, Session-Lifetime, Protection-Capability It might be better to provide functionality to abort session when the 1st EAP round fails Cryptographic binding between the 1st and 2nd EAP rounds is needed Proposed resolution Clarified text will be added It might be better to define a new PANA message for delimiter between 1st and 2nd EAP rounds Re-use of S-bit in authentication phase (S-bit is currently used in discovery and initial handshake phase only) The 2nd EAP round must be protected with a MAC AVP unless lower-layer is secured This means that the 1st EAP round must generate a key
3
Issue 53: Additional discovery information
It might be useful if additional information to identify a PAA is carried in the discovery and initial handshake phase Multi-interface PAA with serving multiple IP subnets can advertise the same PAA identity PaC can perform re-authentication based on PRAR/PRAA exchange when it moves to another subnet as long as it communicates with the “same” PAA Resolution: Define PANA Session-Id to have the same format as Diameter Session-Id Diameter Session-Id AVP contains globally unique NAS identifier
4
Issue 54:Mandatory cookie
Inclusion of the cookie at the start of the PANA exchange be mandatory Justification: Protocol becomes simpler Discussion: Carrying EAP AVP and the cookie together in PANA-Start-Request cannot be “stateless” Resolution?
5
Issue 55:Client cookie is useful
Would it be useful for the client to provide its own cookie as well Justification: This would cost very little, but protect the client against blind PAA spoofing attempts Discussion: The type of DoS attacks between the PaCs and PAAs are not symmetrical. PaC does not need to communicate with multiple PAAs in parallel Is there any DoS prevention such a cookie can provide? Resolution?
6
Issue 56: AAA routing based on NAI vs. ISP choice clarification
Section 4.2 claims that AAA routing is based on the ISP choice. The first hop decision can be based on this, but further on in the network it must be based on the NAI Discussion: Only the destination-host/realm can be inferred from the ISP choice. The rest of the AAA routing will be based on them (not the ISP choice) Resolution: Section 4.2 will be revised to clarify this
7
Issue 57: PSR retransmission strategy
Currently PANA-Start-Request is not retransmitted and initial handshake will stall when unsolicited PSR is lost Discussion: How about making both PSR and PSA to be retransmitted? Retransmission of PSR conflict with stateless discovery (i.e., with insertion of cookie) Proposed Resolution: Stateless discovery: PSA is retransmitted Stateful discovery: PSR is retransmitted Stateless Discovery Stateful Discovery PDI PSR[Cookie] PSR PDI(retransmitted) PSR(retransmitted) PSR[Cookie] PSA PSA PSR(retransmitted) PSA(retransmitted) PSA
8
Issue 58: Fast-reauthentication and authorization
PANA optionally supports mobility optimization but there are a number of security issues at the system level when the mobility optimization is done based on context transfer between PAAs. See draft-ietf-eap-keying-01.txt, Sections 1.4 and in particular for some examples Proposed Resolution: we should minimally update the text to take people's attention to these issues.
9
Issue 62: PAA discovery triggered by data traffic
Optional use of PDI message sent from EP to PAA is a part of PAA-EP protocol PAA-EP protocol should be described in a separate document Do we still need to use PDI message when SNMP is used for PAA-EP protocol? Proposed Resolution: Deprecate the use of PDI message sent from EP to PAA
10
Issue 63: MAC AVP a SHOULD or a MUST
MAC AVP should always appear in PANA-Auth-Request/Answer exchanges when a PANA SA exists Currently, MAC AVP is “SHOULD” “For any EAP-based re-authentication, if there is an established PANA SA, PANA-Auth-Request and PANA-Auth-Answer messages SHOULD be protected by adding a MAC AVP to each message.” Proposed Resolution: Replace “SHOULD” with “MUST”
11
Issue 64: Two separate codes for Session ID AVP
Session-Id AVP has two AVP type codes (263 and 1026) depending on whether the AVP payload has the same format as Diameter Session-Id A single type code should be used A single format should be used to avoid ambiguity Proposed Resolution: Use type code 1026 Use the same format as Diameter Session-Id
12
Issue 65: Clarification on simultaneous per-packet protection
Issues: Protection-Capability AVP is defined as a collection of flags for different data protection capability indications, but actually only one protection capability is allowed An “UNKNOWN” protection capability is defined but is it needed? Proposed Resolution: Change the Protection-Capability AVP definition to: "The Protection-Capability AVP (Code 1028) is of type Unsigned32. The AVP data indicates the data protection capability supported by EP. Below is a list of specified data protection capabilities: L2_PROTECTION IPSEC_PROTECTION"
13
Issue 28 – PaC/PAA State Machine
Should the state machine be included in the PANA Protocol I-D? Yes. But not necessarily in the format that has been presented earlier. Proposal is to create an ascii state table (with state, condition/event, action, next state) similar to Sec. 8.1, 8.2 etc. of the diameter RFC (RFC3588) Table derived from the graphical state machine diagram has been created and posted for comments Next step: Incorporate the state machine in the next revision of the I-D as an appendix
14
Issue 35 – EP Information Issue:
Setup of an IPsec SA, post authentication relies on the PaC knowing the address of the EP Proposed solution: Sec specifies the EP-Device-ID AVP which is included in the success response sent to the PaC in the PANA exchange Status: Closed
15
Issue 36 - Reauthentication race condition
It is possible that both PAA and PaC initiate the discovery and initial handshake procedure at the same time, i.e., the PAA sends a PANA-Start-Request message while the PaC sends a PANA-PAA-Discover message. Proposed solution: The PAA SHOULD silently discard the PANA-PAA-Discover message received from the PaC after it has sent a PANA-Start-Request message while creating a state for the PaC. Status: Closed
16
Other Issues Issue 59 (TTL):
TTL checks will be incorporated in the text Issue 60 (MSK vs AAA-Key): I-D will use AAA-Key instead of MSK. Issue 61 (PANA SA): PANA SA definition is revised (it can only exist when there is a AAA-key)
Similar presentations
© 2024 SlidePlayer.com. Inc.
All rights reserved.