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

Re: Comments on IKEv2

On Wed, 05 Dec 2001 09:54:20 PST you wrote
> 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?

There was a complaint expressed in the WG that when new payloads are
chained onto a message there is no way to tell the recipient whether
he should ignore the payload or discard the entire message (containing
the payload) if he does not understand the message type. That's what
this is for.

Coincidentally, this is actually in Cheryl's requirements document.

> (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.

We went around and around on this. Different protocol elements would
make sense. Alternatively it was suggested to not allow the responder
to change cookies since the amount of "meaningful"ness the new cookie
could have probably won't outweigh the complexity on the protocol.

> 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?

Yes. Deployment experience has shown that a box is usually not under
attack and that it would be nice to eliminate the overhead for the
usual (overwhelming majority) case.

> (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?

We want the two sides to converge on the largest intersection of their
policy in the fewest possible number of messages. If the Responder added
things it might be unacceptable to the Initiator and result in more
round trips.

> (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.

OK.

> (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.

The scariness is inherited from IKEv1. We tried to make it less scary by
eliminating the combinatorial explosion of options that the notion of a
"protection suite" introduced. There was a much simpler version of this
in an early edit but it could not specify the whole range of things this
can and it was abandoned. 

> 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?

If I understand the question, you'd do that to "rekey" the IKE SA.

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

It's the same as in the "Certificate Data" in S 3.9 of RFC2408.

> (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.

Correct. An oversight on my part. 

Thanks for the comments!

  Dan.
Follow-Ups: References: