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

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



>>>>> "Dan" == Dan Harkins <dharkins@Network-Alchemy.COM> writes:

 Dan> The text specifically discusses "certain negotiable attributes
 Dan> [that] have ranges or multiple acceptable values." It's not
 Dan> discussing the relative strengths of different algorithms.

I realize that.  The key length case is clear.  The group number case
could be misinterpreted as a comparison among algorithms, since some
groups are MODP and some are elliptic curve.  The example is fine, but 
you might want to clarify that it doesn't apply to, say, a local
policy for group 2 and a proposal of group 3.

 Dan> Let me try a different tact: Does anyone think that an
 Dan> implementation should never accept an offer which contains a
 Dan> variable-length encryption algorithm which includes a key length
 Dan> greater than what it would have offered had it inititated? I'm
 Dan> assuming the answer is no. So I'm trying to note that such
 Dan> behavior is acceptable.

Sounds good to me.

 Dan> You don't see a reason to refuse a lifetime offer of 2 hours if
 Dan> you're locally configured for 1 hour? Do you think that all
 Dan> vendors MUST accept any lifetime then? Your behavior is not
 Dan> prohibited, just that it is also not mandatory.

Yes to the former, no to the latter.  But I see no reason to give
second-class status to the former, which "should" is doing.

 Dan> ...
 Dan> Regarding lifetimes, if the text in this draft is not acceptable
 Dan> than what about the text in section 4.5.4 of RFC2407? Don't
 Dan> people have a problem with option 1?

Yes.  Which was the point, because it seems that the draft is
recommending option 1 ("...that offer SHOULD be refused as it violates
the local policy" -- top of page 8).  Contrast that with 4.5.4 of
RFC2047, which lists the 3 alternatives as equally acceptable.

 Dan> So let me ask the entire working group: should vendors be
 Dan> prohibited from accepting a key length greater than what they
 Dan> have configured? Should they be prohibited from accepting a
 Dan> stronger group?

Was that ever a proposal?  I don't remember that it was.  I don't
remember any comments saying it should be.

	paul


Follow-Ups: References: