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

[Phil Hunt <[e-mail]>]

+1

Phil

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



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

> 
> 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]> 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
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>> 
>> 
>> 
>> 
>> 
> 
> _______________________________________________
> Kitten mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/kitten