Re: [kitten] [OAUTH-WG] I-D Action: draft-ietf-kitten-sasl-oauth-16.txt

[Phil Hunt <[e-mail]>]

Torsten,

Big +1 to your comments.

I think the SASL-OAuth work is very important work and it is the *classic* use case for OAuth Dynamic Registration.

SASL clients are typically developed independently of server implementation and are meant to work with any server.  This means that having a pre-negotiated client_id is pretty much impossible without dyn reg or some equivalent solution — and why do another?

There may be simpler profiles you can develop specific to SASL, but I think OAuth Dyn Reg should work well for this use case.

Phil

@independentid
www.independentid.com
[e-mail]



On Oct 11, 2014, at 4:33 AM, Torsten Lodderstedt <[e-mail]> wrote:

> Hi all,
> 
> there is some discussion going on in the KITTEN WG regarding the SASL/Oauth mechanism that might be of interest for the OAuth WG as well.
> 
> kind regards,
> Torsten.
> 
> 
> -------- Original-Nachricht --------
> Betreff:	Re: [kitten] I-D Action: draft-ietf-kitten-sasl-oauth-16.txt
> Datum:	Sat, 11 Oct 2014 13:30:48 +0200
> Von:	Torsten Lodderstedt <[e-mail]>
> An:	[e-mail]
> Kopie (CC):	[e-mail] <[e-mail]>
> 
> Hi all,
> 
> as one of the proposers (beside Hannes) of the change, I would like to explain the rationale.
> 
> > -16 is submitted, and there is one suggested change (which I was supposed to have added in already and blew it), which is to replace section 3.2.2 with the text (farther) below. My comments on the suggested text:
> 
> > #1)  I don't think the dynamic registration stuff is baked enough to want to pull that in to the "oauth-configuration" definition. I don't want to pull it in because I don't think dynamic registration is required for SASL/OAUTH (as evidenced by the Google and Outlook.com implementations.
> 
> 
> Existing implementations at Google and Outlook.com are no evidence against dynamic client registration. They demonstrate that it is possible
> to implement the server side. But we are talking about clients (more precisely about generic clients). I'm not aware of any generic
> client implementing the SASL mechanisms in the moment. I recommend taking a look at https://bugzilla.mozilla.org/show_bug.cgi?id=849540.
> 
> Before I dive into the registration details, I would like to give my personal summary why this SASL profile is needed.
>  
> In my opinion, one of the main purposes of this mechanism is to allow generic clients to authorize access to standard protocols, such as IMAP,
> using OAuth Access Tokens. This offers the following advantages:
> 
> - multi-factor authn: An increasing number of service providers (e.g. Google, Yahoo, Apple) offer 2-factor authentication to their users,
> but only for apps and web sites. Why? It currently does not work in conjunction with IMAP and the like. Instead, application-specific passwords
> must be used, which offer a terrible user experience and therefore are a significant burden for better Internet security. Using OAuth access tokens
> allows to decouple service access and authentication/authorization process. So the authorization server can choose the appropriate/available
> mechanisms to authenticate at its discretion. This also allows to use any kind of (provider-specific) multi-factor authentication methods also
> in the context of IMAP and the like.
> 
> - Furthermore, using OAuth also allows to use refresh tokens as persistent credential for service login, that way eleminating the need to store user
> passwords on devices.
>  
> So basically, the SASL OAuth profile can (at least in my opinion) be a major leap forward in Internet security.
> 
> Why does this require dynamic registration?
> 
> Well, OAuth requires any client to possess a client_id (and client_secret) with the particular authorization server. Nowadays developers typically
> register with the authz server's provider out of band and bake the credentials into the software package. This works for clients, which
> are directly programmed against a certain deployment/API, such as Facebook, but is inappropriate (if not unfeasible) for generic
> clients using standardized protocols, e.g. Thunderbird.
> 
> Or do you want to register the Thunderbird deveopers with every e-Mail/Calendar-provider in the world up-front?
> 
> I don't think so. That's why the OAuth WG came up with the specification for dynamic client registration, which allows
> the client to dynamically obtain client credentials from the authorization server. It basically solves the client credential challenge for generic
> clients, but it does integrate the registration step into an overall process.
> 
> That's why I think we must define a way for a generic SASL client to, based on user-provided data, find the appropriate authorization server and
> register with it. I think the SASL mechanism should specify how those mechanisms are used in concert in order to authorize service access using OAuth.
> Otherwise, the SASL mechanism can only be used for point to point integrations among partners but never for generic clients.
> 
> So I think true interoperability calls for addition of registration as well.
> 
> Regarding state of dynamic client registration: It's not ratified yet but already sent to IESG for publication.
> Beside that it is already implement in existing OpenId Connect deployments.
> 
> > #2)  I didn't really want to make all of the OpenID elements required but I don't have a strong opinion here, my initial intent was to use the OpenID Discovery format as an existing format to be re-used here but leave it flexible.
> 
> Agreed. Using the format as specified by OpenID Connect makes sense. As generic OAuth differs from OpenID Connect, the WG should (probably in cooperation with
> the OAuth WG) discuss, which elements are really needed.
> 
> > #3)  I am against recommending scope names at all in any way.  I would not include the last sentence of paragraph 5 below and strike the scope names.
> 
> 
> Given there is already a response parameter scope, which intructs the client on what scope to use in the authz request, I tend to agree. I'm not yet fully
> convinced whether this approach will work. But let's give it a try.
> 
> kind regards,
> Torsten.
> 
> 
> 
> >   New text for 3.2.2:
> > -----------------------
> > 3.2.2.  Server Response to Failed Authentication
> >
> >
> > For a failed authentication the server returns a JSON [RFC4627]
> > formatted error result, and fails the authentication.  The error
> > result consists of the following values:
> >
> >
> > status (REQUIRED):  The authorization error code.  Valid error
> > codes are defined in the IANA "OAuth Extensions Error Registry"
> > specified in the OAuth 2 core specification.
> >
> >
> > scope (OPTIONAL):  An OAuth scope which is valid to access the
> > service.  This may be empty which implies that unscoped tokens
> > are required, or a scope value.  If a scope is specified then a
> > single scope is preferred, use of a space separated list of
> > scopes is NOT RECOMMENDED.
> >
> >
> > oauth-configuration (OPTIONAL):  The URL for a document following
> > the OpenID Provider Configuration Information schema, as
> > described in Section 3 of the OpenID Connect Discovery
> > [OpenID.Discovery], that is appropriate for the user.  The
> > server MAY return different URLs for users from different
> > domains and a client MUST NOT cache a single returned value and
> > assume it applies for all users/domains that the server
> > suports.  The returned discovery document MUST have all data
> > elements required by the OpenID Connect Discovery specification
> > populated.  In addition, the discovery document MUST contain
> > the 'registration_endpoint' element to learn about the endpoint
> > to be used with the Dynamic Client Registration protocol
> > [I-D.ietf-oauth-dyn-reg] to obtain the minimum number of
> > parameters necessary for the OAuth protocol exchange to
> > function.  Authorization servers MUST implement the
> > authorization code grant and other grant types MAY be
> > supported.  Furthermore, authorization servers MUST implement
> > the ability to issue refresh tokens for use with native
> > applications to benefit from an abbreviated protocol exchange.
> > The use of the 'offline_access' scope, as defined in
> > [OpenID.Core] is RECOMMENDED to give clients the capability to
> > explicitly request a refresh token.
> >
> >
> > If the resource server provides a scope (as part of the element of
> > the configuration payload) then the client MUST always request
> > scoped tokens from the token endpoint.  This specification
> > RECOMMMENDs the use of the following scopes:
> >
> > imap:  The 'imap' scope value is used to interact with IMAP mail
> > servers.
> >
> > pop3:  The 'pop3' scope value is used to interact with POP3 mail
> > servers.
> >
> > xmpp:  The 'xmpp' scope value is used to interact with XMPP servers.
> >
> >
> >
> > If the resource server provides no scope to the client then the
> > client SHOULD presume an empty scope (unscoped token) is needed.
> >
> >
> > Since clients may interact with a number of application servers,
> > such as email servers and XMPP servers, they need to have a way
> > to determine whether dynamic client registration has been performed
> > already and whether an already available refresh token can be
> > re-used to obtain an access token for the desired resource server.
> > This specification RECOMMENDs that a client uses the information in
> > the 'issue' element to make this determination.
> > -----------------------
> >
> >
> > I think we're getting very close :)
> >
> > -bill
> 
> 
> 
> 
> _______________________________________________
> Kitten mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/kitten
> 
> 
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth