Issue 369: Key-Lifetime Parameter removal

Issue 369: Key-Lifetime Parameter removal
Submitter name: Bernard Aboba
Submitter email address: abobainternaut.com
Date Submitted: June 8, 2006
Reference:
Document: KEYING-13
Comment type: 'T'echnical
Priority: S
Section: Various
Rationale/Explanation of issue:

In 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 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."

Change:

"EAP methods also MAY export method-specific peer and
server
identifiers (Peer-Id and Server-Id), a method-specific EAP
conversation identifier known as the Session-Id, and the
lifetime of
the exported keys, known as the Key-Lifetime.  "

To:

"EAP methods also MAY export method-specific peer and
server
identifiers (Peer-Id and Server-Id) and a method-specific
EAP
conversation identifier known as the Session-Id.  "

In Section 2, change:

"   On completion of EAP authentication, keying
material and material and
   parameters exported by the EAP method are provided to the
lower layer
   and AAA layer (if present).  These include the Master
Session Key
   (MSK), Extended Master Session Key (EMSK), Peer-Id,
Server-Id,
   Session-Id and Key-Lifetime.  The Initialization Vector
(IV) is
   deprecated."

To:

"   On completion of EAP authentication, keying
material and material and
   parameters exported by the EAP method are provided to the
lower layer
   and AAA layer (if present).  These include the Master
Session Key
   (MSK), Extended Master Session Key (EMSK), Peer-Id,
Server-Id,
   and Session-Id.  The Initialization Vector (IV) is
   deprecated."

Delete the Key-Lifetime parameter from Figure 2.

In Section 3, delete:

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

In Section 3.5, change:

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

To:

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

Change:

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

To:

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

In Section 3.6, change:

"   Where the EAP method does not export the
Key-Lifetime parameter, the
   lifetime of the EAP keying material may not be defined
until
   completion of the Secure Association Protocol, if ever.
"

To:

"Where the EAP method does not negotiate the
lifetime of exported keys, the lifetime of the EAP keying
material may not be defined until completion of the
Secure Association Protocol, if ever."

Change Appendix A to the following:

"Appendix A - Exported Parameters in Existing Methods

   This Appendix specifies Session-Id, Peer-Id and Server-Id
   for EAP methods that have been published prior to this
   specification.  Future EAP method specifications MUST
include a
   definition of the Session-Id,  Peer-Id, and Server-Id
(could be the
   empty string).

   EAP-Identity

      The EAP-Identity method is defined in [RC3748].  It
does not
      derive keys, and therefore does not define the
      Session-Id.  The Peer-Id exported by the Identity
method is
      determined by the octets included within the EAP-
      Response/Identity.  The Server-Id is the empty string
(zero
      length).

   EAP-Notification

      The EAP-Notification method is defined in [RFC3748]. 
It does not
      derive keys and therefore does not define the
      Session-Id.  The Peer-Id and Server-Id are the empty
string (zero
      length).

   EAP-GTC

      The EAP-GTC method is defined in [RFC3748].  It does
not derive
      keys and therefore does not define the Session-
      Id.  The Peer-Id and Server-Id are the empty string.

   EAP-OTP

      The EAP-OTP method is defined in [RFC3748].  It does
not derive
      keys and therefore does not define the Session-
      Id.  The Peer-Id and Server-Id are the empty string.

   EAP-TLS

      EAP-TLS is defined in [RFC2716].  The EAP-TLS
Session-Id is the
      concatenation of the Expanded EAP Type Code (including
the Type,
      Vendor-Id and Vendor-Type fields defined in [RFC3748]
Section 5.7)
      with the peer and server nonces.  The Peer-Id and
Server-Id are
      the contents of the altSubjectName in the peer and
server
      certificates.

   EAP-AKA

      EAP-AKA is defined in [RFC4187].  The EAP-AKA
Session-Id is the
      concatenation of the Expanded EAP Type Code (including
the Type,
      Vendor-Id and Vendor-Type fields defined in [RFC3748]
Section 5.7)
      with the contents of the RAND field from the AT_RAND
attribute,
      followed by the contents of the AUTN field in the
AT_AUTN
      attribute.

      The Peer-Id is the contents of the Identity field from
the
      AT_IDENTITY attribute, using only the Actual Identity
Length
      octets from the beginning, however.  Note that the
contents are
      used as they are transmitted, regardless of whether
the
      transmitted identity was a permanent, pseudonym, or
fast re-
      authentication identity.  The Server-Id is an empty
string.

   EAP-SIM

      EAP-SIM is defined in [RFC4186].  The EAP-SIM
Session-Id is the
      concatenation of the Expanded EAP Type Code (including
the Type,
      Vendor-Id and Vendor-Type fields defined in [RFC3748]
Section 5.7)
      with the contents of the RAND field from the AT_RAND
attribute,
      followed by the contents of the NONCE_MT field in the
AT_NONCE_MT
      attribute.

      The Peer-Id is the contents of the Identity field from
the
      AT_IDENTITY attribute, using only the Actual Identity
Length
      octets from the beginning, however.  Note that the
contents are
      used as they are transmitted, regardless of whether
the
      transmitted identity was a permanent, pseudonym, or
fast re-
      authentication identity.  The Server-Id is an empty
string."

Delete all other mentions of the Key-Lifetime parameter from
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

Works for me. --Jari

Bernard Aboba wrote:

