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

From: "William J. Mills" <[email-masked]>
Date: Thu, 7 Jul 2011 11:52:56 -0700 (PDT)

Hi,

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.

The draft also fixes the channel binding text, not tls-unique specific.  Also defining how the CB data is properly generated.

Subject to the open issue above (which could be significant) I think this is close to a last call.

Does this draft need some discussion time in Quebec?  If so I'll need to make travel plans.

Thanks,

-bill

Meta-Data from the Draft
Documentdraft-mills-kitten-sasl-oauth 
[View first two pages] 
	* [Txt version ]
	* [Pdf version ]
	* [Xml version ] 
Revision03 
WGIndividual Submission 
Document date2011-07-01 
Submission date2011-07-02 
TitleTunneled HTTP Authentication For SASL 
Author information
Author 1William Mills <[email-masked]> 
Author 2Tim Showalter <[email-masked]> 
Author 3Hannes Tschofenig <[email-masked]> 
AbstractSimple Authentication and Security Layer (SASL) is a framework for
providing authentication and data security services in connection-
oriented protocols via replaceable mechanisms.  OAuth is a protocol
framework for delegated HTTP authentication and thereby provides a
method for clients to access a protected resource on behalf of a
resource owner.

This document defines the use of HTTP authentication over SASL, and
additionally defines authorization and token issuing endpoint
discovery.  Thereby, it enables schemes defined within the OAuth
framework for non-HTTP-based application protocols.

A significant benefit of OAuth for usage in clients that usually
store passwords is storing tokens instead of passwords.  This is much
lower risk since tokens can be more limited in scope of access and
can be managed and revoked separately from the user credential
(password).
 
Pages24

---

From: Shawn Emery <[email-masked]>
Date: Mon, 11 Jul 2011 00:46:12 -0600

On 07/ 7/11 12:52 PM, William J. Mills wrote:
> Hi,
>
> 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.
>
> The draft also fixes the channel binding text, not tls-unique 
> specific. Also defining how the CB data is properly generated.
>

Of course it is always helpful to be there, but is not a requirement.  
There are a number of ways that we have joined remote participants to 
the sessions in the past; WebEx, Skype, jabber, chair, co-author, etc.  
However, is it possible that we can resolve the open issue before the 
session?

Shawn.
--
>
>
>     Meta-Data from the Draft
>
> Document 	draft-mills-kitten-sasl-oauth
> [View first two pages] 
> <https://datatracker.ietf.org/submit/status/33695/a4fa263fb7371aecddccdc6674d408d9/#> 
>
>
>     * [Txt version ]
>       <http://www.ietf.org/staging/draft-mills-kitten-sasl-oauth-03.txt>
>     * [Pdf version ]
>       <http://www.ietf.org/staging/draft-mills-kitten-sasl-oauth-03.pdf>
>     * [Xml version ]
>       <http://www.ietf.org/staging/draft-mills-kitten-sasl-oauth-03.xml>
>
> Revision 	03
> WG 	Individual Submission
> Document date 	2011-07-01
> Submission date 	2011-07-02
> Title 	Tunneled HTTP Authentication For SASL
> Author information
> Author 1 	William Mills <[email-masked]>
> Author 2 	Tim Showalter <[email-masked]>
> Author 3 	Hannes Tschofenig <[email-masked]>
> Abstract 	Simple Authentication and Security Layer (SASL) is a 
> framework for
> Pages 	24
> _______________________________________________
> Kitten mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/kitten

---

From: Nico Williams <[email-masked]>
Date: Mon, 11 Jul 2011 15:18:26 -0500

> 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 co…

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