Skip to main content

Telechat Review of draft-ietf-httpbis-p7-auth-25
review-ietf-httpbis-p7-auth-25-genart-telechat-moriarty-2014-06-09-00

Request Review of draft-ietf-httpbis-p7-auth
Requested revision No specific revision (document currently at 26)
Type Telechat Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2013-12-17
Requested 2013-11-06
Authors Roy T. Fielding , Julian Reschke
I-D last updated 2014-06-09
Completed reviews Genart Last Call review of -24 by Kathleen Moriarty (diff)
Genart Telechat review of -25 by Kathleen Moriarty (diff)
Secdir Early review of -?? by Stephen Kent
Secdir Last Call review of -24 by Stephen Kent (diff)
Assignment Reviewer Kathleen Moriarty
State Completed
Request Telechat review on draft-ietf-httpbis-p7-auth by General Area Review Team (Gen-ART) Assigned
Reviewed revision 25 (document currently at 26)
Result Ready
Completed 2014-06-09
review-ietf-httpbis-p7-auth-25-genart-telechat-moriarty-2014-06-09-00
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