Joe Salowey wrote:
> This is the working group last call for draft-ietf-emu-chbind-09. Please
> send your comments to the list by October 21, 2011.
I've read the document, and have comments as follows.
Section 4.3 Page 11:
For example, information carried
in AAA attributes such as the NAS IP address may have been lost in
transition and are thus not known to the EAP server.
Even worse, that information might exist, but be entirely useless. For
example, a NAS can be in a private network, and send a NAS IP address of
192.168/16. Many AAA proxy hops later, the EAP server receives that IP.
As the next piece of text says:
However, often verification of the MAC or IP address of the NAS is
not useful for improving the overall security posture of a network.
Channel bindings can be used to verify that the NAS is not lying (i.e.
it is sending the same information to the client and to the EAP server.)
But that information has no useful context, and is therefore useless
for any purpose.
Bottom of page 11, there is a typo "lyes" should be "lies".
Page 11 and 12 again:
As discussed in the next section, some of the most important
information to verify cannot come from AAA attributes but instead
comes from local configuration. For example in the mobile phone
case, the expected roaming rate cannot come from the roaming provider
without being verified against the contract between the two
providers. Similarly, in an enterprise, the SSID a particular access
point is expected to advertize is a matter of configuration rather
typo: "advertise"
than something that can be trusted because it is included in an AAA
exchange.
I think that this point could be clearer. The EAP peer and
authenticator do not share trust, but all other parties do. Channel
bdingins allows the EAP peer and authenticator to gain trust in each other.
5.1. Protocol Operation
It may be useful to point out that specifications have traditionally
treated the AAA server and EAP server as separate entities. However,
there is no specification for any protocol which allows those two
servers to communicate. i.e. there is no equivalent to EAPoL for servers.
Much of the rest of the text in this section is a round-about way of
saying that we assume the AAA server and EAP server can communicate, via
some mechanism not specified here
5.2. Channel Binding Consistency Check
It may be useful to add the note from Section 4.3, where the EAP
server verifies the information against it's local database. This
prevents the EAP peer and authenticator from colluding to cheat the EAP
server.
5.3. EAP Protocol
For clarity, it would be good to add some blank lines around the
definitions of NSID, Length, and NS-Specific. The use of NS-Specific
should be made consistent between the text and the diagrams.
The diagram also has two instances of the "NSSID, Length, NS-Specific"
data, but only one instance of Code. Is it meant to show that multiple
instances of channel binding data can appear in the packet? I presume so...
I recommend changing the assigned code point for RADIUS from 0 to 1.
The value of "0" is often used in code for uninitialized data. It may
be useful to distinguish that data from the intention to send RADIUS.
It says:
Length: Two octets of length in network byte order, not including
the length or the namespace ID.
I suggest replacing this with:
Length: two octets of length in network byte order, indicating the
number of octets of data in the NS-Specific field. The octets for NSSID
and Length are not included in this count.
It says:
A given NSID MUST NOT appear more than once in a channel binding data
or channel binding response.
I suggest adding a following sentence:
Instead, all NS-Specific data for a particular NSSID MUST occur
within the context of one (NSSID, Length, NS-Specific) field.
It says:
In channel binding data, the code is set to 0 (channel binding data)
As above, I suggest leaving the value "0" as unused, and starting
assignments from "1". If we want to get cute, we can re-use the values
from EAP:
2 data from client
3 success
4 fail
_______________________________________________
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
