[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Comments on draft-ietf-ipsec-ike-01.txt (long)
I would like to see the following:
For any symmetric ciphers where there is negligible differences in memory
consumption and performance overhead between key lengths, the ID/RFC that
explains how the cipher is negotiated via IKE (transform ID, etc) MUST state
that only the maximum key length is used (no key length attribute).
If this was the case, "negotiating up" for these ciphers would no longer be
an issue.
For security attributes that have performance/security tradeoffs, security
gateway administrators will most likely want the policy that they configure
to be enforced (hypothetically - they wouldn't want a policy that says PFS
off being "negotiated up" to 2048-bit DH for 1000 simultaneous SA
negotiations). If an administrator wants to allow "negotiation up" he would
configure it that way and all combinations for a security attribute of value
X and greater would be offered and allowed (but then that wouldn't be
"negotiate up").
-dave
> -----Original Message-----
> From: Paul Koning [SMTP:pkoning@xedia.com]
> Sent: Thursday, June 10, 1999 10:24 AM
> To: ipsec@lists.tislabs.com
> Subject: RE: Comments on draft-ietf-ipsec-ike-01.txt (long)
>
> >>>>> "Heyman," == Heyman, Michael <Michael_Heyman@nai.com> writes:
>
> Heyman,> Hmmm, this means if a policy _explicitly_ states 128 bit
> Heyman,> encryption (note, the policy _did not_ state 128 bit
> Heyman,> encryption or greater), then IKE has the right to change the
> Heyman,> policy to be 128 bit or greater?
>
> Heyman,> IMHO, IKE must act dumb when it comes to policy and must not
> Heyman,> assume it knows better then whatever set that policy....
>
> I think this is the right approach. Rather than add ways for IKE to
> do things not stated in the policy, let's have recommendations about
> what the policies should be able to express. That's a better solution
> because it satiesfies the "principle of least astonishment".
>
> In other words,
> a. IKE should negotiate exactly according to the policy it has been
> given.
> b. Implementation should be encouraged to implement policies of the
> form "accept exactly X" as well as "accept X or stronger". The spec
> should give some examples of what "X or stronger" means.
>
> I believe this should satisfy both sides, because it allows and
> encourages negotiating up, without allowing negotiating up when it
> goes against the expressed policies.
>
> paul
Follow-Ups: