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

4. PANA Header Format Flags
| 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

5. 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

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

10. 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
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)?
July
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
July
IETF57 PANA WG

13. 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

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

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]
July
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
July
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 and 9.4.7
July
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
July
IETF57 PANA WG

22. Thank you!
July
IETF57 PANA WG

23. Backup Slides
July
IETF57 PANA WG

24. 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
IETF57 PANA WG

25. 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
IETF57 PANA WG