On 6/24/11 04:12 CDT, Philip Homburg wrote:
In your letter dated Thu, 23 Jun 2011 20:30:05 -0500 you wrote:
OH... That's an intriguing idea, use 802.1x to securely feed SEND.  That
might even make using SEND practical in an open network environment like
a University.  Its a massing protocol layering violation, but most
things in the security realm are.

I'm not sure how that's supposed to improve things. To make 802.1x secure
(for the client) the client needs to have the server's certificate. Otherwise
there can be a man-in-the-middle attack.

If you have a way of providing clients with certificates, why not distribute
the keys for SEND directly?

From a technical and theoretical point of view you are correct, they are fundamentally the same problem. However, from a practical point of view, there are available solutions and tools, even some commercially available, for dealing with securely configuring 802.1x, especially in the wireless realm with WPA2, at many different scales, from the home user network all the way up to multinational enterprise.

The issue even has some mind share with the non-technical end users world, thanks to the virus like spread of wireless home gateways.

So, the key/certificate distribution problem is hard enough to do right once. We are getting close with 802.1x and WPA2, why not build on that for SEND? I'm not saying you shouldn't be able to configure SEND separately if you wish, and if you can that might be even more secure. But, being able to securely generate keys or obtain certificates for SEND using 802.1x and/or WPA2 would create a much lower barrier to entry for SEND.

But even with all that, we don't eliminate the usefulness of RA-Guard in may situations.

--
===============================================
David Farmer               Email:far...@umn.edu
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota 
2218 University Ave SE      Phone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

Reply via email to