Subject: [eap] Proposed Resolution to Issue 373: Organization of Section 4

From: "Bernard Aboba" <[email-masked]>
Date: Thu, 11 Jan 2007 21:29:44 -0800

The text of Issue 373 is enclosed below.  The proposed resolution is to 
replace Section 4 with the following text:

"4.  Handoff Vulnerabilities

   Several mechanisms have been proposed for reducing handoff latency
   within networks utilizing EAP.  These include:

EAP pre-authentication
     In EAP pre-authentication, an EAP peer pre-establishes EAP keying
     material with an authenticator prior to arrival.  EAP pre-
     authentication only affects the timing of EAP authentication, but
     does not shorten or eliminate EAP (phase 1a) or AAA (phase 1b)
     exchanges;  Discovery (phase 0) and Secure Association Protocol
     (phase 2) exchanges occur as described in Section 1.3.  As a
     result, the primary benefit is to enable EAP authentication to be
     removed from the handoff critical path, thereby reducing latency.
     Use of EAP pre-authentication within IEEE 802.11 is described in
     [8021XPreAuth] and [IEEE-802.11i].

Proactive key distribution
     In proactive key distribution, derived keying material and
     authorizations are transported from the backend authentication
     server to a candidate authenticator in advance of a handoff.  As a
     result, EAP (phase 1a) is not required, but the Discovery (phase
     0), and Secure Association Protocol exchanges (phase 2) are still
     necessary.  Within the AAA exchange (phase 1b), authorization and
     key distribution functions are typically supported, but not
     authentication.  Proactive key distribution is described in
     [MishraPro], [IEEE-03-084] and [I-D.irtf-aaaarch-handoff].

Key caching
     Caching of EAP keying material enables an EAP peer to re-attach to
     an authenticator without requiring EAP (phase 1a) or AAA (phase 1b)
     exchanges.  However, Discovery (phase 0) and Secure Association
     Protocol (phase 2) exchanges are still required.  Use of key
     caching within IEEE 802.11 is described in [IEEE-802.11i].

Context transfer
     In context transfer schemes, keying material and authorizations are
     transferred between a previous authenticator and a new
     authenticator.  This can occur in response to a handoff request by
     the EAP peer,  or in advance, as in proactive key distribution.  As
     a result, EAP (phase 1a) is eliminated, but not the Discovery
     (phase 0) or Secure Association Protocol exchanges (phase 2).  If a
     secure channel can be established between the new and previous
     authenticator without assistance from the backend authentication
     server, then the AAA exchange (phase 1b) can be eliminated;
     otherwise, it is still required, although it may be shortened.
     Context transfer protocols are described in [IEEE-802.11F] (now
     deprecated) and "Context Transfer Protocol (CXTP)" [RFC4067].
     "Fast Authentication Methods for Handovers between IEEE 802.11
     Wireless LANs" [Bargh] analyzes fast handoff techniques, including
     context transfer mechanisms.

Token distribution
     In token distribution schemes the EAP peer is provided with a
     credential, subsequently enabling it to authenticate with one or
     more additional authenticators.  During the subsequent
     authentications, EAP (phase 1a) is eliminated or shortened; the
     Discovery (phase 0) and Secure Association Protocol exchanges
     (phase 2) still occur, although the latter may be shortened.  If
     the token includes authorizations and can be validated by an
     authenticator without assistance from the backend authentication
     server, then the AAA exchange (phase 1b) can be eliminated;
     otherwise it is still required, although it may be shortened.
     Token-based schemes are described in [Token] and [I-D.friedman-ike-
     short-term-certs].

   The sections that follow discuss the security vulnerabilities
   introduced by the above schemes.

4.1.  EAP Pre-authentication

   EAP pre-authentication differs from a normal EAP conversation
   primarily with respect to the lower layer encapsulation.  For
   example, in [IEEE-802.11i], EAP pre-authentication frames utilize a
   distinct Ethertype, but otherwise conform to the encapsulation
   described in [IEEE-802.1X].  As a result, an EAP pre-authentication
   conversation differs little from the model described in Section 1.3,
   other than the introduction of a delay between phase 1 and phase 2.

   EAP pre-authentication relies on lower layer mechanisms for discovery
   of candidate authenticators.  Where discovery can provide information
   on candidate authenticators outside the immediate listening range,
   and the peer can determine whether it already possesses valid keying
   material with candidate authenticators, the peer can avoid
   unnecessary EAP pre-authentications and can establish keying material
   well in advance, regardless of the coverage overlap between
   authenticators.  However, if the peer can only discover candidate
   authenticators within listening range and cannot determine whether it
   can reuse existing key material, then peer may not be able to
   complete EAP pre-authentication prior to connectivity loss or may
   pre-authenticate multiple times with the same authenticator,
   increasing backend authentication server load.

   Since a peer may complete EAP pre-authentication with an
   authenticator without eventually attaching to it, phase 2 may never
   occur.  As a result, 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.

   As noted in "IEEE 802.1X RADIUS Usage Guidelines" [RFC3580], the AAA
   exchange resulting from EAP pre-authentication differs little from an
   ordinary exchange described in "RADIUS Support for EAP" [RFC3579].
   For example, since in IEEE 802.11i an Association exchange does not
   occur prior to EAP pre-authentication, the SSID is not known by the
   authenticator at authentication time, so that an Access-Request
   cannot include the SSID within the Called-Station-Id attribute as
   described in [RFC3580] Section 3.20.

   Since only the absence of an SSID in the Called-Station-Id attribute
   distinguishes an EAP pre-authentication attempt, if the authenticator
   does not always include the SSID for a normal EAP authentication
   attempt, the backend authentication server may not be able to
   determine whether a session constitutes an EAP pre-authentication
   attempt, potentially resulting in authorization or accounting
   problems.  Where the number of simultaneous sessions is limited, the
   backend authentication server may refuse to authorize a valid EAP
   pre-authentication attempt or may enable the peer to engage in more
   simultaneous sessions than they are authorized for.  Where EAP pre-
   authentication occurs with an authenticator which the peer never
   attaches to, the backend accounting server may not be able to
   determine whether the absence of an Accounting-Request was due to
   packet loss or a session that never started.

   In order to enable pre-authentication requests to be handled more
   reliably, it is RECOMMENDED that AAA protocols explicitly identify
   EAP pre-authentication.  In order to suppress unnecessary EAP pre-
   authentication exchanges, it is RECOMMENDED that authenticators
   unambiguously identify themselves as described in Section 2.2.1.

4.2.  Proactive Key Distribution

   In proactive key distribution schemes, the backend authentication
   server transports keying material and authorizations to an
   authenticator in advance of the arrival of the peer.  The
   authenticators selected to receive the transported key material are
   selected based on past patterns of peer movement between
   authenticators known as the "neighbor graph".  Since proactive key
   distribution schemes typically only demonstrate proof of possession
   of transported keying material between the EAP peer and
   authenticator, the backend authentication server may not be provided
   with proof that the peer successfully authenticated to an
   authenticator.  To compute the "neighbor graph" the backend
   authentication server therefore may need to rely on a stream of
   accounting messages without a corresponding set of authentication
   exchanges.

   In order to prevent compromise of one authenticator from resulting in
   compromise of other authenticators,  cryptographic separation needs
   to be maintained between the keying material transported to each
   authenticator.  However, even where cryptographic separation is
   maintained, an attacker compromising an authenticator may still
   disrupt the operation of other authenticators.  Since proactive key
   distribution schemes typically only demonstrate proof of possession
   of transported keying material between the EAP peer and
   authenticator, the backend authentication server is typically not
   provided with proof that the peer actually connected to an
   authenticator.  To compute the "neighbor graph" it therefore may be
   necessary to rely on a stream of accounting messages without a
   corresponding set of authentication exchanges to verify against.

   As noted in [RFC3579] Section 4.3.7, in the absence of spoofing
   detection within the AAA infrastructure, it is possible for EAP
   authenticators to impersonate each other.  By forging NAS
   identification attributes within accounting messages, an attacker
   compromising one authenticator could corrupt the neighbor graph,
   tricking the backend authentication server into transporting keying
   material to arbitrary authenticators.  While this would not enable
   recovery of EAP keying material without breaking fundamental
   cryptographic assumptions, it could enable fraudulent charges or
   allow an attacker to disrupt service by increasing load on the
   backend authentication server or thrashing the authenticator key
   cache.

   Since proactive key distribution requires the distribution of derived
   keying material to candidate authenticators,  the effectiveness of
   this scheme depends on the ability of backend authentication server
   to anticipate the movement of the EAP peer.  As described in [Mishra-
   Pro], knowledge of the "neighbor graph" can be established via static
   configuration or analysis of accounting messages.  Since proactive
   key distribution relies on backend authentication server knowledge of
   the "neighbor graph" it is most applicable to intra-domain handoff
   scenarios.  However, in inter-domain handoff where there may be many
   authenticators, the "neighbor graph" may not be readily derived on
   the backend authentication server, since peers may frequently connect
   to authenticators that have not previously been encountered.

   Since proactive key distribution schemes typically require
   introduction of server-initiated messages as described in [RFC3576]
   and [I-D.irtf-aaaarch-handoff],  security issues described in
   [RFC3576] Section 5 are applicable, including authorization (Section
   5.1) and replay detection (Section 5.4) problems.

