Subject: [eap] Resolution to Issue 372: Key Lifetime

From: "Bernard Aboba" <[email-masked]>
Date: Tue, 15 Aug 2006 22:53:53 -0700

The text of Issue 372 is enclosed below.   The proposed resolution is as 
follows:

Change Section 3.5 to the following:

"3.5.  Exported and Calculated Key Lifetimes'

   The following mechanisms are available for communicating the lifetime
   of exported and calculated keying material between the EAP peer, server
   and authenticator:

       AAA protocols  (backend server and authenticator)
       Lower layer mechanisms (authenticator and peer)
       EAP method-specific negotiation (peer and server)

    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 and calculated keys.  In this
    case the lifetime of exported keys can be managed as a system
    parameter on the peer and authenticator;  a default lifetime of 8
    hours is RECOMMENDED.

3.51 AAA Protocols

     AAA protocols such as RADIUS [RFC2865] and Diameter [RFC4072]
     can be used to communicate the maximum exported
     key lifetime from the backend authentication server to the
     authenticator.

    The Session-Timeout attribute, defined for RADIUS in [RFC2865]
     and Diameter in [RFC4005], 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.

3.52 Lower Layer Mechanisms

    Lower layer mechanisms can be used to enable the lifetime of
    exported and calculated keys to be negotiated between the
    peer and authenticator.  This can be accomplished either using
    the Secure Association Protocol or within the lower layer transport.

     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.

3.53  EAP Method-Specific Negotiation

   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.

   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.  Also, there is no guarantee that the
   lifetime negotiated within the EAP method would be compatible
   with backend authentication server policy.  In the interest of
   method independence and compatibility with backend server
   implemenations,  key management of exported or  derived keys
   SHOULD NOT be provided within EAP methods."

---------------------------------
Issue 372: Key-Lifetime
Submitter name: Alper Yegin
Submitter email address: [email-masked]
Date Submitted: July 19, 2006
Reference: http://lists.frascone.com/pipermail/eap/msg04464.html
Document: KEYING-14
Comment type: 'T'echnical
Priority: S
Section: 3.5
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.
[Bernard Aboba]
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.

Right.

Alper: I think what I'm suggesting is to enumerate these alternatives, such
that (a) appears under "how authenticator dynamically learns the MSK
lifetime."

This makes sense.

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.

In practice the SAP handles this in a number of cases, including IKEv2, 
802.16e, and 11r. So I don't think we can leave it out.

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.

We should probably describe this as another option.

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

Yes. In fact, it might create problems if *both* the method and 
SAP/transport are trying to negotiate the lifetime. Do you have text to 
suggest?

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.

Right. Another potential conflict.
[Alper Yegin]

>In practice the SAP handles this in a number of cases, including IKEv2,
>802.16e, and 11r.   So I don't think we can leave it out.

I don't think we want to recommend that method. For that, not even
mentioning is the best thing, IMHO. If we really want to capture those
examples, I'd say they should go with a "NOT RECOMMENDED" qualifier in the
document.

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

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

---

From: "M. Vanderveen" <[email-masked]>
Date: Wed, 16 Aug 2006 09:42:26 -0700 (PDT)

Regarding the sentence in section 3.51:

 "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."
   
  This seems superfluous .. .it mentions key lifetimes in the backends server, while the server does not cache keys in the first place.  IMO it is enough to say that the backend servers are not *expected* to cache exported keys, and thus it's clear that the lifetimes of exported keys from the server's perspective is always 0. Therefore, any other lifetimes/timeouts have no bearing on it (including the Session Timeout).
   
  Another point, that is probably addressed elswhere (and so my apologies), what does the "do not cache keys" really mean, "SHOULD NOT", or "MAY NOT", or "MUST NOT"?
   
  Thanks
  Michaela

---------------------------------
Do you Yahoo!?
 Next-gen email? Have it all with the  all-new Yahoo! Mail Beta.

---

From: "Bernard Aboba" <[email-masked]>
Date: Wed, 16 Aug 2006 14:29:03 -0700

How about this?

Change:

"3.51 AAA Protocols

    including the TSK lifetime."

To:

"3.51 AAA Protocols

    AAA protocols such as RADIUS [RFC2865] and Diameter [RFC4072]
    can be used to communicate the maximum exported key lifetime
    from the backend authentication server to the authenticator.

   The Session-Timeout attribue is defined for RADIUS in [RFC2865] and
   for Diameter in [RFC4005].  Where EAP is used for authentication,
   [RFC3580] Section 3.17 indicates that a Session-Timeout attribute sent
   in an Access-Accept along with a Termination-Action value of
   RADIUS-Request specifies the maximum number of seconds of service
   provided prior to re-authentication.

   However, there is also a need to be able to specify the maximum
   lifetime of cached keying material.  Where EAP pre-authentication
   is supported,  cached keys can be pre-established on the
   authenticator prior to session start, and will remain there
   until they expire.  EAP lower layers supporting caching of
   exported keying material may also persist that material after
   the end of a session, enabling the peer to subsequently resume
   communication utilizing the cached keying material.  In these
   situations it may be desirable for the backend authentication
   server to specify the maximum lifetime of cached keying material.

   To accomplish this, [IEEE-802.11i] overloaded the Session-Timeout
   attribute, assuming that it represents the maximum time after which
   transported EAP keying material will expire on the authenticator,
   regardless of whether transported keying material is cached.

   An IEEE 802.11 authenticator receiving keying material is expected
   to initialize a timer to the Session-Timeout value, and once the timer 
