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

Open Issue List (ordered by importance) http://www. danforsberg Issue Name Status 9 Message Format Almost Resolved 4,5,16 Device Identifier, including multi-homing Fair Amount of Discussion 6 Session Identifier 3 PANA SA Initial Text Provided 8 Refresh Interval Negotiation 11 Event Notification 7 Mobility Handling 15 Cookie vs. Puzzle Under Discussion 18,19 Values for Termination-Cause and Result-Code AVPs 1,2 Capability Negotiation and Downgrading Protection 17 Error Handling To Be Discussed July 14 2003 IETF57 PANA WG

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) July 14 2003 IETF57 PANA WG

PANA Header Format Flags 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. July 14 2003 IETF57 PANA WG

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. July 14 2003 IETF57 PANA WG

List of Changes in Message Names -00 draft -01 draft PANA_discover PANA-Discover PANA_start PANA-Start-{Request,Answer} PANA_auth PANA-Auth-{Request,Answer} PANA_{success,failure}{,_ack} PANA-Bind-{Request,Answer} PANA_reauth{,_ack} PANA-Reauth-{Request,Answer} PANA_{disconnect,revocation}{,_ack} PANA-Termination-{Request,Answer} July 14 2003 IETF57 PANA WG

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 July 14 2003 IETF57 PANA WG

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 July 14 2003 IETF57 PANA WG

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 July 14 2003 IETF57 PANA WG

Using both MAC and IP addresses at 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 July 14 2003 IETF57 PANA WG

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)? July 14 2003 IETF57 PANA WG

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 July 14 2003 IETF57 PANA WG

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 July 14 2003 IETF57 PANA WG

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) July 14 2003 IETF57 PANA WG

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? July 14 2003 IETF57 PANA WG

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 July 14 2003 IETF57 PANA WG

Issue 7: Mobility Handling Issue: In case of mobility it is useful to move PANA session state from one PAA to another for performance 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) July 14 2003 IETF57 PANA WG

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] July 14 2003 IETF57 PANA WG

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 July 14 2003 IETF57 PANA WG

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 July 14 2003 IETF57 PANA WG

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 July 14 2003 IETF57 PANA WG

Thank you! July 14 2003 IETF57 PANA WG

Backup Slides July 14 2003 IETF57 PANA WG

Termination-Cause AVP Values Name Value Direction LOGOUT 1 PaC to PAA (SERVICE_NOT_PROVIDED) 2 PAA to PaC BAD_ANSWER 3 ADMINISTRATIVE 4 (LINK_BROKEN) 5 AUTH_EXPIRED 6 (USER_MOVED) 7 SESSION_TIMEOUT 8 July 14 2003 IETF57 PANA WG

Result-Code AVP Values SUCCESS 2001 COMMAND_UNSUPPORTED 3001 UNABLE_TO_DELIVER 3002 REALM_NOT_SERVED 3003 TOO_BUSY 3004 INVALID_HDR_BITS 3008 INVALID_AVP_BITS 3009 AUTHENTICATION_REJECTED 4001 AVP_UNSUPPORTED 5001 UNKNOWN_SESSION_ID 5002 AUTHORIZATION_REJECTED 5003 INVALID_AVP_VALUE 5004 MISSING_AVP 5005 RESOURCES_EXCEEDED 5006 AVP_OCCURS_TOO_MANY_TIMES 5009 UNSUPPORTED_VERSION 5011 INVALID_AVP_LENGTH 5014 INVALID_MESSAGE_LENGTH 5015 July 14 2003 IETF57 PANA WG