[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Comments on Section 3.1 of new IKE draft
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
IKE is not a world unto itself. IKE needs to operate as a member of
a grand unified international security infrastructure. The
"deployment" of IKE today is miniscule compared to what it will be in
the future. Every other security working group (as far as I can
recall...) has specified unpatented algorithms like DSA and ElGamal
as their MUST algorithms with RSA left in the MAY or SHOULD category.
Requiring an algorithm like RSA specifically *prohibits* the
creation of any free product based on IPSec/IKE that is in compliance
with the old draft. The many other working groups have shown the way
out of this mess, and I applaud this working group for moving forward
to encourage the use of unpatented algorithms as well, thus enabling
classes of products for this technology which were previously
impossible. IKE needs to be a part of the overall infrastructure
created by the other working groups.
I would be in favor of moving RSA to MAY with ElGamal in SHOULD, but
I think the current draft reflects a sound melding of requirements
and SHOULDs based on IKE's current deployment and the need for
unpatented algorithms.
In addition, it is *always* a good idea to have a backup algorithm.
The encryption modes were previously so tied to RSA that most people
just called them the RSA encryption modes. Now IKE has a good
balance where encryption can be accomplished with ElGamal or RSA,
signing with DSA or RSA, hashing with Tiger or SHA-1, and encryption
with CAST or 3DES.
I'd really like a 2048 bit MODP group now... ;-)
- -Will
Jesse Walker wrote:
> Before we had any deployment experience with IKE, I didn't have
> any problem with loading IKE with a full set of crypto algorithms
> as MUSTs or SHOULDs. As we gained deployment experience, I have
> changed my mind. Less seems to be more. People trying to deploy
> IKE seem overwhelmed and confused by the number of choices
> presented to them; and every deployment I know of falls back to
> 3DES and RSA signatures or shared secrets, because the
> administrators can't make sense of much else. I have seen (many)
> more than one potential customer throw up their hands and complain
> they won't deploy anyone's IPSec, because it is just too
> (many explitives deleted) complicated. This is just my experience
> for what that's worth--it may not be shared by anyone else--but I
> do get the same impression from talking with other implementors
> and from the trade press.
>
> Because of this experience, I've migrated to the belief that we
> should not add any more MUSTs or SHOULDs without first holding a
> discussion articulating just what problems we think a new algorithm
> would solve that is not already solved by the mandatory algorithms;
> otherwise, they become gratuitous implementation overhead at best
> but more likely a barrier to a successful IKE deployment. For the
> same reason, I also believe that it is even worth considering to
> change many of the SHOULDs to MAYs as the document moves forward.
> ElGamal is a wonderful crypto algorithm and fully worthy of our
> endorsement via a MAY. The issue is why we should grant it any
> greater status.
>
> >> 3. One issue Section 3.1 raises by omission is the subject of
> >> default values for each of the options. We've talked about and
> >> rejected defaults before. I'm wondering whether we have made an
> >> error in our collective judgement and we need to do something
> >> here. There are three ways in which defaults might help:
> >>
> >> a. improve out-of-the-box interoperability;
> >>
> >> b. experience shows it is usually easier to move from a known
> >> working configuration to another working configuration than to
> >> build a new configuration from scratch;
> >>
> >> c. experience shows it is can be much easier to debug problems
> >> by moving to a known working configuration, trouble-shooting
> >> there, and then applying (b), than to trouble-shoot an arbitrary
> >> configuration.
> >>
> >> Even if this reasoning is correct, the IKE specification may not
> >> be the right place to document the defaults. We have rejected
> >> defaults before because it is never clear that good defaults
> >> today will be good ones tomorrow. Maybe we need a separate
> >> document a la the "profiles" or implementers' agreement from the
> >> ISO days. The profile document would have a prescribed finite
> >> lifetime, just like DES or IETF drafts, to account for the fact
> >> that security requirements change?
> >
> > When were defaults rejected by this working group? We agreed that
> > DES, SHA & MD5, group 1, and pre-shared keys were the the
> mandatory-to-implement
> > options. We decided this a long time ago. Deep Crack has made the
> > use of DES very questionable so I changed DES to 3DES and,
> > correspondingly,
> group
> > 1 to 2. What is wrong with that?
>
> Yeah, this was probably the wrong point to bring up this issue,
> because the spec does a good job in the options arena. I will raise
> it again in comments on other sections of the draft.
>
> >> Profiles could help in a lot more areas than just defaults. From
> >> the bake-offs we know that having well-defined profiles speeds
> >> configuration in general.
> >
> >Are you happy with the mandatory-to-implement IPSec transforms but
> >unhappy with the mandatory-to-implement attributes in IKE?
> >
> >You don't like the term "Mandatory Option" yet you fail to suggest
> >any alternative and allude to some nebulous group of people who
> >know "the answer". You seem to have some problem with El-Gamal yet
> >you don't say what it is. What is this unconstructive criticism
> >supposed to accomplish?
>
> -- Jesse
- --
Will Price, Architect/Sr. Mgr., PGP Client Products
Total Network Security Division
Network Associates, Inc.
-----BEGIN PGP SIGNATURE-----
Version: PGP 6.5
iQA/AwUBN1gUs6y7FkvPc+xMEQL/jQCgpizdP/49InJFxMDZV18Z5bd9qwgAoIQg
TlndwGgTzYIjnUCQ+tewcyew
=+Jho
-----END PGP SIGNATURE-----
References: