Keying lifetimes (WG LC "Keying Fwk")

Key lifetime management needs revision
Submitter name: Alper Yegin 
Submitter email address: alper.yeginyegin.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.

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

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

Keying lifetimes (WG LC "Keying Fwk")

Thread: Keying lifetimes (WG LC "Keying Fwk")