Subject: [weirds] Ted Lemon's Discuss on draft-ietf-weirds-rdap-sec-10: (with DISCUSS)

From: "Ted Lemon" <[email-masked]>
Date: Wed, 29 Oct 2014 18:59:46 -0700

Ted Lemon has entered the following ballot position for
draft-ietf-weirds-rdap-sec-10: 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-weirds-rdap-sec/

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

As far as I can tell, this specification effectively relies on HTTP
authentication as its sole MTI mechanism, and leaves things like OAuth as
sort of "you could do this, but we aren't saying how."   I am deeply
uncomfortable with this, because HTTP authentication really sucks when
you are trying to make it work in a context where authentication is
optional.

I think if you want to rely on this mechanism, you need to give the
reader more guidance on how to make this work.   What I mean is that in
order to trigger the client to send authentication, you have to send back
a 401 Unauthorized HTTP response.   But that assumes that authentication
_is_ required, and it's not.   So how does the server know to send back
the HTTP unauthorized response?   The answer is that it does not, and so
you need to somehow signal to the client that it should send more
authentication info if it wants better information, while still returning
information in case the client has no credentials to offer.

This is probably doable, but simply relying on RFC 7235 without
explaining how to make it work isn't sufficient.

---

From: Richard Barnes <[email-masked]>
Date: Thu, 30 Oct 2014 00:39:35 -0700

> http://datatracker.ietf.org/doc/draft-ietf-weirds-rdap-sec/

This is a feature request, not a DISCUSS.

There are bazillions of HTTP servers out there today that get by just fine
with a binary, per-resource distinction between authorized and
unauthorized.  And I can see situations where that would make sense here
too.  For example, a server might not grant access to entity records
without authorization.

That said, I do expect that "add more fields to the JSON object if
authenticated" will be a common pattern here, so it might be useful to have
a standard mechanism for the server to hint that more data might be
available.  (Or it might not be useful -- if the client has credentials,
why didn't it use them the first time?)  It's also worth considering that
the hint itself might be privacy sensitive, in that it reveals that there
is more information than is being provided.

The point is that you're asking for a feature which is clearly
non-essential, and likely of negligible utility.  This is not an interop
problem.

--Richard

---

From: Ted Lemon <[email-masked]>
Date: Thu, 30 Oct 2014 08:33:02 -0400

On Oct 30, 2014, at 3:39 AM, Richard Barnes <[email-masked]> wrote:
> There are bazillions of HTTP servers out there today that get by just fine with a binary, per-resource distinction between authorized and unauthorized.  And I can see situations where that would make sense here too.  For example, a server might not grant access to entity records without authorization.

No, this isn't correct.   If you look at the base spec, it's clear that some queries may get one answer if authenticated, and a different answer if not authenticated.   That's not something that HTTP authentication supports without tweaks, so the security document needs to describe those tweaks.   The security document currently appears to be claiming to address this use case, but it clearly doesn't.   Hence the DISCUSS.

One way to address the DISCUSS would be to say "this security model does not support one of the use cases described in the base spec: returning different answers depending on whether or not the client has authenticated.   A mechanism for addressing this is left as future work."   I think that would be unfortunate, but it would resolve the DISCUSS.

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Thu, 30 Oct 2014 13:50:08 +0000

> -----Original Message-----
> From: weirds [mailto:[email-masked]] On Behalf Of Ted Lemon
> Sent: Wednesday, October 29, 2014 10:00 PM
> To: The IESG
> Cc: [email-masked]; weirds-
> [email-masked]; [email-masked]
> Subject: [weirds] Ted Lemon's Discuss on draft-ietf-weirds-rdap-sec-10:
> (with DISCUSS)
> 

Would adding something like this suffice?

"A client typically does not know in advance if a server requires client authentication to process a query. If a client sends a request for a query that can be processed without authentication information, a server can return an RDAP response consistent with local policies for unauthenticated access. If authentication is required, a server MUST return an HTTP 401 (Unauthorized) response to challenge the authorization of a user agent. The authentication process can then proceed as described in Section 2 of RFC 7235 [RFC7235]."

FWIW I noticed that I need to change the title of RFC 7235 where it's currently referenced. It should be "Hypertext Transfer Protocol (HTTP/1.1): Authentication".

Scott

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Thu, 30 Oct 2014 13:51:02 +0000

> Sent: Thursday, October 30, 2014 8:33 AM
> To: Richard Barnes
> [email-masked]; The IESG; [email-masked]
> Subject: Re: [weirds] Ted Lemon's Discuss on draft-ietf-weirds-rdap-
> sec-10: (with DISCUSS)
> 
> > There are bazillions of HTTP servers out there today that get by just
> fine with a binary, per-resource distinction between authorized and
> unauthorized.  And I can see situations where that would make sense
> here too.  For example, a server might not grant access to entity
> records without authorization.
> 
> No, this isn't correct.   If you look at the base spec, it's clear that
> some queries may get one answer if authenticated, and a different
> answer if not authenticated.   That's not something that HTTP
> authentication supports without tweaks, so the security document needs
> to describe those tweaks.   The security document currently appears to
> be claiming to address this use case, but it clearly doesn't.   Hence
> the DISCUSS.

I disagree with the "clearly doesn't" statement, so yes, let's have a discussion.

In Section 3.2 we have text that explicitly acknowledges the use case ("Server operators MAY offer varying degrees of access depending on policy and need in conjunction with the authentication methods described in Section 3.1"). There is no way I can describe the server-side response-building tweaks that might be made by every single server operator because there is no "one size fits all" approach in this space. Operators will provide service in accordance with local laws, local policies, and whatever agreements they happen to have in place with entities like ICANN. The document reflects that reality.

The answers that can be returned are described in json-response. Perhaps we need to add text there. I do not know what I can add to address this particular concern, which leads to:

> One way to address the DISCUSS would be to say "this security model
> does not support one of the use cases described in the base spec:
> returning different answers depending on whether or not the client has
> authenticated.   A mechanism for addressing this is left as future
> work."   I think that would be unfortunate, but it would resolve the
> DISCUSS.

I am open to adding text, but I do not agree with adding *this* text. The model described in rdap-sec acknowledges the use case. Could you be more specific about the additional detail that you think is missing? I don't see it described in the DISCUSS text. That's focused on authentication. I sent a suggestion for that comment a moment ago.

Scott

Scott

---

From: Ted Lemon <[email-masked]>
Date: Thu, 30 Oct 2014 11:06:49 -0400

> "A client typically does not know in advance if a server requires client authentication to process a query. If a client sends a request for a query that can be processed without authentication info…

No, that's how it works today.   The problem is that this doesn't address the use case where a client without credentials gets an answer, just not the same answer as it would have got if it had credentials.   There's no programmatic way to advise the client that it would benefit from sending credentials without completely denying access for clients that don't have credentials to send.   And if you notify the user out of band, there's still no protocol mechanism for providing credentials if you don't get an error code from the HTTP server.   The client could just supply them pre-emptively, but if you want clients to do that, you need to say so, and explain how to do it.

---

From: Richard Barnes <[email-masked]>
Date: Thu, 30 Oct 2014 08:53:09 -0700

On Thu, Oct 30, 2014 at 5:33 AM, Ted Lemon <[email-masked]> wrote:

> some queries may get one answer if authenticated, and a different answer if
> not authenticated.   That's not something that HTTP authentication supports
> without tweaks, so the security document needs to describe those tweaks.
>  The security document currently appears to be claiming to address this use
> case, but it clearly doesn't.   Hence the DISCUSS.
>

Your assertions here are obviously false.  Consider, for example:
  https://tools.ietf.org/wg/weirds/trac/wiki

It presents different content depending on whether the client is
authenticated or not.  If you are unauthenticated, you see the "login"
link.  If you are authenticated, it says "logged in as ...", and shows more
options.  Different content depending on authentication state.

> One way to address the DISCUSS would be to say "this security model does
> not support one of the use cases described in the base spec: returning
> different answers depending on whether or not the client has
> authenticated.   A mechanism for addressing this is left as future work."
>  I think that would be unfortunate, but it would resolve the DISCUSS

Returning different answers is fully supported, just like for the example
above.  The only thing that's missing is a hint to the client that it
should authenticate which is clearly a nice-to-have, not a requirement.

--Richard

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Thu, 30 Oct 2014 15:53:36 +0000

> From: Ted Lemon [mailto:[email-masked]]
> Sent: Thursday, October 30, 2014 11:07 AM
> To: Hollenbeck, Scott
> Cc: The IESG; [email-masked]; weirds-
> > "A client typically does not know in advance if a server requires
> client authentication to process a query. If a client sends a request
> for a query that can be processed without authentication information, a
> server can return an RDAP response consistent with local policies for
> unauthenticated access. If authentication is required, a server MUST
> return an HTTP 401 (Unauthorized) response to challenge the
> authorization of a user agent. The authentication process can then
> proceed as described in Section 2 of RFC 7235 [RFC7235]."
> 
> No, that's how it works today.   The problem is that this doesn't
> address the use case where a client without credentials gets an answer,
> just not the same answer as it would have got if it had credentials.
> There's no programmatic way to advise the client that it would benefit
> from sending credentials without completely denying access for clients
> that don't have credentials to send.

Yes, there is. The json-response document describes status values (section 10.2.2) to indicate that a response element is private, redacted, or obscured. If I'm a client and I see those status values in a response I know that I might benefit (receive more information) by sending credentials. Which leads us to...

> And if you notify the user out
> of band, there's still no protocol mechanism for providing credentials
> if you don't get an error code from the HTTP server.   The client could
> just supply them pre-emptively, but if you want clients to do that, you
> need to say so, and explain how to do it.

We're not suggesting out of band notification or non-standard HTTP behavior. RFC 2617 says "A client MAY preemptively send the corresponding Authorization header with requests for resources in that space without receipt of another challenge from the server". This text doesn't appear in RFC 7235, which now says "The "Authorization" header field allows a user agent to authenticate itself with an origin server -- usually, but not necessarily, after receiving a 401 (Unauthorized) response."

Would it be sufficient to add text that refers to the status codes and provides instruction for sending the authorization header to preemptively provide credentials?

Scott

---

From: Ted Lemon <[email-masked]>
Date: Thu, 30 Oct 2014 12:09:40 -0400

On Oct 30, 2014, at 11:53 AM, Richard Barnes <[email-masked]> wrote:
> It presents different content depending on whether the client is authenticated or not.  If you are unauthenticated, you see the "login" link.  If you are authenticated, it says "logged in as ...", and shows more options.  Different content depending on authentication state.

This is a crappy example, because the wiki login mechanism is actually pretty broken--frequently when I submit a change after logging in, it complains that I'm not logged in.   But admittedly that is likely browser brokenness, so not really the protocol spec's problem.   The reason I raised the discuss is that my experience is that this is hard to get right, and usually not gotten right.   I think some language in the spec to make this clearer would be good, but I've cleared my discuss on the basis of your response and Pete's explanation on the call.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 30 Oct 2014 12:13:08 -0400

> Would it be sufficient to add text that refers to the status codes and provides instruction for sending the authorization header to preemptively provide credentials?

It would be nice to have some text saying "servers may provide a login page that triggers HTTP authentication; clients should continue sending the http authentication header once they receive an initial 401 response from the HTTP server, as long as the scheme portion of the URL doesn't change."   I've seen clients get this wrong, and speaking as someone who's tried to make this work, the login mechanism isn't obvious based on reading the relevant RFC.

---

From: Andy Newton <[email-masked]>
Date: Thu, 30 Oct 2014 16:57:45 +0000

On Oct 30, 2014, at 11:53 AM, Hollenbeck, Scott <[email-masked]<mailto:[email-masked]>> wrote:

Yes, there is. The json-response document describes status values (section 10.2.2) to indicate that a response element is private, redacted, or obscured. If I'm a client and I see those status values in a response I know that I might benefit (receive more information) by sending credentials. Which leads us to…

Section 10.2.1 is also relevant to indicating the response would be different if credentials were given.

-andy

---

From: Ted Lemon <[email-masked]>
Date: Thu, 30 Oct 2014 13:05:14 -0400

> Section 10.2.1 is also relevant to indicating the response would be different if credentials were given.

That doesn't help, because it's a signal to the user, and if the user agent and/or server don't provide a way to trigger the credentials being sent, the user has no action to take.

---

From: "John Levine" <[email-masked]>
Date: 30 Oct 2014 21:20:02 -0000

>It would be nice to have some text saying "servers may provide a login page that triggers
>HTTP authentication; clients should continue sending the http authentication header once
>they receive an initial 401 response from the HTTP server, as long as the scheme portion
>of the URL doesn't change."   I've seen clients get this wrong, and speaking as someone
>who's tried to make this work, the login mechanism isn't obvious based on reading the
>relevant RFC.

A lot of the clients for RDAP are going to be using wget or curl or
python scripts, not web browsers.  Remember that the results are JSON, so browser
isn't going to produce very nice results unless it's already running a Javascript
thing to interpret and format the JSON.

It occurs to me that the obvious workaround is to use a different URL
for authenticated access.  You have to make some out of band
arrangements to get the login credentials, so at the same time they
can tell you what URL to use.

R's,
John

---

From: Ted Lemon <[email-masked]>
Date: Thu, 30 Oct 2014 17:25:32 -0400

> can tell you what URL to use.

That would certainly work too.