4.3.  AAA Bypass

   Fast handoff techniques which enable elimination of the AAA exchange
   (phase 1b) differ fundamentally from typical network access scenarios
   (dial-up, wired LAN, etc.)  which include user authentication as well
   as authorization for the offered service.  Where the AAA exchange
   (phase 1b) is omitted, authorizations and keying material are not
   provided by the backend authentication server, and as a result they
   need to be supplied by other means.  This section describes some of
   the implications.

4.3.1.  Key Transport

   Where transported keying material is not supplied by the backend
   authentication server, it needs to be provided by another party
   authorized to access that keying material.  As noted in Section 1.5,
   only the EAP peer, authenticator and server are authorized to possess
   transported EAP keying material.   Since EAP peers do not trust each
   other, if the backend authentication server does not supply
   transported keying material to a new authenticator, it can only be
   provided by a previous authenticator.

   As noted in Section 1.5, the goal of the EAP conversation is to
   derive session keys known only to the peer and the authenticator.  If
   EAP keying material is replicated between a previous authenticator
   and a new authenticator, then the previous authenticator may
   potentially know the session keys used between the peer and new
   authenticator.  Also, the new authenticator may potentially know the
   session keys used between the peer and the previous authenticator.

   If a one-way function is used to derive the keying material to be
   transported to the new authenticator, then the new authenticator is
   not longer able to know previous session keys without breaking a
   fundamental cryptographic assumption.

4.3.2.  Authorization

   As a part of the authentication process, the backend authentication
   server determines the user's authorization profile and transmits the
   authorizations to the authenticator along with the transported EAP
   key material.  Typically, the profile is determined based on the user
   identity, but a certificate presented by the user may also provide
   authorization information.

   The backend authentication server is responsible for making a user
   authorization decision, which requires answering the following
   questions:

[a]  Is this a legitimate user of this network?

[b]  Is the user allowed to access this network?

[d]  Is the user permitted to access this network on this day and at
     this time?

[e]  Is the user within the concurrent session limit?

[f]  Are there any fraud, credit limit, or other concerns indicating
     that access should be denied?

[g]  If access is to be granted, what are the service parameters
     (mandatory tunneling, bandwidth, filters, and so on) to be
     provisioned for the user?

   While the authorization decision is in principle simple, the
   distributed decision making process may add complexity.  Where
   brokers or proxies are involved, all of the AAA entities in the chain
   from the authenticator to the home backend authentication server are
   involved in the decision.  For example, a broker can deny access even
   if the home backend authentication server would allow it, or a proxy
   can add authorizations (e.g., bandwidth limits).

   Decisions can be based on static policy definitions and profiles as
   well as dynamic state (e.g. time of day or concurrent session
   limits).  In addition to the Accept/Reject decisions made by AAA
   entities, service parameters or constraints may be communicated to
   the authenticator.

   The criteria for Accept/Reject decisions or the reasons for choosing
   particular authorizations are typically not communicated to the
   authenticator, only the final result.  As a result, the authenticator
   has no way to know what the decision was based on.  Was a set of
   authorization parameters sent because this service is always provided
   to the user, or was the decision based on the time of day and the
   capabilities of the authenticator?

4.3.3.  Correctness

   When the AAA exchange (phase 1b) is bypassed,  several challenges
   arise in ensuring correct authorization:

[a]  Theft of service.  Bypassing the AAA exchange (phase 1b) should not
     enable a user to extend their network access or gain access to
     services they are not entitled to.

[b]  Consideration of network-wide state.  Handoff techniques should not
     render the backend authentication server incapable of keeping track
     of network-wide state.  For example, a backend authentication
     server may need to keep track of simultaneous user sessions.

