From: Charlie Kaufman <charliekexchange.microsoft.com
To: "iesgietf.org" <iesgietf.org,
"secdirmit.edu" <secdirmit.edu,
    Bernard Aboba <bernardawindows.microsoft.com,     
  Dan
Simon<dansimonmicrosoft.com,       
"Pasi.Eronennokia.com"
<Pasi.Eronennokia.com,        "henriklevkowetz.com"
<henriklevkowetz.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.


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

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