1 / 16

Open issues with PANA Protocol

Open issues with PANA Protocol. IETF59 Yoshihiro Ohba/Basavaraj Patil. 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

lysandra-rose
Download Presentation

Open issues with PANA Protocol

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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 Issue: • 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 Issue: • 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 Issue: • 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 Issue: • 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 Issue: • 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 Issue: • 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 1.4.1 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 Issue: • 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 Issue: • 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 Issue: • 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: 1 L2_PROTECTION 2 IPSEC_PROTECTION"

  13. Issue 28 – PaC/PAA State Machine Issue: • 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 9.4.15 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 Issue: • 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)

More Related