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

Re: Comments on draft-ietf-ipsec-ike-01.txt



Hi Dan,

Dan Harkins wrote:
> 
> Your religious approach to policy is clouding your vision. The policies do
> indeed intersect. Alice's says "blowfish of at least 256 bits", Bob says
> "blowfish of at least 128". The union of the two ends up being Alice's
> policy.

You've substantially changed the discussion basis here. If the policies
intersect, then there is no need for the text to begin with, and you can
delete it entirely. We're arguing about the case where they do not. You
said in the document

   Certain negotiable attributes have ranges or multiple acceptable
   values.  For instance, if the policy specification on a peer mandates
   group 2 but is offered group 5, as part of an otherwise acceptable
   protection suite, the peer SHOULD accept that value as it provides
   more security than demanded.

That's a far cry from what you're saying above, i.e. "blowfish of at
least 256 bits". In fact, that is entirely my point. If this is truly
the policy, then there is no need for the language in the document, and
it should be deleted, as I said. But if, on the other hand, the policy
MANDATES something, you are saying it SHOULD be circumvented - and this
is a slippery slope.

> We're not circumventing some Sacred Policy, we're doing what makes sense
> and increasing security whereever possible makes sense.

It does not make sense if, for *whatever* reason, the administrator
configured it so that you do not use a "stronger" algorithm. It is not
up to the IKE implementation to decide what makes sense, or to decide
what is "stronger"; it is up to whoever configures the security.

> > IKE is implemented in an application - a service provider for the ipsec
> > core. As such, IKE should not be making any sort of policy decisions.
> > Rather, the kernel (or whatever component) should be requesting that IKE
> > negotiate the SA within a given set of parameters. If the requester
> > specifies DH-2 alone, and no other DH group, then IKE should provide
> > that and that alone, failing if it cannot.
> 
> Why on earth would you want to specify group 2 and group 2 alone with no
> other group accepted? Don't say memory- or performance- challenged box
> because that's the edge condition that keeps this from being a MUST. Give
> me a valid reason to configure your security is such a manner.

I might say group 2 or 1, with a preference for group 2 - whatever. You
have argued that if you present me with group 5 in this case, I should
accept it, or rather, my IKE implementation should accept it, even
though the specified policy does not explicitly permit this. This is
just plain wrong. Maybe I know something you don't about group 5. In any
event, that's irrelevant. I have argued that it is a policy matter, and
that policies are sufficiently expressive as to provide for the
functionality you want, as should be the request interface into your IKE
implementation. Also, an IKE implementation should only do what it's
asked to do, and not presume to know what's "best" under any
circumstance.

> > I'm surprised this discussion is even occurring. Am I missing something
> > obvious here?
> 
> So am I! I can't think of a reason why you wouldn't want to do stronger
> crypto if given the option. I want to recommend to people to always do
> stronger crypto because this is a security protocol. If it's possible to
> do things in a more secure manner, with longer key lengths, and stronger
> Diffie-Hellman shared secrets then I strongly recommend people to do that.
> But like I said before, this isn't legislation. People are free to not
> take this recommenation.
> 
> We're trying to engineer a security protocol and recommending people do
> things that are more secure seems like a no-brainer to me.

The point is, I may have a valid reason for not wanting to use option x.
Maybe you think it's stronger, but I know of an exploitable weakness.
Maybe I have overhead concerns. Whatever the reason, I should be able to
specify (control) the parameters in whatever manner desired, and know
that the implementation won't override my settings because it thinks it
knows better than me.

Scott


Follow-Ups: References: