eap Mailing List: Re: Issue 392: Authorization Issues

[M. Vanderveen (mvandervn]

Sounds fine to me, thanks for your effort.

----- Original Message ----
From: Bernard Aboba <bernard_aboba [at] hotmail.com>
To: mvandervn [at] yahoo.com; eap [at] frascone.com
Sent: Wednesday, February 7, 2007 10:29:29 AM
Subject: Re: [eap] 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" <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

---

Food fight? Enjoy some healthy debate
in the Yahoo! Answers Food & Drink Q&A.