Subject: [kitten] GSS BrowserID draft

From: Luke Howard <[email-masked]>
Date: Mon, 11 Mar 2013 12:04:38 +1100

Hey folks,

Nico and I have started hacking on an Internet Draft describing the GSS BrowserID protocol.

https://raw.github.com/lhoward/gss-browserid-id/master/gss-browserid.txt

It probably could do with some reorganising (not to mention a proper security considerations section), so we're not going to submit it yet, but comments are welcome. Although poorly formatted, there is an IMAP example which comes from our working implementation.

cheers,

-- Luke
--
Luke Howard / [email-masked]
www.padl.com / www.lukehoward.com

---

From: Nico Williams <[email-masked]>
Date: Sun, 10 Mar 2013 22:10:36 -0500

> Nico and I have started hacking on an Internet Draft describing the GSS

Luke is being generous.  Most of the text (and all of the
implementation it documents) is from Luke.

This is a very cool mechanism.  It's what SPKM wanted to be, but couldn't.

Nico
--

---

From: "Henry B. Hotz" <[email-masked]>
Date: Tue, 12 Mar 2013 12:44:25 -0700

OK, now I'm interested. ;-)

It's always bugged me that (in common deployment terms) TLS is X.509 PKI-only and GSSAPI is Kerberos-only.

> This is a very cool mechanism.  It's what SPKM wanted to be, but couldn't.

------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
[email-masked], or [email-masked]

---

From: Luke Howard <[email-masked]>
Date: Wed, 13 Mar 2013 09:51:34 +1100

Note that you can't get away from TLS entirely. It is used to retrieve IdP certificates (although I guess you could use sneakernet if you really wanted).

Also, X.509 certificates are used for optionally authenticating the acceptor to the initiator. I figured that this was a practical compromise because the infrastructure for long-term server certificates already exists.

-- Luke

---

From: Nico Williams <[email-masked]>
Date: Tue, 12 Mar 2013 20:26:34 -0500

> It's always bugged me that (in common deployment terms) TLS is X.509 PKI-only and GSSAPI is Kerberos-only.

There's also the GSI GSS mechanism that consists of... TLS.  (If you
send tokens with no extra framing then you're speaking TLS on the
wire.)

And there's Microsoft's PKU2U, which is TLS-like but based on PKINIT.

Nico
--

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 12 Mar 2013 21:42:40 -0400

> And there's Microsoft's PKU2U, which is TLS-like but based on PKINIT.

In fact, PKU2U was the subject of an internet-draft that never quite got
finished (it was very close, and I'm afraid I dropped the ball
somewhere, Larry moved on to other work, and no one else was pushing
very hard).

---

From: Luke Howard <[email-masked]>
Date: Wed, 13 Mar 2013 19:42:25 +1100

> send tokens with no extra framing then you're speaking TLS on the

One thing about BrowserID is that it's a little closer to Kerberos, in that you get short-lived certificates that behave more like tickets than traditional client certs.

-- Luke

---

From: [email-masked] (Martin Rex)
Date: Fri, 15 Mar 2013 01:45:57 +0100 (CET)

Nico Williams wrote:
> Luke Howard <[email-masked]> wrote:
>>

SPKM (rfc2025) never tried to be anything else than what it was:
One vendors description of his product.
(GSS IDUP is even more so, for the same vendor).

The idea of SPKM to use asymmetric crypto digital signatures for
per-message integrity protection is mindbogglingly lame
(and a real performance-killer).

-Martin