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 ValuesName 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 ValuesSUCCESS 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

Date post:	15-Mar-2016
Category:	Documents
Upload:	flavia-pittman
View:	57 times
Download:	1 times

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

Documents