eap Mailing List: Re: Issue 392: Authorization Issues

[Bernard Aboba (bernard_aboba]

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 [at] yahoo.com>
> To: Bernard Aboba <bernard_aboba [at] hotmail.com>, eap [at] frascone.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