Re: [kitten] New draft of https://tools.ietf.org/htmdraft-mills-kitten-sasl-oauth

[Nico Williams <[e-mail]>]

On Thu, Jul 7, 2011 at 1:52 PM, William J. Mills <[e-mail]> wrote:
> I've posted a new draft.  I believe there is one open issue, and that is whether we're going to include text defining how Tunneled HTTP authentication (started as OAuth) works with GSS-API. I am coming more and more to the opinion that the GSS-API definition is going to be very auth mechanism specific.  This draft only defines what SASL needs currently, which is user auth.  GSS-API has message integrity as well, and possibly other things that can be mapped into HTTP auth schemes, and I think it's going to be  required that the auth schemes define their capabilities and GSS_API mappings.

Per-message tokens in the GSS-API are optional.  Not having them makes
a mechanism very uninteresting for GSS applications.  If your
mechanism does have a way to exchange session keys between the
initiator and acceptor then you can copy the text from RFC5802 to make
your mechanism a GSS mechanism (basically you get to say that the
per-message tokens and the PRF are the same as for the Kerberos V5
mechanisms, and you then specify how to get the base protocol key
needed to key those things).

Any mechanism that can exchange session keys should.  I completely
agree with you regarding this and the desirability of key exchange.

You mention mapping GSS mechanisms onto HTTP authentication.  See: a)
HTTP/Negotiate (RFC4559) (and what Windows calls Integrated Windows
Authentication with Extended Protection), and b)
http://tools.ietf.org/html/draft-williams-rest-gss-00 .

Nico
--