Pre-authentication Problem Statement (draft-ohba-hokeyp-preauth-ps-00.txt)

1
Pre-authentication Problem Statement(draft-ohba-
hokeyp-preauth-ps-00.txt)

• Yoshihiro Ohba (yohba_at_tari.toshiba.com)
• Ashutosh Dutta (adutta_at_research.telcordia.com)
• Srinivas Sreemanthula (Srinivas.Sreemanthula_at_nokia
  .com)
• Alper Yegin (alper01.yegin_at_partner.samsung.com)

2
What is pre-authentication

• Pre-authentication is network access
  authentication by performing EAP authentication
  with a target authenticator via the serving
  network
• Pre-authentication was originally defined in IEEE
  802.11i where the usage is intra-ESS transitions
• We are extending the notion of pre-authentication
  to work across multiple ESSs and even across
  multiple access technologies

3
Expected Improvement with Pre-authentication
Network access Authentication and Authorization
L2 Handoff
Without Pre-authentication
Time
With Pre-authentication
Time
Network access Authentication and Authorization
with Pre-authentication
Possible packet loss or interface activation
delay during this period
4
Scenario 1 Direct Pre-authentication
Serving network
home network
mobile host
MN-TA Signaling EAP over L2 (for
intra-technology, Intra-subnet
pre-authentication) EAP over L3 (for other cases)
Internet
home AAA server
EAP over AAA
Target Network
Target Authenticator (TA)
- Generate MSK with the authenticator-2 by
executing EAP through it.
5
Scenario 2 Indirect Pre-authentication
Serving Authenticator (SA)
Serving Network
home network
MN-SA signaling EAP over L2/L3
mobile host
Internet
SA-TA signaling EAP over L3
home AAA server
EAP over AAA
Target Network
Target Authenticator (TA)
- Generate MSK with the authenticator-2 by
executing EAP through it.
6
Basic pre-auth AAA requirements

• Requirements identified in IETF65 HOAKEY BOF
• AAA needs to know that this is a
  pre-authentication not normal authentication
• User may only be allowed to have a single logon
  at the same time
• User may not be allowed pre-authentication
• Can pre-auth session timeout (see below)
  attribute serve as an indication of pre-auth or
  some other attribute is needed?
• AAA needs to know how long to hold the session
  before timing out
• Session timeout for pre-auth may be different for
  normal session
• If the mobile moves after timeout then do normal
  authentication
• Addressed in draft-aboba-radext-wlan-03.txt
• What would signal that the host has successfully
  connected to a target network? Another round of
  (non-blocking) Access-Req/Accept? Or do we rely
  on accounting messages? If latter, then they must
  be mandated for pre-auth case

7
Other potential pre-auth AAA requirements/issues
(presented to RADEXT WG)

• Extending pre-auth session lifetime
• Reverting to pre-auth state from full authorized
  state (related to key caching)
• Maximum number of pre-auth sessions for different
  authenticators
• Information on the serving network
• Calling-Station-Id
• Network-initiated pre-authentication

Detailed issues are available at
http//www.opendiameter.org/docs/ietf66-radext-pr
eauth-aaa-reqs.ppt
8
Scope of the pre-authentication work

• This group will work on pre-authentication
  signaling requirements including MN-TA signaling,
  MN-SA signaling and SA-TA signaling and new or
  existing attributes of AAA protocols (from
  HOKEYP charter http//www.opendiameter.org/piperma
  il/hokeyp/2006-May/000142.html)
• Possible work separation
• AAA signaling RADEXT and DIME WGs
• MN-TA, MN-SA signaling PANA WG (for L3), L2 SDO
  (for L2)
• SA-TA signaling new IETF WG

9
Deliverables

• Pre-authentication problem statement draft
  (Informational)
• This draft is intended for detailed problem
  definition and usage scenarios for
  pre-authentication. draft-ohba-hokeyp-preauth-ps-
  00.txt will be used as the baseline.
• Pre-authentication protocol requirements draft
  (Informational)
• Requirements of new protocols or new
  options/attributes for existing protocols for
  enabling a target authenticator to authenticate
  the peer attached to the serving network using
  EAP. The requirements are for both
  pre-authentication protocols and AAA protocols.
• Following completion of requirements definitions
  for a pre-authentication procedure, this group
  will continue with developing a solution for some
  portion of pre-authentication signaling if it is
  identified that the solution needs to be defined
  in the group

10
High-Level Requirements on pre-authentication

• Inter-technology pre-authentication MUST be
  supported.
• Inter-subnet pre-authentication MUST be
  supported.
• Inter-administrative domain pre-authentication
  MUST be supported.
• Direct pre-authentication MUST be supported.
• Indirect pre-authentication MUST be supported
• Pre-authentication MUST work with RADIUS and
  Diameter