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

[Bernard Aboba (bernard_aboba]

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.