Here is some revised text:
5.1. Peer and Authenticator Compromise
Requirement: In the event that an authenticator is
compromised or
stolen, an attacker may gain access to the network
through that
authenticator, or may obtain the credentials required for
the
authenticator/AAA client to communicate with one or more
backend
authentication servers. Similarly, if a peer is
compromised or
stolen, an attacker may obtain credentials required to
communicate with one or more authenticators. Compromise
of a single
peer MUST NOT compromise keying material held by any
other peer
within the system, including session keys and long-term
keys, with
the possible exception of group keys. Likewise,
compromise of a
single authenticator MUST NOT compromise keying material
held by any
other authenticator within the system. In the context of
a key
hierarchy, this means that the compromise of one node in
the key
hierarchy must not disclose the information necessary to
compromise
other branches in the key hierarchy. Obviously, the
compromise of
the root of the key hierarchy will compromise all of the
keys;
however, a compromise in one branch MUST NOT result in
the compromise
of other branches. There are many implications of this
requirement;
however, two implications deserve highlighting. First,
the scope of
the keying material must be defined and understood by all
parties
that communicate with a party that holds that keying
material.
Second, a party that holds keying material in a key
hierarchy must
not share that keying material with parties that are
associated with
other branches in the key hierarchy.
Some of the implications of the requirement are as
follows:
No Key Sharing
An EAP authenticator MUST NOT share any keying material
with
another EAP authenticator, since if one EAP
authenticator were
compromised, this would enable the compromise of keying
material on
another authenticator. In order to be able to
determine whether
keying material has been shared, it is necessary for
the identity
of the EAP authenticator to be defined and understood
by all
parties that communicate with it. Similarly, an EAP
peer MUST NOT
share any keying material with another EAP peer.
No AAA Credential Sharing
AAA credentials (such as RADIUS shared secrets, IPsec
pre-shared
keys or certificates) MUST NOT be shared between AAA
clients, since
if one AAA client were compromised, this would enable
an attacker
to impersonate other AAA clients to the backend
authentication
server, or even to impersonate a backend authentication
server to
other AAA clients.
No Compromise of Long-Term Credentials
An attacker obtaining TSKs, TEKs or EAP keying material
such as the
MSK MUST NOT be able to obtain long-term user
credentials such as
pre-shared keys, passwords or private-keys without
breaking a
fundamental cryptographic assumption.
>From: "M. Vanderveen" <mvandervn yahoo.com>
>To: Bernard Aboba <bernard_abobahotmail.com>, eapfrascone.com
>Subject: Re: [eap] Issue 392: Authorization Issues
>Date: Tue, 6 Feb 2007 13:48:46 -0800 (PST)
>
>I guess part of the confusion is between compromise of a
key vs. compromise
>of an entity. The latter probably includes the former
(for keys that the
>compromised entity holds).
>
>Compromise of an authenticator must not lead to
compromise of another
>authenticator. But here it seems that what we are saying
is that compromise
>of an authenticator must not lead to compromise of a key
held by another
>authenticator (who is still holding up and is not
compromised). Perhaps the
>guidelines should be clarified, e.g. compromise of a key
must not lead to
>compromise of another key (held by a different entity).
This is what the
>hierarchy discussion is applicable.
>
>Michaela
____________________________________________________________
_____
To unsubscribe or modify your subscription options, please
visit:
http:/
/lists.frascone.com/mailman/listinfo/eap
Arhives: http://lists.
frascone.com/pipermail/eap
|
