>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.
____________________________________________________________
_____
To unsubscribe or modify your subscription options, please
visit:
http:/
/lists.frascone.com/mailman/listinfo/eap
Arhives: http://lists.
frascone.com/pipermail/eap
|