>Issue 369: Key-Lifetime Parameter removal
>Submitter name: Bernard Aboba
>Submitter email address: abobainternaut.com
>Date Submitted: June 8, 2006
>Reference:
>Document: KEYING-13
>Comment type: 'T'echnical
>Priority: S
>Section: Various
>Rationale/Explanation of issue:
>
>In 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 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."
>
>Change:
>
>"EAP methods also MAY export method-specific peer
and server
>identifiers (Peer-Id and Server-Id), a method-specific
EAP
>conversation identifier known as the Session-Id, and the
lifetime of
>the exported keys, known as the Key-Lifetime.  "
>
>To:
>
>"EAP methods also MAY export method-specific peer
and server
>identifiers (Peer-Id and Server-Id) and a
method-specific EAP
>conversation identifier known as the Session-Id. 
"
>
>In Section 2, change:
>
>"   On completion of EAP authentication, keying
material and material and
>   parameters exported by the EAP method are provided to
the lower layer
>   and AAA layer (if present).  These include the Master
Session Key
>   (MSK), Extended Master Session Key (EMSK), Peer-Id,
Server-Id,
>   Session-Id and Key-Lifetime.  The Initialization
Vector (IV) is
>   deprecated."
>
>To:
>
>"   On completion of EAP authentication, keying
material and material and
>   parameters exported by the EAP method are provided to
the lower layer
>   and AAA layer (if present).  These include the Master
Session Key
>   (MSK), Extended Master Session Key (EMSK), Peer-Id,
Server-Id,
>   and Session-Id.  The Initialization Vector (IV) is
>   deprecated."
>
>Delete the Key-Lifetime parameter from Figure 2.
>
>In Section 3, delete:
>
>"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."
>
>In Section 3.5, change:
>
>"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."
>
>To:
>
>"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."
>
>Change:
>
>"[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."
>
>To:
>
>"[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."
>
>In Section 3.6, change:
>
>"   Where the EAP method does not export the
Key-Lifetime parameter, the
>   lifetime of the EAP keying material may not be
defined until
>   completion of the Secure Association Protocol, if
ever. "
>
>To:
>
>"Where the EAP method does not negotiate the
>lifetime of exported keys, the lifetime of the EAP
keying
>material may not be defined until completion of the
>Secure Association Protocol, if ever."
>
>Change Appendix A to the following:
>
>"Appendix A - Exported Parameters in Existing
Methods
>
>   This Appendix specifies Session-Id, Peer-Id and
Server-Id
>   for EAP methods that have been published prior to
this
>   specification.  Future EAP method specifications MUST
include a
>   definition of the Session-Id,  Peer-Id, and Server-Id
(could be the
>   empty string).
>
>   EAP-Identity
>
>      The EAP-Identity method is defined in [RC3748]. 
It does not
>      derive keys, and therefore does not define the
>      Session-Id.  The Peer-Id exported by the Identity
method is
>      determined by the octets included within the EAP-
>      Response/Identity.  The Server-Id is the empty
string (zero
>      length).
>
>   EAP-Notification
>
>      The EAP-Notification method is defined in
[RFC3748].  It does not
>      derive keys and therefore does not define the
>      Session-Id.  The Peer-Id and Server-Id are the
empty string (zero
>      length).
>
>   EAP-GTC
>
>      The EAP-GTC method is defined in [RFC3748].  It
does not derive
>      keys and therefore does not define the Session-
>      Id.  The Peer-Id and Server-Id are the empty
string.
>
>   EAP-OTP
>
>      The EAP-OTP method is defined in [RFC3748].  It
does not derive
>      keys and therefore does not define the Session-
>      Id.  The Peer-Id and Server-Id are the empty
string.
>
>   EAP-TLS
>
>      EAP-TLS is defined in [RFC2716].  The EAP-TLS
Session-Id is the
>      concatenation of the Expanded EAP Type Code
(including the Type,
>      Vendor-Id and Vendor-Type fields defined in
[RFC3748] Section 5.7)
>      with the peer and server nonces.  The Peer-Id and
Server-Id are
>      the contents of the altSubjectName in the peer and
server
>      certificates.
>
>   EAP-AKA
>
>      EAP-AKA is defined in [RFC4187].  The EAP-AKA
Session-Id is the
>      concatenation of the Expanded EAP Type Code
(including the Type,
>      Vendor-Id and Vendor-Type fields defined in
[RFC3748] Section 5.7)
>      with the contents of the RAND field from the
AT_RAND attribute,
>      followed by the contents of the AUTN field in the
AT_AUTN
>      attribute.
>
>      The Peer-Id is the contents of the Identity field
from the
>      AT_IDENTITY attribute, using only the Actual
Identity Length
>      octets from the beginning, however.  Note that the
contents are
>      used as they are transmitted, regardless of
whether the
>      transmitted identity was a permanent, pseudonym,
or fast re-
>      authentication identity.  The Server-Id is an
empty string.
>
>   EAP-SIM
>
>      EAP-SIM is defined in [RFC4186].  The EAP-SIM
Session-Id is the
>      concatenation of the Expanded EAP Type Code
(including the Type,
>      Vendor-Id and Vendor-Type fields defined in
[RFC3748] Section 5.7)
>      with the contents of the RAND field from the
AT_RAND attribute,
>      followed by the contents of the NONCE_MT field in
the AT_NONCE_MT
>      attribute.
>
>      The Peer-Id is the contents of the Identity field
from the
>      AT_IDENTITY attribute, using only the Actual
Identity Length
>      octets from the beginning, however.  Note that the
contents are
>      used as they are transmitted, regardless of
whether the
>      transmitted identity was a permanent, pseudonym,
or fast re-
>      authentication identity.  The Server-Id is an
empty string."
>
>Delete all other mentions of the Key-Lifetime parameter
from 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
>
>
>  
>


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

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