I'm not sure which commercial interoperability testing and certification program for IPsec products you work for but I have an idea. In fact, I think I know who you are!
I used to work for a Very Large Router Company. I wrote the IKE RFC and conveniently wrote the code running on the routers for said company. When we submitted for certification with a commercial interoperability testing and certification group for IPsec products, one of the testers called me and told me my code was not compliant. Then he proceeded to tell me what the IKE RFC "actually said". You can guess where this is going. I told him that since I wrote the text I knew what it "actually said". He was not happy but he backed down. I did not change a line of code. We received our plack.
True story! Ask your co-workers.
Alas, I will be missing the Anaheim meeting. Vote "yes" for me!:-)
The only way you'll get "bomb-proof security" out of a Contivity box is if you give all your clients a certificate.
The password option-- which most everyone deploys-- is insecure.
It uses a shared password in the IKE exchange and then does an ineffectual username/password authentication. It's ineffectual because it is not bound to the phase 1 IKE exchange. The keys derived from phase 1 and phase 2 in IKE will not be authenticated and therefore the security guarantee that IPsec gives you has just been voided.
Really! It's snake oil. It's an insecure hack. IKE with pre-shared keys only works in a site-to-site VPN situation, not with clients. If you have clients doing IPsec and they don't have certificates then you're not secure. Period. Full stop.
There is no way that 802.11i is going to change anything about CCMP. It's in sponsor ballot and has something like 4 comments to deal with. CCMP was not any of those comments. Repeat: there is absolutely no way that TGi will change the draft to affect CCMP. The cement is long dry on that.
There is also absolutely no reason why anyone should worry about CCMP. The underlying AES algorithm has received extensive cryptographic review and the CCMP mode has also been reviewed. It has proven security characteristics.
And CCMP is MUCH, MUCH, MUCH better than TKIP which uses a weak message integrity check. CCMP all the way. Don't worry a bit about it.
The only problem in the proposed scheme is PSK. Because of the way the PSK is used in the 4-way handshake (which generates unique session keys) it is open to a passive attack. Someone could record the exchange between the client and AP and then go crunch numbers trying to guess the PSK. If your PSK is set by using a passphrase it's even more easy to guess. If it's a raw PSK then it's a bit harder. There are ways to come up with a pre-shared key authentication scheme that is not susceptible to a passive attack (IKE, RFC2409, defines one for instance) but the 4way handshake is not such a scheme.
A VPN is not a solution for wireless security. IPsec was not designed to provide per-hop security, it was defined to provide end-to-end security over a routed network over many hops. When you have a hammer, though, lots of things look like nails and it is very tempting to use IPsec to provide link-level encryption. Better to use something designed for the task at hand.
If you're going to go to the trouble of per-user authentication (and not group authentication using PSK) then use 802.1x.
Another problem with IPsec is that most deployments use some sort of "password". This means that they use XAUTH and XAUTH is an INSECURE HACK on what was otherwise a cryptographically sound protocol-- IKE. If your IPsec solution has clients entering some shared password-- and Contivity does this-- then don't do it. If you want to use IPsec for clients then use certificates that is really the only secure way to go. Anything else is snake oil.
Slashdot Mirror
I'm not sure which commercial interoperability
:-)
testing and certification program for IPsec
products you work for but I have an idea. In
fact, I think I know who you are!
I used to work for a Very Large Router Company. I
wrote the IKE RFC and conveniently wrote the code
running on the routers for said company. When we
submitted for certification with a commercial
interoperability testing and certification group
for IPsec products, one of the testers called me
and told me my code was not compliant. Then he
proceeded to tell me what the IKE RFC "actually
said". You can guess where this is going. I told
him that since I wrote the text I knew what it
"actually said". He was not happy but he backed
down. I did not change a line of code. We received
our plack.
True story! Ask your co-workers.
Alas, I will be missing the Anaheim meeting.
Vote "yes" for me!
The only way you'll get "bomb-proof security" out
of a Contivity box is if you give all your clients
a certificate.
The password option-- which most everyone deploys--
is insecure.
It uses a shared password in the IKE exchange and
then does an ineffectual username/password authentication.
It's ineffectual because it is not bound to the
phase 1 IKE exchange. The keys derived from phase 1
and phase 2 in IKE will not be authenticated and
therefore the security guarantee that IPsec gives
you has just been voided.
Really! It's snake oil. It's an insecure hack.
IKE with pre-shared keys only works in a site-to-site
VPN situation, not with clients. If you have
clients doing IPsec and they don't have certificates
then you're not secure. Period. Full stop.
There is no way that 802.11i is going to change
anything about CCMP. It's in sponsor ballot and
has something like 4 comments to deal with. CCMP
was not any of those comments. Repeat: there is
absolutely no way that TGi will change the draft
to affect CCMP. The cement is long dry on that.
There is also absolutely no reason why anyone
should worry about CCMP. The underlying AES
algorithm has received extensive cryptographic
review and the CCMP mode has also been reviewed.
It has proven security characteristics.
And CCMP is MUCH, MUCH, MUCH better than TKIP
which uses a weak message integrity check. CCMP
all the way. Don't worry a bit about it.
The only problem in the proposed scheme is PSK.
Because of the way the PSK is used in the 4-way
handshake (which generates unique session keys)
it is open to a passive attack. Someone could
record the exchange between the client and AP and
then go crunch numbers trying to guess the PSK.
If your PSK is set by using a passphrase it's
even more easy to guess. If it's a raw PSK then
it's a bit harder. There are ways to come up with
a pre-shared key authentication scheme that is not
susceptible to a passive attack (IKE, RFC2409,
defines one for instance) but the 4way handshake
is not such a scheme.
A VPN is not a solution for wireless security.
IPsec was not designed to provide per-hop security,
it was defined to provide end-to-end security
over a routed network over many hops. When you
have a hammer, though, lots of things look like
nails and it is very tempting to use IPsec to
provide link-level encryption. Better to use
something designed for the task at hand.
If you're going to go to the trouble of per-user
authentication (and not group authentication
using PSK) then use 802.1x.
Another problem with IPsec is that most deployments
use some sort of "password". This means that they
use XAUTH and XAUTH is an INSECURE HACK on what
was otherwise a cryptographically sound protocol--
IKE. If your IPsec solution has clients entering
some shared password-- and Contivity does this--
then don't do it. If you want to use IPsec for
clients then use certificates that is really the
only secure way to go. Anything else is snake oil.