Transcript hokey-1x

EAP Extensions for EAP Early Authentication Protocol (EEP)
Hao Wang, Yang Shi, Tina Tsou
EEP in Hokey architecture
Hokey Goal: Minimize handover delay
2 approaches
Re-authentication
(Problem Statement, RFC5169)
Early authentication
(Problem Statement, RFC5836)
2 models
ERP
(RFC5296)
Authenticated anticipatory
keying usage model
Pre-authentication
usage model
2 sub-models
Indirect
ERP/AAK
(draft-ietf-hokey-erp-aak-02)
EEP
(draft-hao-hokey-eep-00)
Only consider intra-AAA-realm
Handover
Support both intra-AAA-realm
and inter-AAA-realm handover
Direct
PANA Extension
(RFC 5873, Experimental)
Support both intra-AAA-realm
and inter-AAA-realm handover
Early authentication Model Discussion
(Refer to RFC5836)
Application problem of early authentication models
Models
Scenarios
Intra-AAA-Realm handover
Inter-AAA-Realm handover
Direct pre-authentication
Need to establish the direct IP communication between MH and CAP.
Indirect pre-authentication
Need to establish the direct IP communication between SAP and CAP.
Need to maintain the trust relationship for each pairs of SAP and CAP.
Authenticated Anticipatory Key
OK!
Need to establish the trust relationship
between AAAs.
Security context transfer must be allowed.
Early authentication Model Discussion
(Refer to RFC5836)
A improved Indirect pre-authentication model for Inter-AAA-Realm handover
Original indirect pre-authentication model
SAP-AAA
CAP-AAA
New indirect pre-authentication model
SAP-AAA
CAP-AAA
EAP over AAA
EAP over AAA
SAP
EAP over L3
CAP
AAA
SAP
EAP over L2 or L3
CAP
EAP over L3
MH
MH
Original
New
Trust relationship
Established between APs
Established between AAAs
IP Communications
across network
“Many” for every pair of APs
Only one between AAAs. Shared by all APs
Whether it can be established
depend on network topology
More applicable because AAA servers
usually are distributed on high layer network
Early authentication Model Discussion
(Refer to RFC5836)
There is no best model for all cases!
①
②
Intra-AAA-Realm handover
Inter-AAA-Realm handover
Proper model
Authenticated Anticipatory Key
Trust relationship can be established
Between SAP network and CAP network?
No
Direct IP communication can be
Established between MH and CAP?
No
Possible to do
Early authentication?
Yes
Yes
Security transfer between
AAAs is allowed?
No
Yes
Proper model
Proper model
Proper model
Direct pre-authentication
New Indirect
pre-authentication
Authenticated
Anticipatory Key
The basic design idea of EEP is “adopting proper model based on scenario”.
Inter-AAA-realm handover problem statement
Problem 1. The trust relationship needs to be
established between SAP-AAA and CAP-AAA.
①
CAP-AAA
SAP-AAA
③
Problem 3. In new indirect model,
SAP, SAP-AAA should forward EAP
authentication packets to CAP-AAA
instead of processing them locally.
③
CAP
Internet
SAP
④
②
Problem 2. MH need to know which early
authentication model should be used.
Problem 4. Frequent MH handover may
lead to obsolete early authentication
sessions on AAA servers.
Problem 1: Establish the trust relationship between AAAs
How to establish the trust relationship is out of scope of this document.
But we can consider 3 cases: Full, Semi and No trust relationship.
Relation between AAAs
Full Trust Relationship
Semi Trust Relationship
No Trust Relationship
Accept the other acting as an AAA proxy
Yes
Yes
No
Trust the other’s authentication result
Yes
No
No
Security context transfer
Yes
No
No
For Full Trust Relationship:
EAP authentication is not required. So the AAK model is adapt to this case.
For Semi Trust Relationship:
MH need to do full EAP authentication with CAP-AAA through SAP-AAA. So the New indirect
pre-authentication model is adapt to this case.
For No Trust Relationship:
MH need to do full early authentication directly. So the Direct pre-authentication model
is adapt to this case.
Problem 2: MH start early authentication
②
SAP-AAA depend on the trust relationship
No trust relationship:
Inform MH of starting EAP authentication through CAP.
Semi trust relationship: Inform MH of starting EAP authentication through SAP-AAA.
Full trust relationship:
Transfer security context to CAP-AAA and inform MH of the Early authentication result.
Full trust relationship
Security context transfer
SAP-AAA
CAP-AAA
EAP authentication
Semi trust relationship
EAP over PANA
CAP
Internet
No trust relationship
SAP
①
MH send the NAS-id and domain name of CAP to SAP-AAA.
Problem 3: Forwarding EAP authentication packets
(Semi trust relationship and New indirect pre-authentication model)
③
SAP-AAA forward EAP packets to CAP-AAA
and take the responsibility of virtual NAS and AAA proxy.
EAP over PANA
CAP
Internet
SAP
②
①
CAP-AAA
EAP over AAA
SAP-AAA
SAP forward the packets to
SAP-AAA as the normal data.
MH send out the EAP authentication packets to
SAP-AAA over PANA (with CAP domain name and E
Bit = 1 Refer to RFC5873).
Problem 4: Frequent Handovers
CAP-AAA
SAP-AAA
CAP
Internet
SAP
Frequent handovers
Discussion:
Define special message for MH to release early authentication session proactively.
Define special message for MH to reversely change the state from full authenticated to Early authenticated.
Further discussion
Problem 1: Authorized before handover or after handover?
② AAA authorize before handover.
Internet
SAP
① MH start early authentication.
CAP
Problem: Before handover, MH has not connected with CAP yet.
With whom, the authorization information and security context
will be bound on CAP?
Further discussion
Problem 2: How to ensure the information consistency?
Early authentication session has just been expired.
Internet
CAP
SAP
③
②
Handover
① MH start early authentication
Problem: Key?
Derive the key for lower layer
EAP Early authentication protocol (EEP) Solution
(Authorize after handover and confirm the key simultaneously)
③
Internet
MH request to change state from early authenticated
to full authenticated and confirm the key.
AAA authorize and distribute security
④ context to CAP.
CAP
SAP
⑤ Derive the key for lower layer.
②
Handover
① MH start early authentication.
EAP Early authentication protocol (EEP)
(EAP Packet and TLV Extension)
1. Design Idea
a. Unified packet extension to support different models.
b. Balance between reuse and extensibility.
2. EAP Packet Extension
0
1
2
3
01234567890123456789012345678901
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code
|
Identifier
|
Length
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type
|
Type-Data ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reuse the EAP codes defined in ERP (RFC5296) and extend its usage for early authentication.
5 Initiate
6 Finish
New types values are defined:
1
2
3
4
Re-auth-Start:
Re-auth:
Pre-Early-auth:
Post-Early-auth:
(RFC5296)
(RFC5296)
Used before handover.
Used after handover.
Please give your guidance and comments
to this work, Thanks!
Wish you join it!