expires,
   the exported keying material expires.  Whether this results in session
   termination or re-authentication is controlled by the value of the
   Termination-Action attribute.  Where re-authentication occurs the
   exported keying material is replaced, and with it, new calculated
   keys are put in place.  Where session termination occurs, exported
   and calculated keying material is deleted.

   Overloading the Session-Timeout attribute is problematic in
   situations where it is necessary to control the maximum session
   time and key lifetime independently.  For example, it might be
   desirable to limit the lifetime of cached keys to 5 minutes
   while permitting a user once authenticated to remain connected for
   up to an hour without re-authenticating.  As a result, in the
   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.

   including the TSK lifetime."

>From: "M. Vanderveen" <[email-masked]>
>To: Bernard Aboba <[email-masked]>, [email-masked]
>Subject: Re: [eap] Resolution to Issue 372: Key Lifetime
>Date: Wed, 16 Aug 2006 09:42:26 -0700 (PDT)
>
>   This seems superfluous .. .it mentions key lifetimes in the backends 
>server, while the server does not cache keys in the first place.  IMO it is 
>enough to say that the backend servers are not *expected* to cache exported 
>keys, and thus it's clear that the lifetimes of exported keys from the 
>server's perspective is always 0. Therefore, any other lifetimes/timeouts 
>have no bearing on it (including the Session Timeout).
>
>   Another point, that is probably addressed elswhere (and so my 
>apologies), what does the "do not cache keys" really mean, "SHOULD NOT", or 
>"MAY NOT", or "MUST NOT"?
>
>   Thanks
>   Michaela
>
>
>
>
>

---

From: "Bernard Aboba" <[email-masked]>
Date: Wed, 16 Aug 2006 15:08:22 -0700

Some of Section 3.6 also appears to have been made redundant by the proposed 
text.  So here is a revised proposal for both Sections 3.5 and 3.6:

"3.5.  Exported and Calculated Key Lifetimes

   The following mechanisms are available for communicating the lifetime
   of exported and calculated keying material between the EAP peer,
   server and authenticator:

   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 and calculated keys.  This can leave
   the peer uncertain how long the authenticator will maintain EAP
   keying material within the key cache.  In this case the lifetime of
   exported keys can be managed as a system parameter on the peer and
   authenticator;  a default lifetime of 8 hours is RECOMMENDED.

3.5.1.  AAA Protocols

   AAA protocols such as RADIUS [RFC2865] and Diameter [RFC4072] can be
   used to communicate the maximum exported key lifetime from the
   backend authentication server to the authenticator.

   [RFC3580] Section 3.17 indicates that a Session-Timeout attribute

   However, there is also a need to be able to specify the maximum
   lifetime of cached keying material.  Where EAP pre-authentication is
   supported,  cached keys can be pre-established on the authenticator
   prior to session start, and will remain there until they expire.  EAP
   lower layers supporting caching of exported keying material may also
   persist that material after the end of a session, enabling the peer
   to subsequently resume communication utilizing the cached keying
   material.  In these situations it may be desirable for the backend
   authentication server to specify the maximum lifetime of cached
   keying material.

   An IEEE 802.11 authenticator receiving keying material is expected to
   initialize a timer to the Session-Timeout value, and once the timer
   expires, the exported keying material expires.  Whether this results
   in session termination or re-authentication is controlled by the
   value of the Termination-Action attribute.  Where re-authentication
   occurs the exported keying material is replaced, and with it, new
   calculated keys are put in place.  Where session termination occurs,
   exported and calculated keying material is deleted.

   Overloading the Session-Timeout attribute is problematic in
   situations where it is necessary to control the maximum session time
   and key lifetime independently.  For example, it might be desirable
   to limit the lifetime of cached keys to 5 minutes while permitting a
   user once authenticated to remain connected for up to an hour without
   re-authenticating.  As a result, in the 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.

3.5.2.  Lower Layer Mechanisms

   Lower layer mechanisms can be used to enable the lifetime of exported
   and calculated keys to be negotiated between the peer and
   authenticator.  This can be accomplished either using the Secure
   Association Protocol or within the lower layer transport.

   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.

3.5.3.  EAP Method-Specific Negotiation

   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.  Also, there is no guarantee that the lifetime negotiated
   within the EAP method would be compatible with backend authentication
   server policy.  In the interest of method independence and
   compatibility with backend server implemenations,  key management of
   exported or  derived keys SHOULD NOT be provided within EAP methods.

3.6.  Key cache synchronization

   Key lifetime negotiation alone cannot guarantee key cache
   synchronization.  Even where a lower layer exchange is run
   immediately after EAP in order to determine the lifetime of EAP
   keying material, it is still possible for the authenticator to
   reclaim resources.

   The lower layer may utilize the Discovery phase 0 to improve key
   cache synchronization.  For example, if the authenticator manages the
   key cache by deleting the oldest key first (LIFO), the relative
   creation time of the last key to be deleted could be advertised
   within the Discovery phase, enabling the peer to determine whether
   keying material had been prematurely expired from the authenticator
   key cache."