Subject: [eap] [Fwd: Re: hopefully final changes for draft-ietf-eap-keying]

From: "Dan Harkins" <[email-masked]>
Date: Wed, 14 Nov 2007 11:02:10 -0800 (PST)

Sam,

  Where in RFC4962 are the properties of a "key derivation function"
enumerated and where does it explain which of these properties makes
a derived key "sharable"?

  I see the following sentence in RFC4962:

   "If the authenticator uses a key derivation function to derive
    additional keying material, the authenticator is trusted to
    distribute the derived keying material only to the appropriate
    party that is known to the peer, and no other party."

Now if one takes that sentence out of context one may think that there
does exist a magical function that makes keys sharable. But the context
around that sentence includes this before:

   "The authenticator is trusted not to distribute keying material
    provided by the AAA server to any other parties."

and this after:

   "When this approach is used, care must be taken to ensure that the
    resulting key management system meets all of the principles in this
    document, confirming that keys used to protect data are to be known
    only by the peer and authenticator."

So how can one use a key derivation function to distribute keying material
to another party such that it meets all the principles in that document,
like "prevent the domino effect", such that only the peer and authenticator
know the keys? Well, if one parses the above 3 sentences with _session
keys_ in mind it is possible. The "appropriate party known to the peer" is
the entity engaging in the "secure association protocol". That entity is
not another authenticator.

  So there's a key that an authenticator uses with a key derivation
function to produce session keys which are then used to protect data.
There isn't a key that's used in a key derivation function by an
authenticator to derive another key that is distributed to and used by a
different authenticator that is then used (by this different
authenticator) with another key derivation function to produce session
keys.

  The "indistinguishable from random" property of a key derivation
function is necessary and sufficient if it's deriving session keys on
an authenticator to be used to protect sessions. But that is _not_ the
way it's being proposed to be used by this modification to the EAP
keying draft. If non session keys are being distributed then how does
it "meet all principles in [RFC4962]", including preventing the domino
effect?

  Dan.

On Wed, November 14, 2007 8:28 am, Sam Hartman wrote:
>>>>>> "Dan" == Dan Harkins <[email-masked]> writes:
>
>     Dan>   Hi Jari,
>
>     Dan>   Thanks for forwarding this.
>
>     Dan>   Sam, comments below.
>
>     Dan> On Tue, November 13, 2007 1:33 pm, Jari Arkko wrote:
>     >> Dan,
>     >>
>     >> Please find a reply from Sam Hartman on your issue below.
>     >>
>     >> ----
>     >>
>     >> Jari, I don't know where this was sent, so feel free to forward
>     >> my reply.
>     >>
>     dan> Dan Harkins kirjoitti:
>     >> >> Hi Jari,
>     >> >>
>     >> >> I have some issues with the proposed changes to section 5.1.
>     >> >> You add an exception to key sharing permitting it if "it has
>     >> >> been derived with a key-derivation function." What are the
>     >> >> properties such a function has that would make sharing of
>     >> keys >> it derives acceptable?
>     >>
>     >> This sounds like an excellent area to focus future work.  I
>     >> don't think adding items to the scope of the eap keying
>     >> document is appropriate at this time.
>
>     Dan>   I don't understand how this is "future work". There was a
>     Dan> proposal that adding "if it was been derived with a
>     Dan> key-derivation function" would make it OK to share keys. I
>     Dan> think it's incumbent upon the one making such an assertion to
>     Dan> say what the properties this function has that make it OK to
>     Dan> now share a key.
>
> Ah.  I believe that we already enabled this in RFC 4962 and that this
> proposal is simply aligning eap-keying with 4962.  So, that's the
> sense in which I think it is future work.
>
>     >> >> It is also not sufficient because the EAP peer has no way of
>     >> >> knowing when compromise has happened. Keys in his key
>     >> hierarchy >> just pop up on the network and he is expected to
>     >> just _assume_ >> everything is fine.
>     >>
>     >> We had a discussion during RFC 4962's last call about whether
>     >> the peer needed to be notified when keys were distributed.  I
>     >> saw no support besides your comments for your position that
>     >> peers needed to be notified.
>
>     Dan> My comment was that a peer has no idea whether a key
>     Dan> hierarchy was compromised or not. Is that not a true
>     Dan> statement?
>
> That is a true statement.  However your comment went beyond making a
> statement about what peers know; by saying "this is not sufficient
> because," you make the claim that peers knowing whether the key
> hierarchy is compromised is a requirement.  I agree that peers will
> not know of a compromise.  I disagree that this is a requirement.
>
>
>     Dan> Yes, I know. Because it's easy to just throw keys around
>     Dan> hither-and-yon.  It is frequently argued that possession of a
>     Dan> key implies authorization to hold that key but it is never
>     Dan> argued why (except via the "why not?"  non-argument
>     Dan> argument).
>
> I think any spec that proposed to share keys would need to discuss how in
> that spec the keys were authorized.
>
>     >> >> >> If you want to start sharing keys between authenticators
>     >> then >> you REALLY have a 3 party protocol: 1) EAP peer; 2) EAP
>     >> >> server-cum-authenticator running a key derivation function;
>     >> and >> 3) another authenticator being the recipient of the
>     >> output of >> the key derivation function. There's no way to
>     >> fudge that into >> 2 parties.
>     >>
>     >> Absolutely correct.
>
>     Dan>   So what's the 3 party protocol then?
>
> To be implementable any spec that described a specific instance of
> sharing keys would need to describe what three-party protocol is used.
>
>     >> Some of the things hokey is doing are very clearly three or
>     >> more party.
>
>     Dan> I agree.
>
>     >> This document covers interactions that go beyond EAP.  RFC 4962
>     >> definitely does and may even have a broader scope.  >> that new
>     >> authenticator would severely, and in my opinion >>
>     >> deleteriously, affect the security of EAP.
>     >> >>
>     >> >> If a 3 party key distribution protocol is the answer to some
>     >> >> problem then a true 3 party protocol MUST be used. I really
>     >>
>     >> This decision belongs within the charter of hokey.  To the
>     >> extent it is not already decided, please discuss it there.
>
>     Dan>   This is a proposal to modify the EAP keying draft. It seems
>     Dan> like the EAP working group's mailing list, and not hokey, is
>     Dan> an entirely appropriate place to discuss it.
>
>     Dan>   Obviously you want to enable hokey to share EAP keys. If
>     Dan> you want to do that then I think the procedure is to do a
>     Dan> RFC4962bis that removes the "prevent the domino effect"
>     Dan> requirement, which acceptable AAA solutions MUST comply
>     Dan> with. Then EAP can relax its requirements to say it's OK, but
>     Dan> I still think it has to ascribe properties to functions that
>     Dan> it is using. And then hokey can start saying how it's going
>     Dan> to share keys.
>
>     Dan>   I don't think it's right to cram through nebulous language
>     Dan> into a document discussing security. And I say "cram" because
>     Dan> of your statement, "To the extent it is not already
>     Dan> decided". This doesn't smell right.
>
>     Dan>   Dan.
>
>
>
>
>

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

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

