Subject: Re: Results of protocol straw poll

From: "Darren Dukes" <[email-masked]>
Date: Fri, 4 May 2001 14:01:25 -0400

Below is a review of who voted for what and why (those posted to the list at
least).  Hopefully this will clear up some of the questions of intent.

Note
 -  5 of 6 No New Protocol votes were for Hybrid or Crack.
 -  one PIC vote would rather see us start all over again.
 -  All "Either" votes were for GETCERT or PIC
 -  Three No New Protocol voters prefers PIC over GETCERT

I agree with Paul that there appears to be narrow agreement on PIC, although
I would prefer a solution that was a lot less complex.  Speculating further,
if the "don't add to IKE" rule didn't exist I think Hybrid or Crack would
have been chosen long ago and this group would be done.  Oh well can't
change that, enjoy.

GetCert - 3
~~~~~~~
Bernard Aboba - V2
Marcus Leech - V2
Tero Kivinen - getcert.

PIC- 5
~~~
Steve Robinson - PIC, but doesn't like either (doesn't like extra server).
Rather see "start from scratch" option.
Sankar Ramamoorthi - Better code reuse.
Scott G. Kelly -No Comment
Ari Huttunen - PIC has a better chance of quickly replacing XAuth and
Hybrid.
Peter Maricle - PIC

Either PIC or GETCERT - 3
~~~~~~~~~~~~~~~~~~~~~
Ricky Charlet - Votes for Leader, tie goes to PIC.
Richard Welty - Agrees with Ricky, votes for leader.
Bill Sommerfeld - Either Getcert or PIC.

No New Protocol - 6
~~~~~~~~~~~~~~
Stephane Beaulieu - Prefer Hybrid or Crack, PIC/GETCERT too tough to
implement
Scott Fanning - L2TP Hybrid or Crack can solve this.
Will Price - Replies to Scott Fanning, agrees that solutions already exist.
Uri Blumenthal - Prefers CRACK
David Mason - Prefers "that-whick-must-not-be-named" [XAUTH?] but PIC if
that won't happen.
Andrew Krywaniuk - Prefers (in order) Hybrid, Crack, PIC, Getcert
Yuri Poeluev - PIC/GETCERT limited on small devices, prefers PIC if No New
Protocol is not accepted.

Yet more details - Full Replies
*****************
Bernard Aboba
>GetCert v2 (the new and improved version)
*****************
Steve Robinson
>PIC
>
>It is a simpler solution, and IP Security is complex enough as it is.  But
to
>be honest, I don't like PIC because I don't want to be dependent on a
server
>outside of the scope of my security software on the host machine (this was
the
>reason I voted for GetCert the first time).   I feel like I'm trying to
choose
>the lesser of two evils here -- if we had a fourth option "try again from
>scratch"  I'd vote for it over "no new protocol" even though I don't have a
>better idea to present at this time.
***************
Stephane Beaulieu
> No new protocol.
>
> Reason: I'd prefer something that's easier to implement, and (more
> importantly) easy to deploy.  If Hybrid or CRACK were candidates, I'd vote
> for them.
***************
Scott Fanning
>No new protocol.
>
>Between L2TP, Hybrid, CRACK and the other "unnamed" methods, I think we
>can solve this problem.
****************
Will Price
> No new protocol.
>
> Agreed that adequate solutions to this problem set already exist.
***************
Uri Blumenthal
> I prefer CRACK.
***************
David Mason
>No new protocol.
>
>For now I prefer that-which-must-not-be-named.  Barring that I'd vote for
>PIC.
***************
Andrew Krywanuik
>In order of preference:
>
>1. Hybrid
>2. Crack
>3. PIC
>4. GetCert
>
>Justification:
>
>- PIC/GetCert address what I believe to be non-existant flaws in the
>Hybrid/Crack approach.
>
>- Hybrid and Crack are functionally equivalent, however Hybrid reuses code
>that many IPsec implementers already have.
>
>- PIC and GetCert are functionally similar, however I believe that PIC will
>integrate into existing gateways better.
****************
Ricky Charlet
>Howdy,
>
>Count my vote with the leader, wether it is PIC or getCert (in case of
>a tie I vote for PIC).
*****************
Sankar Ramamoorthi
>PIC
>Better code reusability.
*****************
Richard Welty
>i agree; this requires a sensible resolution.
>PIC or Getcert, whichever is leading the vote.
*****************
Bill Sommerfeld
> either getcert or pic
*****************
Peter Maricle
>PIC
>For reasons others have already pointed out.
*****************
Scott G. Kelly
> PIC
*****************
Ari Huttunen
>PIC
>I think PIC has a better chance of quickly replacing X-Auth and Hybrid.
*****************
Yuri Poeluev
>No new protocol" - is the first choice
>    When running IKE on small constrained devices "PIC"/"GetCert"
>    introduces a potential problem due to code size, OS limitations,
>    and other similar constraints.
>
>"PIC" - is the second preferred choice, but *only if the first one is not
accepted*
>    By choosing it there is a possibility of reusing ISAKMP code from IKE
>    implementation. Again it's an issue for the constrained devices.
************
Tero Kivinen
>getcert
************
Marcus Leech
>getcert2

---

From: "Mason, David" <[email-masked]>
Date: Mon, 7 May 2001 07:25:16 -0700

The purpose of IKE is to provide internet authentication and key exchange.
I never understood why support for remote access requirements should be
excluded from it.  Fulfilling remote access requirements adds complexity.
What's the logic behind dividing that support (and complexity) between four
entities (IKE, legacy system, CA, and new protocol) being more secure than
doing it between three entities (IKE, legacy system, and CA)?

It's ironic that the first two paragraphs of section 2 of RFC 2409 (IKE)
mention "hybrid protocol" and support for remote user access.

-dave

-----Original Message-----
From: Ari Huttunen [mailto:[email-masked]]
Sent: Sunday, May 06, 2001 12:12 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: Results of protocol straw poll

Andrew Krywaniuk wrote:

> Yeah, but many of us have also implemented Hybrid. You're right that not
> doing any more work would be my first choice, but you're wrong about what
> that implies. My second choice would still be CRACK, which would involve
> rewriting all our code just to get a less flexible but functionally
> equivalent alternative to Hybrid. What does that imply?

What are the many who have implemented Hybrid? I enclose the questionnaire
results 
that Will Price collected in January, and you can see that only two of those
said
they do Hybrid.

I voted for PIC because my understanding is that touching IKE is a no-no,
ruling 
out all these protocols. If IKE can be changed (I want area directors to
state
this, please), I might vote differently. In particular I might vote for some
combination of PIC and CRACK.

Ari

-- 
Ari Huttunen                   phone: +358 9 2520 0700
Software Architect             fax  : +358 9 2520 5001

F-Secure Corporation       http://www.F-Secure.com 

F(ully)-Secure products: Integrated Solutions for Enterprise Security

---

From: "Mason, David" <[email-masked]>
Date: Mon, 7 May 2001 08:42:53 -0700

If IKE is too complex it should never have been advanced to RFC (which I
agree with to a certain degree).

I agree with modular building blocks but there is no reason that there can't
be different building blocks within IKE.  I would think that using a single
transport protocol (ISAKMP/IKE) for these separate "modules" is less complex
than using a different transport protocol for each module (authentication,
key exchange, ID assignment, access request, etc).  Each one of these
modules is complex within itself.  Since they are done together under one
transport (IKE), people label IKE as too complex.  Using a different
transport for each step will not make the whole thing any less complex (it
will actually do the reverse in my opinion).

I found that the implementation of XAuth was extremely modular within IKE.
Has anybody else found that it wasn't?

-dave

-----Original Message-----
From: Steven M. Bellovin [mailto:[email-masked]]
Sent: Monday, May 07, 2001 10:56 AM
To: Mason, David
Cc: 'Ari Huttunen'; [email-masked]; [email-masked]
Subject: Re: Results of protocol straw poll 

