Subject: Results of protocol straw poll

From: Paul Hoffman / VPNC <[email-masked]>
Date: Wed, 2 May 2001 14:04:44 -0700

Greetings again. Thank you to everyone who expressed short or long 
opinions on the protocol straw poll. There were 18 public messages 
and 4 private messages. The totals are:

GetCert:                 4
PIC:                     7
No new protocol:         8
Whatever the leader is:  3

I think it is safe to assume that the "whatever the leader" votes 
were for "the leader between PIC and GetCert".

This shows a majority of folks want the WG to move forwards with PIC. 
I note again that this is not a strong majority; it is closely 
trailed by "no new protocol". So, would the PIC authors let the WG 
know that status of the current draft? draft-ietf-ipsra-pic-01.txt 
has now expired, but it can easily be revived by turning in a -02 
document.

--Paul Hoffman, Director
--VPN Consortium

---

From: "Glen Zorn" <[email-masked]>
Date: Wed, 2 May 2001 19:26:55 -0700

> were for "the leader between PIC and GetCert".

Why?  By your count, the leader is "No new protocol".  BTW, I saw several
votes for protocols other than PIC and GetCert which do not appear to be
reflected in the above.  In particular, Uri Blumenthal voted for CRACK, and
Bill Sommerfeld said "either getcert or pic".  Does Uri's vote not count?
If not, why not?  True, CRACK wasn't mentioned as an option in your original
message, but neither was "Whatever" (since when is "Whatever" a valid vote,
except possibly in Florida ;-).  Is Bill's a vote for both or neither?

> This shows a majority of folks want the WG to move forwards with PIC.

Interesting math.  Mod 11?

> trailed by "no new protocol".

No, it is _led_ by "no new protocol".

> So, would the PIC authors let the WG

---

From: Paul Hoffman / VPNC <[email-masked]>
Date: Wed, 2 May 2001 19:55:36 -0700

At 7:26 PM -0700 5/2/01, Glen Zorn wrote:
>Why?  By your count, the leader is "No new protocol".

No, by my count the "whatever the leader" folks bring PIC up to 10. 
If you want to interpret the votes for "whichever is the leader" as 
going towards "no new protocol", that's fine, but it seems pretty 
unlikely that this was their intention.

>   BTW, I saw several
>reflected in the above.

Correct.

>   In particular, Uri Blumenthal voted for CRACK

...which I counted as "no new protocol"...

>, and
>Bill Sommerfeld said "either getcert or pic".

...which I counted as "whatever the leader is"...

>   Does Uri's vote not count?

Yes, it does. As did yours (which was sent to me privately and not 
sent to the mailing list).

--Paul Hoffman, Director
--VPN Consortium

---

From: Greg Burns <[email-masked]>
Date: Wed, 02 May 2001 20:58:10 -0700

At 07:55 PM 5/2/01 -0700, Paul Hoffman / VPNC wrote:
>No, by my count the "whatever the leader" folks bring PIC up to 10. If you 
>want to interpret the votes for "whichever is the leader" as going towards 
>"no new protocol", that's fine, but it seems pretty unlikely that this was 
>their intention.

It is incorrect, at least, to say that PIC+3 constitutes a majority, since
I count 22 votes cast.

Maybe you want to have a run-off between PIC and no new protocol.
--
Greg

>Yes, it does. As did yours (which was sent to me privately and not sent to 
>the mailing list).
>
>--Paul Hoffman, Director
>--VPN Consortium

---

From: Ari Huttunen <[email-masked]>
Date: Thu, 03 May 2001 22:32:11 +0300

> Maybe you want to have a run-off between PIC and no new protocol.

What exactly does "no new protocol" mean? 
a) After finalizing the DHCP draft this WG is closed? All those who currently use
   CRACK, Hybrid, X-Auth, L2TP, whatever, shall continue to use these protocols.
b) This WG chooses between alternatives like CRACK, Hybrid, X-Auth, L2TP, whatever,
   and does something to standardize its usage for remote access?

I voted for PIC, but I like either of these choices less than GetCert. I think
the majority is clearly "GetCert or PIC".

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: Greg Burns <[email-masked]>
Date: Thu, 03 May 2001 12:54:57 -0700

>    and does something to standardize its usage for remote access?

I prefer b).

>the majority is clearly "GetCert or PIC".

A majority voted for either GetCert or PIC.
A larger majority voted for either GetCert or no new protocol.
A larger majority voted for either PIC or no new protocol.

You assume people voting for GetCert prefer PIC over no new protocol.
I don't see how you can justifiably infer that.

You can't install PIC with 10 of 22 votes.  This isn't a minority government
in a multi-party parliament.  One solution is chosen.  The others are tossed.
--
Greg

---

From: Henry Spencer <[email-masked]>
Date: Thu, 3 May 2001 16:10:52 -0400 (EDT)

On Thu, 3 May 2001, Ari Huttunen wrote:
> a) After finalizing the DHCP draft this WG is closed?

While that may not be the best thing to do, the possibility *is* worth
considering.  The urge to *do* something runs deep, but "take no action"
is a valid and legitimate approach, and sometimes the best one.  We can
all think of standards committees which would have done the world a favor
if they had made that choice. 

The IETF standards process has been described as operating on "rough
consensus and working code".  To my mind, the main conclusion that comes
out of the straw poll is that this working group has not achieved even a
rough consensus.  Can that be changed?  If not, then "take no action" *is*
the right conclusion. 

                                                          Henry Spencer
                                                       [email-masked]

---

From: "Scott G. Kelly" <[email-masked]>
Date: Thu, 03 May 2001 13:50:56 -0700

Comments below...

> rough consensus.  Can that be changed?  If not, then "take no action" *is*

The "no new protocol" votes are actually votes for the status quo. The
status quo is xauth, and the many issues associated with this have been
discussed to death on multiple lists.

The primary problem we are trying to solve pertains to use of legacy
user authentications systems (primarily RADIUS) for authenticating IPsec
remote access users.  This is a security area working group - our
primary consideration must be to provide secure solutions. 

It is clear that xauth is trivially susceptible to DoS attacks, among
other things, and that should be a strong incentive against implementing
it. It is also clear that adding complexity to IKE for this purpose
increases the probability of introducing significant
security-compromising errors to implementations. Hence, we should prefer
solutions which use IKE as is, if possible.

Given the constraints, the IKE and GetCert qualify, while "no new
protocol" does not. It was stated at the outset that the vote would not
be a 50% + 1 straight vote. The fact that there are those here who do
not wish to adequately address security should not sway this working
group from its course. We should choose one of these protocols and
finish our work.

Scott

---

From: Paul Hoffman / VPNC <[email-masked]>
Date: Thu, 3 May 2001 13:49:12 -0700

When the straw poll was taken, the call said "Note that this is a 
straw poll, not a "50%+1" straight vote. In the IETF tradition, the 
WG chairs will view the results and look for consensus." A few people 
here seem to think that the best way to find consensus is to look 
narrowly at the responses as precise and accurate voting; I don't.

We have a mandate from our Area Director to move forwards with a 
protocol unless there is overwhelming WG resistance to doing so. At 
the Minneapolis meeting, we heard no such overwhelming resistance. In 
the straw poll, there was no such overwhelming resistance (although 
there was certainly more than was voiced in Minneapolis).

Those WG members who feel that I interpreted the results of the straw 
poll incorrectly should take your concerns to the WG's responsible 
Area Director (Marcus Leech <[email-masked]>). If he 
agrees with you (which is not bloody likely, of course), I'm quite 
willing to reinterpret the results.

--Paul Hoffman, Director
--VPN Consortium

---

From: Henry Spencer <[email-masked]>
Date: Thu, 3 May 2001 17:39:02 -0400 (EDT)

On Thu, 3 May 2001, Scott G. Kelly wrote:
> The "no new protocol" votes are actually votes for the status quo...

Or for continued experimentation, with standardization to follow at a
later date, perhaps because neither of the options offered seems
attractive. 

> It was stated at the outset that the vote would not
> be a 50% + 1 straight vote.

The purpose of a straw poll is to assess the degree of consensus, not to
make a final decision.  But think about what the poll reveals.  The group
lacks consensus on which option to choose, but much more seriously, it
also lacks consensus that either option is acceptable.  This is a real
issue which should not be swept under the rug. 

> The fact that there are those here who do

In other words, "we should ignore the requirement for consensus, because
we know we're right and the people saying no are wrong"?

The question of whether *either* of these protocols constitutes a suitable
end to this work -- and if not, whether there are any other options which
might, and if not, whether this work *should* proceed to a standard -- is
legitimate and deserves consideration, not dismissal.  "A motion to
adjourn is always in order." 

                                                          Henry Spencer
                                                       [email-masked]

---

From: Dan Harkins <[email-masked]>
Date: Thu, 03 May 2001 17:33:53 -0700

On Thu, 03 May 2001 13:50:56 PDT you wrote
> status quo is xauth

Actually that's not true. One of the "no new protocol" votes was actually
a vote for CRACK. 

  Dan.

---

From: Jari Arkko <[email-masked]>
Date: Fri, 04 May 2001 09:36:10 +0300

>considering.  The urge to *do* something runs deep,
>but "take no action" is a valid and legitimate approach,
>and sometimes the best one.  We can

Perhaps it's too late since I didn't cast my
"vote" in due time.

But I just wanted to voice my opinion that
I (and Ericsson) care about the results of
this group. We want a _standard_ protocol for
doing IPsec remote access. I don't have
much of an opinion of what solution should
be picked, but I'm sure I want the result
of this WG. I do not want us to do nothing.
I do not want us to be forced to use non-standard
or even proprietary schemes, with the need to
perhaps support multiple such schemes in
products.

Jari

---

From: "Stephane Beaulieu" <[email-masked]>
Date: Fri, 4 May 2001 09:31:45 -0400

Hi All,

I know this is not the proper forum to discuss Xauth issues, but someone
else raised them, so I will politely respond, and encourage any further
comments on Xauth, or more specifically its implementation details or
security concerns (those that are VALID at least) to be discussed on
[email-masked]

"Scott G. Kelly" <[email-masked]> wrote:

> it.

Scott,
You often wildly make these kinds of allegations against XAUTH, yet you've
never demonstrated or discussed the rationale behind them.  Would you care
to share these with me please (preferably on the [email-masked] mailing
list).  I think it is important that you do this, because, for some reason,
some people actually believe you, and then they send me emails asking when
I'm going to fix these problems in the draft.  Of, course, I have no idea
what they are talking about.  DoS attacks?  Please explain.  This is the
first of heard of it.

P.S. Just to make my position clear on Xauth (w/regards to this WG).  Even
though I am the author, I don't think that Xauth is the best solution for
this problem.  I think the models of Hybrid or CRACK are much better than
all the other candidates.  I specifically prefer Hybrid because it will
allow me to re-use much of the code base I already have.  Hybrid is actually
VERY trivial once you already have Xauth.

Stephane.

---

From: "Stephane Beaulieu" <[email-masked]>
Date: Fri, 4 May 2001 09:53:53 -0400

> discussed to death on multiple lists.

I thought status quo was to have everyone disagree, have no one listen to
each other, have people bury their head in the sand, and have vendors chose
their own routes because they don't believe this WG will produce a protocol
which will meet their requirements in a timely fashion.

If a protocol is chosen without a good CLEAR majority, I suspect status quo
is what you'll get.  If you can't get the vendors to agree (much less
commit) to something, then it aint gonna happen, (except maybe on paper).

my 2cents (Canadian for what that's worth ;)
Stephane.

---

From: "Scott G. Kelly" <[email-masked]>
Date: Fri, 04 May 2001 08:35:44 -0700

Hi Dan,

> Actually that's not true. One of the "no new protocol" votes was actually

Sorry for the misunderstanding - I stand corrected. I'd be personally
interested to hear if any other "no new protocol" votes were also
intended to be definitive votes for CRACK.

Scott

---

From: "Scott G. Kelly" <[email-masked]>
Date: Fri, 04 May 2001 09:01:35 -0700

Hi Henry,

I think some things were muddled in the translation of my thoughts. I'll
try to clarify.

> later date, perhaps because neither of the options offered seems

Let's be very clear on context here. Two coupled proposals were made for
remote access in the ipsec wg around 3 years ago: mode-cfg and xauth. I
believe that very few vendors paid much attention to these for a long
time, as most were scrambling to get other aspects of their
implementations in order, and at least one had alternative solutions to
these problems.

Around 2 years ago (or so), vendors began to express more interest in
resolving the remote access problem in ipsec, and the ipsra group was
proposed. It was at this point that the proposed mechanisms first
garnered a significant amount of attention. A number of people
subsquently raised serious concerns about these mechanisms, and some of
those folks are highly respected contributors to numerous security area
working groups. The end result was the current direction of the ipsra
group: DHCP for configuration, PIC or GetCert for user authentication
needs.

In the straw poll, many of the those who chose "no new protocol" work
for vendors who have already deployed mode-cfg and xauth, so I assumed
that they were implicitly voting for these, given their vested interest.
I see that I was incorrect in at least one case, and have asked for
further corrections in a related post.

I would not rule out other proposals (continued experimentation), but I
don't think that's what we'll get if we don't resolve this. Rather, I
think vendors have a strong incentive to keep using what they've been
using, resulting in a defacto standard which is less than desirable from
a security standpoint.

> issue which should not be swept under the rug.

Yes, I agree. However, there seems to be an element here who wishes to
prevent this work from proceeding. I believe that if nothing is done by
this group, we will have a less than desirable defacto standard in short
order.

> we know we're right and the people saying no are wrong"?

Not exactly, but the relative security of our solution must be a
signicant consideration in the final analysis. Obviously, the ideal
outcome is to reach agreement on this point if possible. On the other
hand, there are a number of respected security experts who support the
pic/getcert approach for security reasons. Surely we must weigh this
accordingly, given that this is a security area working group?

> adjourn is always in order."

Either of these options solves the problem within the working group's
charter constraints, so either would constitute a suitable end to the
work. As for other options, I don't think anyone has proposed any which
meet the charter constraints. 

Scott

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 4 May 2001 09:43:18 -0700 (PDT)

> which will meet their requirements in a timely fashion.

That's a blunt but accurate description of the status quo ;) 

> commit) to something, then it aint gonna happen, (except maybe on paper).

I'd also note that we now have other WGs (IPS) creating their own
IPSEC key exchange methods in order to get around the "don't touch
IKE" limitations. So in addition to a potential explosion of
vendor-specific routes, we also are now facing proliferation of
application-specific key exchange methods as well. As a result, IPSEC is
very likely to become the next RPC - a standardized framework that is
used largely for creation of proprietary protocols. We're more than
half-way there.

So unless any proposal has a realistic chance of putting a stop to this, 
I'd say that it's not worth doing, because we'll still have all the
problems we had before magnified by whatever time it takes to produce the
(probably ineffective) cure.

---

From: "Andrew Krywaniuk" <[email-masked]>
Date: Fri, 4 May 2001 15:24:07 -0400

Scott,