---

From: <[email-masked]>
Date: Wed, 14 Nov 2007 11:29:27 -0800

> Well, if one parses the above 3 sentences with _session
> keys_ in mind it is possible.

The definition of "keying material" in RFC 4962 is the same as in the
EKMF document -- it refers to EAP keying material as well as session keys
and intermediate keys.

In reading these paragraphs, I don't believe they prohibit a fast
reauthentication exchange where the new authenticator obtains
from the AAA server a key that is cryptographically separate from a previous
key given to the old authenticator.

Since compromise of one authenticator would not result in compromise of
another one,  I don't think that this would run afoul of any statements in
RFC 4962 or the EKMF (related to key sharing or otherwise).

---

From: "Dan Harkins" <[email-masked]>
Date: Wed, 14 Nov 2007 12:09:41 -0800 (PST)

Hi Bernard,

  Yes that sounds like another valid parsing of that text. And I
note that such a parsing doesn't cover the case of an authenticator
taking a key it received from a AAA server, running some "key derivation
function" on it and sending the derived key to a distinct authenticator.

  Dan.

---

From: "Dan Harkins" <[email-masked]>
Date: Wed, 14 Nov 2007 12:39:16 -0800 (PST)

Hi Sam,

On Wed, November 14, 2007 11:26 am, Sam Hartman wrote:
>     Dan>   Sam,
>     Dan>   Where in RFC4962 are the properties of a "key derivation
>     Dan> function" enumerated and where does it explain which of these
>     Dan> properties makes a derived key "sharable"?
>
> They are not.  You may have found a problem with RFC 4962.  I don't
> think that means we need to fix that now in order to bring this spec
> into alignment with RFC 4962.
>
> Alternatively one could argue (and I do) that RFC 4962 leaves the
> security analysis of the key derivation function up to the protocol
> defining that function.

  That may very well be but RFC4962 explicitly says that a solution that
is acceptable and conforms MUST meet the requirements in it. One of those
is that:

        "compromise of a single authenticator MUST NOT compromise
         keying material held by any other authenticator within the
         system."

If an authenticator runs a key derivation function on a key it obtained
from the AAA server and ships that derived key off to another
authenticator it will violate that requirement.

  So if the draft we're discussing wishes to make an exception on the
key sharing prohibition when "[the key] has been derived with a
key-derivation function" then it has to explain what property of this
"key-derivation function" allows it to still conform to RFC4962. Well,
that's what my argument is. Why is that argument not valid?

  Dan.

---

From: <[email-masked]>
Date: Wed, 14 Nov 2007 12:48:13 -0800

> that's what my argument is. Why is that argument not valid?

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? 
For example, would the following text (from -22) work? 

"Some of the implications of the requirement are as follows:

Key Sharing
     In order to be able to determine whether keying material has been
     shared, it is necessary for the identity of the EAP authenticator
     (NAS-Identifier) to be defined and understood by all parties that
     communicate with it.  EAP lower layer specifications such as
     [IEEE-802.11], [IEEE-802.16e], [IEEE-802.1X], IKEv2 [RFC4306] and
     PPP [RFC1661] do not involve key sharing.

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.

Compromise of Long-Term Credentials
     An attacker obtaining keying material (such as TSKs, TEKs or 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.  The mandatory requirements
     of [RFC4017] Section 2.2 include generation of EAP keying material,
     capability to generate EAP keying material with 128-bits of
     effective strength, resistance to dictionary attacks, shared state
     equivalence and protection against man-in-the-middle attacks." 
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/eap

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 14 Nov 2007 16:19:49 -0500

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

Yoshihiro Ohba

---

From: <[email-masked]>
Date: Wed, 14 Nov 2007 13:35:13 -0800

> to the specific text on the requirement on "Prevent the Domino effect"

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