In message <[email-masked]>,
"Maso
>doing it between three entities (IKE, legacy system, and CA)?

The rationale for ruling out changes to IKE is not abstract; rather, 
it's that IKE is too complex already, and adding more stuff to it will 
make it much worse.

It's always an engineering tradeoff to decide when to add new modules; 
I'll assert that for the last 25 years, the bulk of computer science 
opinion has been that composing simple building blocks is a better idea 
than building monolithic, complex ones.

		--Steve Bellovin, http://www.research.att.com/~smb

---

From: "Horn, Mike" <[email-masked]>
Date: Tue, 8 May 2001 11:28:29 -0600

Having watched this list for ~ 9 months it is frustrating as an IPSec
technology deployer to see the constant quagmire the ipsra working group
seems to be stuck in.  Currently working in a multi-vendor IPSec environment
is painful due to the lack of standards.  For instance in order to support
remote client applications there are three important issues:

1. Support for legacy user based authentication systems (primarily Radius)
2. Support for a "keepalive" mechanism
3. Support for dynamic client configuration

Of these, all have been documented with one or more drafts, but none have
been standardized (DHCP does seem to be getting close).  It seems the
development community has gone around the working group and has tried to
meet the user community's needs by implementing expired drafts like XAUTH.
This makes it very difficult to push multiple vendors to interoperability
and leaves the question of on-going support for the draft implementations
unanswered.  

I know that there is a mandate to not change IKE, but it doesn't even seem
like this issue will be fixed with a "Son of IKE" standard.  I would hope
that the working group(s) (both ipsra and ipsec) recognize the need to
change the way future solutions are developed so that as new technologies
are designed the existing protocols are extensible to support new
technologies.

Since I'm not a developer I didn't think I should really vote in the PIC vs.
GetCert straw poll, but my vote would be for PIC (if existing solutions like
XAUTH, CRACK, etc. are excluded from the poll).

Mike Horn

-----Original Message-----
From: Scott G. Kelly [mailto:[email-masked]]
Sent: Tuesday, May 08, 2001 9:08 AM
To: Dan Harkins
Cc: Ari Huttunen; [email-masked]; [email-masked]
Subject: Re: Results of protocol straw poll

Hi Dan,

Comments below...

Dan Harkins wrote:
> 
>   Comparing PIC and CRACK is also interesting. Both use UDP/500. Both add
> and define payloads. One (which one?) looks like this:
> 
>    hdr, sa, ke, ni         ---->
>                           <----  hdr, sa, ke, nr, id, sig, hash, <new
payload>
>    hdr, hash, <new payload> ---->
>                           <---- hdr, hash, <new payload>
> 
>                     repeat last two as needed
> 
> while the other (which one?) looks like this:
> 
>    hdr, sa, ke, ni          ---->
>                             <---- hdr, sa, ke, nr, id, sig
>    hdr, <new payload>       ---->
>                             <---- hdr, <new payload>
> 
>                     repeat last two as needed
> 
> One of these is a change to IKE while the other is not.
> 
>   The main difference between the two seems to be that with PIC you get an
> authenticated Diffie-Hellman and then throw it away and get another
> authenticated Diffie-Hellman before you start doing IPsec while with CRACK
> you get an authenticated Diffie-Hellman and then start doing IPsec.
> 
>   But PIC is very IKE-like. It uses the same payloads. It listens on the
same
> port. Given these facts it seems a little disingenuous to keep saying that
> PIC is not changing IKE but CRACK is. Both would end up doing almost
exactly
> the same thing. You'd touch almost exactly the same chunks of code to
write
> each one and IKE would end up being changed in exactly the same way.
> 
>   Dan.
> 

One significant difference is that CRACK must run on the sgw, while PIC
may not. This is not meant as an endorsement of PIC over CRACK, but
simply a statement of a difference.

I'm working on a (brief) draft comparing the various proposed
alternatives which I should be able to get out to the list within the
next few days. This should aid us in this discussion.

Scott