Subject: Re: suites vs. a la carte and IPcomp in IKEv2-05

From: Paul Koning <[email-masked]>
Date: Sat, 1 Mar 2003 20:42:39 -0500

>>>>> "Abraham" == Abraham Shacham <[email-masked]> writes:

 Abraham> Paul Koning wrote:
 >> IKEv1 handled this by negotiation, but 90% of what it does for
 >> IPcomp is unnecessary and confusing.

 Abraham> Could you substantiate "90%", detail what is exactly
 Abraham> "unnecessary", and "confusing" to whom?

We discussed that a while back, and Henry Spencer just summarized it
very nicely.  As for "confusing" -- to the implementer of IKEv1.

     paul

---

From: "Jayant Shukla" <[email-masked]>
Date: Sat, 1 Mar 2003 20:37:22 -0800

> -----Original Message-----
> From: [email-masked]
[mailto:[email-masked]]
> On Behalf Of Andrew Krywaniuk
> Sent: Friday, February 28, 2003 3:33 PM
> To: [email-masked]
> Subject: Re: suites vs. a la carte and IPcomp in IKEv2-05
> 
> 
> >I think the best way to accomodate this disconnect is with the
> >"gui suites" proposal -- on the wire, send a la carte parameters, but
> >require only the suite combinations to be supported through the
> >management interfaces.
> 
> My sentiments exactly.
> 

I am sure if I completely understood you, but you are proposing GUI
suites, but require one or more a la carte proposals to be supported? In
that case I would agree with you.

Speaking as someone whose product has a GUI to build proposals! We had
trouble in interop testing with a third party VPN hardware box because
our proposals did not match the only proposal that device would accept.
The GUI helps in building proposals easily, but if the proposal does not
exactly match what the other side would accept, you got problems.

I almost put in a method to analyze received proposals to see if they
could be generated by our GUI.

Cipher suites are important if you want security according to your
needs/requirements and a la carte proposals are important for interop.

Regards,
Jayant
www.trlokom.com 

> Andrew
> --------------------------------------
> The odd thing about fairness is when
> we strive so hard to be equitable
> that we forget to be correct.
> 
> 
> 
> 
> _________________________________________________________________
> Add photos to your messages with MSN 8. Get 2 months FREE*.
> http://join.msn.com/?page=features/featuredemail

---

From: Derek Atkins <[email-masked]>
Date: 03 Mar 2003 11:39:43 -0500

Hugo, thanks for correcting me..

To everyone else: I mistakenly asserting a position of Hugo.
Below is his ACTUAL opinion on the topic.

-derek

Hugo Krawczyk <[email-masked]> writes:

> You may want to send to the list the
> clarification below as I sent to you. At least it will document my real
> opinion before people start attributing to me something I disagree
> with.
> 
> 
> > Hugo Krawczyk <[email-masked]> writes:
> > 
> > > On 28 Feb 2003, Derek Atkins wrote:
> > > 
> > > > Perhaps some people's comments jumbled together after reading through
> > > > 2000+ messages.  I seem to recall that you had an issue with choosing
> > > > algorithms a la carte due to the lack of security proof of arbitrary
> > > > combinations of various algorithms.
> > > 
> > > This was not (and is not) my opinion.
> > > Actually one of the main criteria I use in designing crypto protocols is
> > > that their security will not depend on specific functions but rather on
> > > general functionalities (or "primitives", as we usally call these in
> > > cryptography). Therefore if the protocol uses a prf, a MAC and 
> > > encryption, then ANY secure implementations of these functions will do.
> > > No need to check the specific inter-relations. Those are taken care
> > > already in the protocol analysis. In particular this is the case for the
> > > IKE's design.
> > > 
> > > Hugo

-- 
       Derek Atkins
       Computer and Internet Security Consultant
       [email-masked]             www.ihtfp.com