There are two issues that arise in dealing with the "Lying NAS problem":
a. Whether the NAS is telling the same thing to the AAA server and to the EAP
peer;
b. Whether the information that the NAS provides to either party is actually
correct.
While the AAA protocol info is useful for problem a), it isn't that helpful for
problem b), since as you point out, the authenticator may not be trusted by
the AAA server. So the NAS could be telling the same lie to both the AAA server
and the EAP peer.
So overall, my take is that you are suggesting that the draft focus more on
problem b).
I would agree that it is important for the document to make the distinction
between a) and b) and for it to point out the relatively value (and cost)
of solving each of these problems.
However, I do think that there are sound reasons to retain an interest
in problem a, so long as that interest is not carried to an extreme (e.g.
defining more and more AAA attributes that wouldn't be needed for any
other purpose, such as the IEEE 802.11 RSN IE).
To my mind, the primary reason for tackling problem a) is as a quick
"sanity check" on NAS behavior, in situations where assembling an appropriate
database for dealing with problem b) is prohibitively expensive.
However, for such a "sanity check" to work reasonably well, it is necessary for
the
data formats for the channel bindings and AAA to be well aligned so that
they can be mechanically compared. This issue isn't currently dealt with in
the
draft.
======================================================================
After reviewing recent comments from Klaas on the list on Channel
bindings there is one issue I would like to try to resolve before
bringing this draft to last call.
In section 5.1, the draft defines a message i2, which is the message
carrying AAA attributes from the authenticator to the server using a AAA
protocol. While, this message does occur in the protocol interactions,
it is actually not that important in the channel binding interactions
because the server does not completely trust the authenticator and must
know what is valid through some other mechanism, such as the local
database defined in the draft. I think this section is a bit misleading
and needs to emphasize this point. This is further confused by the fact
that in some sections the draft focuses entirely on AAA attributes to
carry channel-binding information. While AAA attributes are undoubtedly
important to carry it does not appear that they should be the only type
of data allowed especially since the AAA protocol is not required to be
directly involved other than to carry EAP. This is demonstrated by the
"TODO" 7.3 which suggests we need to add a way to carry the 802.11
RSN-IE. Since AAA protocols haven't needed to carry this information to
date, it is not clear that adding this information to them would be
helpful. Given this I would suggest the following modifications to the
draft:
1. In sections 5.1 and 5.2 clarify the role of message i2 with respect
to channel bindings.
2. In section 6.1 define channel binding data as a superset of AAA
attributes. In particular the last paragraph needs work and seems
inconsistent with 7.1 which allows for the inclusion of Diameter
attributes without the exclusion of other attributes.
3. Sections 7.1, 7.2, 7.3 only recommend comparing information with what
is received from the NAS and not about comparing with local information
4. Section 8 is about AAA validation and is not channel bindings, is
this section necessary?
If the working group agrees with this direction I can provide text for
the changes.
Please send comments to the list.
Thanks,
Joe
EMAILING FOR THE GREATER GOOD
Join me
_______________________________________________
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
