Issue 369: Key-Lifetime Parameter removal
From: Bernard Aboba (bernard_abobahotmail.com)
Date: Thu, 8 Jun 2006 10:06:46 -0700 (PDT)
Issue 369: Key-Lifetime Parameter removal
Submitter name: Bernard Aboba
Submitter email address: aboba [at] internaut.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.


Results generated by Tiger Technologies using MHonArc.