mnot
commented
10 years ago julian.reschke@gmx.de commented:
From 2500:
tiny rephrasing (see #522)
Closed mnot closed 3 years ago
mnot
commented
10 years ago unassigned to 26In IETF LC to In IESG Evaluationmnot
commented
10 years ago 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.
to:
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.
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.
design to editorialmnot
commented
10 years ago julian.reschke@gmx.de changed description from:
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.
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.
to:
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.
Minor issues:
---- 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:~~ -- see http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1147.html ---- 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.
mnot
commented
10 years ago julian.reschke@gmx.de changed description from:
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.
Minor issues:
---- 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:~~ -- see http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1147.html ---- 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.
to:
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.
Minor issues:
---- 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:~~ -- see http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1147.html ---- 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.~~ - [2500](../commit/2500) ----- 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.
mnot
commented
10 years ago julian.reschke@gmx.de changed description from:
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.
Minor issues:
---- 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:~~ -- see http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1147.html ---- 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.~~ - [2500](../commit/2500) ----- 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.
to:
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.
Minor issues:
---- 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:~~ -- see http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1147.html ---- 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.~~ - [2500](../commit/2500) ----- ~~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".~~ - see http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1147.html ---- ~~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.~~ - see http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1147.html
mnot
commented
10 years ago @mnot commented:
Re: 4.1, I don't see any way to improve.
mnot
commented
10 years ago 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.
Minor issues:
---- 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:~~ -- see http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1147.html ---- 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.~~ - [2500](../commit/2500) ----- ~~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".~~ - see http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1147.html ---- ~~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.~~ - see http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1147.html
to:
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.
Minor issues:
---- 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:~~ -- see http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1147.html ---- ~~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)."~~ ''I believe the paragraph is fine the way it is right now.'' ---- ~~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.~~ - [2500](../commit/2500) ----- ~~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".~~ - see http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1147.html ---- ~~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.~~ - see http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1147.html
incorporatednew to closed
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.
Minor issues: