eap Mailing List: Re: Issue 392: Authorization Issues

[M. Vanderveen (mvandervn]

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

---

No need to miss a message. Get email on-the-go 
with Yahoo! Mail for Mobile. Get started.