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

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

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

Issue # Issue Name Status

9 Message Format •Almost Resolved

4,5,16 Device Identifier, including multi-homing •Fair Amount of Discussion

6 Session Identifier •Almost Resolved

3 PANA SA •Initial Text Provided

8 Refresh Interval Negotiation •Fair Amount of Discussion

11 Event Notification •Almost Resolved

7 Mobility Handling •Almost Resolved

15 Cookie vs. Puzzle •Under Discussion

18,19 Values for Termination-Cause and Result-Code AVPs •Initial Text Provided

1,2 Capability Negotiation and Downgrading Protection •Fair Amount of Discussion

17 Error Handling •To Be Discussed


•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)


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.


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.


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}


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


•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


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


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?A. Support either MAC or IP addresses as a DI, and not

both addresses at the same timeB. 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


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)?


•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


•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


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)


•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 reauthenticationII. 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?


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


•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)


Mobility Handling Example

PaCNewPAA

PANA-Discover

PANA-Start-Request[Cookie]

PANA-Start-Answer[Cookie, Session-Id]

PANA-Reauth-Answer[Session-Id,MAC]

PANA-Reauth-Request[Session-Id,MAC]

OldPAA

ContextTransfer(Session-Id, MSK, etc)


•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


•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


•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


Thank you!


Backup Slides


Termination-Cause AVP Values

Name Value Direction

LOGOUT 1 PaC to PAA

(SERVICE_NOT_PROVIDED) 2 PAA to PaC

BAD_ANSWER 3 PaC to PAA

ADMINISTRATIVE 4 PAA to PaC

(LINK_BROKEN) 5

AUTH_EXPIRED 6 PAA to PaC

(USER_MOVED) 7 PAA to PaC

SESSION_TIMEOUT 8 PAA to PaC


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

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

Documents

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