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

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

I may be misunderstanding what is being decided here, but as I see it,
there is two possible interpretations of the "Must" clause.

1) Implementation must support negotiating up key lengths depending on
   policy configuration.

2) Implementation must always negotiate up key lengths when possible 
   regardless of policy configuration.

If the consensus is that "Must" is option 1, I have no problem with "Must".
However, I don't like option 2 at all...

> Luckily the IETF has a standing policy to ignore local (political)
> issues (such as key length restrictions) during the standards process.
> The fact that some of us live in less-free countries does not mean
> that the standard cannot require us to create something that might be
> illegal to use in (or export from) our own country.  This means we
> can reasonably ignore political issues when answering these technical
> questions.
> 
> So, the question is:  TECHNICALLY, is there any reason not to use
> 'must' in this case?

Depends on what you mean by TECHNICALLY,  I don't feel that this is a 
technical question at all, rather it's a question of policy flexibility.
We are making a decision on artificially limiting policy flexability because
we feel stronger crypto is always better.

Where are we going to draw the line?  If an implementation supports a
variety of encryption and authentication algorithms, are we going to require
that IKE negotiate the best combination of security and resource consumption
regardless of local policy?

What if (as Scott has suggested) a discovery is made that demonstrates an
algorithmic weakness with certain key lengths, are going to preclude the 
administrator from configuring a secure VPN until such time as we the vendors
can come up with a patch?

In the end, I will allow the adminstrator to allow or disallow upward
negotiation regardless of the standard. Similar to the way we allow
administrators to not configure DES depending on policy (even though it's 
a Must). I prefer that we keep the control of policy in the hands 
of our customers rather having to explain why they can't.

Regards,
Michael Carney
> 
> -derek
> 
> Paul Koning <pkoning@xedia.com> writes:
> 
> > As you well know, some of us (fortunately not you) have to deal with
> > government restrictions on key length.  That means that a particular
> > product may be required to reject (for example) RC4 keys longer than
> > 56 bits even though longer keys require no more processing.  The
> > reason is not technical but political.
> > 
> > Similarly, in other countries a customer may be prohibited from using
> > keys longer than, say, 128 bits, so again the implementation would
> > have to reject your hypothentical proposal of a 448 bit key.
> > 
> > So while I'm comfortable with "should", I cannot accept "must".
> > 
> > 	paul
> 
> -- 
>        Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
>        Member, MIT Student Information Processing Board  (SIPB)
>        URL: http://web.mit.edu/warlord/      PP-ASEL      N1NWH
>        warlord@MIT.EDU                        PGP key available
References: