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

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



Dan Harkins wrote:
> So we can mandate the support for negotiating up things like key lengths but
> not require that it be done every single time. If someone wants to have a
> policy that says, "128 bits no more no less" then they are free to do that
> without violating any IETF requirements just as Ran (and you, and me) is free
> to type telnet 1.2.3.4 and not violate any IETF requirements.
> 
>   As I stated before, the text that is causing so many people problems is being
> rewritten and the word "policy" will not show up anywhere. No one is advocating
> overriding any policy. But the text said SHOULD. Some want MUST. So, keeping
> in mind the difference between mandating implementation support versus
> mandating use, what should it be? SHOULD or MUST? Is there a reason not to
> support this capability (again, keeping in mind the difference between
> mandating implementation support versus mandating use)?
> 
>   Dan.

Maybe part of the problem in this debate is related to another word that
keeps cropping up, i.e. "mandate".  I have a Webster in hand that lists
the first definition for mandate as "1. an authoritative order or
command, especially a written one". This has been part of what I viewed
as problematic with this argument all along.

In most cases, the appropriate behavior is specified by the policy we
already support, and is permitted via the use of multiple proposals,
e.g. (dh-1 OR dh-2 OR dh-5). The problem seems to be only with certain
algorithms which permit variable key lengths (blowfish keeps coming up),
and I have come around to agreeing that this case is not so
cut-and-dried. Some have suggested a policy capability for specifying
"accept keylength >= x", and this seems sensible, since the alternative
is exhaustive enumeration in the proposals, which *I* sure don't want to
parse. I think the point here is that we need a way to specify ranges
somehow, i.e. up to x, x only, a <= x <= b, etc. 

I guess my bottom line is showing again: the admin needs to be able to
control the behavior such that discovery of a weakness only requires
reconfiguration, not an IKE patch, and such that if they want to limit
strength for whatever reason, they can. It seems to me that this could
be accomplished if there were key length attributes of some sort which
allowed us to express such key length ranges in our proposals. Then, we
could require as part of the spec that implementations support these
attributes, subject of course to local policy.

Scott


Follow-Ups: References: