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

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

Paul Koning wrote:
> 
> >>>>> "Dan" == Dan Harkins <dharkins@network-alchemy.com> writes:
> 
>  Dan> I guess it would. But that's not what I'm talking about. The
>  Dan> text addresses attributes whose values can be of variable
>  Dan> length. So that's Blowfish's key length, Hasty Pudding's block
>  Dan> length, or Diffie-Hellman groups of the same type. DES vs. 3DES
>  Dan> or SHA vs. MD5 or some distinct invariate algorithm vs. some
>  Dan> another distinct invariate algorithm is not what is being
>  Dan> discussed.
> 
> Hm, I had thought of DES and 3DES to be key-length variants.  That's
> not literally true of course, but close.
> 
> So I would think that the same action (i.e., "negotiate up") should be
> allowed in that case.  I assume you didn't mean to exclude it; if you
> don't want to recommend it as much as you're doing for Blowfish etc.,
> that's fine.
> 

I should add at this point that I didn't mean to imply that we shouldn't
*allow* such behavior. What I meant to say was that we should not give
the impression that an implementation SHOULD violate policy, and that
I'm not even sure this discussion should be in the doc. Regarding the
case where Dan suggested that Alice could succeed if initiating with Bob
but not vice versa, I would suggest that this is only because you permit
this negotiating up, when in fact, their policies do not intersect. I
whole-heartedly agree that this is a maddening consequence of the
complexity of all this security business, but still do not think we
should RECOMMEND (the RFC2119 equivalent to SHOULD) that it be
circumvented.

What we are discussing here is local policy. If it seems too complex,
this really is an implementation issue. To resolve this, my default
configuration in "expert" mode might permit "DH group x or stronger"
with priority ordering implied, and it might support a little checkbox
which means ONLY x (or something). In any event, I think we've missed
the point entirely, that being that it is not up to IKE to decide.

IKE is implemented in an application - a service provider for the ipsec
core. As such, IKE should not be making any sort of policy decisions.
Rather, the kernel (or whatever component) should be requesting that IKE
negotiate the SA within a given set of parameters. If the requester
specifies DH-2 alone, and no other DH group, then IKE should provide
that and that alone, failing if it cannot.

I'm surprised this discussion is even occurring. Am I missing something
obvious here? 

Scott
Follow-Ups: References: