I agree with Yaron that this document is not ready to be advanced. 

Aside from whether the document is appropriate for publication on the Standards Track (I believe that Informational would be a better choice), I'd suggest that the document has a more basic problem in that it doesn't do a very good job of defining the problem it is trying to solve or demonstrating that the solution offered actually solves that problem or can be practically
implemented. 

For example, early on the document makes the following statement: 
   This document defines and implements EAP channel bindings to solve
   the lying NAS and the lying provider problems, using a process in
   which the EAP peer provides information about the characteristics of
   the service provided by the authenticator to the AAA server protected
   within the EAP method.  This allows the server to verify the
   authenticator is providing information to the peer that is consistent
   with the information received from this authenticator as well as the
   information stored about this authenticator.  "AAA Payloads" defined
   in [I-D.clancy-emu-aaapay] proposes a mechanism to carry this
   information.

However, as noted in Section 3:

   In service provider networks, global knowledge is
   infeasible due to indirection via roaming.  When a peer is outside
   its home administrative domain, the goal is to ensure that the level
   of service received by the peer is consistent with the contractual
   agreement between the two service providers.

Unfortunately the term "level of service" is not well enough defined here to give a good sense of what is
possible and what is not.  As noted above, in general the home AAA server does not have 
enough information to independently verify AAA attributes provided to it by 
roaming partners.  The problem is not just lack of "global knowledge";  even if it were possible
for a home AAA server to have perfect global knowledge, if that knowledge were obtained from the
providers themselves (where else could it come from?) then if those providers were untrustworthy,
then how could it be used in channel binding verification?  

As a result, I'd suggest that some careful analysis is needed to describe in detail the threats that 
the "lying provider" solution really can mitigate.  As noted later:

      In other words, channel bindings enable the
      detection of inconsistencies in the information from a visited
      network, but cannot determine which entity is lying.  

Given that it is not really possible to determine whether a provider is actually lying or not, how
does the offered solution actually solve the "lying provider" problem? 

The service provider attacks described in Section 3, which attempt to make the case for the
utility of channel bindings are not very convincing: 

  a. Inappropriate billing.  In this scenario, it's not clear to me how Channel Bindings would be
     helpful  Today rates are not advertised in Beacons, and if accounting fraud is suspected,
     wouldn't this be best verified by computing the expected billed amounts against the actual
     ones, based on RADIUS accounting data?  

  b. Transmit power boost.  Detecting inappropriate levels of transmit power seems like something
     beyond the capability of channel bindings (and more in the jurisdiction of regulatory agencies
     like the FCC).  Even if the geolocation were to be transmitted along with the power measurement,
     detecting an inappropriate transmit power level would involve some fairly complex modeling with
     lots of variables (e.g. precise tower location, absorption along the line of sight, etc.). 

At a minimum, I'd suggest that the document needs to come up with some more plausible service provider
scenarios.