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 <tors...@lodderstedt.net>
An: kit...@ietf.org
Kopie (CC): t...@psaux.com <t...@psaux.com>
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
kit...@ietf.org
https://www.ietf.org/mailman/listinfo/kitten
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
