eap Mailing List

View Index by: Date - Thread - Author
Re: Proposed Resolution to Issue 338: Key Scope
From: Jari Arkko (jari.arkkopiuha.net)
Date: Sun, 5 Mar 2006 23:39:48 -0800 (PST)
Text is fine. --Jari

Bernard Aboba wrote:

The text of Issue 338 is enclosed below. This issue was split off from Issue 322 to allow the revised Authenticator Architecture and Key Scope sections to be discussed separately.

The proposed resolution is to reorganize the key scope material into Section 2.5. How does this look?

"2.5. Key Scope

Where the EAP peer and authenticator cannot unambiguously identify
each other they may not be able to determine the scope of transported
EAP keying material. This is particularly problematic for lower
layers where key caching is supported.

For example, if the EAP peer cannot identify the EAP authenticator,
it will be unable to determine whether transported EAP keying
material has been shared outside of its authorized scope, and
therefore needs to be considered compromised. There is also a
practical problem because the EAP peer will be unable to utilize the
EAP authenticator key cache in an efficient way.

To avoid these problems, it is recomended that lower layers:

[1] Specify the lower layer parameters used to identify the
authenticator and peer;

[2] Communicate the lower layer identities between the peer and
authenticator within phase 0;

[3] Communicate the lower layer authenticator identity between the
authenticator and backend server within the NAS-Identifier
attribute;

[4] Include the lower layer identities within channel bindings (if
supported) in phase 1a, ensuring that they are communicated between
the EAP peer and server;

[5] Securely verify the lower layer identities within phase 2a;

[6] Utilize the advertised lower layer identities to enable the peer
and authenticator to verify that keys are maintained within the
advertised scope;

Absent explicit specification within the lower layer, after the
completion of phase 1b, EAP keying material and parameters are
bound to the EAP peer and authenticator, but are not bound to a
specific peer or authenticator port.

While EAP Keying Material passed down to the lower layer is not
intrinsically bound to particular authenticator and peer ports,
Transient Session Keys MAY be bound to particular authenticator and
peer ports by the Secure Association Protocol. However, a lower
layer MAY also permit TSKs to be used on multiple peer and/or
authenticator ports, providing that TSK freshness is guaranteed
(such as by keeping replay counter state within the authenticator).

In order to further limit the key scope the following measures are
suggested:

[a] The lower layer MAY specify additional restrictions on key usage,
such as limiting the use of EAP keying material and parameters on
the EAP peer to the port over which on the EAP conversation was
conducted.

[b] The backend authentication server and authenticator MAY implement
additional attributes in order to further restrict the scope of EAP
keying material. For example, in 802.11, the backend
authentication server may provide the authenticator with a list of
authorized Called or Calling-Station-Ids and/or SSIDs for which EAP
keying material is valid.

[c] Where the backend authentication server provides attributes
restricting the key scope, it is RECOMMENDED that restrictions be
securely communicated by the authenticator to the peer. This can
be accomplished using the Secure Association Protocol, but also
can be accomplished via the EAP method or the lower layer."

-------------------------------------------------------------------------------------------------------------------- 

Issue 338: Key Scope
Submitter name: Joe Salowey
Submitter email address: jsalowey [at] cisco.com
Date Submitted: December 1, 2005
Reference:
Document: Keying-08
Comment type: T
Priority: 1
Section: 2.4
Rationale/Explanation of issue:
The key scope section is a little hard to understand.
---
The key scope recommendations should specify which key it refers to.  I
believe it refers to the AAA-key.
---
There could be some more generic text about key scoping that describes
the requirements in the lower layer such as:

- Identify what parameters in the lower layer define the key scope
- In phase 0 communicate lower layer parameters that identify the key
scope between Peer and Authenticator
- If channel bindings are supported then include these parameters in the
channel bindings in phase 1a
- The peer can now use the key scope parameters to determine if it has
correct keys for phase 2 lower layer protocol interactions
Requested change:

Include in the key scoping section introduction (2.4) something along
the lines of the following text:

"Since authenticator architectures and deployment scenarios vary the
usable scope of the keys derived by the peer and server and sent to the
authenticator vary.  By defining a key scope a lower layer can take
advantage of key caches in the system to optimize lower layer
interactions.  In order to address key scoping the following needs to be
specified by the lower layer:

- Identify what parameters in the lower layer define the key scope
- In phase 0 communicate lower layer parameters that identify the key
scope between Peer and Authenticator
- If channel bindings are supported then include these parameters in the
channel bindings in phase 1a
- The peer can now use the key scope parameters to determine if it has
correct keys for phase 2 lower layer protocol interactions"

The following sections describe key scoping with respect to the AAA-Key
that is sent to the authenticator for lower layer protection.  It is
possible that a lower layer may define other keys and key uses which
need to have scoping applied.
---

Make it clear that remaining parts of sections 2.4.1 and 2.4.2 refer to
the AAA-Key.


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

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




Results generated by Tiger Technologies using MHonArc.