Section 5.1
The local database is perhaps the most important part of this system.
In order for the EAP server or AAA server to know whether i1 and i2
are correct, they need access to trustworthy information, since an
authenticator could include false information in both i1 and i2.
Additional reasons why such a database is necessary for channel
bindings to work are discussed in the next subsection. The
information contained within the database could involve wildcards.
For example, this could be used to check whether WiFi access points
on a particular IP subnet all use a specific SSID. The exact IP
address is immaterial, provided it is on the correct subnet.
[BA] Is it really true that the IP address of the NAS is always immaterial?
For example, couldn't a
NAS lie about its IP address in order to impersonate another NAS?
During an EAP method execution with channel bindings, the goal is to
transport i1 from the peer to the EAP server, and allow the system to
verify the consistency of i1 provided by the peer, i2 provided by the
authenticator, and the information in the local database. Upon the
check, the EAP server sends a message to the peer indicating whether
the channel binding validation check succeeded or failed and
optionally includes all or some of the information that was used in
the check. The message flow is illustrated in Figure 1.
[BA] Is it always necessary for the EAP server to provide information to the
peer
about why the channel binding check succeeded or failed? While this info might
be helpful for
debugging, it seems like there could be situations in which the AAA server just
returns an
Accept/Reject indication.
If the compliance of i1 or i2 information with the authoritative
policy source is mandatory and a consistency check failed, then after
sending a protected indication of failed consistency, the EAP server
MUST send an EAP-Failure message to terminate the session. If the
EAP server is otherwise configured, it MUST allow the EAP session to
complete normally, and leave the decision about network access up to
the peer's policy.
[BA] I would suggest that normative language is not appropriate here. For one
thing, an EAP-Failure
does not actually result in the host being denied access to the network -- an
Access-Reject is what
accomplishes this. Also, since an EAP-Failure (or EAP-Success) may not be
delivered, it doesn't make
sense to rely on it. Furthermore, couldn't there be situations where rather
than denying access
some other action is taken, such as putting up a warning message, isolating the
host in some way
(e.g. filters or VLAN setting, etc.)?
Section 5.2
These checks enable the EAP server to detect lying NAS/authenticator
in enterprise networks and lying providers in service provider
[BA] As noted in the previous message, these checks do not actually enable the
determination of whether
a provider is lying.
Checking the consistency of i1 and i2 is nontrivial, as has been
pointed out already in [HC07]. First, i1 can contain any type of
information propagated by the authenticator, whereas i2 is restricted
to information that can be carried in AAA attributes.
[BA] Actually, i1 can only contain information that is both propagated by the
authenticator *and*
passed up by the host in the proper format. This requires coordination between
the
driver implemented on the host and the EAP method. In practice, this has been
a major impediment
to implementation of Channel Bindings, because without driver changes, many of
the parameters desired
by channel binding implementations will not be available.
Similarly, the database referred to in this section also requires a non-trivial
effort to put together,
comparable to the "wire map" required to support geographic location or
emergency services calling.
For example, if the EAP MTU is 1020 octets, and EAP-GPSK is used as
the authentication method, and maximal-length identities are used, a
maximum of 384 octets are available for conveying channel binding.
[BA] This is an important point -- and one that indicates that the ability to
implement channel
bindings is limited on EAP methods that don't support fragmentation.
Section 6.3
If transporting data within a lower-layer's secure association
protocol (SAP), this protocol MUST support transport of integrity
protected data using a key known only by the EAP peer and EAP server,
and not known to the authenticator. There must be mechanism whereby
the authenticator can transport the protected payloads to the EAP
server, either via a AAA protocol or some other means, and receive a
protected result.
[BA] This paragraph does not make sense, because by definition the SAP
exchange occurs between the authenticator and the peer, and therefore
any keys derived in the process need to be known by the authenticator
and the peer. In a number of cases (such as IKEv2), the EAP server
only doesn't know the key used by the SAP, but it is an explicit
design requirement that this not be possible.
This protocol MUST support exporting channel binding data to the AAA
subsystem on the EAP server for validation. The SAP must have access
to channel binding data required for transport to the EAP server.
[BA] The last sentence also doesn't make sense. Elsewhere in the document
it says that the authenticator is not supposed to have access to the
channel bindings data, but here it implies that it must have access,
since the SAP is run between the peer and authenticator.
Section 7.1
7.1. Requirements for Lower-Layer Bindings
Lower-layer protocols MUST support EAP in order to support EAP
channel bindings. These lower layers MUST support EAP methods that
derive keying material, as otherwise no integrity-protected channel
would be available to execute the channel bindings protocol. Lower-
layer protocols need not support traffic encryption, since this is
independent of the authentication phase.
[BA] Channel Bindings can still be used even on lower layers that don't use
keying material. For
example, an EAP method supporting channel bindings could be used with a wired
network supporting
IEEE 802.1X-2004. Since the EAP server/AAA server will still obtain i1/i2 in
this situation, why
should it matter whether an integrity-protected channel is in place?
_______________________________________________
Emu mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/emu
