Alan DeKok wrote:
Dan Harkins wrote:
Once this group gets around to selecting a protocol for advancement
is it your view that we just have a coronation followed immediately
by publication or do we actually get to update the selected protocol
to meet our needs?
Portions of any protocol will likely need to be updated. The tunnel
requirements draft lists a number of issues that have to be addressed in
any protocol before it is accepted as the agreed-upon method.
Any *other* changes unrelated to security and/or the tunnel
requirements are out of scope.
Then I must ask a stupid question. Who is the group that decides what
should and shouldn't be allowed? While I understand that the changes
EAP-FAST makes to existing EAP methods are already published and have
many implementations, it seems that allowing future EAP methods to make
random changes is something that will ultimately lead to
interoperability problems. It is just a bad precedent to allow to
continue. I would be happy to raise this issue on a different list if
there is one more appropriate. But where this is an EAP related issue
this seemed to be the right list.
As for security, I think the majority of the Internet community expects
all of the standards setting bodies to put good security high on their
list of things to care about. While the comment that EAP-TTLS can be
just as dangerous in letting credentials out, there is one major
difference from my point of view. No where that I have seen in the
EAP-TTLS specifications did I ever see any hint that the supplicant
could (or should) operate in a mode where the certificate isn't
verified. For EAP-FAST provisioning anonymous provisioning is clearly
spelled out as a possible mode of operation. By allowing things to be
published like that without anyone calling attention to the related
security issues seems like a bad idea. Further it bothers me more when
I see a NIST document that indicates that EAP-FAST is the best choice
for a secure, but easy to deploy, EAP method.
It is certainly my understanding that the WG would update the selected
protocol (please correct me if I'm wrong!). Therefore *discussing* the
architectural choices a protocol made is something we certainly should
not discourage as it will guide our choice and, possibly, prepare us for
work ahead.
Some issues are less important. e.g. The TLS PRF being dependent on
(client + server), or (server + client) random. Unless there are
security issues related to a particular choice of order, the use of one
order or another shouldn't be factor in choosing a tunneled EAP method.
Alan DeKok.
I agree. It was not my intention to claim that all issues were of equal
importance. There are obviously cases where decisions were made and
released to the wild. My goal by listing all of the issues I did was to
attempt to start a conversation and allow the important issues to rise
to the top. Ultimately I want to see the use of EAP continue to be
successful, but also to be secure. I figured I either had to put the
issues (as I see them) out there and try to be part of the solution, or
ignore them and just hope it works out. I would prefer to be part of
the solution where possible.
However, again, if I am trying to get this discussion going in the wrong
forum, please point me to a better one.
_______________________________________________
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
