Fwd: Gen-art review of draft-ietf-httpbis-p7-auth-25

(FYI)


-------- Original Message --------
Subject: Gen-art review of  draft-ietf-httpbis-p7-auth-25
Resent-To: barryleiba@gmail.com, fielding@gbiv.com, 
julian.reschke@greenbytes.de, mnot@pobox.com,
Date: Mon, 18 Nov 2013 15:26:20 -0500
From: Moriarty, Kathleen <kathleen.moriarty@emc.com>
To: gen-art@ietf.org <gen-art@ietf.org>, iesg@ietf.org <iesg@ietf.org>, 
        draft-ietf-httpbis-p7-auth.all@tools.ietf.org 
<draft-ietf-httpbis-p7-auth.all@tools.ietf.org>
CC: fielding@gbiv.com <fielding@gbiv.com>, 
julian.reschke@greenbytes.de <julian.reschke@greenbytes.de>, 
ietf-http-wg@w3.org <ietf-http-wg@w3.org>

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

Received on Monday, 18 November 2013 21:01:14 UTC