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

Re: Comments on draft-ietf-ipsec-ike-01.txt

Hi Dan,

Dan Harkins wrote:
> 
>   I guess it would. But that's not what I'm talking about. The text
> addresses attributes whose values can be of variable length. So that's
> Blowfish's key length, Hasty Pudding's block length, or Diffie-Hellman
> groups of the same type. DES vs. 3DES or SHA vs. MD5 or some distinct
> invariate algorithm vs. some another distinct invariate algorithm is not
> what is being discussed.
> 

I guess I don't see the difference (for purposes of this discussion)
between increasing from DES to 3DES, and doubling Blowfish's keylength,
and increasing the DH modulus length. Either way, I think it's a local
policy matter, and should not be legislated in any way by this document.
I think that if you must say anything at all, then MAY is the
appropriate qualifier.

>   The only reasons presented on why someone would not want to negotiate
> up are for performance- or memory-constrained implementations. And that's
> a perfectly legititmate reason why not to. And that seems to be fine
> with a SHOULD. You should increase security if possible unless you have
> a good reason why and you fully understand the implications of not doing
> so. That's a good reason why not to and the understanding seems to be
> there.
> 

The text says

   Certain negotiable attributes have ranges or multiple acceptable
   values.  For instance, if the policy specification on a peer mandates
   group 2 but is offered group 5, as part of an otherwise acceptable
   protection suite, the peer SHOULD accept that value as it provides
   more security than demanded.

<trimmed...>

I think that if the policy specification on a peer MANDATES group 2, the
peer MUST NOT accept any other value.


                           ...SA lifetimes pose similar issues.  If a
   peer has a local policy which requires SAs live for no more than 2
   hours and is offered a protection suite which contains a lifetime
   value of 1 hour, the peer SHOULD accept that value as it provides
   less opportunity for key exposure.

<trimmed...>

I agree that lifetimes are a different case, in that either peer may
terminate the SA in their own time, so that the one with the lower
lifetime is in an equivalent state if he permits the SA with the other
side asking for a larger lifetime. That is, the one with the lower
lifetime simply terminates when appropriate, according to local policy.

More text from the same stretch:

   It is therefore possible to be in a situation where Alice can
   successfully initiate an IKE exchange with Bob but not the other way
   around. A simple way around this situation is to not enforce local
   policy and accept any lifetime offered or any group offered.  This
   behavior is strongly discouraged; implementations SHOULD NOT ignore
   local policy. If an implementation accepts a protection suite all
   values of that protection suite MUST be honored-- in other words,
   implementations MUST NOT ignore lifetime or Diffie-Hellman group
   offers and just "do their own thing".

SHOULD NOT ignore local policy? I'm really surprised by this text. Maybe
I'm misinterpreting, and if so, I'm sure you'll correct me, but when is
it *ever* okay to ignore local policy? If we say anything at all about
this, shouldn't it be that an IKE implementation MUST NOT ignore local
policy under any circumstances?

Scott
Follow-Ups: References: