Subject: [SPKM] SPKM Design Team Meeting Notes

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Tue, 6 Feb 2007 17:09:15 -0800

On 1/16/2007, the SPKM design team Larry Zhu, Nicolas Williams and Olga
Kornievskaia had a conf call that was aimed to produce a comparison of
PkU2U and the TLS mechanism for the community so the community can
decide between them.

Here is the list of things that came up:

PKU2U has a draft,  hence the description is omitted here.

PKU2U Pros:

----------

1) Kerberos alike, easy to implement for folks who already have a PKINIT
and a Kerberos implementation

2) one less round trip per handle-shake

PKU2U Cons:

----------

1) not easier than TLS approach for folks who do not have a PKINIT
implementation

2) this is a new mechanism

TLS approach currently does not have a draft. Here is a brief
description: at high level, it can be based on TLS or Datagram TLS. And
per-message tokens are based on RFC4121, in the same way how PKU2U
per-message tokens work.

TLS approach Pros:

-----------------

1) this is based on an existing mechanism that is mature

2) this is the single mechanism for certificate-based peer to peer
authentication mechanism.

3) open source TLS implementations are available

TLS approach Cons:

------------------

1)at least 2 extra messages (one extra roundtrip) per handshake

The design team discussed the differences in encoding of the
context-establishment tokens employed by these two approaches, and did
not believe the differences are significant to make one preferable over
the other.

Olga raised objections to PKU2U on the ground it is dependent on
Kerberos. She also considered the PKU2U ID underspecified and
significant work need to be done to wrap up PKU2U.

The design team acknowledged that common problems exist such as GSS-API
naming based on distinguished names, channel bindings, certificate
selections, and credentials managements.

--Larry

_______________________________________________
SPKM mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/spkm

---

From: Sam Hartman <[email-masked]>
Date: Wed, 07 Feb 2007 16:28:42 -0500

Thanks Larry.

I guess some of you are wondering why you never saw an announcement of
a design team before their report.

That's my fault.

I had originally hoped to get a design team together to select between
the four mechanisms presented at the BOF.

However talking to Andy and some people who had talked to Andy, it
seemed like the NFS folks might benefit more from a quick decision
than from a protracted discussion.  I suggested that if they were
willing to join the design team and if they were willing to limit the
options to the TLS and PKU2U mechanisms we could quickly come to
consensus and move forward.

Unfortunately, one of the people I asked to serve on the design team
declined to do so citing work time commitment and lack of faith in the
process.  I didn't feel that Nico, Larry and Olga were representative
enough to actually pick an option, but I did feel that they would do a
great job of summarizing the differences.

I'd like to think them for doing that; I think they've done a great
job of what they were asked to do.

Sadly, we're in sort of a bind.

1) The updated SPKM spec clearly needs work before it can be
   considered.  No one besides the original authors has stepped
   forward indicating interest in doing that work.  I do believe that
   we need some additional eyes on that document if we were going to
   consider it.

2) I've been unable to get a group together that I feel is
    representative enough to choose a direction.

I do not know how to proceed at this point.

--Sam

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 7 Feb 2007 17:38:53 -0600

> TLS approach Cons:

Actually, it's exactly three round-trips.  Even with fragmentation
(fragmentation doesn't add round-trips -- the GSS mechanism has to
gather the fragments into one token).

That said, I am currently not able to devote enough time to GSS-TLS.  To
be fair to you, unless someone else pops up to do that work I will
support PKU2U instead.

> selections, and credentials managements.

Yes.

Nico
--

---

From: Love Hörnquist Åstrand <[email-masked]>
Date: Thu, 8 Feb 2007 10:59:39 +1100

>    we need some additional eyes on that document if we were going to

I think the SPKM document is broken enough there is no reason
update it. Just start over, either using DTLS, rewritten SPKM
or Larrys KRB5 thingy.

> I do not know how to proceed at this point.

Love

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 07 Feb 2007 19:52:28 -0500

> be fair to you, unless someone else pops up to do that work I will

This is an important point, and it's not unique to GSS-TLS.  All of the 
proposals that have been brought forward require real work.  It's not fair 
or realistic to expect that all of that work will be done by their 
respective authors.  Additionally, I will note that none of these proposals 
is so hand-wavy that its editorship cannot be taken up by someone other 
than its original author, provided there are people willing to do the work.

So, regardless of the direction we take, the chance of success will depend 
heavily on how many people are willing to participate actively in the work, 
not just reviewing documents and shouting down bad ideas, but actually 
contributing design ideas and text and maybe even serving as an editor.

I would like to see some indication of who might be willing to participate 
at that level, for each of these proposals.  There's no point in choosing 
an approach that no one is willing to work on, and IMHO any of the choices 
available to us would be better than nothing.

-- Jeff