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

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

July 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 IETF57 PANA WG PANA Header Format | 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 IETF57 PANA WG PANA AVP Format | 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 IETF57 PANA WG List of Changes in Message Names -00 draft-01 draft PANA_discoverPANA-Discover PANA_startPANA-Start-{Request,Answer} PANA_authPANA-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 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 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 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 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? A.Support either MAC or IP addresses as a DI, and not both addresses at the same time B.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 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? A.Is this sufficient? B.Should we list all IP addresses as DI and bind to PANA session (in order to solve IP address authorization problem)?

July 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 IETF57 PANA WG Issue 3: PANA SA Issue: What is PANA SA? How it is created? Proposed resolution: Added a new section “PANA Security Association

July 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 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: I.Session lifetime for EAP-based reauthentication II.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 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 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 IETF57 PANA WG Mobility Handling Example PaC New PAA PANA-Discover PANA-Start-Request[Cookie] PANA-Start-Answer[Cookie, Session-Id] PANA-Reauth-Answer[Session-Id,MAC] PANA-Reauth-Request[Session-Id,MAC] Old PAA Context Transfer (Session-Id, MSK, etc)

July 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 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 and 9.4.7

July 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 IETF57 PANA WG Thank you!

July IETF57 PANA WG Backup Slides

July IETF57 PANA WG Termination-Cause AVP Values NameValueDirection LOGOUT1PaC to PAA (SERVICE_NOT_PROVIDED)2PAA to PaC BAD_ANSWER3PaC to PAA ADMINISTRATIVE4PAA to PaC (LINK_BROKEN)5 AUTH_EXPIRED6PAA to PaC (USER_MOVED)7PAA to PaC SESSION_TIMEOUT8PAA to PaC

July IETF57 PANA WG Result-Code AVP Values SUCCESS2001 COMMAND_UNSUPPORTED3001 UNABLE_TO_DELIVER3002 REALM_NOT_SERVED3003 TOO_BUSY3004 INVALID_HDR_BITS3008 INVALID_AVP_BITS3009 AUTHENTICATION_REJECTED4001 AVP_UNSUPPORTED5001 UNKNOWN_SESSION_ID5002 AUTHORIZATION_REJECTED5003 INVALID_AVP_VALUE5004 MISSING_AVP5005 RESOURCES_EXCEEDED5006 AVP_OCCURS_TOO_MANY_TIMES5009 UNSUPPORTED_VERSION5011 INVALID_AVP_LENGTH5014 INVALID_MESSAGE_LENGTH5015