RE: [Gen-art] Gen-art review of draft-ietf-httpbis-p7-auth-25

Hi Jari,

A question was put out to the mailing list and there was some push-back on adding the sentences provided as they were concerned with the length of the document.  I don't know what the final decision was from the WG though.

Thanks,
Kathleen

-----Original Message-----
From: Jari Arkko [mailto:jari.arkko@piuha.net] 
Sent: Thursday, December 19, 2013 5:45 AM
To: Moriarty, Kathleen
Cc: gen-art@ietf.org; iesg@ietf.org; draft-ietf-httpbis-p7-auth.all@tools.ietf.org; fielding@gbiv.com; ietf-http-wg@w3.org; julian.reschke@greenbytes.de
Subject: Re: [Gen-art] Gen-art review of draft-ietf-httpbis-p7-auth-25

Thank you Kathleen for your review! I agree with the comments, was there a response from the authors or the working group? 

Jari

On Nov 18, 2013, at 3:26 PM, "Moriarty, Kathleen" <kathleen.moriarty@emc.com> wrote:

> I am the assigned Gen-ART reviewer for this draft. For background on 
> Gen-ART, please see the FAQ at
> 
> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
> 
> Please resolve these comments along with any other Last Call comments 
> you may receive.
> 
> Document: draft-ietf-httpbis-p7-auth-25
> Reviewer: Kathleen Moriarty
> Review Date: November 18, 2013
> IETF LC End Date: 
> IESG Telechat date: 12/19
> 
> Summary: The draft is ready from a Gen-art perspective with a few nits to resolve.  I also added a security consideration with suggested text below.
> 
> Major issues:
> 
> 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 interoperability, so I think a keyword is important.  Unless there is another error message, one should be provided when the role access requirements are not met.  Users would expect this functionality.
> 
> 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:
> 
> Section 4.1, second to last paragraph.  Please consider rewording the content in parenthesis, it is difficult to read and probably found just be a separate sentence rather than included with the prior sentence in parenthesis.
> "If a request is authenticated and a realm specified, the same
>   credentials are presumed to be valid for all other requests within
>   this realm (assuming that the authentication scheme itself does not
>   require otherwise, such as credentials that vary according to a
>   challenge value or using synchronized clocks)."
> 
> 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.
> 
> 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".
> 
> 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 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.
> Perhaps something like the following:
> 
> When a web service is configured to use authentication, content from the application server requiring authentication MUST not be accessed until the authentication has completed successfully.
> 
> Thanks,
> Kathleen
> _______________________________________________
> Gen-art mailing list
> Gen-art@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art

Received on Thursday, 19 December 2013 18:45:50 UTC