eap Mailing List: Issue 370: Key Management

[Bernard Aboba (bernard_aboba]

Issue 370:  Key Management
Submitter name: Bernard Aboba
Submitter email address: aboba [at] internaut.com
Date Submitted: June 23, 2006
Reference:
Document: KEYING-13
Comment type: 'T'echnical
Priority: '1' Should fix
Section: 3
Rationale/Explanation of issue:

Section 3 does not clearly describe why EAP is not a key management 
protocol.

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