eap Mailing List: Re: Issue 369: Key-Lifetime Parameter removal

[Jari Arkko (jari.arkko]

Works for me. --Jari

Bernard Aboba wrote:

>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.
>
>
>_________________________________________________________________
>To unsubscribe or modify your subscription options, please visit:
>http://lists.frascone.com/mailman/listinfo/eap
>
>Arhives: http://lists.frascone.com/pipermail/eap
>
>
>  
>