|
List Info
Thread: Resolution to Issue 372: Key Lifetime
|
|
| Resolution to Issue 372: Key Lifetime |
|
2006-08-16 05:53:53 |
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: alper.yegin yegin.org
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
|
|
| Resolution to Issue 372: Key Lifetime |
|
2006-08-16 16:42:26 |
|
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. |
| Resolution to Issue 372: Key Lifetime |
|
2006-08-16 21:29:03 |
How about this?
Change:
"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."
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.
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."
>From: "M. Vanderveen" <mvandervnyahoo.com>
>To: Bernard Aboba <bernard_abobahotmail.com>, eapfrascone.com
>Subject: Re: [eap] Resolution to Issue 372: Key Lifetime
>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.
____________________________________________________________
_____
To unsubscribe or modify your subscription options, please
visit:
http:/
/lists.frascone.com/mailman/listinfo/eap
Arhives: http://lists.
frascone.com/pipermail/eap
|
|
| Revised resolution to Issue 372: Key
Lifetime |
|
2006-08-16 22:08:22 |
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:
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. 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.
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.
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
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.
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."
____________________________________________________________
_____
To unsubscribe or modify your subscription options, please
visit:
http:/
/lists.frascone.com/mailman/listinfo/eap
Arhives: http://lists.
frascone.com/pipermail/eap
|
|
[1-4]
|
|