1. ERP/AAK support for Inter-AAA realm handover discussion Hao Wang, Tina Tsou, Richard

2. Inter-AAA realm handover application scenarios Scenario 1:intra-operator authenticationScenario 2: Inter-operator authentication Home AAA and CAP-AAABelongs to the same operatorBelongs to the different operators Establish the trust relationshipTight trust relationship between AAALoose trust relationship between AAA Early authenticationw/ofull EAP method exchangew/o and w/ full EAP method exchange Request DSRK and EMSK NameDerived pMSK from DSRKDerive new DSRK and pMSK from EMSK or Make one new EMSK Attach to the CAPUsing pMSK derived by DSRKUsing MSK derived in EAP authentication or pMSK derived from the same EMSK and different DSRK The Roles of AAA servers after handoverHome AAA is not changed CAP-AAA act as a Local AAA server a.Home AAA is changed,CAP-AAA act as the new Home AAA b. Home AAA is not changed CAP-AAA SAP Internet Home AAA CAP Local AAA/SAP-AAA Early authentication DSRK Request, Domain Name DSRK, EMSK Name Keep the early authentication sessions for early authentication life time. ② ③ ④ Attach to the CAP Establish Trust Relationship between AAA ①

3. Inter-AAA realm handover problem statement (Based on RFC 5836 AAK Model) Local AAA/SAP-AAA CAP-AAA SAP Internet Home AAA CAP ① ③ ④ ② Problem 1. The trust relationship needs to be established between Home AAA and CAP-AAA. Problem 2. CAPs are discovered through EAP Lower layer. Early authentication is done through EAP layer. So MH needs to know whether the discovered CAPs can be early authenticated through Home AAA or not. Problem 4. SAP-AAA and Home AAA should forward EAP early authentication packets to CAP-AAA instead of processing them locally. Problem 3. Full EAP method exchange may be required in early authentication. Problem 5. Frequent MH handover may lead to redundant obsolete early authentication sessions on AAA servers. Problem 6. Higher possibility of information inconsistency between MH and CAP-AAA. For example: After handover, MH start to use pMSK for EAP lower layer key derivation. But the early authentication session on CAP-AAA has just been expired without notifying MH.

4. Topic 1: Reuse the Re-authentication messages or define new messages? The existing normal authentication session on AAA server is the prerequisite of EAP Re- authentication process. In intra-AAA realm handover, early authentication happened between MH and Home AAA. There is a normal authentication exist in Home AAA, So Re-authentication process can be reused. (Such as methods defined in draft-ietf-hokey-erp-aak-02) In inter-AAA realm handover, early authentication happened between MH and CAP-AAA. There is no normal authentication exist in CAP-AAA, Reuse Re-authentication messages may cause logic confusion. Comments: Suggest to reuse Initiate and Finish EAP codes defined in ERP, but add new message types to differentiate from EAP Re-authentication process. For example: Define EAP Initiate/Pre-auth and EAP Finish/Pre-auth messages Topic 2: How to announce the inter-AAA realm handover capability? To avoid redundant trigger message at the beginning, New start message should not be defined. Comments: Suggest to modify ERP/Re-auth-Start message and add new flag bit to announce the support of new messages. The MH who did not support new messages will ignore the flag bits and do early authentication using ERP/AAK (Defined in draft-ietf-hokey-erp-aak-02). ERP/AAK support inter-AAA realm handover discussion

5. Topic 3: The new functions need to be extended to support inter-AAA handover. (Refer to Inter-AAA realm handover problem statement) (For Problem 2) New NAS-Id-NAI (Format: NAS-id@realm name) TLV to identify the CAPs in other realms. (For Problem 2) Support probe mechanism before early authentication to avoid repeating authentication failure. (For Problem 3) Support MH to negotiate whether EAP full authentication is required with CAP-AAA. (For Problem 4) Inform authenticator, SAP-AAA, Home AAA and CAP-AAA of the early authentication startup. Establish the routing path. After being informed, SAP-AAA and Home AAA should forward EAP early authentication packets to CAP-AAA. And CAP-AAA should take following EAP method exchange as an early authentication. (For Problem 4) Restrict MH to start early authentication with CAPs one by one. (For Problem 5) Support bidirectional state transition a. From early authenticated state to normal authenticated and authorized state. b. From normal authenticated and authorized state to early authenticated state. (Adapt to the situation where MH keep moving between 2 AAA realms.) ERP/AAK support inter-AAA realm handover discussion

6. (For Problem 5) Support to release the obsolete early authentication sessions proactively to avoid resource consumption. (For Problem 6) Support early authentication lifetime extension to solve the problem that the lifetime is expiring when MH is anticipated to move. (For Problem 6) Mutually authenticated (one round trip) and verify the key possession after handover. (For Problem 6) New result code TLV to let MH know the detailed reason of early authentication faiure. Comments: 1. Problem 1 is out of scope of this discussion. 2. Currently the reserved flag bits in ERP messages are less. Defining message types is more flexible for future function extension. 3. New messages can cover both intra-AAA and inter-AAA realm handover scenarios. ERP/AAK support inter-AAA realm handover discussion