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

[Jari Arkko (jari.arkko]

Bernard Aboba wrote:

> > Should we talk about the potential use of the EAP channel (with
> > things like draft-arkko-eap-service-identity-auth) to deliver
> > lifetime information? I'm not proposing that we need to do that --
> > in fact I'm quite happy with the "system default" approach -- but
> > sounds like it is something might be mentioned.
>
> Yes, I think we should discuss this.  Can you file an issue on that
> subject?

Yes. Here goes:

Description of issue
Submitter name: Jari Arkko
Submitter email address: jari.arkko [at] piuha.net
Date first submitted: Feb 20, 2004
Reference: -
Document: Keying Framework
Comment type: T
Priority: 1 - Should fix
Section: 4.4 and 4.5
Rationale/Explanation of issue:

> 4.5.  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.

Should we talk about the potential use of the EAP channel (with
things like draft-arkko-eap-service-identity-auth) to deliver
lifetime information? I'm not proposing that we need to do that --
in fact I'm quite happy with the "system default" approach -- but
sounds like it is something might be mentioned.

Requested change:

Add text to the end of Section 4.4:

  [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.