eap Mailing List: Issue 351: Incomplete EAP Pre-authentication discussion

[Bernard Aboba (bernard_aboba]

Issue 351: Incomplete EAP Pre-authentication discussion
Submitter name: Bernard Aboba
Submitter email address: aboba [at] internaut.com
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."