Subject: [eap] Issue: "neighbor cache" corruption

From: "Bernard Aboba" <[email-masked]>
Date: Sat, 05 May 2007 10:01:08 -0700

Issue 393: Neighbor Cache Corruption
Submitter name: Bernard Aboba
Submitter email address: [email-masked]
Date Submitted: May 5, 2007
Reference:
Document: KEYING-18
Comment type: Editorial
Priority: S
Section: 4.2
Rationale/Explanation of issue:

In Section 4.2 it is noted that the "neighbor graph" can be calculated based 
on accounting messages, and it is also noted that accounting messages can be 
sent without a corresponding authentication exchange.  Shortly thereafter 
there is a discussion of "neighbor graph" corruption attacks.  The 
discussion leaves the impression that the issues of "neighbor graph" 
corruption and accounting messages without authentication exchanges are 
related, when they are not.  "Neighbor Graph" entries are either created 
statically or as the result of authentication exchanges with the backend 
server, so that accounting messages generated from a fast handoff cannot 
result in "neighbor graph" corruption.   Rather, authenticator impersonation 
is required.

To make this relationship more clear, a few transitional sentences need to 
be added.

The proposed resolution is as follows:

Change Section 4.2 from:

"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.
"

To:

"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".  In order to reduce
   handoff latency, proactive key distribution schemes typically only
   demonstrate proof of possession of transported keying material
   between the EAP peer and authenticator.  During a handoff, the
   backend authentication server is not provided with proof that the
   peer successfully authenticated to an authenticator; instead, the
   authenticator generates a stream of accounting .  messages without a
   corresponding set of authentication exchanges.  As described in
   [Mishra-Pro], knowledge of the neighbor graph can be established via
   static configuration or analysis of authentication exchanges.  In
   order to prevent corruption of the neighbor graph, new neighbor graph
   entries can only be created as the result of a successful EAP
   exchange, and accounting packets with no corresponding authentication
   exchange need to be verified to correspond to neighbor graph entries
   (e.g. corresponding to handoffs between neighbors).

   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 can still
   disrupt the operation of other authenticators.  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
   authentication 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
   subsequent fraudulent accounting messages, 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.  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 can be many
   authenticators, peers can frequently connect to authenticators that
   have not been previously encountered, making it difficult for the
   backend authentication server to derive a complete neighbor graph.

   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.
"

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

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