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

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

> > 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.
> 
> I guess I don't see how your bottom line is effected then since we're
> not talking about mandating use. "require...that 
> implementations support
> these attributes subject...to local policy"? We're not talking about
> imposing a mandate on end users or on their policy, we're 
> talking about
> imposing a mandate on implementors. 
> 
> This idea of a cipher becoming "weak" with longer keys is bizarre. Any
> cipher which supports a variable-length key that becomes weaker as the
> key becomes longer is a cipher with a fundamental problem and 
> it should
> not be used period. There are always ridiculous, hypothetical, and 
> unrealistic edge conditions (and a fictitious and fatally 
> flawed cipher 
> which some admin insists on using is a prime example) but focusing on
> them only confounds the issue. The issue at hand is whether to impose
> a requirement on implementations to support negotiating up certain
> attributes. It is not (and let me say again, IT IS NOT!) whether end
> users must configure their boxes to do so. 
> 
>   Dan.

I think there is agreement that it is generally a good idea to negotiate up
(though why would anyone specify shorter keys if there is no downside to
specifying longer in the first place?).  My only concern is that it
increases the asymmetry of IKE.

I think the disagreement is on whether it should be part of 'IKE' or
'Security Policy', where the latter is seen as something different to
former.

IKE specifies that you can only accept one of the proposed SAs unchanged.
It is down to local security policy to decide which, if any, should be
accepted.  Thus this issue is the domain of the Security policy rather than
IKE.  

The contra-view to your own is that security policy should be sufficiently
expressive to allow the specification of both fixed values or ranges for key
length.  This would allow policy specification to be stated explicitly
rather than being implicit in the IKE implementation (which may vary from
implementor to implementor).

Chris