1 / 25

PANA Discussion and Open Issues (draft-ietf-pana-pana-01.txt)

PANA Discussion and Open Issues (draft-ietf-pana-pana-01.txt). Dan Forsberg, Yoshihiro Ohba, Basavaraj Patil, Hannes Tschofenig, Alper Yegin. Open Issue List (ordered by importance) http://www.danforsberg.info:8080/pana-issues/. Issue 9: Message Format.

louvain
Télécharger la présentation

PANA Discussion and Open Issues (draft-ietf-pana-pana-01.txt)

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. PANA Discussion and Open Issues(draft-ietf-pana-pana-01.txt) Dan Forsberg, Yoshihiro Ohba, Basavaraj Patil, Hannes Tschofenig, Alper Yegin IETF 57 PANA WG

  2. Open Issue List (ordered by importance)http://www.danforsberg.info:8080/pana-issues/ IETF57 PANA WG

  3. Issue 9: Message Format • Issue: Message format Not defined in -00 draft • Proposed resolution: -01 draft contains format • Diameter-like message format: header + AVPs • No application-Identifier (as in Diameter) in PANA message header • Hop-by-hop and End-to-end identifiers (that exist in Diameter header) are replaced with sequence numbers in PANA header • The same AVP format as Diameter AVPs • Changes to message names (from 00 to 01) IETF57 PANA WG

  4. PANA Header Format 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version | Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |R r r r F r r r| Message Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Transmitted Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Received Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVPs ... +-+-+-+-+-+-+-+-+-+-+-+-+- • Flags • ‘R’-flag: Indicates whether the message is a request. • ‘F’-flag: Indicates if this was the final authentication from sender's perspective. Used in PANA-Bind-Request/Answer messages. IETF57 PANA WG

  5. PANA AVP Format 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVP Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V M r r r r r r| AVP Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vendor-Id (opt) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data ... +-+-+-+-+-+-+-+-+ • Flags • ‘V’-flag: Indicates whether this AVP is a vendor-specific AVP. • ‘M’-flag: Indicates whether this AVP is mandatory supported AVP. IETF57 PANA WG

  6. List of Changes in Message Names IETF57 PANA WG

  7. List of AVPs • Cookie AVP • Device-Id AVP • EAP-Payload AVP • MAC AVP • Protection-Capability AVP • Result-Code AVP • Session-Id AVP • Session-Lifetime AVP • Termination-Cause AVP IETF57 PANA WG

  8. Issue 4,5,16: Device Identifier • Issues: • There is a scenario where the DI needs to be updated • There may be a case where both MAC and IP addresses are used at the same time as a DI • There may be a case where multiple IP addresses are used as a DI IETF57 PANA WG

  9. Updating Device Identifier • Possible scenario: • PaC performs PANA using unspecified IP address and establishes MSK • The MAC address is used as the DI and bound to MSK, or DI can be null if it is enough to bind Session-ID to the MSK • PaC obtains an IP address (via DHCP, etc.) • PaC and EP bootstraps IKE from the MSK • The MSK needs to be bound to the IP address • Proposed Resolution: DI update can be done in PANA-Reauth exchange • PANA-Reauth-{Request,Answer} message can carry Device-ID AVP IETF57 PANA WG

  10. Using both MAC and IP addressesat the same time as DI • This is the case where both L2 and L3 ciphering are bootstrapped from PANA • Insider attackers can spoof either IP or MAC address of data packets without both ciphering • Resolution? • Support either MAC or IP addresses as a DI, and not both addresses at the same time • Support both addresses at the same time as well • Note: neither A nor B solves IP address ownership problem which is solved only by SEND IETF57 PANA WG

  11. Multiple IP Addresses as DI • PaC can have multiple IP addresses on the same interface • Link local address, global addresses, etc. • PaC does not specify all IP addresses as PANA DI if: • Only L2 ciphering is used, or • One (link-local) address is used as DI and the local end-point of IPsec tunnel, and other addresses are configured inside the tunnel • Multi-interfaced PaC can perform separate PANA per interface • Resolution? • Is this sufficient? • Should we list all IP addresses as DI and bind to PANA session (in order to solve IP address authorization problem)? IETF57 PANA WG

  12. Issue 6: Session Identifier • Issue: How can a PANA session be identified? • Discussion: • Can a DI be used as a session identifier ? • A separate session ID is useful when updating DI • Such a session ID can be used for mobility handling • Proposed resolution: A Session-Id AVP is defined • The Session-Id AVP MAY use Diameter message formatting IETF57 PANA WG

  13. Issue 3: PANA SA • Issue: What is PANA SA? How it is created? • Proposed resolution: Added a new section 4.1.5 “PANA Security Association IETF57 PANA WG

  14. Definition of PANA SA • A PANA SA is created when EAP authentication succeeds with a creation of MSK (Master Session Key) • When two EAP authentications are performed in PANA (i.e., ISP/NAP separation), two MSKs may be created • PANA SA is bound to the first established MSK, not to both MSKs • PANA_MAC_Key = The first N-bit of HMAC_SHA1(MSK, ISN_pac|ISN_paa|Session-ID) (N=128 and 160, if MAC algorithm is HMAC-MD5 and HMAC-SHA1, respectively) IETF57 PANA WG

  15. Issue 8: Refresh Interval Negotiation • Issue: What parameter should PAA communicate to PaC to perform re-authentication? • There are two types of re-authentication: (I) EAP-based re-auth. and (II) fast re-auth. via PANA-Reauth exchange • Possible parameters: • Session lifetime for EAP-based reauthentication • Interval for PANA-Reauth exchange • Mobile IP supports refresh interval negotiation while 802.1X and IKEv2 do not • Resolution? • Should session lifetime be carried? • When carried, it is indicated by the PAA as a non-negotiable, informational parameter • Should PANA-Reauth interval be carried? IETF57 PANA WG

  16. Issue 11: New PANA Client Notification • Issue: Should PANA define message format for event notification from EP to PAA? • Proposed resolution: Added a new section 4.10 “Event Notification” • Event notification message can be one of the messages provided by the PAA-EP protocol or can be a “PANA-Discover” message IETF57 PANA WG

  17. Issue 7: Mobility Handling • Issue: In case of mobility it is useful to move PANA session state from one PAA to another forperformance reasons • Proposed resolution: Added a new section 4.9 “Mobility Handling” • Fast re-authentication can be used instead of EAP-based re-authentication when PANA session state is available on the new PAA • Assumes the state can be brought to the new PAA (e.g., by Seamoby Context Transfer Protocol) IETF57 PANA WG

  18. Mobility Handling Example Old PAA New PAA PaC PANA-Discover PANA-Start-Request[Cookie] Context Transfer (Session-Id, MSK, etc) PANA-Start-Answer[Cookie, Session-Id] PANA-Reauth-Request[Session-Id,MAC] PANA-Reauth-Answer[Session-Id,MAC] IETF57 PANA WG

  19. Issue 15: Cookie vs. Puzzle • Issue: The cookie mechanism defined in discovery and handshake phase might not be effective for on-link attackers • Another mechanism based on ‘Puzzle’ is proposed • The PAA sends a challenge that does not need a shared secret for PaC to respond but need some calculation on PaC • Introducing another DoS attack by sending ‘difficult-to-solve’ puzzle to PaC • Proposed Resolution: • Use Cookie by default, with allowing Puzzle to be specified in a separate document if needed IETF57 PANA WG

  20. Issue 18,19: Values for Termination-Cause and Result-Code AVPs • Issue: AVP values need to be defined for Termination-Cause and Result-Code AVPs • Proposed resolution: Values are defined in sections 9.4.6 and 9.4.7 IETF57 PANA WG

  21. Issue 1,2: Capability Negotiation and Downgrading Protection • Issue: Does PANA need to support capability negotiation • Capability of L2/L3 ciphers • Discussion: • Capability negotiation outside EAP can be a place for downgrading attack • Proposed resolution • Support capability indication (i.e., non-negotiable) from PAA • Protection-Capability AVP in protected PANA-Bind-Request/Answer exchange is used for this purpose IETF57 PANA WG

  22. Thank you! IETF57 PANA WG

  23. Backup Slides IETF57 PANA WG

  24. Termination-Cause AVP Values IETF57 PANA WG

  25. Result-Code AVP Values IETF57 PANA WG

More Related