Keying lifetimes (WG LC "Keying Fwk")
Alper Yegin <alper.yegin <at> yegin.org>
2006-07-19 21:26:03 GMT
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.
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/eap
Arhives: http://lists.frascone.com/pipermail/eap
RSS Feed