Transcript 1: Early Re-Authentication, Direct Pre-Authentication Model

HOKEY Architecture
draft-hoeper-hokey-arch-design-02
HOKEY Working Group Presentation
IETF 77
Katrin Hoeper
Sebastien Decugis
Glen Zorn
Qin Wu
Tom Taylor
Warning
This work assumes inter-domain handover, with
the idea that if that works, intra-domain will also
work.
Please bear this assumption in mind.
Functions To Be Supported




HOKEY authentication services:

EAP early authentication

EAP re-authentication

EAP early re-authentication
Peer's discovery of:

Authenticators

Available authentication services

Local domain name
HOKEY key management

Key derivation

Key distribution
Local ER server authorization
3
HOKEY Architectural Components

Peer

Authenticator (serving, candidate, target)

EAP server

ER server


Local

Home
Local information server?
(Not currently documented in draft)
4
EAP Early Authentication
Peer
New
protocol
IP
Candidate
Authenticator
AAA
EAP
Server
1: Early Authentication, Direct Pre-Authentication Model
Peer
New
protocol / IP
or L2
Serving
Authenticator
New
protocol/IP
Candidate
Authenticato AAA
r
EAP
Server
2: Early Authentication, Indirect Pre-Authentication Model
Peer
New
protocol / IP
or L2
Serving
Authenticato
r
AAA
EAP
Server
AAA
3: Early Authentication, Anticipatory Authentication Keying Model
5
Candidate
Authenticato
r
Comments On Direct Pre-Authentication Model


Peer has to discover the candidate authenticator, including its
address.
In the general case, can't assume L2 connectivity between peer
and candidate authenticator. Hence need a new protocol to
transport the EAP pre-authentication exchanges over IP.
6
Comments On Indirect Pre-Authentication Model




Can be specified so as to appear the same to the peer as the
anticipatory authentication keying model, but can also be
specified so that differences appear between them.
Either the peer or the serving authenticator is responsible for
discovery of the candidate authenticator. If the serving
authenticator is responsible, it will in general take the original
pre-authentication request from the peer and expand it into
requests to multiple candidates.
Protocol between the peer and serving authenticator can be
almost the same as for EAP authentication.
In general, cannot assume L2 connectivity between serving and
candidate authenticators. Hence need a new protocol over IP to
carry the EAP pre-authentication exchanges between them.
7
Comments On Anticipatory Authentication Keying Model



Can be specified so as to appear the same to the peer as the
indirect pre-authentication model, but can also be specified so
that differences appear between them.
Either the peer, the serving authenticator, or the EAP server is
responsible for discovery of the candidate authenticator. Again,
the discovering entity is responsible for fan-out of the preauthentication messaging to the complete set of candidates.
Protocol between the peer and serving authenticator can be
almost the same as for EAP authentication.
8
General Comments On EAP Early Authentication



Will the same operator deploy more than one of these models?
Are there use cases that require one of the models rather than
another?
Will interworking be possible if the candidate network has
deployed a different model from the serving network?
DO WE REALLY NEED TO STANDARDIZE THREE DIFFERENT
MODELS??
9
EAP Re-Authentication
Peer
Initial EAP
exchange
Moves
Peer
Serving
Authenticator
AAA
EAP
Server
Keying
material
pulled as
AAA? required
Home or
EAP reauth
New
protocol?
Target
Local
exchange Authenticator
ER Server
10
Comments On EAP Re-Authentication




Target authenticator assumed to be configured with FQDNs of
any local ER servers.
In the absence of such configuration, target authenticator needs
to be able to discover home ER server (e.g., using SRVLOC).
If entanglement with AAA architecture to be avoided, need new
protocol between target authenticator and local or home ER
server.
Probably OK to use AAA between ER server and home EAP
server.
11
EAP Early Re-Authentication
Peer
Initial EAP
exchange
Serving
Authenticator
AAA
New
protocol
over IP
Candidate
Authenticator
EAP
Server
AAA?
Keying
material
pulled as
required
Home or
Local
ER Server
New protocol
over IP
1: Early Re-Authentication, Direct Pre-Authentication Model
12
EAP Early Re-Authentication
1. Initial EAP
exchange
Peer
2. EAP re-authen
over IP or L2
Serving
Authenticato
r
AAA
EAP
Server
New
protocol
over IP
AAA?
Candidate
Authenticato
r
Keying
material
pulled as
required
Home or
Local
ER Server
New protocol
over IP
2: Early Re-Authentication, Indirect Pre-Authentication Model
13
EAP Early Re-Authentication
1. Initial EAP
exchange
Peer
2. EAP re-authen
over IP or L2
Serving
Authenticato
r
AAA
New
protocol
over IP
Candidate
Authenticato
r
EAP
Server
Keying
AAA? material
pulled as
required
Home or
Keying material
Local
pushed via new
ER Server
protocol over IP
3: Early Re-Authentication, Anticipatory Authentication Keying Model
14
What Remains To Be Done?


Identification of responsibilities for support of discovery
Selection of the early authentication model(s) that will be
supported

Specification of protocol requirements on the different interfaces

Specification of OAM requirements
15
Wrapping Up


Can this be a WG work item?
If so, is draft-hoeper-hokey-arch-design-02 a sufficient starting
point for the work?
16