| Re: [Fwd: Re: hopefully final changesfordraft-ietf-eap-keying] | <– Date –> <– Thread –> |
|
From: Bernard_Aboba (Bernard_Aboba |
|
| Date: Wed, 14 Nov 2007 13:34:56 -0800 (PST) | |
If RFC 4962 covers this topic, what text do we need in the EKMF document? Is deleting the sentence in question (and saying nothing) acceptable?
Yes, it is acceptable to me, as long as the EKMF draft has a citation to the specific text on the requirement on "Prevent the Domino effect" in RFC 4962.
The document actually copies the RFC 4962 text verbatim. From -22 Section 5.1:
"5.1. Peer and Authenticator Compromise
Requirement: In the event that an authenticator is compromised or stolen, an attacker can gain access to the network through that authenticator, or can obtain the credentials needed for the authenticator/AAA client to communicate with one or more backend authentication servers. Similarly, if a peer is compromised or stolen, an attacker can obtain credentials needed to communicate with one or more authenticators. Mandatory requirement from [RFC4962] Section 3:
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.Group keys are an obvious exception. Since all members of the
group have a copy of the same key, compromise of any one of the
group members will result in the disclosure of the group key.
"
- Re: [Fwd: Re: hopefully final changes for draft-ietf-eap-keying], (continued)
- Re: [Fwd: Re: hopefully final changes for draft-ietf-eap-keying] Dan Harkins, November 14 2007
- Message not available
- Re: [Fwd: Re: hopefully final changes for draft-ietf-eap-keying] Dan Harkins, November 14 2007
- Re: [Fwd: Re: hopefully final changes fordraft-ietf-eap-keying] Bernard_Aboba, November 14 2007
- Re: [Fwd: Re: hopefully final changes fordraft-ietf-eap-keying] Yoshihiro Ohba, November 14 2007
- Re: [Fwd: Re: hopefully final changesfordraft-ietf-eap-keying] Bernard_Aboba, November 14 2007
Results generated by Tiger Technologies using MHonArc.