Subject: [eap] Issue 384: Security Association Management

From: "Bernard Aboba" <[email-masked]>
Date: Thu, 11 Jan 2007 21:40:17 -0800

Issue 384: Security Association Management
Submitter name: Bernard Aboba
Submitter email address: aboba [at] internaut.com
Date Submitted: January 11, 1007
Reference:
Document: KEYING-16
Comment type: Technical
Priority: 1
Section: 3, 3.1
Rationale/Explanation of issue:

The title of Section 3 seems to suggest that the function of the Secure 
Association Protocol is purely key management.  That is certainly a large 
part of it, but the SAP also handles setup of security associations, and 
negotiation of traffic selectors.   Neither Section 3 nor 3.1 currently 
mentions traffic selection, yet some EAP lower layers (e.g. IKEv2 and IEEE 
802.16e) support negotiation of traffic selectors in the SAP.  This feature 
turns out to be quite important for the correct operation of these EAP lower 
layers, so it is important to mention it.

The proposed resolution is as follows:

Change Section 3 to the following:

"3.  Security Association Management

   EAP as defined in [RFC3748] supports key derivation, but does not
   provide for the management of lower layer security associations.
   Missing functionality includes:

[a]  Security Association negotiation.  EAP does not negotiate lower
     layer unicast or multicast security associations, including
     cryptographic algorithms or traffic profiles.  EAP methods only
     negotiate cryptographic algorithms for their own use, not for the
     underlying lower layers.  EAP also does not negotiate the traffic
     profiles to be protected with the negotiated ciphersuites;  in some
     cases the traffic to be protected may have lower layer source and
     destination addresses different from the lower layer peer or
     authenticator addresses.

[b]  Re-key.  EAP does not support re-key of exported keys without EAP
     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]  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."

In Section 3.1, add the following item:

"[i]  Traffic profile negotiation.  The traffic to be protected by a
     lower layer security association may not necessarily have the same
     lower layer source or destination address as the EAP peer and
     authenticator.  Where this is the case, the profile of protected
     traffic SHOULD be explicitly negotiated.  For example, in IKEv2 it
     is possible for an Initiator and Responder to utilize EAP for
     authentication, then negotiate a Tunnel Mode Security Association
     (SA) which permits passing of traffic originating from hosts other
     than the Initiator and Responder.  Similarly, in IEEE 802.16e a
     Subscriber Station (SS)  may forward traffic to the Mobile Station
     (MS) which originates from the Local Area Network (LAN) to which it
     is attached.  To enable this, Security Associations within IEEE
     802.16e are identified by the Connection Identifier (CID), not by
     the EAP peer (SS) and authentication (MS) MAC addresses."

_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/eap

Arhives: http://lists.frascone.com/pipermail/eap

---

From: "Bernard Aboba" <[email-masked]>
Date: Sun, 14 Jan 2007 10:10:33 -0800

>  the EAP peer (SS) and authentication (MS) MAC addresses."

I think that Base Station (BS) is intended here instead of MS.   Also there 
are no examples of multiple SAs between the peer and authenticator.  A 
corrected version is enclosed below:

"[i]  Traffic profile negotiation.  The traffic to be protected by a
     lower layer security association may not necessarily have the same
     lower layer source or destination address as the EAP peer and
     authenticator, and it is possible for the peer and authenticator to
     negotiate multiple security associations, each with a different
     traffic profile.  Where this is the case, the profile of protected
     traffic SHOULD be explicitly negotiated.  For example, in IKEv2 it
     is possible for an Initiator and Responder to utilize EAP for
     authentication, then negotiate a Tunnel Mode Security Association
     (SA) which permits passing of traffic originating from hosts other
     than the Initiator and Responder.  Similarly, in IEEE 802.16e a
     Subscriber Station (SS)  may forward traffic to the Base Station
     (BS) which originates from the Local Area Network (LAN) to which it
     is attached.  To enable this, Security Associations within IEEE
     802.16e are identified by the Connection Identifier (CID), not by
     the EAP peer and authenticator MAC addresses.  In both IKEv2 and
     IEEE 802.16e, multiple security associations may exist between the
     EAP peer and authenticator, each with their own traffic profile and
     quality of service parameters."