eap Mailing List: Re: Issue 370: Key Management

[Jari Arkko (jari.arkko]

Looks good to me. --Jari

>The proposed resolution is to change Section 3 from:
>
>"3. Key Management
>
>   EAP as defined in [RFC3748] supports key derivation, but does not
>   provide for the management of exported or derived keys.  Although EAP
>   methods may support "fast reconnect" as defined in [RFC3748] Section
>   7.2.1, EAP does not support re-key of exported keys without re-
>   authentication."
>
>to:
>
>"3.  Key Management
>
>   EAP as defined in [RFC3748] supports key derivation, but does not
>   provide for the management of exported or derived keys.  Missing
>   functionality includes:
>
>[a]  Re-key. EAP does not support re-key of exported keys without re-
>     authentication, although EAP methods may support "fast reconnect"
>     as defined in [RFC3748] Section 7.2.1.
>
>[b]  Key delete/install semantics.  EAP does not synchronize
>     installation or deletion of keying material on the EAP peer and
>     authenticator.
>
>[c]  Lifetime negotiation. EAP does not support lifetime negotiation for
>     exported keys, and existing EAP methods also do not support key
>     lifetime negotiation.
>
>[d]  Cryptographic algorithm negotiation. EAP methods only negotiate
>     cryptographic algorithms for their own use, not for the underlying
>     lower layers.
>
>[e]  Guaranteed TSK freshness.  Without a post-EAP handshake, TSKs can
>     be reused if EAP keying material is cached.
>
>   These deficiencies are typically addressed via a post-EAP handshake
>   known as the Secure Association Protocol."
>
>
>_________________________________________________________________
>To unsubscribe or modify your subscription options, please visit:
>http://lists.frascone.com/mailman/listinfo/eap
>
>Arhives: http://lists.frascone.com/pipermail/eap
>
>
>  
>