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