#522, was: Fwd: Gen-art review of draft-ietf-httpbis-p7-auth-25

On 2013-11-18 22:00, Julian Reschke wrote:
> Minor issues:
>
> In section 2.1, in third to last paragraph, why is ought used here
> instead of a keyword?  This is a point that could help with

Because it is related to an untestable condition ("what it considers to 
be the most secure auth-scheme that it understands"),

The other one (choice of 403) really is not required to interop.

> ...

> Nits/editorial comments:
>
> Section 3.2.1 - please fix the run-on sentence, the first one as it is
> difficult to read.  Suggestion:
> From:
> If a server receives a request for an access-protected object, and an
>     acceptable Authorization header is not sent, the server responds with
>     a "401 Unauthorized" status code, and a WWW-Authenticate header as
>     per the framework defined above, which for the digest scheme is
>     utilized as follows:
> To:
> If a server receives a request for an access-protected object and an
>     acceptable Authorization header is not sent.  The server responds with
>     a "401 Unauthorized" status code and a WWW-Authenticate header as
>     per the framework defined above.  For the digest scheme, this is
>     utilized as follows:

That is text from RFC 2617, not httpbis-p7.

> ...
> Section 4.2, second paragraph, consider breaking the following sentence
> into two:
> From:
> However, if a recipient proxy needs to obtain its
>     own credentials by requesting them from a further outbound client, it
>     will generate its own 407 response, which might have the appearance
>     of forwarding the Proxy-Authenticate header field if both proxies use
>     the same challenge set.
> To:
> However, if a recipient proxy needs to obtain its
>     own credentials by requesting them from a further outbound client, it
>     will generate its own 407 response.  This might have the appearance
>     of forwarding the Proxy-Authenticate header field if both proxies use
>     the same challenge set.

Ack.

> Section 4.4, the last paragraph could be read more clearly with the
> following change:
> From:
> This header field contains two challenges; one for the "Newauth"
>     scheme with a realm value of "apps", and two additional parameters
>     "type" and "title", and another one for the "Basic" scheme with a
>     realm value of "simple".
> To:
> This header field contains two challenges; one for the "Newauth"scheme
>   with a realm value of "apps" and two additional parameters
>     "type" and "title", and the second for the "Basic" scheme with a
>     realm value of "simple".

I don't think this is an improvement.

> Section 6: Security Considerations
> Could you add in text to inform developers that content should not be
> accessed before authentication occurs when required?  I know this sounds

Please define "accessed". The server really can do whatever it wants as 
long as the protocol requirements are fulfilled.

> obvious, but I recently ran into this issue.  On a Mac, I am able to see
> that the application server/database information is actually loaded
> before I authenticate (sure there is a SQL injection happening here too)
> and the screen is slightly greyed out.  On a PC, it appears to block
> access, but this is a display thing rather than requiring the
> authentication to actually work prior to serving content.

To understand what's going on here we really need more information. 
Which browsers are used? Do you have HTTP traces?

> ...

Best regards, Julian

Received on Monday, 18 November 2013 21:19:31 UTC