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

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

  That text is going to be re-written along the lines of what I said
in <199906030424.VAA04924@potassium.network-alchemy.com> on the 2nd
of June.

  I'm sorry you don't see a difference between the two. You probably
won't get much argument about DES vs. 3DES but when comparing two 
different encryption algorithms the comparison is not quite as
straightforward as increasing the key length of a variable key cipher.
Those are quite different. It seems quite obvious to me and also to
several people I talked to that negotiating up an attribute whose
value can be a range (as opposed to attributes like encryption algorithm
which are decidedly NOT ranges) is the wise thing to do. 

  If you want to make a box that accepts 3DES when configured for DES
or SHA when configured for MD5 then knock yourself out. It's just
that that is not going to be in the draft and I don't see a point
in having a discussion along those lines. 

  This is not legislation. It is a statement of what a common sense
negotiation technique should be. You think MAY is appropriate? What's
wrong with SHOULD? Negotiating up the key length, block size, # of rounds, 
and Diffie-Hellman group will make you 1) more secure and 2) more 
interoperable in more situations. Is that not a good thing? I'd say it 
should be a MUST except that there are some valid situations-- a memory- or 
performance-challenged box for instance-- where one might not want to do 
that. You're free to not do this if you fully understand the implications
of what you're doing (namely, that you're throwing away a chance to use
stronger crypto and possibly refusing to interoperate with people) but 
in general this is the behavior that SHOULD be done. Mandating that group
2 and group 2 only be negotiated is stupid. We can't bar stupidity but 
we can say that if you choose to do something stupid you should know 
the full ramifications of your stupidity.

  As far as SHOULD NOT ignore local policy, I wrote that because there
are lots and lots of implementations that do and I knew I'd get heat
if I unilaterally declared them uncompliant. There are lots of people
who just ignore what the locally configured lifetime is and do their
own thing. That seems very wrong to me but my sense of right and wrong
and what is common sense and what is not is obviously not shared by
all so I decided SHOULD NOT. But, as I said in the beginning of this
email, that text is being rewritten.

  Dan.

On Fri, 04 Jun 1999 10:22:04 PDT you wrote
> 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
References: