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

Re: Comments on Section 3.1 of new IKE draft



Dan:

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

I was requesting that text be added to the specification describing
in what sense the options are optional. The text would go something like
"If an implementation does not offer lifetime and pseudo-random function
in its proposal, then..."

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

Whether or not Charles or I or anyone else has a problem with El-Gamal
is not what is at issue here. The issue is what is the criteria by which
we decide on MAY, SHOULD, or MUST.

>"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.

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




Follow-Ups: