Subject: [OAUTH-WG] Stephen Farrell's Discuss on draft-ietf-oauth-dyn-reg-28: (with DISCUSS and COMMENT)

From: "Stephen Farrell" <[email-masked]>
Date: Fri, 24 Apr 2015 04:52:05 -0700

Stephen Farrell has entered the following ballot position for
draft-ietf-oauth-dyn-reg-28: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

(1) cleared

(2) If the response (defined in 3.2.1) includes metadata that
the server has altered, but that the client doesn't like, then
what does the client do? (It may be that that's ok, but I'm
not following why that is the case.) I'm also not sure the
"https" requirement (1st bullet in section 5) is useful there.

We had some mail discussion on this but I'd like to 
continue that a bit more to understand if the changes
in -28 address the issue. I'll send mail.

(3) cleared

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

My previous DISCUSS point (1) is below. That has been 
handled via new text in section 5 (on p27). I do wonder
though if you ought also say a bit about, or point at a
reference describing, the possible bad outcomes if 
one of these URLs  goes bad. The new text I think 
assumes that the developer will get how bad that can 
be, but I'm not sure if they would or not. 

(1) General: there are many URIs sent to the AS from the
client here. Nothing prevents the client messing about with
the content served from those later, after registration. What
mechanism holds clients accountable for such misbehaviours?
(Examples, logo_uri, tos_uri, policy_uri, jwks_uri) Section 5
does say that the AS "SHOULD check" but does not say what
"checking" means, nor what to do if the check fails.  I think
a bit more security considerations-like text here, reflecting
what is (or ought;-) actually be done would be good. Do you
agree?

--- OLD COMMENTS, I didn't check if they'd been handled

- s2, software_version: what is the impact if the s/w is
updated twice a day, every day?

- 3.2.1 - why is the response status 201? That may be correct,
but seems to subtle if so to only state in an exmaple.

- s5, last para - "be very particular" is not good spec
language - what do you actually mean that can be implemented?

- thanks for section 6 - it's great to see thought being
devoted to these issues.

- Did the secdir review [1] get a response? And I think I
quite agree with Charlie's point#2 about versions.

   [1] https://www.ietf.org/mail-archive/web/secdir/current/msg05519.html

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 24 Apr 2015 13:09:45 +0100

So this is to follow up on my discuss point#2, which said:

In -28 you added a bit of text to 3.2.1. saying:

"The client or developer can check the values in the response to	
determine if the registration is sufficient for use (e.g., the	
registered "token_endpoint_auth_method" is supported by the client	
software) and determine a course of action appropriate for the client	
software.  The response to such a situation is out of scope for this	
specification but could include filing a report with the application	
developer or authorization server provider."

That new text may be fine, but I'd like to check that I
understand it correctly and that it addresses the issue
sensibly.

Say I'm a developer who writes and distributes a client
that uses this and I test it with the BIGreg.example.com
registration endpoint and it works, but for my application
to work I need a specific token_endpoint_auth_method, say
client_secret_basic.

Say time passes, and we discover that client_secret_basic
is bad for some reason and client_secret_supergood is
invented and gets used a lot.

At that point BIGreg.example.com would like to turn off
the (now-crappy) client_secret_basic and only allow use
of client_secret_supergood. If it does that, then new
installs of our application will fail at registration
time with an (opaque) error to the human user and we
need the application developer to do an update to add
client_secret_supergood.

Or, what seems more likely is that BIGreg.example.com
will have to keep offering the now insecure
client_secret_basic until essentially no interesting
applications remain that don't support the new, better
thing. And that's the bit I don't like so much.

This spec could (maybe, I'm not 100% sure) have been
written to allow for the client and registration endpoint
to first try to use the new better things and, if that
doesn't work, to try fallback to the old not so good
things, but that is not supported here afaics - once
the client sees response metadata it doesn't like,
there's no way for the client to say "bummer, I'd have
been fine if only you'd said foo and not bar, can we
try register again and use foo?"

And I also don't see how the client who is really stuck
can tell the registration endpoint "actually, I'm not
successfully registered because your said bar and I don't
like that bit of metadata" - won't that lead to our
BIGreg.example.com ending up with a misleading picture
of what clients were successfully registered?

So my question is: is all that really ok, or am I confused
in the above? (And confused is quite possible - this is
OAuth after all:-)

Cheers,
S.

---

From: Justin Richer <[email-masked]>
Date: Fri, 24 Apr 2015 08:20:14 -0400

Stephen, thanks for the comments.

We discussed but decided to stop short of a full back-and-forth 
multi-trip information negotiation protocol in order to keep things as 
simple as possible for the simple case. The model here is that the 
client *requests* a certain set of information in the registration, and 
the server *dictates* to the client what actually occurred. This is to 
allow sensible defaults for blank fields, and other mechanisms like 
that. Instead of just saying "no", the server here has an opportunity to 
do something slightly reasonable. It's up to the client if it agrees 
with the reasonableness, and most clients (in my experience) are going 
to be super dumb and just do what they're told by the server if they're 
able to. If they're unable to, they'll just fail to use the OAuth 
protocol with that AS and users will complain (rightly) of an 
incompatibility bug. A smarter client can try to re-register and see if 
that works instead, but the vast majority of OAuth clients are really 
dumb (by design).

However, there's a bit more to the story: As it turns out, when coupled 
with the management protocol and a discovery mechanism, you actually can 
do more of a negotiated registration with the existing mechanism: client 
says "I want foo", server says "you get bar", client sends an UPDATE 
that says "can I have baz instead?", and so forth. Without the update 
mechanism, you don't have a way to tie one registration request to a 
subsequent one. If you've got server capability discovery (such as is 
defined in OpenID Connect and still-ignored by this working group) then 
you've got the ability for a smart client to see which values might work 
ahead of time. This gets a little tricky with values that have 
relationships (such as grant_types and response_types), but it's still 
workable when they've got well-defined relationships (as is required in 
the Dyn Reg spec).

So it really is out of scope for us to say what the client does when it 
gets information back it doesn't want: it can ignore it, fail on it, or 
use it. With management and discovery, it can try to re-negotiate, but 
that's a fairly sophisticated behavior.

Hope this helps,
  -- Justin

On 4/24/2015 8:09 AM, Stephen Farrell wrote:
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 24 Apr 2015 13:24:04 +0100

> that's a fairly sophisticated behavior.

So could we just point at the relevant specs for that behaviour?
(Not normatively, and I don't care if they're not RFCs.)

S.

---

From: Justin Richer <[email-masked]>
Date: Fri, 24 Apr 2015 08:28:14 -0400

> I do wonder

It can get as bad as the web, which is pretty bad, but I hope we don't 
have to point that out in great detail in every RFC that deals with the 
web. :) I think the drive-by-download malware example is a good one, and 
we could add another concrete one if you've got an idea, but I think the 
advice we have is sound and actionable and we should avoid having this 
spec be a catalogue of "bad things what can happen on the web". If there 
is such a reference, I'm happy to point to it!

  -- Justin

---

From: Justin Richer <[email-masked]>
Date: Fri, 24 Apr 2015 08:30:34 -0400

> (Not normatively, and I don't care if they're not RFCs.)

OK, so are you asking for something like:

"If the server supports an update mechanism such as [Dyn-Reg-Management] 
and a discovery mechanism such as [OIDC-Discovery], then a smart client 
could use these components to renegotiate undesirable metadata values."

With both of these being informative references? I'm not opposed to it.

  -- Justin

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 24 Apr 2015 13:38:01 +0100

> With both of these being informative references? I'm not opposed to it.

That'd work for me, yes, thanks.

S.

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 24 Apr 2015 14:00:27 +0100

> is such a reference, I'm happy to point to it!

That's fair. I'm not aware of a really good reference tbh. I
wonder is there any relevant bits in the OAuth threat analysis?
(I've not looked.) Or just a pointer to some well known
incident might help.

But this is a non-blocking comment, so you should feel entirely
free to handle it as you think best.

Cheers,
S.

---

From: Justin Richer <[email-masked]>
Date: Fri, 24 Apr 2015 17:27:57 -0400

Stephen, I’ve worked on this this afternoon and this is my proposed text:

          The response to such a
           situation is out of scope for this specification but could include
           filing a report with the application developer or authorization
          server provider, attempted re-registration with different metadata
          values, or various other methods. For instance, if the server also
          supports a registration management mechanism such as that defined in
          <xref target="OAuth.Registration.Management"/>, the client or
          developer could attempt to update the registration with different
          metadata values. This process could also be aided by a service
          discovery protocol such as <xref target="OpenID.Discovery"/> which
          can list a server's capabilities, allowing a client to make a more
          informed registration request. The use of any such management or
          discovery system is OPTIONAL and outside the scope of this
          specification.

Does this text work for you?

 — Justin

> On Apr 24, 2015, at 8:38 AM, Stephen Farrell <[email-masked]> wrote:
> 
> 
>

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 24 Apr 2015 22:32:18 +0100

> Does this text work for you?

It does, nicely.

Thanks,
S.

---

From: Kathleen Moriarty <[email-masked]>
Date: Fri, 24 Apr 2015 18:01:57 -0400

Thank you, both!

-- 

Best regards,
Kathleen

---

From: Mike Jones <[email-masked]>
Date: Fri, 24 Apr 2015 22:25:27 +0000

Thanks all. Justin, please add a comma after the OpenID.Discovery reference.
________________________________
From: Kathleen Moriarty<mailto:[email-masked]>
Sent: ‎4/‎24/‎2015 3:02 PM
To: Stephen Farrell<mailto:[email-masked]>
Cc: Justin Richer<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; <[email-masked]><mailto:[email-masked]>; The IESG<mailto:[email-masked]>
Subject: Re: [OAUTH-WG] Stephen Farrell's Discuss on draft-ietf-oauth-dyn-reg-28: (with DISCUSS and COMMENT)

Thank you, both!

On Fri, Apr 24, 2015 at 5:32 PM, Stephen Farrell <[email-masked]<mailto:[email-masked]>> wrote:

It does, nicely.

Thanks,
S.

>
>  — Justin
>
>> On Apr 24, 2015, at 8:38 AM, Stephen Farrell <[email-masked]<mailto:[email-masked]>> wrote:
>>
>>
>>

--

Best regards,
Kathleen

---

From: Justin Richer <[email-masked]>
Date: Sat, 25 Apr 2015 08:13:19 -0400

Thanks for the catch. I’ll add that and put in a reference to BCP100 in the next revision.

 — Justin

> On Apr 24, 2015, at 6:25 PM, Mike Jones <[email-masked]> wrote:
> 
> From: Kathleen Moriarty <mailto:[email-masked]>
> To: Stephen Farrell <mailto:[email-masked]>
> Cc: Justin Richer <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>; <[email-masked]> <mailto:[email-masked]>; The IESG <mailto:[email-masked]>
> On Fri, Apr 24, 2015 at 5:32 PM, Stephen Farrell <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
> >> On Apr 24, 2015, at 8:38 AM, Stephen Farrell <[email-masked] <mailto:[email-masked]>> wrote:
> >>
> >>
> >>