eap Mailing List: Keying lifetimes (WG LC "Keying Fwk")

[Alper Yegin (alper.yegin]

Key lifetime management needs revision
Submitter name: Alper Yegin 
Submitter email address: alper.yegin [at] yegin.org
Date first submitted: 7/19/2006
Reference: 
Document: Keying Framework
Comment type: T
Priority: S
Section: 3.5.  Exported and Calculated Key Lifetimes
Rationale/Explanation of issue:

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.


Alper: We shall not present this (a) as if it is a complete mechanism that
can manage key lifetimes on all relevant parties (peer, authenticator,
authentication server). This only provides the MSK lifetime to the
authenticator. Only when coupled with how peer learns the key lifetime for
MSK and EMSK we'd have a complete solution. 

Alper: I think what I'm suggesting is to enumerate these alternatives, such
that (a) appears under "how authenticator dynamically learns the MSK
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.


Alper: Secure Association Protocol is a "consumer" of MSK. For that, I don't
expect it to set the any attributes of the MSK it is "using." Doing
otherwise is a hack, IMHO. I recommend we remove the current text from this
option.

Alper: But, we shall retain the option. IMO, the technically correct way of
doing this is not via the "secure association" protocol, but via the "eap
transport". The lifetime learned from the authentication server via AAA
protocols can be conveyed to the EAP peer via such protocols. If people
agree, I can propose text.


[c]  System defaults.  Where the EAP method does not support the
     negotiation of the lifetime of exported keys, and a key lifetime
     negotiation mechanism is not provided by the lower lower, there may
     be no way for the peer to learn the lifetime of exported keys.  In
     this case it is RECOMMENDED that the peer assume a default value; 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.  In the
     interest of method independence, key management of exported or
     derived keys SHOULD NOT be provided within EAP methods.


Alper: again, this is all about how peer and authentication server agrees on
the MSK and EMSK lifetimes. It does not help the authenticator. We shall
categorize this mechanism as such.

Alper: Besides, what is the interaction between the lifetimes known and
delivered by the EAP methods and the AAA protocols? My understanding is, EAP
methods may export lifetimes, and the AAA protocol has the last say whether
the lifetime should be same as reported by the EAP method, or something
less. This is all about the "authorization" aspect. 




Requested change:

See above.