[c]  Elevation of privilege.  Backend authentication servers often
     perform conditional evaluation, in which the authorizations
     returned in an Access-Accept message are contingent on the
     authenticator or on dynamic state such as the time of day.  In this
     situation, bypassing the AAA exchange could enable unauthorized
     access unless the restrictions are explicitly encoded within the
     authorizations provided by the backend authentication server.

   A handoff mechanism that provides proper authorization is said to be
   "correct".  One condition for correctness is as follows:

      For a handoff to be "correct" it MUST establish on the new
      authenticator the same authorizations as would have been created
      had the new authenticator completed a AAA conversation with the
      backend authentication server.

   A properly designed handoff scheme will only succeed if it is
   "correct" in this way.  If a successful handoff would establish
   "incorrect" authorizations, it is preferable for it to fail.  Where
   the supported services differ between authenticators, a handoff that
   bypasses the backend authentication server is likely to fail.
   [RFC2865] section 1.1 states:

      A authenticator that does not implement a given service MUST NOT
      implement the RADIUS attributes for that service.  For example, a
      authenticator that is unable to offer ARAP service MUST NOT
      implement the RADIUS attributes for ARAP.  A authenticator MUST
      treat a RADIUS access-accept authorizing an unavailable service as
      an access-reject instead.

   This behavior applies to attributes that are known, but not
   implemented.  For attributes that are unknown, [RFC2865] Section 5
   states:

      A RADIUS server MAY ignore Attributes with an unknown Type.  A
      RADIUS client MAY ignore Attributes with an unknown Type.

   In order to perform a correct handoff, if a new authenticator is
   provided with RADIUS authorizations for a known but unavailable
   service, then it MUST process these authorizations the same way it
   would handle a RADIUS Access-Accept requesting an unavailable
   service;  this MUST cause the handoff to fail.  However, if a new
   authenticator is provided with authorizations including unknown
   attributes, then these attributes MAY be ignored.  The definition of
   a "known but unsupported service" MUST encompass requests for
   unavailable security services.  This includes vendor-specific
   attributes related to security, such as those described in [RFC2548].
   Although it may seem somewhat counter-intuitive, failure is indeed
   the "correct" result where a known but unsupported service is
   requested.

   Presumably a correctly configured backend authentication server would
   not request that an authenticator provide a service that it does not
   implement.  This implies that if the new authenticator were to
   complete a AAA conversation, it would be likely to receive different
   service instructions.  Failure of the handoff is the desired result
   since it will cause the new authenticator to go back to the backend
   server in order to receive the appropriate service definition.

   Handoff mechanisms which bypass the backend authentication server are
   most likely to be successful when employed in a homogeneous
   deployment within a single administrative domain.  In a heterogeneous
   deployment, the backend authentication server may return different
   authorizations depending on the authenticator making the request, in
   order to make sure that the requested service is consistent with the
   authenticator capabilities.  Where a backend authentication server
   would send different authorizations to the new authenticator than
   were sent to a previous authenticator,  transferring authorizations
   between the previous authenticator and the new authenticator will
   result in incorrect authorization.

   Virtual LAN (VLAN) support is defined in [IEEE-802.1Q]; RADIUS
   support for dynamic VLANs is described in [RFC3580] and [RFC4675].
   If some authenticators support dynamic VLANs while others do not,
   then attributes present in the Access-Request (such as the NAS-Port-
   Type, NAS-IP-Address, NAS-IPv6-Address and NAS-Identifier) could be
   examined by the backend authentication server to determine when VLAN
   attributes will be returned, and if so, which ones.  However, if the
   backend authenticator is bypassed, then a handoff occurring between
   authenticators supporting different VLAN capabilities could result in
   a user obtaining access to an unauthorized VLAN (e.g. a user with
   access to a guest VLAN being given unrestricted access to the
   network).

   Similarly, a handoff between an authenticator providing
   confidentiality and another that does not should fail, since if the
   handoff were successful, the user would be moved from a secure to an
   insecure channel without permission from the backend authentication
   server."

====================================
Issue 373: Organization of Section 4
Submitter name: Bernard Aboba
Submitter email address: [email-masked]
Date Submitted: August 2, 2006
Reference: http://lists.frascone.com/pipermail/eap/msg04476.html
Document: KEYING-14
Comment type: 'T'echnical
Priority: S
Section: 4
Rationale/Explanation of issue:

Section 4 states the following:

" With EAP, several mechanisms are available to reduce the latency in
   handoff between authenticators:

[a]  EAP pre-authentication.  This utilizes EAP to pre-establish EAP
     keying material on an authenticator prior to arrival of the peer.
     Use of pre-authentication within IEEE 802.11 is described in
     [8021XHandoff] and [IEEE-802.11i].

[b]  Key caching.  This mechanism enables an EAP peer to re-attach to an
     authenticator without requiring EAP re-authentication.

[c]  Context transfer, such as is defined in [IEEE-802.11F] (now
     deprecated) and [RFC4067].  Use of context transfer for handoff
     latency improvement is described in [IEEE-02-758].

[d]  Proactive key distribution, such as is described in
     [IEEE-02-758][IEEE-03-084] and [I-D.irtf-aaaarch-handoff].

   The sections that follow discuss the security vulnerabilities
   introduced by the above mechanisms."

However, while Section 4.1 does talk about Pre-authentication,
it is not made explicit how Sections 4.2 and 4.3 relate to the
security of Key Caching, Context Transfer or Proactive Key
distribution.

For example, issues of authorization and correctness do not
apply to mechanisms which utilize AAA to distribute authorizations.
Therefore Section 4.2 and 4.3 do not seem to relate to the
Pre-authentication or Proactive Key Distribution mechanisms,
only to Key Caching and Context Transfer.

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

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