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

[Torsten Lodderstedt <[e-mail]>]

Am 14.10.2014 17:06, schrieb Bill Mills:
> I wasn't planning to.   OpenID is already doing it basically.  There 
> might not yet be  a "here's what a well behaved generic client looks 
> like" draft yet, but is that really needed?

I think so.

>
>
> On Monday, October 13, 2014 11:03 PM, Torsten Lodderstedt 
> <[e-mail]> wrote:
>
>
> Hi Bill,
>
> are you proposing to write a new "generic client" I-D/RFC in the OAuth WG?
>
> kind regards,
> Torsten.
>
>
> -------- Ursprüngliche Nachricht --------
> Von: Bill Mills
> Datum:13.10.2014 23:05 (GMT+01:00)
> An: Torsten Lodderstedt , [e-mail]
> Cc: [e-mail], Hannes Tschofenig , Benjamin Kaduk
> Betreff: Re: [kitten] I-D Action: draft-ietf-kitten-sasl-oauth-16.txt
>
> 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]> <mailto:[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
>>
>>
>>
>>
>>
>>
>
>
>
>
>