Subject: Re: [eap] Issue 392: Authorization Issues

From: "M. Vanderveen" <[email-masked]>
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

----- Original Message ----
From: Bernard Aboba <[email-masked]>
To: [email-masked]; [email-masked]
Sent: Tuesday, February 6, 2007 1:31:15 PM
Subject: Re: [eap] Issue 392: Authorization Issues

>I have read the new text and agree with most of them.
>
>1. Here is one change that I disagre with ("should not" turned into "must 
>not", and no basis from the Guidelines BCP-to-be that I can see): Section 
>5.1:
>Text of -17.txt: "
>[.. ]this should not allow the attacker to compromise other
>authenticators or the backend authentication server"
>New text:
>Compromise of a single authenticator MUST
>NOT compromise keying material held by any other authenticator within
>the system, and SHOULD NOT allow the attacker to compromise the
>backend authentication server

The MUST NOT appears to come from Section 3 of 
draft-housley-aaa-key-mgmt-06.txt:

      Prevent the Domino effect

         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.  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.

>2. Compromise of Peer in section 5.1: hopefully this does not invalidate 
>the idea of Group keys for multicast (if a Peer's group key is compromised, 
>so will the group keys of other peers in his multicast group - can't be 
>helped).

Right. We should add: "with the possible exception of group keys".

>3. Last paragraph of Section 5.8 "
>the backend authentication server can impersonate the authenticator ". Not 
>really necessary to say this, especially since the guidelines say that the 
>backend authentication server is a trusted party, yes?

Right.  We can delete this.

>Some nits: page 43 bottom: "an stale key" -> "a stale key".
>Section 5.7, 3rd paragraph starts with "EAP EAP", 4th paragraph contains 
>"and and", 5th paragraph starts with "AAA The AAA".

Thanks.  We should fix these.

____________________________________________________________________________________
Need a quick answer? Get one in minutes from people who know.
Ask your question on www.Answers.yahoo.com

_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/eap

Arhives: http://lists.frascone.com/pipermail/eap

---

From: "Bernard Aboba" <[email-masked]>
Date: Wed, 07 Feb 2007 10:29:29 -0800

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" <[email-masked]>
>To: Bernard Aboba <[email-masked]>, [email-masked]
>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

---

From: Lakshminath Dondeti <[email-masked]>
Date: Sun, 11 Feb 2007 10:52:54 -0800

I was catching on this discussion and it occurred to me that we can 
generalize the following text a bit further:

Bernard Aboba wrote:
>    Likewise, compromise of a
>    other authenticator within the system.  

Does this mean we are ok with a key management system where compromise 
of two or more authenticators leads to the compromise of keys help by 
other authenticators?  I think not.

We could reword to say "compromise of one or more authenticators MUST 
NOT compromise keying material held by the rest of the authenticators 
within the system"  or something like that.

thanks Bernard,
Lakshminath