Subject: GSS-API mechanism review

From: Wesley Leggette <[email-masked]>
Date: Sat, 21 Mar 2009 15:08:22 -0500

We are using GSS-API for authentication on a distributed storage system. In
order to support basic password authentication using a backing LDAP
infrastructure we designed a disclosing password mechanism that supports
delegation. The authentication protocol is heavily based on the SSH
authentication protocols.

1. Were we duplicating work? Is there an existing password-based GSS-API
mechanism?

2. We would like to document and present this protocol and mechanism for
review. Is this the correct body to present this information to?

Thanks,

Wesley Leggette
Senior Software Developer
Cleversafe, Inc.

---

From: Nicolas Williams <[email-masked]>
Date: Sat, 21 Mar 2009 22:16:39 -0500

> authentication protocols.

So, this mechanism does a Diffie-Hellman key exchange with the server
authenticated by an RSA/DSA public key signature, and then a password
is sent encrypted with a session key derived from the DH exchange?

> 1. Were we duplicating work? Is there an existing password-based GSS-API

Maybe.  There's SCRAM, which we're likely to get consensus on this week.
If we do then we'll have a password-based GSS-API mechanism.  SCRAM is
like DIGEST-MD5, and does not authenticate the server first.  SCRAM as
proposed also does not support delegation, but it could probably be
extended to do so.

SCRAM has fairly different properties from what I *think* you're
proposing, so, I don't think you're duplicating work.

> review. Is this the correct body to present this information to?

The KITTEN WG does not do work on mechanisms, but it's as a good forum
to start seeking review.

Nico
--

---

From: Wesley Leggette <[email-masked]>
Date: Sat, 21 Mar 2009 23:02:57 -0500

> is sent encrypted with a session key derived from the DH exchange?

Precisely.

> proposing, so, I don't think you're duplicating work.

Thanks for the reference. I will investigate this.

> The KITTEN WG does not do work on mechanisms, but it's as a good forum

Thanks. Can you offer any advice on how I should proceed from here?

Wesley Leggette

---

From: Nicolas Williams <[email-masked]>
Date: Sat, 21 Mar 2009 23:14:33 -0500

> > is sent encrypted with a session key derived from the DH exchange?

I imagine that delegation is a simple matter of sending the password as
is?

> Thanks for the reference. I will investigate this.

Actually, I didn't give you a reference, but that's partly because only
recently have we begun to reach consensus on how to make SCRAM both, a
SASL mechanism and a GSS-API mechanism.  I'll submit an I-D that covers
that tomorrow, in the mean time you should look at:

draft-newman-auth-scram-10.txt

> Thanks. Can you offer any advice on how I should proceed from here?

Submit an individual Internet-Draft, ask for review on several mailing
lists, such as the old SECSH WG mailing list and this one (but set
Reply-To so we don't need to keep cross-posting), and follow the
individual I-D process.

Nico
--

---

From: Wesley Leggette <[email-masked]>
Date: Sun, 22 Mar 2009 12:58:18 -0500

Speaking of SPKM, we were thinking of implementing it, but could not find
any reference implementations to ensure compatibility. In any case, because
we require delegation, we're thinking of implementing a mechanism that uses
RFC 3820 proxy certificates. Does PKU2U provide this?

Wesley Leggette

On 3/22/09 12:41, "Nicolas Williams" <[email-masked]> wrote:

> Actually, there is some duplication.
> 
> Originally we had SPKM and LIPKEY, where the latter was a simple
> username & password sent protected by the former, and the former is a
> PKI-based mechanism.
> 
> SPKM was never widely implemented and deployed.  There is a replacement
> for SPKM coming called PKU2U, which is also a PKI-based mechanism, but
> using Kebreros V and PKINIT messages as building blocks.
> 
> So once we get PKU2U it will be possible to define a successor to LIPKEY
> but in terms of PKU2U.
> 
> That does not mean that you should not proceed with your mechanism
> though.

---

From: Nicolas Williams <[email-masked]>
Date: Sun, 22 Mar 2009 12:41:43 -0500

---

From: Love Hörnquist Åstrand <[email-masked]>
Date: Sun, 22 Mar 2009 11:09:13 -0700

SPKM is based on crypto from 1980/1990 and very under specified.

I didn't even bother implementing one since it was so weird and  
detached from reality.

Love

22 mar 2009 kl. 10:58 skrev Wesley Leggette:

> _______________________________________________
> Kitten mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/kitten

---

From: Nicolas Williams <[email-masked]>
Date: Sun, 22 Mar 2009 13:39:10 -0500

> RFC 3820 proxy certificates. Does PKU2U provide this?

No, PKU2U is just PKI based, but LIPKEY does indirectly imply delegation
since LIPKEY sends the username and password as is -- protected, yes,
but the acceptor gets the cleartext, so there's your delegation :)

PKU2U will allow:

 - anonymous DH
 - DH + acceptor authentication using certs
 - DH + initiator and acceptor authentication using certs

Nico
--