[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Comments on draft-ietf-ipsec-ike-01.txt
On Fri, 04 Jun 1999 13:44:59 PDT Scott G. Kelly wrote
>
> I should add at this point that I didn't mean to imply that we shouldn't
> *allow* such behavior. What I meant to say was that we should not give
> the impression that an implementation SHOULD violate policy, and that
> I'm not even sure this discussion should be in the doc. Regarding the
> case where Dan suggested that Alice could succeed if initiating with Bob
> but not vice versa, I would suggest that this is only because you permit
> this negotiating up, when in fact, their policies do not intersect. I
> whole-heartedly agree that this is a maddening consequence of the
> complexity of all this security business, but still do not think we
> should RECOMMEND (the RFC2119 equivalent to SHOULD) that it be
> circumvented.
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.
We're not circumventing some Sacred Policy, we're doing what makes sense
and increasing security whereever possible makes sense.
> What we are discussing here is local policy. If it seems too complex,
> this really is an implementation issue. To resolve this, my default
> configuration in "expert" mode might permit "DH group x or stronger"
> with priority ordering implied, and it might support a little checkbox
> which means ONLY x (or something). In any event, I think we've missed
> the point entirely, that being that it is not up to IKE to decide.
OK, fine you can have "expert mode" and "idiot mode" but what's being
recommended in not "idiot mode".
> 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.
It seems to me that a real-world configuration is "do at least group 2",
not "group 2 only group 2 and nothing else including group 5". Also, it
seems a real-world configuration is "do blowfish with a key length of
at least 256 bits", not "do blowfish with a key length of 256 bits no
more no less".
> 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.
Dan.
Follow-Ups:
References: