Re: Issue 392: Authorization Issues

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" <mvandervnyahoo.com&gt;
>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).
&gt;
>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