eap Mailing List: FW: [secdir] secdir review of draft-ietf-eap-keying-18.txt (part 3)

[Bernard Aboba (Bernard_Aboba]

-----Original Message-----
From: Charlie Kaufman [mailto:charliek [at] exchange.microsoft.com] 
Sent: Monday, October 29, 2007 1:56 PM
To: Bernard Aboba; secdir [at] mit.edu
Cc: eap [at] frascone.com
Subject: RE: [secdir] secdir review of draft-ietf-eap-keying-18.txt (part 3)

I've reviewed all of the proposed changes and they address all of my
previous comments and concerns.

        --Charlie

-----Original Message-----
From: secdir-bounces [at] mit.edu [mailto:secdir-bounces [at] mit.edu] On 
Behalf Of
Bernard Aboba
Sent: Tuesday, October 16, 2007 2:17 PM
To: secdir [at] mit.edu
Cc: eap [at] frascone.com
Subject: Re: [secdir] secdir review of draft-ietf-eap-keying-18.txt (part 3)

From: Charlie Kaufman <charliek [at] exchange.microsoft.com
To: "iesg [at] ietf.org" <iesg [at] ietf.org, "secdir [at] mit.edu" <secdir 
[at] mit.edu,
    Bernard Aboba <bernarda [at] windows.microsoft.com,        Dan
Simon<dansimon [at] microsoft.com,        "Pasi.Eronen [at] nokia.com"
<Pasi.Eronen [at] nokia.com,        "henrik [at] levkowetz.com"
<henrik [at] levkowetz.com
Subject: [secdir] secdir review of draft-ietf-eap-keying-18.txt
Date: Sun, 25 Feb 2007 18:55:23 -0800

P29 3.1 (j): Why is it important that the SAP be implemented in the
authenticator rather than the backend authentication server? I can see how
it would usually be implemented there, and the system would be marginally
more secure if it were implemented there, but MUST NOT seems a bit strong.
This is really an implementation choice.

[BA] Within EAP lower layers such as IKEv2, EAP is only used for
authentication, not TSK derivation, so that the backend authentication
server does not have knowledge of the TSKs.  Were the TSKs to be
derived on the backend authentication server, the TSKs would
no longer be known only by the two principal parties (peer and
authenticator).

P30 3.3: "This is true even where exported EAP keying material is only used
for entity authentication...". Why? It would seem that in that case, the
lifetime of the TSKs and the lifetime of MSK/EMSK would be independent. If
I use my driver's license to authenticate myself to a passport agency,
there is no requirement that the passport expiration be sooner than the
driver's license expiration. If I authenticate with unexpired credentials,
my authentication does not expire just because the credentials do.

[BA] I think the issue here is the consequence of the compromise
of EAP keying material.  The previous sentence reads:

"  When an EAP re-authentication takes place, new keying material is
   derived and exported by the EAP method, which eventually results in
   replacement of TSKs, regardless of the way they are derived (see
   Section 2.1)."

So the question is what the underlying principle is that leads
to this recommendation.  Note that with respect to IKEv2,
RFC 4718 Section 5.2 states:

"  This means that reauthentication also establishes new keys for the
   IKE_SA and CHILD_SAs.  Therefore, while rekeying can be performed
   more often than reauthentication, the situation where "authentication
   lifetime" is shorter than "key lifetime" does not make sense.

   While creation of a new IKE_SA can be initiated by either party
   (initiator or responder in the original IKE_SA), the use of EAP
   authentication and/or configuration payloads means in practice that
   reauthentication has to be initiated by the same party as the
   original IKE_SA.  IKEv2 base specification does not allow the
   responder to request reauthentication in this case; however, this
   functionality is added in [ReAuth]."

I propose we change the text from:

"   When an EAP re-authentication takes place, new keying material is
   derived and exported by the EAP method, which eventually results in
   replacement of TSKs, regardless of the way they are derived (see
   Section 2.1).  While the maximum lifetime of TSKs or child keys can
   be less than or equal to that of the MSK/EMSK, it cannot be greater.
   This is true even where exported EAP keying material is only used for
   entity authentication and is not used for key derivation (such as in
   IKEv2), so that compromise of exported EAP keying material does not
   imply compromise of the TSKs or child keys.  However, where child
   keys are derived from or are wrapped by EAP keying material,
"
To:

"  When an EAP re-authentication takes place, new EAP keying material is
   exported by the EAP method.  In EAP lower layers where
   EAP re-authentication eventually results in TSK replacement,
   the maximum lifetime of derived keying material (including
   TSKs) can be less than or equal to that of EAP keying material
   (MSK/EMSK), but it cannot be greater.

   Where TSKs are derived from or are wrapped by exported
   EAP keying material, compromise of that exported EAP keying
   material implies compromise of TSKs.  Therefore
   if EAP keying material is considered stale, not only
   SHOULD EAP re-authentication be initiated, but also
   replacement of child keys, including TSKs.

   Where EAP keying material is used only for entity
   authentication but not for TSK derivation (as in IKEv2),
   compromise of exported EAP keying material does not imply
   compromise of the TSKs.  Nevertheless, the compromise
   of EAP keying material could enable an attacker to
   impersonate an authenticator, so that EAP
   re-authentication and TSK re-key are RECOMMENDED.

   With respect to IKEv2, [RFC478] Section 5.2 states:

      Rekeying the IKE-SA and reuathentication are different
      concepts in IKEv2.  Rekeying the IKE_SA establishes
      new keys for the IKE_SA and reets the Message ID
      counters, but it does not authenticate the parties
      again (no AUTH or EAP payloads are involved)...
      This means that reauthentication also establishes
      new keys for the IKE_SA and CHILD_SAs.  Therefore
      while rekeying can be performed more often than
      reauthentication, the situation where "authentication
      lifetime" is shorter than "key lifetime" does not
      make sense."

P43 Security Considerations: What got included under security
considerations, what was in the main text of the document, and what
appeared in both places seemed largely random. That's probably OK. When a
document is primarily about security (as this one is), it's hard to know
how to structure it. This document has a very good flow for readability.

[BA] The structure of the security considerations document is largely
structured around the requirements described in "Guidance for
AAA Key Management" [RFC4962].  To make this more clear, the
RFC 4962 requirement are now quoted and Section 5
now contains the sentence:

"  In order to address these threats, [RFC4962] Section 3 provides a
   description of mandatory system security properties.  These
   requirements are discussed in the sections that follow."

P45 5.1 1st para: This seems to have requirements that conflict with the
ability to hand off connections (though perhaps some clever mechanism
involving doing all handoffs through the EAP server is what you have in
mind).

[BA] The paragraph you refer to is actually taken from RFC 4962.
This is now referenced and quoted verbatim.


_______________________________________________
secdir mailing list
secdir [at] mit.edu
https://mailman.mit.edu/mailman/listinfo/secdir