Subject: [eap] Issue 369: Key-Lifetime Parameter removal

From: "Bernard Aboba" <[email-masked]>
Date: Thu, 08 Jun 2006 10:06:41 -0700

Issue 369: Key-Lifetime Parameter removal
Submitter name: Bernard Aboba
Submitter email address: [email-masked]
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

---

From: Jari Arkko <[email-masked]>
Date: Sat, 24 Jun 2006 21:18:48 +0300

Works for me. --Jari