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

Nov IETF58 PANA WG PANA Issues 15 issues for draf-ietf-pana-pana-01were resolved and closed Resolution text incorporated in pana-02 There are 9 open issues for pana-02

Nov IETF58 PANA WG PANA-01 Issues (Closed)

Nov IETF58 PANA WG Message Format Related Issues The same message type is allocated to each pair of Request and Answer message (Issue 22) –use R-flag to distinguish Request from Answer PANA uses its own type space for message and AVP types (Issue 23) –No type space sharing with Diameter A new message “PANA-Error” is defined (Issue 17) –Section defines the error handling rule –Section defines the message format AVP alignment rule is added (Issue 24) –The same 32-bit alignment rule as Diameter Termination-Cause AVP values are defined (Issue 18) Result-Code AVP values are defined (Issue 19)

Nov IETF58 PANA WG Other Issues Defined detailed retransmission behavior and default parameters (Issue 20, explained later) Service Profile Names (Issue 25, explained later) Clarified that Session-Lifetime is non-negotiable and can be carried in PANA-Bind-Request message sent from PAA (Issue 8) Clarified that PAA SHOULD initiate EAP re- authentication before the session lifetime expires (Issue 31) Security Consideration section is updated (Issue 32) –Re-wording “periodical refresh” to “liveness test”, etc. Clarification of Section 4.9 “Device-ID Choice” (Issue 33) –PaC and PAA checks peer’s Device ID each other Minor editorial changes (Issues 21, 26, 30)

Nov IETF58 PANA WG Issue 20: Retransmission Timers and Counters Issue: Define default timer and retransmission counts Resolution: –Adopt the RFC3315 [DHCPv6] model Define algorithm and parameters for retransmission –Use of exponential backoff Classify messages retransmitted by PANA Each class uses the same default parameter values –PANA-PAA-Discover –Other messages Define default values for each class

Nov IETF58 PANA WG Issue 25: Service Profile Names Issue: Carrying network information during discovery and initial handshake phase would be helpful for a user to choose NAP and ISP Resolution: –Defined two new AVPs: NAP-Information AVP and ISP-Information AVP –Defined a new flag (S-flag) –Define the usage of the AVPs and S-flag

Nov IETF58 PANA WG Issue 25 (cont’d) {NAP,ISP}-Information AVP NAP-Information ::= 0*1 { Provider-Identifier } { Provider-Name } * [ AVP ] ISP-Information ::= 0*1 { Provider-Identifier } { Provider-Name } * [ AVP ] Provider-Identifier (Unsigned32): IANA-Assigned Enterprise Identifier Provider-Name (UTF8String)

Nov IETF58 PANA WG Issue 25 (cont’d) {NAP,ISP}-Information AVP Usage PAA can advertise *-Information AVPs in PANA-Start- Request message S-flag in PANA-Start-Request/Answer exchange is used for negotiating NAP/ISP separate authentication –F(inal)-flag is not needed any more During the negotiation, PaC can choose an ISP by including an ISP-Information AVP in the PANA-Start- Answer message PAA can specify which authentication (NAP or ISP) is occuring –by including a corresponding *-Information AVP in the first PANA-Auth-Request message in each authentication

Nov IETF58 PANA WG Issue 25 (cont’d) Example Sequence PANA-PAA-Discover PANA-Start-Request [ISP1, ISP2, NAP] // S-flag set PANA-Start-Answer [ISP1, NAP] // S-flag set PANA-Auth-Request[NAP, EAP{Req.}] PANA-Auth-Answer[EAP{Resp.}] PANA-Bind-Request/Answer PANA-Auth-Request[ISP1, EAP{Req.}] PANA-Auth-Answer[EAP{Resp.}] … PANA-Bind-Request/Answer … NAP Authentication ISP Authentication Discovery& Initial Handshake Execution order can be reversed

Nov IETF58 PANA WG PANA-02 Issues (Open)

Nov IETF58 PANA WG Open Issue List (ordered by importance) Issue #Issue Name 28PaC and PAA State Machines (to be presented by Dan) 34Behavior with NAP and ISP 37Unknown Realm Error Propagation 29EAP Failure & PANA-Bind-Request 36(Re)authentication Race Condition 35EP Information 16Mutihoming Support 12Supporting Network Access Authentication for Ad-hoc Networks 2Downgrading Protection

Nov IETF58 PANA WG Issue: How Session-Lifetime relates to NAP and ISP authentications? Proposed Resolution: –A single Session-Lifetime is bound to a PANA session –When NAP and ISP have different authorization lifetimes, the smaller one relates to the Session- Lifetime –When EAP re-authentication occurs, both NAP and ISP authentications will be performed Issue 34: Behavior with NAP and ISP

Nov IETF58 PANA WG Issue 37: Unknown Realm Error Propagation Issue: –Should “unknown realm” AAA message routing error be propagated to PaC? Discussion: –EAP state machine does not support propagation of AAA errors When such an error occurs, the authentication state machine enters a sink “failure” state without generating any error or an EAP-Failure message Direct interface from AAA to PAA would be needed Resolution?

Nov IETF58 PANA WG Issue 29: EAP Failure and PANA-Bind- Request Issue: –Should PANA-Termination-Request be used for carrying EAP-Failure instead of PANA-Bind-Request? Discussion: –When NAP/ISP separate authentication is performed, a single EAP failure does not mean PANA authentication failure Resolution –PANA-Term.-Request is not appropriate to carry EAP- Failure for the above reason –Use PANA-Bind-{Request,Answer} message to carry EAP- Success/Failure (as the current draft does) –“Bind” may be renamed to “Result” if the word “Bind” does not make sense to carry EAP-Failure

Nov IETF58 PANA WG Issue 36: (Re)authentication Race Condition Issue: –It is possible for both PaC and PAA to simultaneously initiate EAP (re)authentication. How can PANA handle the case? PaCPAA PANA-PAA-Discover PANA-Start-Request (or PANA-Auth-Request) Proposed Resolution: –PAA can always be the winner, by ignoring the received PANA-PAA-Discover message after it sends a PANA-Start- Request (or PANA-Auth-Request)

Nov IETF58 PANA WG Issue 35: EP Information Issue: –PANA-IPsec draft assumes that PaC learns the IP address of the EP during the PANA exchange. But PANA specification does not support it Proposed Resolution: –Having an AVP to carry the Device-Id of EP(s) –Device-Id AVP can have a field to indicate whether the device belongs to PAA or a separate EP –The AVP is carried in PANA-Bind-Request

Nov IETF58 PANA WG Issue 16: Multihoming Support Issue: –When PaC has multiple interfaces on the same IP link, should it be supported with a single PANA session or separate PANA sessions? Discussion –A single PANA session for multiple interfaces is basically an optimization issue Proposed resolution: –We should do a more thorough analysis if we support the scenario with a single PANA session –Until the analysis is made, separate PANA session is sufficient

Nov IETF58 PANA WG Issue 12: Supporting Network Access Authentication for Ad-hoc Networks Issue: –Should PANA support ad-hoc network scenario where there may be one or more untrusted nodes between PaC and PAA? Resolution? PaCPAA ISP Ad-hoc network Untrusted nodes

Nov IETF58 PANA WG Issue 2: Downgrading Protection Issue: –EAP allows negotiation of an EAP method between authenticator and peer. This mechanism is vulnerable to downgrading attacks. Discussion: –Providing downgrading protection in PANA is not good since an EAP server may not be co-located with PAA –EAP method negotiation is not performed by PANA, so this is an EAP issue Resolution: –Text incorporated in Security Considerations section Recommendation of using EAP-GSSAPI to negotiate an EAP method