Proposed Resolution to Issue 338: Key Scope

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: jsaloweycisco.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

Proposed Resolution to Issue 338: Key Scope

Thread: Proposed Resolution to Issue 338: Key Scope