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

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

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

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

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

  The reaction to IKE is curious. Some people feel that every possible
behavior must be explicitly spelled out. Remember the debate about the
vendor ID payload? Some people said, "should I drop a connection because
I don't recognize the peer's vendor ID payload? The correct behavior
is not described in the RFC." Other people think that if it isn't prohibited
then it's allowed. Like the vendor that was passing a message ID in the
SPI field of a notify payload. I kinda thought that the SPI field was for
SPIs but since it's not explicitly prohibited then this vendor thought
it was OK.

  In attempting to satisfy both camps-- some want the freedom to cross the
street by themselves, others want an escort-- I added text to allow what
seems like perfectly common sense behavior.

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

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

  Dan.

On Wed, 02 Jun 1999 13:30:33 EDT you wrote
> Some comments triggered by what Tim said:
> 
> In a sense the discussion about how to handle "stronger" proposals is
> innocuous since it contains the word "SHOULD".  On the other hand, it
> still implies that something is recommended and encouraged when it
> isn't necessarily a good thing for some implementations.  Shawn Mamros 
> raised the good point of performance:  if local policy is to use group 
> 1 and group 5 is proposed, should it be accepted?  Or 3DES in place of 
> DES?  Extra security is not free.  Saying an implementation MAY do
> this is fine, but saying SHOULD may not be.
> 
> It isn't clear from the text that it is only talking about parameters
> of a single system.  For example, while it's clear that group 2 is
> stronger than group 1, it isn't clear whether how groups 2 and 3
> compare.  (Safest decision would be that they do not, so if I want 2
> and 3 is proposed, I'll reject.)
> 
> By the way, in his comments Tim referred to "2DES" (meaning "two key
> triple DES").  Currently that's not allowed for; it would be useful to 
> have that option given that some countries give special treatment to
> below-128 bit ciphers but not to 168 bit ciphers.  (Yes, I know from a 
> practical point of view the difference in strength is not particularly 
> interesting, but it's easier to add an option to a protocol spec than
> to change a government regulation.)
> 
> On the subject of lifetime negotiation, I agree with Tim.  That case
> is clearly different from the others in that each side can enforce a
> lifetime on its own.  If I need a 1 hour lifetime, I should obviously
> propose that if initiating, but there is nothing that prevents me from 
> deleting SAs after 1 hour even if 2 hours were negotiated.  Since you
> can get the desired effect (lifetime limit) unilaterally, I see no
> reason to refuse such a proposal.  It's fine to allow it to be
> rejected, but the draft *requires* it to be rejected and that's going
> too far.
> 
> 	paul
Follow-Ups: References: