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

Re: Interoperability (was: Death to AH?)

Paul Koning wrote:
> 
> >>>>> "Dan" == Dan Harkins <dharkins@cips.nokia.com> writes:
> 
>  Dan> On Fri, 02 Jun 2000 16:05:43 EDT you wrote
>  >>  You mention several other problems.  Perhaps you could start your
>  >> own thread on them :)'
>  >>
>  >> Gee I don't liek the way IKE doesn't really define approaches for
>  >> lifetimes for the ISAKMP SA.  Results in interop challenges......
> 
>  Dan> Here we go again Bob....
> 
>  Dan> Quite a while ago I attempted to define an approach to deal with
>  Dan> things like lifetimes and key lengths and other attributes that
>  Dan> do not have a simple boolean acceptance criteria and
>  Dan> failed. There was no consensus.  But I'm willing to try again:
> 
>  Dan> If someone offers you a keylength for a variable-keylenght
>  Dan> cipher which is greater than or equal to what you have
>  Dan> configured, accept it. If it's less reject it.
> 
> I'd support that.

See comments below.

>  Dan> If someone offers you a lifetime which is less than or equal to
>  Dan> what you have configured, accept it. If it's more reject it.
> 
> I'd support that too.
> 
>  Dan> The hardest one though is the Diffie-Hellman group. I know of
>  Dan> quite a few people that will accept group 5 (and reject group 1)
>  Dan> if they're configured for group 2 but even saying that an
>  Dan> implementation SHOULD do that seemed to be too much for enough
>  Dan> people to kill it.
> 
> Hm.  Weird.  Could we try that one again and see why this is?

I argued this point at length with Dan around a year ago (or so). My
original position was that we shouldn't write the ike standard such that
the admin could not control whether this occurred or not. Dan argued
that In the case of Blowfish, it requires no more work to use a longer
key than a shorter one. We never finished the debate. I think I agree
with Dan when it comes to crypto algorithms like Blowfish, i.e. when
increasing the key length does not affect the load on the machine. On
the other hand, I'm not sure that increasing to 3des when des is
configured is the right thing to do, though I'm willing to consider
other points of view.

I think there is a definite issue with DH values though: if I am
configured to accept group 2, sending me group 5 most definitely affects
my work load in a significant way. This has DoS implications. That being
the case, it might be better to make this a local decision.

Scott


> 
>  Dan> And where in the scale do you add new groups
>  Dan> or groups of different types-- elliptic curve vs. prime modulus?
> 
> I think you have to leave that one out.  The reason is that, unlike
> all the other examples, there is no clear order among these.  That
> indeed is the problem with the group number: it only has a partial
> order.
> 
>         paul
Follow-Ups: References: