This is something that IEEE 802.11r/D5.0 is doing. R0KH-ID is set to the
identity of the NAS Client (e.g., NAS-Identifier if RADIUS is used as
the backend protocol) and this identifier is sent to the peer during
association (before EAP authentication). In addition, both the R0KH-ID
(NAS-Identifier
On Sat, Apr 07, 2007 at 04:44:54PM -0400, Charles Clancy wrote:
> This is one of the fundamental issues with EAP channel bindings. The
> NAS ID is bound to the AAA security association between the
> authenticator and the EAP server. The MAC address is visible to the
> client. Thus the peer a
I'm glad to hear from Steve here that there is support for publishing
TTLSv0. I would like to see that happen regardless of whether it is done
as an EMU work item or not.
My understanding is that a new version of the TTLSv0 document will be
forthcoming which will fill in some of the details tha
I share the concerns expressed about defining yet another password based
EAP method. As people have pointed out here, EAP-TTLSv0 also allows the
use of the TLS record layer to carry a password-based authentication
method without an inner tunneling of EAP.
Several months ago, I tried contacting Pa
Sam Hartman wrote:
"Charles" == Charles Clancy <[EMAIL PROTECTED]> writes:
Charles> I don't think I'm convinced that EAP channel bindings are
Charles> doing this binding to the L2 channel. The identity used
Charles> in an EAP channel binding must be bound to the AAA
Charles> s
I thought folks on these two lists might be interested in this,
Microsoft will be having a web chat next week discussing its EAP
platform if you want to know more about our implementation and how you
can integrate with it this is probably a interesting talk.
See:
http://blogs.technet.com/nap/ar
