[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Comments on IKEv2

In part 2 of our series, I look at IKEv2 :)

(1) Criticality. S 2.5 specifies a "Critical" bit. IMHO, experience
with PKIX shows that criticality is a rathole. Is there some reason
that this is actually necessary?

(2) The use of cookies seems pretty confusing. In S. 2.6 you already
allow the responder to use an anti-clogging token and then change
it's value to be more meaningful. Why not simply make these two
different protocol elements.

Also, S 2.6 says:

   To avoid the cookie exchange
   adding extra messages to the protocol in the common case where the
   Responder is not under attack, IKEv2 goes back to the approach in
   Oakley (RFC 2412) where the cookie challenge is optional. Upon
   receipt of an IKE_SA_init, a Responder may either proceed with
   setting up the SA or may tell the Initiator to send another
   IKE_SA_init, this time providing a supplied cookie.

Does this mean that if you want anti-clogging protection you need to
send 6 messages, not 4?

(3) S 2.9 says:

   The Responder is allowed to narrow the choices by selecting a subset
   of the traffic, for instance by eliminating one or more members of
   the set of traffic selectors provided the set does not become the
   NULL set.

Can the responder widen the choices? If not, why not?

(4) It would be very nice to have a complete diagram of each exchange
pretty early in the document. Having it show up one message at a time
is pretty hard to read.

(5) The proposal section in S 7.3 is, pretty scarey. I understand that
some of this is inherited from IKEv1 but I think it may be time for it
to go. I'll send a separate message to the list with some thoughts
one negotiation but I wanted to mention that this section
gave me a headache.

I also have a question: under what circumstances would you want to propose
an IKE child SA? Is this a normal operation? Have I just missed something?

(6) What's the type of the Certificate Authority field in S 7.7?

(7) S 7.8 says:

   The signature MUST
   be a PKCS#1 encoded signature using the cryptographic hash and
   signature algorithms chosen by the signer.

This is inconsistent with S 3.2 which says that the AUTH payload may
contain a DSS signature. PKCS#1 only specifies RSA signatures. You 
probably want to specify the ASN.1 encoding provided in PKIX. You
of course need to require that DSS be used with SHA-1.


-Ekr

--
[Eric Rescorla                                   ekr@rtfm.com]
Author of "SSL and TLS: Designing and Building Secure Systems"
                  http://www.rtfm.com/
Follow-Ups: