New draft: draft-mills-kitten-sasl-oauth: Tunneled HTTP Authentication For SASL
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.
Meta-Data from the Draft
[View first two pages]
* [Txt version ]
* [Pdf version ]
* [Xml version ]
WG Individual Submission
Document date 2011-07-01
Submission date 2011-07-02
Title Tunneled HTTP Authentication For SASL
Author 1 William Mills <wmills@...>
Author 2 Tim Showalter <timshow@...>
Author 3 Hannes Tschofenig <hannes.tschofenig@...>
Abstract Simple 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
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