![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
|
This issue came up during the last IETF meeting when the WG discussed
channel binding. Pasi said the discussion was within the scope of EMU WG
charter. - A document that defines EAP
channel bindings and provides guidance - A mechanism to support extensible
communication within a TLS I’m not against this. But let’s face it, this is
venturing into dealing with authorization parameters with EAP (EAP layer? EAP
method layer? Etc.) I’m not against that either. In fact, I know there
are a lot of people who’d be happy to see that happen. So, my question is, is this what we are doing: Enabling EAP
to exchange authorization parameters among the EAP peer – authenticator –
authentication server? If not, I hope someone can explain how this is different
than what it takes to solve channel binding problem. Thanks. Alper |