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

[Torsten Lodderstedt <[e-mail]>]

Hi Bill,

are you proposing to write a new "generic client" I-D/RFC in the OAuth WG?

kind regards, 
Torsten. 

<div>-------- Ursprüngliche Nachricht --------</div><div>Von: Bill Mills <[e-mail]> </div><div>Datum:13.10.2014  23:05  (GMT+01:00) </div><div>An: Torsten Lodderstedt <[e-mail]>, [e-mail] </div><div>Cc: [e-mail], Hannes Tschofenig <[e-mail]>, Benjamin Kaduk <[e-mail]> </div><div>Betreff: Re: [kitten] I-D Action: draft-ietf-kitten-sasl-oauth-16.txt </div><div>
</div>3 through 6 should be handled by OAuth (and OpenID?) and are outside the scope of this spec.  This spec deals with 1 and maybe 2 & 7 above).  

A generic mail/contacts/calendar client will used more than SASL endpoints, notably CalDAV and CardDAV.  This isn't the place to solve the general problem.   

-bill



On Monday, October 13, 2014 1:48 PM, Torsten Lodderstedt <[e-mail]> wrote:


Hi Bill,

Am 13.10.2014 18:08, schrieb Bill Mills:
I totally agree that generic and interoperable OAuth client implementations need both endpoint discovery and client registration.  I disagree that this spec needs registration.  
This spec is about using OAuth on resource servers which have nothing to do with authentication and token issuance.

I agree these are different aspects. Does this mean they need to be treated in different specs? What is the benefit of this approach? 

I'm not looking for a generic OAuth client. My goal is to enable the development of generic email/calendar/xmpp ... clients, which authorize access to the respective service using OAuth.
Such a generic client must (at most) perform the following steps in order to get access to the resource server:

1) client tries to access resource server
2) resource server refuses access and returns discovery URL
3) client obtains metadata from discovery URL
4) client determines its client credentials for this particular authz server
5) if client is not in possession of suitable client credentials ->  register with the authz server (at the registration endpoint obtained from the discovery document)
6) client performs authz flow with the authz server
7) client accesses resource server again (with new access token) 

This spec currently does not specify steps 4 through 6, which means there is no way to implement the whole process in an interoperable way in my generic email client. I therefore suggest to add registration to this spec in order to cover the entire process. 

Do you have an alternative proposal to achieve this goal? 

We might need to talk about client registration requirements in a token profile, but this draft doesn't define new tokens either.

There is no need to define new tokens as this is not relevant for client/resource server interop. Resource server know the authz server's token format (which is standard in OAuth deployments). 

kind regards,
Torsten.



On whether to specify the full OpenID Connect Discovery schema, I think a SHOULD is reasonable, I don't really like the MUST.


On Saturday, October 11, 2014 4:30 AM, Torsten Lodderstedt <[e-mail]> wrote:


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