eap Mailing List: Issue: "neighbor cache" corruption

[Bernard Aboba (bernard_aboba]

Issue 393: Neighbor Cache Corruption
Submitter name: Bernard Aboba
Submitter email address: aboba [at] internaut.com
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.
"