I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document describes a new EAP method based on the Encrypted Key Exchange (EKE) protocol. The well-defined EKE exchange is preceded by a new crypto policy negotiation exchange, several of the payloads are protected by authenticated encryption, and a cryptographic confirmation that both the server and peer have seen identical messages has been added. The document and Security Considerations are comprehensive, and I see no issues that need to be addressed. I do have the following suggestions for improvement. Section 3.1. The schematic of the EAP-EKE messages (bottom of page 6) defines a number of terms for the first time, without explanation. The single sentence following it (top of page 7) seems intended to point the reader to Section 5 to find those terms. It ought to be a little more descriptive. At a minimum, I suggest something like "Section 5 explains the various cryptographic values and how they are derived." Section 5.1. The strength of x_s is significantly determined by the choice of randomness method deriving x_s. It seems that a weak source of randomness would be a significant implementation flaw for EAP-EKE. This section does refer to RFC 4086 for randomness recommendations, which should certainly be helpful to implementors. But perhaps also referencing some well-known methods (e.g., NIST SP 800-90) would be even better. Section 7.3. The sentence following the table seems to be trying to define a PRF as something with a "K" and an "S", but doesn't define what those values mean. This should either be clarified, or have the section point to a better external definition of a PRF. Section 7.6. Defining a registry without any standardized values (other than a "reserved" value of 0x0) isn't very useful for interoperability. If the expectation is that private use values will be mainly used, perhaps the channel binding value should be treated as a vendor-id payload rather than a registry. Brian