Subject: [eap] Issue 351: Incomplete EAP Pre-authentication discussion

From: "Bernard Aboba" <[email-masked]>
Date: Fri, 21 Apr 2006 18:58:01 -0700

Issue 351: Incomplete EAP Pre-authentication discussion
Submitter name: Bernard Aboba
Submitter email address: [email-masked]
Date Submitted: April 21, 2006
Reference:
Document: Keying-12
Comment type: T
Priority: 1
Section: 4.1
Rationale/Explanation of issue:

It has been pointed out (in draft-vidya-eap-keying-gap-analysis as well as 
discussion in the HOAKEY BOF) that there are a number of issues raised by 
EAP pre-authentication.  Section 4 includes EAP pre-authentication in a list 
of handoff techniques and claims that "The sections that follow discuss the 
security vulnerabilities  introduced by the above mechanisms."  However, 
Section 4 does not include a discussion of EAP pre-authentication concerns.

The proposed resolution is to add a Section 4.1, with the following text:

"4.1  EAP Pre-authentication

  EAP pre-authentication enables an EAP peer to pre-establish EAP keying 
material with
  an authenticator prior to attaching to it.  Where there is sufficient time 
to pre-establish
  keying material prior to changing the point of attachment, this may enable 
the peer to
  remove EAP authentication from the critical path for handoff, reducing 
latency.

  EAP pre-authentication exchanges typically differ from a normal EAP 
conversation only
  with respect to the lower layer encapsulation.  For example, in 
[IEEE-802.11i], EAP
  pre-authentication frames are encapsulated within a distinct Ethertype, 
but otherwise
  conform to the encapsulation described in [IEEE-802.1X].   As a result, an 
EAP
  pre-authentication conversation that eventually results in establishment 
of security
  associations differs little from the model described in Section 1.3, other 
than the
  potential introduction of a delay between Phase 1 and Phase 2.  However, 
since
  a peer may complete EAP pre-authentication with an authenticator without 
eventually
  attaching to it, it is possible that Phase 2 will not occur.

  [RFC3580] describes only minor differences in the AAA exchange occurring
  as a result of EAP pre-authentication as compared with an ordinary EAP 
authentication
  exchange.  For example, since in 802.11i an Association exchange does
  not occur prior to EAP pre-authentication, the SSID is not yet
  known.  As a result, an Access-Request generated as the
  result of pre-authentication cannot include the SSID
  within the Called-Station-Id attribute as described in
  [RFC3580] Section 3.20.  Since a peer may never
  associate with an authenticator to which it pre-authenticated,
  an Accounting-Request signifying the start of service may
  never be sent, or may only be sent with a substantial delay
  after the completion of authentication.

  Since an EAP pre-authentication exchange differs from an EAP 
authentication exchange
  only in subtle ways, the backend authentication server may not be aware of
  whether it is engaging in a pre-authentication exchange,
  resulting in operational or security problems.  For example,
  where the authenticator does not include the SSID within the 
Called-Station-Id
  attribute in ordinary requests, pre-authentication requests
  may appear indistinguishable.   As a result, the backend
  authentication server may not be able to correctly calculate
  the simultaneous sessions in progress, either preventing
  successful completion of pre-authentication or enabling
  the peer to engage in more simultaneous sessions than
  they are authorized for.

  In order to allow backend authentication servers to handle
  pre-authentication requests more reliably, it is recommended
  that EAP pre-authentication requests be explicitly identified
  within AAA protocols.  Also, in order to supress unnecessary
  EAP pre-authentication exchanges, it is recommended that
  authenticators unambiguously identify themselves as described
  in Section 2.2.1, allowing the peer to determine whether it
  has previously established EAP keying material with that
  authenticator."

_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/eap

Arhives: http://lists.frascone.com/pipermail/eap