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

Comments on Section 3.1 of new IKE draft

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

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.

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?

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.
Follow-Ups: