eap Mailing List: Re: Issue 294: Keying Protocol Requirements

[Bernard Aboba (aboba]

Here are some thoughts on Jesse's requirements submission.  My comments
are noted with [BA].

IEEE  802.11i amendment makes a number of assumptions about this sequence
of messages. These assumptions are

1.        The EAP method performs mutual authentication. Unilateral and
bilateral authentication enables man-in-the-middle attacks against the
Peer, the EAP Server, or both. [AUTHREQ] makes this assumption explicit.

2.        The NAS has a mechanism to guarantee that the AAA-Key is fresh.
Notice that the key freshness assumption is different from a message
replay protection. Message replay protection is necessary for key
freshness, but it is still feasible to deliver an already-used key in a
replay-protected message, so replay protection is necessary but not
sufficient. Lack of a freshness mechanism enables an attacker to deliver a
legitimate but already compromised MSK to the NAS. The EAP session id can
be used for this function.

3.        The channel between the EAP server and the NAS is protected
end-to-end from message forgeries. If this protection is unavailable, then
an attacker can create an AAA-Key and masquerade as the Peer to the NAS.

4.        The AAA-Key is protected from exposure to any party that might
monitor the channel between the EAP Server and the NAS. If this assumption
is violated, then the attacker can masquerade as the NAS to the Peer.

5.        The EAP Server may not reuse the same AAA-Key with a different
NAS. If it did, then compromise of one NAS would compromise the Peers data
at every NAS that used the same MSK. [Housley] also includes this
requirement.

6.        The EAP peer has a mechanism for determining the authenticator
identity, and the authenticator has a mechanism for determining the peer
identity.  Where the identities of one or more of the parties are unknown,
the AAA-Key scope is undefined.

------------------------------------------------------------------
[BA] I like the way these assumptions are linked to specific threats, so
that the reasoning behind them is clear.  In particular the "key
freshness" requirement is not adequately captured in the document as
it stands.  Note that using the EAP Session-ID to determine the freshness
of exported EAP keying material seems to assume caching of EAP
Session-IDs.  I think that requirement 5 ("Domino Effect") could probably
be expanded upon to encompass both NAS and EAP Server behavior.
Note that it is not clear from the above whether assumption 6 is about
security, or just performance.
------------------------------------------------------------------

The logical message flow illustrates that the  Peer and the EAP Server do
not explicitly agree with the NAS that  the NAS will use a particular
AAA-Key. The NAS is never told explicitly by the EAP Server which Peer
corresponds to the AAA-Key. The EAP Server does not bind the AAA-Key to
the authenticated identities of the Peer and the NAS. An acceptable EAP
method must provide this service.

-------------------------------------------------------------------
[BA] The NAS does obtain either a User-Name or CUI attribute corresponding
to the AAA-Key.  And of course the NAS does also obtain the lower layer
peer identity within the Calling-Station-ID attribute.   The AAA server
implicitly limits the scope of the AAA-Key to the NAS identity
provided in the NAS-Identifier attribute.  So the problem here is that all
parties do not have the same information;  the peer may not learn the
NAS-Identifier, and unless explicitly defined within the lower layer, may
not know whether the AAA-Key is bound to use on a particular interface.
Also, key restrictions are not communicated to all parties.
--------------------------------------------------------------------
A second problem is that the Peer never learns the expiration time for the
AAA-Key. Since the Peer cannot anticipate when the AAA-Key will expire, it
must either re-authenticate too frequently or risk a service disruption
when the AAA-Key expires. In the latter case, the Peer learns of the
expiration  implicitly, as it sends datagrams protected by the AAA-Key,
but receives no data traffic in return.
---------------------------------------------------------------------
[BA] Key lifetime issues are discussed in the document.
---------------------------------------------------------------------
The heuristics most relevant here are
o Use explicit communication. Every message should convey all the
information it needs to explicitly specify what it means.
o Fully specify the semantics. All of the conditions for a message
to be acted upon should be spelled out.
o Name entities. If the identity of a Principal is essential to the
meaning of the message, include the name explicitly.
o Make trust assumptions explicit. The protocol designer (and
implementer and deployer!) should know which assumptions and dependencies
are necessary.
----------------------------------------------------------------------
[BA]  These are sound principles that may be worth citing in the document.
----------------------------------------------------------------------
3.2 Mandatory Requirements
A keying protocol must cryptographically bind the EAP Peers authenticated
identity, the NASs authenticated identity, the AAA-Key expiration
condition, and the AAA-Key name in a message from the EAP Server to the
EAP Peer.

[BA] This seems to make Channel Bindings a MUST.  Seems too strong.

A mechanism must be specified by which the EAP Peers authenticated
identity, the NASs authencated identity, the AAA-Key, AAA-Key expiry
condition, and the AAA-Key name is cryptographically bound in a keying
protocol message from the EAP server to the NAS.

[BA]  This is a condition for the Secure Association Protocol.  Should we
add this to Section 4?

A keying protocol instance must be bound to the particular instance of the
EAP method that derived the AAA-Key.

A keying protocol must include a session identifier that allows the EAP
Peer to distinguish one instance of the keying protocol from every other
instance.

A mechanism must be specified to include a session identifier that allows
the NAS to distinguish one instance of the keying protocol from every
other instance.

[BA] These requirements are handled by the EAP Session-Id.

The keying protocol must protect the EAP Peer from forgeries of keying
protocol messages.

[BA] This is required by [Housley].

A mechanism must be specified to protect the NAS from forgeries of keying
protocol messages.  A keying protocol must not expose the AAA-Key when it
is transferred between the AAA Server and the NAS.

[BA] Also required by [Housley].

An EAP method must
produce an authenticated Peer name

[BA] Must seems too strong for an optional feature.