eap Mailing List: Re: Proposed Resolution to Issue 254: Key Lifetime Issues

[Jari Arkko (jari.arkko]

Hi Bernard,

Looks good! A couple of nits inline:

> "2.3.  Key Lifetimes
>
>    Key lifetime issues are discussed in the sections that follow.
>    Issues include:
>
> [a]  Key lifetime negotiation.  Where key lifetimes cannot be assumed,
>      it may be necessary to negotiate them.  Where negotiation is
>      supported, it is RECOMMENDED that the negotiation be secured.  Note
>      that key lifetime negotiation may not always be required.  A
>      difference between IKEv1 and IKEv2 is that in IKEv1 SA lifetimes
>      were negotiated. In IKEv2, each end of the SA is responsible for
>      enforcing its own lifetime policy on the SA and rekeying the SA
>      when necessary.

The reader may wonder why we suddenly talk about
IKE. Suggest s/A difference/To take an example from IKE,
the difference/

> [b]  Key resynchronization.  It is possible for the peer or
>      authenticator to reboot or reclaim resources, clearing portions or
>      all of the key cache.  Therefore, key lifetime negotiation cannot
>      guarantee that the key cache will remain synchronized, and the peer
>      may not be able to determine before attempting to use it whether a
>      particular key exists within the authenticator cache.  It is
>      therefore RECOMMENDED for the lower layer to provide a mechanism
>      for key state resynchronization.  Since in this situation one or
>      more of the parties initially do not possess a key with which to
>      protect the resynchronization exchange, securing this mechanism may
>      be difficult.
>
> 2.3.1.  Parent-child relationships
>
>    When keying material exported by EAP methods expires,  all keying
>    material derived from the exported keying material, (including the
>    AAA-Key, AMSKs and TSKs) also expires.
>
>    Similarly, when an EAP reauthentication takes place, new keying
>    material is derived and exported by the EAP method, which eventually
>    results in replacement of calculated keys, including the AAA-Key,
>    AMSKs, and TSKs.
>
>    As a result, the lifetime of keys calculated from the exported keying
>    material can be no longer than the lifetime of the exported keying
>    material itself.  However, the lifetime of calculated keys can be
>    less than that of the exported keys.  For example, TSK rekey may
>    occur prior to EAP reauthentication.
>
>    Note that deletion of the AAA-Key does not necessarily imply deletion
>    of the corresponding TSKs.  Replacement or deletion of TSKs only
>    implies replacement of the AAA-Key when the TSKs are taken from a
>    portion of the AAA-Key.

I do not understand this paragraph. The first part appears to claim
that TSKs can break the death-of-the-parent rule. The second part
appears to claim that AAA-Key gets changed because it is used twice.
Or maybe the latter is something that we do want to mandate, but
the text still reads funny, it sounds like the requirement only
exists if we take a part of AAA-Key, not all of it. Or did you
want to say that when TSKs are bit-by-bit copies of the AAA-Keys
parts, then we throw that part away?

>    Failure to mutually prove possession of the AAA-Key during the Secure
>    Association Protocol exchange need not be grounds for deletion of the
>    AAA-Key by both parties; rate-limiting Secure Association Protocol
>    exchanges could be used to prevent a brute force attack.
>
> 2.3.2.  Local Key Lifetimes
>
>    The Transient EAP Keys (TEKs) are session keys used to protect the
>    EAP conversation.  The TEKs are internal to the EAP method and are
>    not exported.  TEKs are typically created during an EAP conversation,
>    used until the end of the conversation and then discarded.  However,
>    methods may rekey TEKs during a conversation.
>
>    When using TEKs within an EAP conversation or across conversations,
>    it is necessary to ensure that replay protection and key separation
>    requirements are fulfilled.  For instance, if a replay counter is
>    used, TEK rekey MUST occur prior to wrapping of the counter.
>    Similarly, TSKs MUST remain cryptographically separate from TEKs
>    despite TEK rekeying or caching. This prevents TEK compromise from
>    leading directly to compromise of the TSKs and vice versa.
>
>    EAP methods may cache local keying material which may persist for
>    multiple EAP conversations when fast reconnect is used [RFC 3748].
>    For example, EAP methods based on TLS (such as EAP-TLS [RFC2716])
>    derive and cache the TLS Master Secret, typically for substantial
>    time periods.  The lifetime of other local keying material calculated
>    within the EAP method is defined by the method.  Note that in
>    general, when using fast reconnect, there is no guarantee to that the
>    original long-term credentials are still in the possession of the
>    peer.  For instance, a card hold holding the private key for EAP-TLS
>    may have been removed. EAP servers should verify that the long-term
>    credentials are still valid, such as by checking that certificate
>    used in the original authentication has not yet expired.
>
> 2.3.3.  Exported and Calculated Key Lifetimes
>
>    All EAP methods generating keys are required to generate the MSK and
>    EMSK, and may optionally generate the IV.  Existing EAP methods do
>    not negotiate the lifetime of the exported keys.  EAP, defined in
>    [RFC3748], also does not 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 [DiamEAP] support the Session-Timeout attribute.  The
>      Session-Timeout value represents the maximum lifetime of the
>      exported keys, and all keys calculated from it, in all
>      circumstances.  The AAA server MUST expire the exported keys, and
>      all keys calculated from them, prior to the future time indicated

Is it really "prior to"? Not "latest at"?

>      by Session-Timeout.  On the authenticator,  where EAP is used for
>      authentication, the Session-Timeout value represents the maximum
>      session time prior to re-authentication, as described in [RFC3580].
>      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 time after which the AAA-Key,
>      and all keys calculated from 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, the AAA-Key and
>      all keys calculated from it will be expired by the authenticator
>      prior to the future time indicated by Session-Timeout.
>
>      Since the TSK lifetime is often determined by authenticator
>      resources, the AAA server has no insight into the TSK derivation
>      process, and by the principle of ciphersuite independence, it is
>      not appropriate for the AAA 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 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 secure negotiation of the TSK lifetime between the
>      peer and authenticator.  Where the TSK is taken from the AAA-Key,

Why do we recommend this? What if the lower layer uses the IKEv2
principle?

>      there is no need to manage the TSK lifetime as a separate
>      parameter, since the TSK lifetime and AAA-Key lifetime are
>      identical.
>
> [c]  System defaults.  Where the EAP method does not support the
>      negotiation of the exported key lifetime, and a negotiation
>      mechanism is not provided by the lower lower, there may be no way
>      for the peer to learn knowledge of the exported key liftime.  In
>      this case it is RECOMMENDED that the peer assume a default value of
>      the exported key lifetime; 8 hours is suggested.  Similarly, the
>      lifetime of calculated keys can also be managed as a system
>      parameter on the authenticator.
>
> 2.3.4.  Key cache synchronization
>
>    Issues arise when attempting to synchronize the key cache on the peer
>    and authenticator.  Lifetime negotiation alone cannot guarantee key
>    cache synchronization.
>
>    One problem is that the AAA protocol cannot guarantee synchronization
>    of key lifetimes between the peer and authenticator.  Where the
>    Secure Association Protocol is not run immediately after EAP
>    authentication, the exported and calculated key lifetimes will not be
>    known by the peer during the hiatus.  Where EAP pre-authentication
>    occurs, this can leave the peer uncertain whether a subsequent
>    attempt to use the exported keys will prove successful.
>
>    However, even where the Secure Association Protocol is run
>    immediately after EAP, it is still possible for the authenticator to
>    reclaim resources if the created key state is not immediately
>    utilized.
>
>    The lower layer may utilize Discovery mechanisms to assist in this.
>    For example, the authenticator manages the AAA-Key cache by deleting
>    the oldest AAA-Key first (LIFO), the relative creation time of the
>    last AAA-Key to be deleted could be advertised with the Discovery
>    phase, enabling the peer to determine whether a given AAA-Key had
>    been expired from the authenticator key cache prematurely."

--Jari