Your comments were clearly misleading, which I find odd, since the evidence
to impeach them is publicly available (see Darren's summary).

Most of the "no new protocol" votes were for hybrid, which is a different
protocol from XAuth. Several people have said that they would be okay with
the IPSRA group standardizing Hybrid without standardizing XAuth in its
Cert/Preshared key modes.

Several of the "no new protocol" voters also said that they would be willing
to implement CRACK. Not everyone put it as their first choice, but they
wrote it only their ballot as an acceptable option.

So either you didn't read the straw poll ballots very carefully, or your
read them and chose to misinterpret them. I wonder if everyone can figure it
out...?

Andrew
-------------------------------------------
Upon closer inspection, I saw that the line
dividing black from white was in fact a shade
of grey. As I drew nearer still, the grey area
grew larger. And then I was enlightened.

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Scott G. Kelly
> Sent: Friday, May 04, 2001 11:36 AM
> To: Dan Harkins
> Cc: [email-masked]
> Subject: Re: Results of protocol straw poll
>
>
> Hi Dan,
>
> Dan Harkins wrote:
> >

---

From: Paul Hoffman / VPNC <[email-masked]>
Date: Fri, 4 May 2001 13:41:06 -0700

Two methods for achieving consensus and do good engineering work are 
to make personal attacks on each other and to try to speak for people 
with whom you disagree.

There are also other methods.

--Paul Hoffman, Director
--VPN Consortium

---

From: "Scott G. Kelly" <[email-masked]>
Date: Fri, 04 May 2001 13:51:22 -0700

> Cert/Preshared key modes.

Have I missed something? I can't find my copy of the hybrid draft, but I
believe hybrid simply modifies xauth, and requires both mode-cfg and
xauth in it's current incarnation. Is this wrong?

> wrote it only their ballot as an acceptable option.

What I asked in the email in which you just replied to is, who prefers
CRACK as a first choice?

> read them and chose to misinterpret them. I wonder if everyone can figure it

It is true that I did not review them together before making my comment,
but I believe that most of those suggesting "no new protocol" have
already implemented xauth, and I assume that not doing anymore work
would be their first choice. Here is Darren's summary:

> 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.

All of these folks have already implemented xauth. As I said, I believe
hybrid is a modified version of xauth. Is this incorrect?

Scott

---

From: Ricky Charlet <[email-masked]>
Date: Fri, 04 May 2001 14:21:24 -0600

> has now expired, but it can easily be revived by turning in a -02

	When shall the first interoperability testing of PIC begin?

-- 
  Ricky Charlet   : Redcreek Communications   : usa (510) 795-6903

---

From: "Andrew Krywaniuk" <[email-masked]>
Date: Fri, 4 May 2001 18:09:42 -0400

> xauth in it's current incarnation. Is this wrong?

Hybrid only requires parts of XAuth and Mode-Cfg. As has been pointed out on
this mailing list several times before, a WG-standardized version of Hybrid
does not necessarily have to reference XAuth and Hybrid. It could
incorporate all the text into one document.

> What I asked in the email in which you just replied to is, who prefers

In the straw poll, votes for "either PIC or GetCert" were allowed. Votes for
"no new protocol" were mostly for "either Hybrid or CRACK". Only one of the
votes appeared to be for XAuth specifically, although even that was unclear
(it was for "that which must not be named"). I believe that XAuth is an
acceptable remote access model under some circumstances, but if this WG was
to devise a single all-encompasing remote access model it should be either
Hybrid or CRACK.

> I believe that most of those suggesting "no new protocol" have
> would be their first choice.

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?

Andrew

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 4 May 2001 15:35:19 -0700 (PDT)

> commit) to something, then it aint gonna happen, (except maybe on paper).

I'd also note that this would represent a new and potentially dangerous
interpretation of the meaning of "rough consensus". If a WG can move
forward on a proposal that not even a majority of the WG actually
supports, then putting the IETF standards stamp on that protocol has no
meaning. Ultimately, the "rough consensus and running code" philosophy
is at the heart of what we do here. There are very few circumstances in
which I'd consider sacrificing that in exchange for more rapid progress.

---

From: Ari Huttunen <[email-masked]>
Date: Sun, 06 May 2001 19:12:15 +0300

> 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

---

From: Dan Harkins <[email-masked]>
Date: Mon, 07 May 2001 10:15:12 -0700

Touching IKE seems to be allowed if you say, "I am not touching IKE" and
then proceed to touch IKE. The Group DOI draft in the MSEC WG does exactly
what XAUTH did (create another post-phase 1 exchange). That is permissible
while XAUTH/Hybrid is not for some strange reason.

  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.
 
On Sun, 06 May 2001 19:12:15 +0300 you wrote

---

From: "Andrew Krywaniuk" <[email-masked]>
Date: Mon, 7 May 2001 14:40:39 -0400

> while XAUTH/Hybrid is not for some strange reason.

The other way to improve your chances of having your protocol advanced seems
to be to explicitly name it "simple-<something>". Maybe you should submit a
draft for S-CRACK and see if that garners any more acceptance.

Andrew

---

From: "Scott G. Kelly" <[email-masked]>
Date: Tue, 08 May 2001 08:08:18 -0700

Hi Dan,

Comments below...

> each one and IKE would end up being changed in exactly the same way.

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