Proposed Resolution of Issue 361: Child Key Expiry

To better capture the dependency issue, the following
revision of Section 
3.5 is proposed:

"3.5.  Exported and Calculated Key Lifetimes

   All EAP methods generating keys are required to generate
the MSK and
   EMSK, and may optionally generate the IV.  However, EAP,
defined in
   [RFC3748], does not itself support the negotiation of
lifetimes for
   exported keying material such as the MSK, EMSK and IV.

   Several mechanisms exist for managing key lifetimes:

[a]  AAA attributes.  AAA protocols such as RADIUS [RFC2865]
and
     Diameter [RFC4072] support the Session-Timeout
attribute.  The
     Session-Timeout attribute represents the maximum
lifetime of the
     exported keying material, and all keys depending on it,
on the
     authenticator.  Since existing backend authentication
servers do
     not cache keys exported by EAP methods, or keys
calculated from
     exported keys, the value of the Session-Timeout
attribute has no
     bearing on the key lifetime within the backend
authentication
     server.

     On the authenticator,  where EAP is used for
authentication the
     Session-Timeout attribute represents the maximum
session time prior
     to re-authentication.  As described in [RFC3580]
Section 3.17, when
     sent in an Access-Accept along with a
Termination-Action value of
     RADIUS-Request, the Session-Timeout attribute specifies
the maximum
     number of seconds of service provided prior to
re-authentication.

     Where EAP is used for pre-authentication, the session
may not start
     until some future time, or may never occur. 
Nevertheless, the
     Session-Timeout value represents the maximum time after
which
     transported EAP keying material, and all keys dependent
on it, will
     have expired on the authenticator.  If the session
subsequently
     starts, re-authentication will be initiated once the
Session-Time
     has expired. If the session never started, or started
and ended, by
     default keys transported by AAA and all keys dependent
on them be
     expired by the authenticator prior to the future time
indicated by
     Session-Timeout; this feature is utilized by
[IEEE-802.11i].  Note
     that in future additional attributes may be specified
to control
     the lifetime of cached keys; these attributes may
modify the
     meaning of the Session-Timeout attribute in specific
circumstances.

     Since the TSK lifetime is often determined by
authenticator
     resources, and the backend authentication server has no
insight
     into the TSK derivation process, by the principle of
ciphersuite
     independence, it is not appropriate for the backend
authentication
     server to manage any aspect of the TSK derivation
process,
     including the TSK lifetime.

[b]  Lower layer mechanisms.  While AAA attributes can
communicate the
     maximum exported key lifetime, this only serves to
synchronize the
     key lifetime between the backend authentication server
and the
     authenticator.  Lower layer mechanisms such as the
Secure
     Association Protocol can then be used to enable the
lifetime of
     exported and calculated keys to be negotiated between
the peer and
     authenticator.

     Where TSKs are established as the result of a Secure
Association
     Protocol exchange, it is RECOMMENDED that the Secure
Association
     Protocol include support for TSK re-key.  Where the TSK
is taken
     directly from the MSK, there is no need to manage the
TSK lifetime
     as a separate parameter, since the TSK lifetime and MSK
lifetime
     are identical.

[c]  System defaults.  Where the EAP method does not support
the
     negotiation of the exported key lifetime, and a key
lifetime
     negotiation mechanism is not provided by the lower
lower, there may
     be no way for the peer to learn the exported key
lifetime.  In this
     case it is RECOMMENDED that the peer assume a default
value of the
     exported key lifetime; 8 hours is recommended. 
Similarly, the
     lifetime of calculated keys can also be managed as a
system
     parameter on the authenticator.

[d]  Method specific negotiation within EAP.  While EAP
itself does not
     support lifetime negotiation, it would be possible to
specify
     methods that do.  However, systems that rely on such
negotiation
     for exported keys would only function with these
methods.  As a
     result, it is NOT RECOMMENDED to use this approach as
the sole way
     to determine key lifetimes."


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

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

Here is an update to Section 3.3, which better captures the
distinction 
between maximum lifetime and actual lifetime:

3.3.  Parent-Child Relationships

   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,
   compromise of the MSK/EMSK does imply compromise of the
child keys.

   Child keys that are used frequently (such as TSKs which
are used for
   traffic protection) can expire sooner than the exported
EAP keying
   material they are dependent on, so that it is
advantageous to support
   re-key of child keys prior to EAP re-authentication. 
Note that
   deletion of the MSK/EMSK does not necessarily imply
deletion of TSKs
   or child keys.

   Failure to mutually prove possession of exported EAP
keying material
   during the Secure Association Protocol exchange need not
be grounds
   for deletion of the keying material by both parties;
rate-limiting
   Secure Association Protocol exchanges could be used to
prevent a
   brute force attack.


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

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