[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Comments on draft-ietf-ipsec-ike-01.txt (long)
Hi Dan,
As a preliminary, I should say that I'm assuming that you now agree that
the language in question must not apply to DH groups, ciphers (DES vs
3DES), MAC algorithms, etc, and that we are only discussing the case
where a symmetric cipher has a variable key length. If that assumption
is incorrect, please say so.
Lots trimmed where context is not lost...
Dan Harkins wrote:
> Look, we "mandate" support for manually keyed IPSec SAs. That doesn't mean
> that every single IPSec SA must've been manually created. Implementations
> are free to use key exchange protocols to dynamically establish SAs. Can't
> you see the difference between mandating support and mandating use?
After re-reading my text and yours, I see that I muddled the issue. I
was only referring to the earlier text (which you plan to change), so
let's put this behind us and move on - my mistake.
> > 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.
More on this below...
> 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.
I'm not a cryptographer (yet), and I assume you're not (yet) either. Let
me know if this is an incorrect assumption. If I am correct, then we are
both making assumptions regarding what could happen when key lengths are
changed. That is, the idea of a weakness in a cipher at a certain key
length may or may not be bizarre, and I guess we should ask the
cryptographers. If it *is* a possibility, then we should allow that it
is inappropriate for IKE to automatically accept larger key lengths. My
intuitive feeling is that such behavior is incorrect in any event, but I
am willing to suspend judgement for the moment.
Even if we discover that this is not bizzare, and that such behavior is
possible, we can still support the ability to negotiate up by simply
adding a few other key length attributes. We currently support key
rounds, key length, etc. We could add minimum key length and maximum
key length attributes, with the following understanding:
- the presence of only the key length attribute means "this length and
this length only"
- the presence of the minimum key length attribute alone means "at least
this large, but larger is okay"
- the presence of the minimum key length attribute along with the
maximum key length attribute means min <= key length <= max, i.e. any
key length within the range.
- the presence of the key length attribute together with either or both
of the others is an error
While this adds a small amount of complexity to the attributes, it
leaves the responsibility for the decision with the admin.
Scott
References: