In looking at the discussion of this issue, and reviewing
the text, it is
not clear
how useful it is to have EAP methods export the Key-Lifetime
parameter.
Today no EAP
methods export this parameter, and the text in Section 1.4
suggests that
this
is not very useful anyway:
Key-Lifetime
While EAP itself does not support key lifetime
negotiation, it is
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.
Similarly, Section 3 states:
Existing EAP methods do not export the Key-Lifetime
parameter; in the interest of method independence, key
management of
exported or derived keys SHOULD NOT be provided within
EAP methods.
As a result, it may make sense to remove discussion of the
Key-Lifetime
parameter
from the document.
The text of Issue 361 is enclosed below. The proposed
resolution is as
follows:
In Section 1.4, delete:
" Key-Lifetime
While EAP itself does not support key lifetime
negotiation, it is
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."
Also, delete the Key-Lifetime parameter from Figure 2.
In Section 3, change:
"Existing EAP methods do not export the Key-Lifetime
parameter; in the interest of method independence, key
management of
exported or derived keys SHOULD NOT be provided within EAP
methods."
To:
"Existing EAP methods do not manage the lifetime of
exported EAP
keying material; in the interest of method independence,
key management of
exported or derived keys SHOULD NOT be provided within EAP
methods."
Change Section 3.3 to the following:
"3.3. Parent-Child Relationships
When an EAP re-authentication takes place, new keying
material is
derived and exported by the EAP method, which eventually
results in replacement of TSKs, regardless of the way
they
are derived (see Section 2.1). Thus in practice
replacement of
TSKs is implied by EAP re-authentication.
As a result, it is not possible for TSKs or other keying
material
derived from the MSK/EMSK to have a longer lifetime than
the
exported EAP keying material. This is true even where
exported
EAP keying material is only used for entity
authentication and is
not used for key derivation (such as in IKEv2), so that
compromise
of exported EAP keying material does not imply compromise
of the TSKs
or child keys. However, where child keys are derived
from or are
wrapped by EAP keying material, compromise of the
MSK/EMSK does
imply compromise of the child keys.
While the lifetime of TSKs or child keys can be less than
or
equal that of the exported keying material they are
derived from, it
cannot be greater. Child keys that are used frequently
(such as TSKs
which are used for traffic protection) can expire sooner
than the
exported EAP keying material from which they are derived,
so that it
is advantageous to support re-key of child keying
material prior to
EAP re-authentication.
Failure to mutually prove possession of exported EAP
keying material
during the Secure Association Protocol exchange need not
be grounds
for deletion of the keying material by both parties;
rate-limiting Secure
Association Protocol exchanges could be used to prevent a
brute force
attack."
Change Section 3.5 to the following:
"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 calculated from
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
calculated from 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
calculated from them will 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.
[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. It is RECOMMENDED that lower layer
mechanisms
such as the Secure Association Protocol 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.
[c] System defaults. Where the EAP method does not support
the
negotiation of the exported key lifetime, and a key
lifetime
negotiation mechanism is not provided by the lower
lower, there may
be no way for the peer to learn the exported key
lifetime. In this
case it is RECOMMENDED that the peer assume a default
value of the
exported key lifetime; 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. As a
result, it is NOT RECOMMENDED to use this approach as
the sole way
to determine key lifetimes."
------------------------------------------------------------
------------------------------------------------------------
----------
Issue 361: Child key expiry
Submitter name: Vidya Narayanan
Submitter email address: vidyan qualcomm.com
Date Submitted: May 1, 2006
Reference: http://lists.frascone.com/pipermail/eap/msg04231.html
Document: KEYING-12
Comment type: 'T'echnical
Priority: '2' May fix
Section: 3.3
Rationale/Explanation of issue:
This section states "When keying material exported by
EAP methods
expires, all keying material derived from the exported
keying material
expires, including
the TSKs." This seems to indicate that the keys
derived from the EMSK
will also be expired when the EMSK expires. It is not yet
clear if this
would apply to all kinds of keys derived from the EMSK.
There may be
classes of keys derived from the EMSK for which different
lifetime
guidelines apply. So, it may be good to clarify that the
EMSK usage
documents will specify the guidelines for EMSK-based child
keys.
Requested change:
Change
"When keying material exported by EAP methods expires,
all keying
material derived from the exported keying material expires,
including
the TSKs."
to
"When keying material exported by EAP methods expires,
all keying
material derived from the exported keying material expires,
including
the TSKs. Note that different lifetime guidelines may be
specified in
future specifications for EMSK-based child keys."
____________________________________________________________
_____
To unsubscribe or modify your subscription options, please
visit:
http:/
/lists.frascone.com/mailman/listinfo/eap
Arhives: http://lists.
frascone.com/pipermail/eap
|