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

Re: Comments on Section 3.1 of new IKE draft

On Thu, 03 Jun 1999 08:39:47 EDT you wrote
> 1. Section 3.1 says
> 
>      In addition, optional attributes may be negotiated. These
>      include a lifetime and a pseudo-random function ("prf").
> 
> Something is wrong here, since the section is called "Mandatory
> Options." It is not clear here whether the intent is that it is
> optional to negotiate these items but that all implementations MUST be
> able to negotiate them, or whether the options truely are optional and
> an implementation is not conformant if it REQUIREs the peer to
> negotiate them. (I know "the answer" from the good ol' boy network, but
> the good ol' boy network is not part of the spec.)

The good ol' boy network? Is this the same group that said it was OK
to send a message ID in a payload field labeled "SPI"?

You don't like "Mandatory Option"? Fine. What do you like? Perhaps you
can consult with that gaggle of gregarious geriatrics and get back
to us? What is "the answer"?

> 2. Section 3.1. continues:
> 
>      In addition IKE implementations SHOULD support the following
>      values:
>      - CAST in CBC mode and Blowfish in CBC mode for encryption
>      algorithm.
>      - Tiger ([Tiger]) for hash algorithm.
>      - Authentication using RSA and DSA signatures, and using RSA
>      and El-Gamal public key encryption.
>      - Groups 3 through 5 for Diffie-Hellman group.
> 
> Charles Kunsinger already made the point that most of these have not
> been discussed on the list, and it is not self-evident whether any of
> these algorithms really rate a SHOULD. Without clear guidelines on when
> and why to use each of these algorithms, arbitrarily adding SHOULDs
> also arbitrarily decreases the overall managability of IKE
> implementations and and increases its overall complexity. Both of these
> decreases the overall security IKE affords. Decreasing managability
> decreases security because it adds more training and configuration cost,
> so increases the the number of places where an IPSec solution won't be
> deployed at all.  Increasing complexity decreases security,
> because it becomes harder to verify our own implementations are bug
> free with regard to security issues. All of these need to be MAYs unless
> we can provide operational guidance for them.

I asked Charles Kunzinger so I'll ask you: do you have a problem with
El-Gamal?

"most of these"? If you actually read RFC2409 you'd see that Blowfish,
Tiger, RSA signatures, DSA signatures, and RSA encryption, and groups
3 and 4 are all there. The only new ones are El-Gamal encryption and
group 5. If you bothered to look at the archives of this list or listened
at IETF meetings you'd have heard a discussion of group 5. So the only
new one is El-Gamal. That's 1 out of 9. Hardly "most".

I'm going to add RIPE-MD in the next iteration. Do you have a problem
with that?

It wasn't discussed on the list? OK, fine. Start a discussion then.
Raise some points.

You want clear guidelines? Would you like me to include a large paragraph 
discussing the pros and cons of El-Gamal and RSA? When it's better to use 
CAST or Blowfish? That kind of hand-holding is wholly unsuitable for a 
document like IKE.

How is the security of IKE decreased by the inclusion of another optional
authentication method? Do you know some flaw in El-Gamal? If you don't
want to include this authentication method and therefore a knob to 
allow it then don't; it's not required. What is the problem? The managability
of your implementation is not effected unless you implement this. 

> 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?

> 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?

  Dan.
References: