eap Mailing List: Re: Issue 392: Authorization Issues

[Bernard Aboba (bernard_aboba]

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