ERP/AAK support for Inter-AAA realm handover discussion

Hao Wang, Tina Tsou, Richard

Inter-AAA realm handover application scenarios

Scenario 1:intra-operator authentication Scenario 2: Inter-operator authentication

Home AAA and CAP-AAA Belongs to the same operator Belongs to the different operators

Establish the trust relationship Tight trust relationship between AAA Loose trust relationship between AAA

Early authentication w/ofull EAP method exchange w/o and w/ full EAP method exchange

Request DSRK and EMSK Name Derived pMSK from DSRK Derive new DSRK and pMSK from EMSK or Make one new EMSK

Attach to the CAP Using pMSK derived by DSRK Using MSK derived in EAP authentication or pMSK derived from the same EMSK and different DSRK

The Roles of AAA servers after handover Home 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 NameKeep the early authenticationsessions for early authentication life time.

②

③

④Attach to the CAP

Establish Trust Relationship between AAA①

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.

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

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

(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