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

From: Torsten Lodderstedt <[email-masked]>
Date: Sat, 11 Oct 2014 13:30:48 +0200

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

---

From: Phil Hunt <[email-masked]>
Date: Sun, 12 Oct 2014 17:37:31 -0700

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
[email-masked]

On Oct 11, 2014, at 4:33 AM, Torsten Lodderstedt <[email-masked]> 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 <[email-masked]>
> An:	[email-masked]
> Kopie (CC):	[email-masked] <[email-masked]>
> 
> Hi all,
> 
> _______________________________________________
> Kitten mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/kitten
> 
> 
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Bill Mills <[email-masked]>
Date: Mon, 13 Oct 2014 16:08:47 +0000 (UTC)

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. We might need to talk about client registration requirements in a token profile, but this draft doesn't define new tokens either.
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 <[email-masked]> wrote:

 Hi all,

  

  

kind regards,
Torsten.

---

From: Torsten Lodderstedt <[email-masked]>
Date: Mon, 13 Oct 2014 22:48:05 +0200

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.
>
>
> > -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,
> - 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
> - 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.
>
> 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
> 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
> 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.
>
> Regarding state of dynamic client registration: It's not ratified yet 
> but already sent to IESG for publication.
> > #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
> > #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

---

From: Bill Mills <[email-masked]>
Date: Mon, 13 Oct 2014 21:05:14 +0000 (UTC)

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 <[email-masked]> wrote:

  Hi Bill,

  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:
 
 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)
 
 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. 

  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.

 

 Hi all,

 

   

   

 

 

 

 
 kind regards,
 Torsten.

---

From: "Richer, Justin P." <[email-masked]>
Date: Tue, 14 Oct 2014 16:54:06 +0000

I agree with Phil on this one (hey, it happens!): this is a classic example of having one piece of software and many instances of it talking to many different service providers. Each of those pairings is going to need to agree on a client ID, and one would hope a client secret or equivalent. It's not feasible to pre-pack these even with a single authorization service (and Google and MS are setting a bad example here), let alone every server ever. Classical OAuth has a strong relationship between the client developer and the protected resource provider, but this relationship starts to dissolve when you're talking about common APIs. OpenID Connect is one such common API that we're seeing in the web space (and SCIM will likely be another), but the SASL work is going to open up a whole slew of "common" protected APIs that could use OAuth.

As such, dynamic registration is going to be essential for this to be interoperable and scale beyond a single provider / consumer-app pair, and it makes perfect sense for Kitten to adopt it here.

 -- Justin

On Oct 12, 2014, at 8:37 PM, Phil Hunt <[email-masked]<mailto:[email-masked]>> wrote:

Torsten,

Big +1 to your comments.

Phil

@independentid
www.independentid.com<http://www.independentid.com/>
[email-masked]<mailto:[email-masked]>

On Oct 11, 2014, at 4:33 AM, Torsten Lodderstedt <[email-masked]<mailto:[email-masked]>> wrote:

Hi all,

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 <[email-masked]><mailto:[email-masked]>
An:     [email-masked]<mailto:[email-masked]>
Kopie (CC):     [email-masked]<mailto:[email-masked]> <[email-masked]><mailto:[email-masked]>

Hi all,

> #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<http://outlook.com/> implementations.

Existing implementations at Google and Outlook.com<http://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.

kind regards,
Torsten.

_______________________________________________
Kitten mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/kitten

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth