|
List Info Thread: Issue: "neighbor cache" corruption
[1]
|
||||||||||||
|
about | contact Other archives ( Real Estate discussion Medical topics ) |
||||||||||||
Issue: "neighbor cache" corruption |
|
List Info Thread: Issue: "neighbor cache" corruption
[1]
|
||||||||||||
|
about | contact Other archives ( Real Estate discussion Medical topics ) |
||||||||||||
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.
"
____________________________________________________________
_____
To unsubscribe or modify your subscription options, please
visit: