search

httpwg / httpbis-issues

1 stars 1 forks source link

SECDIR review of draft-ietf-httpbis-p7-auth-24 #510

Closed mnot closed 3 years ago

mnot commented 10 years ago

Stephen Kent:

I reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG.These comments were written primarily for the benefit of the security area directors.Document editors, WG chairs and ADs should treat these comments just like any other last call comments.

The document obsoletes RFC 2616 and updates 2617. It says that it “defines HTTP/1.1 access control and authentication.” I have not been tracking httpbis closely enough to know the specific motivations for generating this doc, so my review is unbiased by that context.

~~I see that “ought” is used in two places on page 6, but not in uppercase as per RFC 6919. The authors should revisit the use of this term here.~~ - see http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/0411.html

~~Also on page 6 it appears that the phrase “receipt of” was omitted in two places:~~

Upon <> a request for a protected resource that omits credentials

Likewise, upon <> a request that requires authentication by proxies - see 2449

Later on page 6 the text says:

The HTTP protocol does not restrict applications to this simple challenge-response framework for access authentication. Additional mechanisms MAY be used, such as encryption at the transport level or via message encapsulation, and with additional header fields specifying authentication information. However, such additional mechanisms are not defined by this specification.

~~Encryption is not, per se, an authentication mechanism. Please revise this text.~~ - see thread starting at http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/0437.html and 2463

In Section 2.2 the text says:

The protection space determines the domain over which credentials can be automatically applied. If a prior request has been authorized, the user agent MAY reuse the same credentials for all other requests within that protection space for a period of time determined by the authentication scheme, parameters, and/or user preference.

~~I’m not clear how user preferences fit into this process. It would seem that the server would decide whether a prior authorization is valid for later requests, not a user.~~ - see http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/0426.html

~~The end of Section 2.2 includes the word “might” but not uppercase, as per RFC 6919. I again suggest that the authors reconsider using this term in this context.~~ - see http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/0411.html

In Section 4.3, the text says:

A proxy MAY relay the credentials from the client request to the next proxy if that is the mechanism by which the proxies cooperatively authenticate a given request.

~~If, as stated here, a set of proxies cooperatively authenticate a request, then isn’t this a MUST vs. a MAY?~~ - see http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/0436.html

In Section 4.4 the text says:

Note: The challenge grammar production uses the list syntax as well. Therefore, a sequence of comma, whitespace, and comma can be considered both as applying to the preceding challenge, or to be an empty entry in the list of challenges. In practice, this ambiguity does not affect the semantics of the header field value

~~Should “both” be “either” in the above text? Does the potentially ambiguous construct ever take on both meanings simultaneously?~~ - see 2450 and http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/0416.html

~~Section 5.1.2 uses “ought” when discussing definitions for new authentication schemes. See comments above re use of this term.The same section also uses the phrase “need to” twice, where MUST seems appropriate.~~ - see http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/0411.html

~~The Security Considerations section (6) is about one page in length. It references the SC sections in two in I-Ds: draft-ietf-httpbis-p1-messaging-24 and draft-ietf-httpbis-p2-semantics-24. Both of these I-Ds have non-trivial SC sections, but one cannot say that this document has an acceptable SC section until those documents are finalized. They are both normative references, so this doc will nor progress independently, but there will still be a need to revisit this SC when those SCs are finalized.~~

~~The SC section here addresses only two issues: purging credentials in clients and user agents, and protection spaces. The discussion of the former topic does not discuss how credential purging applies to proxies. Also, it is not clear that a user control for credential purging will have the desired effect given a potentially complex GUI environment. The discussion of protection spaces provides useful suggestions on how to minimize credential exposure.~~

~~I was a bit surprised that there was no advice deprecating the use of passwords as credentials, if only to make a statement on this topic.~~ - see http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/0412.html

Reported by julian.reschke@gmx.de, migrated from https://trac.ietf.org/trac/httpbis/ticket/510

mnot commented 10 years ago

julian.reschke@gmx.de changed description from:

Stephen Kent:

I reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG.These comments were written primarily for the benefit of the security area directors.Document editors, WG chairs and ADs should treat these comments just like any other last call comments.

The document obsoletes RFC 2616 and updates 2617. It says that it “defines HTTP/1.1 access control and authentication.” I have not been tracking httpbis closely enough to know the specific motivations for generating this doc, so my review is unbiased by that context.

I see that “ought” is used in two places on page 6, but not in uppercase as per RFC 6919. The authors should revisit the use of this term here.

Also on page 6 it appears that the phrase “receipt of” was omitted in two places:

Upon <> a request for a protected resource that omits credentials

Likewise, upon <> a request that requires authentication by proxies

Later on page 6 the text says:

The HTTP protocol does not restrict applications to this simple challenge-response framework for access authentication. Additional mechanisms MAY be used, such as encryption at the transport level or via message encapsulation, and with additional header fields specifying authentication information.However, such additional mechanisms are not defined by this specification.

Encryption is not, per se, an authentication mechanism. Please revise this text.

In Section 2.2 the text says:

The protection space determines the domain over which credentials can be automatically applied. If a prior request has been authorized, the user agent MAY reuse the same credentials for all other requests within that protection space for a period of time determined by the authentication scheme, parameters, and/or user preference.

I’m not clear how user preferences fit into this process. It would seem that the server would decide whether a prior authorization is valid for later requests, not a user.

The end of Section 2.2 includes the word “might” but not uppercase, as per RFC 6919. I again suggest that the authors reconsider using this term in this context.

In Section 4.3, the text says:

A proxy MAY relay the credentials from the client request to the next proxy if that is the mechanism by which the proxies cooperatively authenticate a given request.

If, as stated here, a set of proxies cooperatively authenticate a request, then isn’t this a MUST vs. a MAY?

In Section 4.4 the text says:

Note: The challenge grammar production uses the list syntax as well. Therefore, a sequence of comma, whitespace, and comma can be considered both as applying to the preceding challenge, or to be an empty entry in the list of challenges. In practice, this ambiguity does not affect the semantics of the header field value

Should “both” be “either” in the above text? Does the potentially ambiguous construct ever take on both meanings simultaneously?

Section 5.1.2 uses “ought” when discussing definitions for new authentication schemes. See comments above re use of this term.The same section also uses the phrase “need to” twice, where MUST seems appropriate.

The Security Considerations section (6) is about one page in length. It references the SC sections in two in I-Ds: draft-ietf-httpbis-p1-messaging-24 and draft-ietf-httpbis-p2-semantics-24. Both of these I-Ds have non-trivial SC sections, but one cannot say that this document has an acceptable SC section until those documents are finalized. They are both normative references, so this doc will nor progress independently, but there will still be a need to revisit this SC when those SCs are finalized.

The SC section here addresses only two issues: purging credentials in clients and user agents, and protection spaces. The discussion of the former topic does not discuss how credential purging applies to proxies. Also, it is not clear that a user control for credential purging will have the desired effect given a potentially complex GUI environment. The discussion of protection spaces provides useful suggestions on how to minimize credential exposure.

I was a bit surprised that there was no advice deprecating the use of passwords as credentials, if only to make a statement on this topic.

to:

Stephen Kent:

I reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG.These comments were written primarily for the benefit of the security area directors.Document editors, WG chairs and ADs should treat these comments just like any other last call comments.

The document obsoletes RFC 2616 and updates 2617. It says that it “defines HTTP/1.1 access control and authentication.” I have not been tracking httpbis closely enough to know the specific motivations for generating this doc, so my review is unbiased by that context.

I see that “ought” is used in two places on page 6, but not in uppercase as per RFC 6919. The authors should revisit the use of this term here.

Also on page 6 it appears that the phrase “receipt of” was omitted in two places:

Upon <> a request for a protected resource that omits credentials

Likewise, upon <> a request that requires authentication by proxies

Later on page 6 the text says:

The HTTP protocol does not restrict applications to this simple challenge-response framework for access authentication. Additional mechanisms MAY be used, such as encryption at the transport level or via message encapsulation, and with additional header fields specifying authentication information. However, such additional mechanisms are not defined by this specification.

Encryption is not, per se, an authentication mechanism. Please revise this text.

In Section 2.2 the text says:

The protection space determines the domain over which credentials can be automatically applied. If a prior request has been authorized, the user agent MAY reuse the same credentials for all other requests within that protection space for a period of time determined by the authentication scheme, parameters, and/or user preference.

I’m not clear how user preferences fit into this process. It would seem that the server would decide whether a prior authorization is valid for later requests, not a user.

The end of Section 2.2 includes the word “might” but not uppercase, as per RFC 6919. I again suggest that the authors reconsider using this term in this context.

In Section 4.3, the text says:

A proxy MAY relay the credentials from the client request to the next proxy if that is the mechanism by which the proxies cooperatively authenticate a given request.

If, as stated here, a set of proxies cooperatively authenticate a request, then isn’t this a MUST vs. a MAY?

In Section 4.4 the text says:

Note: The challenge grammar production uses the list syntax as well. Therefore, a sequence of comma, whitespace, and comma can be considered both as applying to the preceding challenge, or to be an empty entry in the list of challenges. In practice, this ambiguity does not affect the semantics of the header field value

Should “both” be “either” in the above text? Does the potentially ambiguous construct ever take on both meanings simultaneously?

Section 5.1.2 uses “ought” when discussing definitions for new authentication schemes. See comments above re use of this term.The same section also uses the phrase “need to” twice, where MUST seems appropriate.

The Security Considerations section (6) is about one page in length. It references the SC sections in two in I-Ds: draft-ietf-httpbis-p1-messaging-24 and draft-ietf-httpbis-p2-semantics-24. Both of these I-Ds have non-trivial SC sections, but one cannot say that this document has an acceptable SC section until those documents are finalized. They are both normative references, so this doc will nor progress independently, but there will still be a need to revisit this SC when those SCs are finalized.

The SC section here addresses only two issues: purging credentials in clients and user agents, and protection spaces. The discussion of the former topic does not discuss how credential purging applies to proxies. Also, it is not clear that a user control for credential purging will have the desired effect given a potentially complex GUI environment. The discussion of protection spaces provides useful suggestions on how to minimize credential exposure.

I was a bit surprised that there was no advice deprecating the use of passwords as credentials, if only to make a statement on this topic.

mnot commented 10 years ago

julian.reschke@gmx.de changed description from:

Stephen Kent:

I reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG.These comments were written primarily for the benefit of the security area directors.Document editors, WG chairs and ADs should treat these comments just like any other last call comments.

The document obsoletes RFC 2616 and updates 2617. It says that it “defines HTTP/1.1 access control and authentication.” I have not been tracking httpbis closely enough to know the specific motivations for generating this doc, so my review is unbiased by that context.

I see that “ought” is used in two places on page 6, but not in uppercase as per RFC 6919. The authors should revisit the use of this term here.

Also on page 6 it appears that the phrase “receipt of” was omitted in two places:

Upon <> a request for a protected resource that omits credentials

Likewise, upon <> a request that requires authentication by proxies

Later on page 6 the text says:

The HTTP protocol does not restrict applications to this simple challenge-response framework for access authentication. Additional mechanisms MAY be used, such as encryption at the transport level or via message encapsulation, and with additional header fields specifying authentication information. However, such additional mechanisms are not defined by this specification.

Encryption is not, per se, an authentication mechanism. Please revise this text.

In Section 2.2 the text says:

The protection space determines the domain over which credentials can be automatically applied. If a prior request has been authorized, the user agent MAY reuse the same credentials for all other requests within that protection space for a period of time determined by the authentication scheme, parameters, and/or user preference.

I’m not clear how user preferences fit into this process. It would seem that the server would decide whether a prior authorization is valid for later requests, not a user.

The end of Section 2.2 includes the word “might” but not uppercase, as per RFC 6919. I again suggest that the authors reconsider using this term in this context.

In Section 4.3, the text says:

A proxy MAY relay the credentials from the client request to the next proxy if that is the mechanism by which the proxies cooperatively authenticate a given request.

If, as stated here, a set of proxies cooperatively authenticate a request, then isn’t this a MUST vs. a MAY?

In Section 4.4 the text says:

Note: The challenge grammar production uses the list syntax as well. Therefore, a sequence of comma, whitespace, and comma can be considered both as applying to the preceding challenge, or to be an empty entry in the list of challenges. In practice, this ambiguity does not affect the semantics of the header field value

Should “both” be “either” in the above text? Does the potentially ambiguous construct ever take on both meanings simultaneously?

Section 5.1.2 uses “ought” when discussing definitions for new authentication schemes. See comments above re use of this term.The same section also uses the phrase “need to” twice, where MUST seems appropriate.

The Security Considerations section (6) is about one page in length. It references the SC sections in two in I-Ds: draft-ietf-httpbis-p1-messaging-24 and draft-ietf-httpbis-p2-semantics-24. Both of these I-Ds have non-trivial SC sections, but one cannot say that this document has an acceptable SC section until those documents are finalized. They are both normative references, so this doc will nor progress independently, but there will still be a need to revisit this SC when those SCs are finalized.

The SC section here addresses only two issues: purging credentials in clients and user agents, and protection spaces. The discussion of the former topic does not discuss how credential purging applies to proxies. Also, it is not clear that a user control for credential purging will have the desired effect given a potentially complex GUI environment. The discussion of protection spaces provides useful suggestions on how to minimize credential exposure.

I was a bit surprised that there was no advice deprecating the use of passwords as credentials, if only to make a statement on this topic.

to:

Stephen Kent:

I reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG.These comments were written primarily for the benefit of the security area directors.Document editors, WG chairs and ADs should treat these comments just like any other last call comments.

The document obsoletes RFC 2616 and updates 2617. It says that it “defines HTTP/1.1 access control and authentication.” I have not been tracking httpbis closely enough to know the specific motivations for generating this doc, so my review is unbiased by that context.

~~I see that “ought” is used in two places on page 6, but not in uppercase as per RFC 6919. The authors should revisit the use of this term here.~~ - see http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/0411.html

Also on page 6 it appears that the phrase “receipt of” was omitted in two places:

Upon <> a request for a protected resource that omits credentials

Likewise, upon <> a request that requires authentication by proxies

Later on page 6 the text says:

The HTTP protocol does not restrict applications to this simple challenge-response framework for access authentication. Additional mechanisms MAY be used, such as encryption at the transport level or via message encapsulation, and with additional header fields specifying authentication information. However, such additional mechanisms are not defined by this specification.

Encryption is not, per se, an authentication mechanism. Please revise this text.

In Section 2.2 the text says:

The protection space determines the domain over which credentials can be automatically applied. If a prior request has been authorized, the user agent MAY reuse the same credentials for all other requests within that protection space for a period of time determined by the authentication scheme, parameters, and/or user preference.

I’m not clear how user preferences fit into this process. It would seem that the server would decide whether a prior authorization is valid for later requests, not a user.

~~The end of Section 2.2 includes the word “might” but not uppercase, as per RFC 6919. I again suggest that the authors reconsider using this term in this context.~~ - see http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/0411.html

In Section 4.3, the text says:

A proxy MAY relay the credentials from the client request to the next proxy if that is the mechanism by which the proxies cooperatively authenticate a given request.

If, as stated here, a set of proxies cooperatively authenticate a request, then isn’t this a MUST vs. a MAY?

In Section 4.4 the text says:

Note: The challenge grammar production uses the list syntax as well. Therefore, a sequence of comma, whitespace, and comma can be considered both as applying to the preceding challenge, or to be an empty entry in the list of challenges. In practice, this ambiguity does not affect the semantics of the header field value

Should “both” be “either” in the above text? Does the potentially ambiguous construct ever take on both meanings simultaneously?

~~Section 5.1.2 uses “ought” when discussing definitions for new authentication schemes. See comments above re use of this term.The same section also uses the phrase “need to” twice, where MUST seems appropriate.~~ - see http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/0411.html

The Security Considerations section (6) is about one page in length. It references the SC sections in two in I-Ds: draft-ietf-httpbis-p1-messaging-24 and draft-ietf-httpbis-p2-semantics-24. Both of these I-Ds have non-trivial SC sections, but one cannot say that this document has an acceptable SC section until those documents are finalized. They are both normative references, so this doc will nor progress independently, but there will still be a need to revisit this SC when those SCs are finalized.

The SC section here addresses only two issues: purging credentials in clients and user agents, and protection spaces. The discussion of the former topic does not discuss how credential purging applies to proxies. Also, it is not clear that a user control for credential purging will have the desired effect given a potentially complex GUI environment. The discussion of protection spaces provides useful suggestions on how to minimize credential exposure.

I was a bit surprised that there was no advice deprecating the use of passwords as credentials, if only to make a statement on this topic.

mnot commented 10 years ago

julian.reschke@gmx.de commented:

From 2449:

s/upon a request/upon receipt of a request/ (see #510)

mnot commented 10 years ago

julian.reschke@gmx.de changed description from:

Stephen Kent:

I reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG.These comments were written primarily for the benefit of the security area directors.Document editors, WG chairs and ADs should treat these comments just like any other last call comments.

The document obsoletes RFC 2616 and updates 2617. It says that it “defines HTTP/1.1 access control and authentication.” I have not been tracking httpbis closely enough to know the specific motivations for generating this doc, so my review is unbiased by that context.

~~I see that “ought” is used in two places on page 6, but not in uppercase as per RFC 6919. The authors should revisit the use of this term here.~~ - see http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/0411.html

Also on page 6 it appears that the phrase “receipt of” was omitted in two places:

Upon <> a request for a protected resource that omits credentials

Likewise, upon <> a request that requires authentication by proxies

Later on page 6 the text says:

The HTTP protocol does not restrict applications to this simple challenge-response framework for access authentication. Additional mechanisms MAY be used, such as encryption at the transport level or via message encapsulation, and with additional header fields specifying authentication information. However, such additional mechanisms are not defined by this specification.

Encryption is not, per se, an authentication mechanism. Please revise this text.

In Section 2.2 the text says:

The protection space determines the domain over which credentials can be automatically applied. If a prior request has been authorized, the user agent MAY reuse the same credentials for all other requests within that protection space for a period of time determined by the authentication scheme, parameters, and/or user preference.

I’m not clear how user preferences fit into this process. It would seem that the server would decide whether a prior authorization is valid for later requests, not a user.

~~The end of Section 2.2 includes the word “might” but not uppercase, as per RFC 6919. I again suggest that the authors reconsider using this term in this context.~~ - see http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/0411.html

In Section 4.3, the text says:

A proxy MAY relay the credentials from the client request to the next proxy if that is the mechanism by which the proxies cooperatively authenticate a given request.

If, as stated here, a set of proxies cooperatively authenticate a request, then isn’t this a MUST vs. a MAY?

In Section 4.4 the text says:

Note: The challenge grammar production uses the list syntax as well. Therefore, a sequence of comma, whitespace, and comma can be considered both as applying to the preceding challenge, or to be an empty entry in the list of challenges. In practice, this ambiguity does not affect the semantics of the header field value

Should “both” be “either” in the above text? Does the potentially ambiguous construct ever take on both meanings simultaneously?

~~Section 5.1.2 uses “ought” when discussing definitions for new authentication schemes. See comments above re use of this term.The same section also uses the phrase “need to” twice, where MUST seems appropriate.~~ - see http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/0411.html

The Security Considerations section (6) is about one page in length. It references the SC sections in two in I-Ds: draft-ietf-httpbis-p1-messaging-24 and draft-ietf-httpbis-p2-semantics-24. Both of these I-Ds have non-trivial SC sections, but one cannot say that this document has an acceptable SC section until those documents are finalized. They are both normative references, so this doc will nor progress independently, but there will still be a need to revisit this SC when those SCs are finalized.

The SC section here addresses only two issues: purging credentials in clients and user agents, and protection spaces. The discussion of the former topic does not discuss how credential purging applies to proxies. Also, it is not clear that a user control for credential purging will have the desired effect given a potentially complex GUI environment. The discussion of protection spaces provides useful suggestions on how to minimize credential exposure.

I was a bit surprised that there was no advice deprecating the use of passwords as credentials, if only to make a statement on this topic.

to:

Stephen Kent:

I reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG.These comments were written primarily for the benefit of the security area directors.Document editors, WG chairs and ADs should treat these comments just like any other last call comments.

The document obsoletes RFC 2616 and updates 2617. It says that it “defines HTTP/1.1 access control and authentication.” I have not been tracking httpbis closely enough to know the specific motivations for generating this doc, so my review is unbiased by that context.

~~I see that “ought” is used in two places on page 6, but not in uppercase as per RFC 6919. The authors should revisit the use of this term here.~~ - see http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/0411.html

~~Also on page 6 it appears that the phrase “receipt of” was omitted in two places:~~

Upon <> a request for a protected resource that omits credentials

Likewise, upon <> a request that requires authentication by proxies - see 2449

Later on page 6 the text says:

The HTTP protocol does not restrict applications to this simple challenge-response framework for access authentication. Additional mechanisms MAY be used, such as encryption at the transport level or via message encapsulation, and with additional header fields specifying authentication information. However, such additional mechanisms are not defined by this specification.

Encryption is not, per se, an authentication mechanism. Please revise this text.

In Section 2.2 the text says:

The protection space determines the domain over which credentials can be automatically applied. If a prior request has been authorized, the user agent MAY reuse the same credentials for all other requests within that protection space for a period of time determined by the authentication scheme, parameters, and/or user preference.

I’m not clear how user preferences fit into this process. It would seem that the server would decide whether a prior authorization is valid for later requests, not a user.

~~The end of Section 2.2 includes the word “might” but not uppercase, as per RFC 6919. I again suggest that the authors reconsider using this term in this context.~~ - see http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/0411.html

In Section 4.3, the text says:

A proxy MAY relay the credentials from the client request to the next proxy if that is the mechanism by which the proxies cooperatively authenticate a given request.

If, as stated here, a set of proxies cooperatively authenticate a request, then isn’t this a MUST vs. a MAY?

In Section 4.4 the text says:

Note: The challenge grammar production uses the list syntax as well. Therefore, a sequence of comma, whitespace, and comma can be considered both as applying to the preceding challenge, or to be an empty entry in the list of challenges. In practice, this ambiguity does not affect the semantics of the header field value

Should “both” be “either” in the above text? Does the potentially ambiguous construct ever take on both meanings simultaneously?

~~Section 5.1.2 uses “ought” when discussing definitions for new authentication schemes. See comments above re use of this term.The same section also uses the phrase “need to” twice, where MUST seems appropriate.~~ - see http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/0411.html

The Security Considerations section (6) is about one page in length. It references the SC sections in two in I-Ds: draft-ietf-httpbis-p1-messaging-24 and draft-ietf-httpbis-p2-semantics-24. Both of these I-Ds have non-trivial SC sections, but one cannot say that this document has an acceptable SC section until those documents are finalized. They are both normative references, so this doc will nor progress independently, but there will still be a need to revisit this SC when those SCs are finalized.

The SC section here addresses only two issues: purging credentials in clients and user agents, and protection spaces. The discussion of the former topic does not discuss how credential purging applies to proxies. Also, it is not clear that a user control for credential purging will have the desired effect given a potentially complex GUI environment. The discussion of protection spaces provides useful suggestions on how to minimize credential exposure.

I was a bit surprised that there was no advice deprecating the use of passwords as credentials, if only to make a statement on this topic.

mnot commented 10 years ago

julian.reschke@gmx.de changed description from:

Stephen Kent:

I reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG.These comments were written primarily for the benefit of the security area directors.Document editors, WG chairs and ADs should treat these comments just like any other last call comments.

The document obsoletes RFC 2616 and updates 2617. It says that it “defines HTTP/1.1 access control and authentication.” I have not been tracking httpbis closely enough to know the specific motivations for generating this doc, so my review is unbiased by that context.

~~I see that “ought” is used in two places on page 6, but not in uppercase as per RFC 6919. The authors should revisit the use of this term here.~~ - see http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/0411.html

~~Also on page 6 it appears that the phrase “receipt of” was omitted in two places:~~

Upon <> a request for a protected resource that omits credentials

Likewise, upon <> a request that requires authentication by proxies - see 2449

Later on page 6 the text says:

The HTTP protocol does not restrict applications to this simple challenge-response framework for access authentication. Additional mechanisms MAY be used, such as encryption at the transport level or via message encapsulation, and with additional header fields specifying authentication information. However, such additional mechanisms are not defined by this specification.

Encryption is not, per se, an authentication mechanism. Please revise this text.

In Section 2.2 the text says:

The protection space determines the domain over which credentials can be automatically applied. If a prior request has been authorized, the user agent MAY reuse the same credentials for all other requests within that protection space for a period of time determined by the authentication scheme, parameters, and/or user preference.

I’m not clear how user preferences fit into this process. It would seem that the server would decide whether a prior authorization is valid for later requests, not a user.

~~The end of Section 2.2 includes the word “might” but not uppercase, as per RFC 6919. I again suggest that the authors reconsider using this term in this context.~~ - see http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/0411.html

In Section 4.3, the text says:

A proxy MAY relay the credentials from the client request to the next proxy if that is the mechanism by which the proxies cooperatively authenticate a given request.

If, as stated here, a set of proxies cooperatively authenticate a request, then isn’t this a MUST vs. a MAY?

In Section 4.4 the text says:

Note: The challenge grammar production uses the list syntax as well. Therefore, a sequence of comma, whitespace, and comma can be considered both as applying to the preceding challenge, or to be an empty entry in the list of challenges. In practice, this ambiguity does not affect the semantics of the header field value

Should “both” be “either” in the above text? Does the potentially ambiguous construct ever take on both meanings simultaneously?

~~Section 5.1.2 uses “ought” when discussing definitions for new authentication schemes. See comments above re use of this term.The same section also uses the phrase “need to” twice, where MUST seems appropriate.~~ - see http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/0411.html

The Security Considerations section (6) is about one page in length. It references the SC sections in two in I-Ds: draft-ietf-httpbis-p1-messaging-24 and draft-ietf-httpbis-p2-semantics-24. Both of these I-Ds have non-trivial SC sections, but one cannot say that this document has an acceptable SC section until those documents are finalized. They are both normative references, so this doc will nor progress independently, but there will still be a need to revisit this SC when those SCs are finalized.

The SC section here addresses only two issues: purging credentials in clients and user agents, and protection spaces. The discussion of the former topic does not discuss how credential purging applies to proxies. Also, it is not clear that a user control for credential purging will have the desired effect given a potentially complex GUI environment. The discussion of protection spaces provides useful suggestions on how to minimize credential exposure.

I was a bit surprised that there was no advice deprecating the use of passwords as credentials, if only to make a statement on this topic.

to:

Stephen Kent:

I reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG.These comments were written primarily for the benefit of the security area directors.Document editors, WG chairs and ADs should treat these comments just like any other last call comments.

The document obsoletes RFC 2616 and updates 2617. It says that it “defines HTTP/1.1 access control and authentication.” I have not been tracking httpbis closely enough to know the specific motivations for generating this doc, so my review is unbiased by that context.

~~I see that “ought” is used in two places on page 6, but not in uppercase as per RFC 6919. The authors should revisit the use of this term here.~~ - see http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/0411.html

~~Also on page 6 it appears that the phrase “receipt of” was omitted in two places:~~

Upon <> a request for a protected resource that omits credentials

Likewise, upon <> a request that requires authentication by proxies - see 2449

Later on page 6 the text says:

The HTTP protocol does not restrict applications to this simple challenge-response framework for access authentication. Additional mechanisms MAY be used, such as encryption at the transport level or via message encapsulation, and with additional header fields specifying authentication information. However, such additional mechanisms are not defined by this specification.

Encryption is not, per se, an authentication mechanism. Please revise this text.

In Section 2.2 the text says:

The protection space determines the domain over which credentials can be automatically applied. If a prior request has been authorized, the user agent MAY reuse the same credentials for all other requests within that protection space for a period of time determined by the authentication scheme, parameters, and/or user preference.

I’m not clear how user preferences fit into this process. It would seem that the server would decide whether a prior authorization is valid for later requests, not a user.

~~The end of Section 2.2 includes the word “might” but not uppercase, as per RFC 6919. I again suggest that the authors reconsider using this term in this context.~~ - see http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/0411.html

In Section 4.3, the text says:

A proxy MAY relay the credentials from the client request to the next proxy if that is the mechanism by which the proxies cooperatively authenticate a given request.

If, as stated here, a set of proxies cooperatively authenticate a request, then isn’t this a MUST vs. a MAY?

In Section 4.4 the text says:

Note: The challenge grammar production uses the list syntax as well. Therefore, a sequence of comma, whitespace, and comma can be considered both as applying to the preceding challenge, or to be an empty entry in the list of challenges. In practice, this ambiguity does not affect the semantics of the header field value

Should “both” be “either” in the above text? Does the potentially ambiguous construct ever take on both meanings simultaneously?

~~Section 5.1.2 uses “ought” when discussing definitions for new authentication schemes. See comments above re use of this term.The same section also uses the phrase “need to” twice, where MUST seems appropriate.~~ - see http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/0411.html

~~The Security Considerations section (6) is about one page in length. It references the SC sections in two in I-Ds: draft-ietf-httpbis-p1-messaging-24 and draft-ietf-httpbis-p2-semantics-24. Both of these I-Ds have non-trivial SC sections, but one cannot say that this document has an acceptable SC section until those documents are finalized. They are both normative references, so this doc will nor progress independently, but there will still be a need to revisit this SC when those SCs are finalized.~~

~~The SC section here addresses only two issues: purging credentials in clients and user agents, and protection spaces. The discussion of the former topic does not discuss how credential purging applies to proxies. Also, it is not clear that a user control for credential purging will have the desired effect given a potentially complex GUI environment. The discussion of protection spaces provides useful suggestions on how to minimize credential exposure.~~

~~I was a bit surprised that there was no advice deprecating the use of passwords as credentials, if only to make a statement on this topic.~~ - see http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/0412.html

mnot commented 10 years ago

julian.reschke@gmx.de commented:

From 2450:

s/both/either/ in discussion of WWW-A parsing (see #510)

mnot commented 10 years ago

julian.reschke@gmx.de changed description from:

Stephen Kent:

I reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG.These comments were written primarily for the benefit of the security area directors.Document editors, WG chairs and ADs should treat these comments just like any other last call comments.

The document obsoletes RFC 2616 and updates 2617. It says that it “defines HTTP/1.1 access control and authentication.” I have not been tracking httpbis closely enough to know the specific motivations for generating this doc, so my review is unbiased by that context.

~~I see that “ought” is used in two places on page 6, but not in uppercase as per RFC 6919. The authors should revisit the use of this term here.~~ - see http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/0411.html

~~Also on page 6 it appears that the phrase “receipt of” was omitted in two places:~~

Upon <> a request for a protected resource that omits credentials

Likewise, upon <> a request that requires authentication by proxies - see 2449

Later on page 6 the text says:

The HTTP protocol does not restrict applications to this simple challenge-response framework for access authentication. Additional mechanisms MAY be used, such as encryption at the transport level or via message encapsulation, and with additional header fields specifying authentication information. However, such additional mechanisms are not defined by this specification.

Encryption is not, per se, an authentication mechanism. Please revise this text.

In Section 2.2 the text says:

The protection space determines the domain over which credentials can be automatically applied. If a prior request has been authorized, the user agent MAY reuse the same credentials for all other requests within that protection space for a period of time determined by the authentication scheme, parameters, and/or user preference.

I’m not clear how user preferences fit into this process. It would seem that the server would decide whether a prior authorization is valid for later requests, not a user.

~~The end of Section 2.2 includes the word “might” but not uppercase, as per RFC 6919. I again suggest that the authors reconsider using this term in this context.~~ - see http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/0411.html

In Section 4.3, the text says:

A proxy MAY relay the credentials from the client request to the next proxy if that is the mechanism by which the proxies cooperatively authenticate a given request.

If, as stated here, a set of proxies cooperatively authenticate a request, then isn’t this a MUST vs. a MAY?

In Section 4.4 the text says:

Note: The challenge grammar production uses the list syntax as well. Therefore, a sequence of comma, whitespace, and comma can be considered both as applying to the preceding challenge, or to be an empty entry in the list of challenges. In practice, this ambiguity does not affect the semantics of the header field value

Should “both” be “either” in the above text? Does the potentially ambiguous construct ever take on both meanings simultaneously?

~~Section 5.1.2 uses “ought” when discussing definitions for new authentication schemes. See comments above re use of this term.The same section also uses the phrase “need to” twice, where MUST seems appropriate.~~ - see http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/0411.html

~~The Security Considerations section (6) is about one page in length. It references the SC sections in two in I-Ds: draft-ietf-httpbis-p1-messaging-24 and draft-ietf-httpbis-p2-semantics-24. Both of these I-Ds have non-trivial SC sections, but one cannot say that this document has an acceptable SC section until those documents are finalized. They are both normative references, so this doc will nor progress independently, but there will still be a need to revisit this SC when those SCs are finalized.~~

~~The SC section here addresses only two issues: purging credentials in clients and user agents, and protection spaces. The discussion of the former topic does not discuss how credential purging applies to proxies. Also, it is not clear that a user control for credential purging will have the desired effect given a potentially complex GUI environment. The discussion of protection spaces provides useful suggestions on how to minimize credential exposure.~~

~~I was a bit surprised that there was no advice deprecating the use of passwords as credentials, if only to make a statement on this topic.~~ - see http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/0412.html

to:

Stephen Kent:

I reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG.These comments were written primarily for the benefit of the security area directors.Document editors, WG chairs and ADs should treat these comments just like any other last call comments.

The document obsoletes RFC 2616 and updates 2617. It says that it “defines HTTP/1.1 access control and authentication.” I have not been tracking httpbis closely enough to know the specific motivations for generating this doc, so my review is unbiased by that context.

~~I see that “ought” is used in two places on page 6, but not in uppercase as per RFC 6919. The authors should revisit the use of this term here.~~ - see http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/0411.html

~~Also on page 6 it appears that the phrase “receipt of” was omitted in two places:~~

Upon <> a request for a protected resource that omits credentials

Likewise, upon <> a request that requires authentication by proxies - see 2449

Later on page 6 the text says:

The HTTP protocol does not restrict applications to this simple challenge-response framework for access authentication. Additional mechanisms MAY be used, such as encryption at the transport level or via message encapsulation, and with additional header fields specifying authentication information. However, such additional mechanisms are not defined by this specification.

Encryption is not, per se, an authentication mechanism. Please revise this text.

In Section 2.2 the text says:

The protection space determines the domain over which credentials can be automatically applied. If a prior request has been authorized, the user agent MAY reuse the same credentials for all other requests within that protection space for a period of time determined by the authentication scheme, parameters, and/or user preference.

I’m not clear how user preferences fit into this process. It would seem that the server would decide whether a prior authorization is valid for later requests, not a user.

~~The end of Section 2.2 includes the word “might” but not uppercase, as per RFC 6919. I again suggest that the authors reconsider using this term in this context.~~ - see http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/0411.html

In Section 4.3, the text says:

A proxy MAY relay the credentials from the client request to the next proxy if that is the mechanism by which the proxies cooperatively authenticate a given request.

If, as stated here, a set of proxies cooperatively authenticate a request, then isn’t this a MUST vs. a MAY?

In Section 4.4 the text says:

Note: The challenge grammar production uses the list syntax as well. Therefore, a sequence of comma, whitespace, and comma can be considered both as applying to the preceding challenge, or to be an empty entry in the list of challenges. In practice, this ambiguity does not affect the semantics of the header field value

~~Should “both” be “either” in the above text? Does the potentially ambiguous construct ever take on both meanings simultaneously?~~ - see 2450 and http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/0416.html

~~Section 5.1.2 uses “ought” when discussing definitions for new authentication schemes. See comments above re use of this term.The same section also uses the phrase “need to” twice, where MUST seems appropriate.~~ - see http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/0411.html

~~The Security Considerations section (6) is about one page in length. It references the SC sections in two in I-Ds: draft-ietf-httpbis-p1-messaging-24 and draft-ietf-httpbis-p2-semantics-24. Both of these I-Ds have non-trivial SC sections, but one cannot say that this document has an acceptable SC section until those documents are finalized. They are both normative references, so this doc will nor progress independently, but there will still be a need to revisit this SC when those SCs are finalized.~~

~~The SC section here addresses only two issues: purging credentials in clients and user agents, and protection spaces. The discussion of the former topic does not discuss how credential purging applies to proxies. Also, it is not clear that a user control for credential purging will have the desired effect given a potentially complex GUI environment. The discussion of protection spaces provides useful suggestions on how to minimize credential exposure.~~

~~I was a bit surprised that there was no advice deprecating the use of passwords as credentials, if only to make a statement on this topic.~~ - see http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/0412.html

mnot commented 10 years ago

julian.reschke@gmx.de changed description from:

Stephen Kent:

I reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG.These comments were written primarily for the benefit of the security area directors.Document editors, WG chairs and ADs should treat these comments just like any other last call comments.

The document obsoletes RFC 2616 and updates 2617. It says that it “defines HTTP/1.1 access control and authentication.” I have not been tracking httpbis closely enough to know the specific motivations for generating this doc, so my review is unbiased by that context.

~~I see that “ought” is used in two places on page 6, but not in uppercase as per RFC 6919. The authors should revisit the use of this term here.~~ - see http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/0411.html

~~Also on page 6 it appears that the phrase “receipt of” was omitted in two places:~~

Upon <> a request for a protected resource that omits credentials

Likewise, upon <> a request that requires authentication by proxies - see 2449

Later on page 6 the text says:

The HTTP protocol does not restrict applications to this simple challenge-response framework for access authentication. Additional mechanisms MAY be used, such as encryption at the transport level or via message encapsulation, and with additional header fields specifying authentication information. However, such additional mechanisms are not defined by this specification.

Encryption is not, per se, an authentication mechanism. Please revise this text.

In Section 2.2 the text says:

The protection space determines the domain over which credentials can be automatically applied. If a prior request has been authorized, the user agent MAY reuse the same credentials for all other requests within that protection space for a period of time determined by the authentication scheme, parameters, and/or user preference.

I’m not clear how user preferences fit into this process. It would seem that the server would decide whether a prior authorization is valid for later requests, not a user.

~~The end of Section 2.2 includes the word “might” but not uppercase, as per RFC 6919. I again suggest that the authors reconsider using this term in this context.~~ - see http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/0411.html

In Section 4.3, the text says:

A proxy MAY relay the credentials from the client request to the next proxy if that is the mechanism by which the proxies cooperatively authenticate a given request.

If, as stated here, a set of proxies cooperatively authenticate a request, then isn’t this a MUST vs. a MAY?

In Section 4.4 the text says:

Note: The challenge grammar production uses the list syntax as well. Therefore, a sequence of comma, whitespace, and comma can be considered both as applying to the preceding challenge, or to be an empty entry in the list of challenges. In practice, this ambiguity does not affect the semantics of the header field value

~~Should “both” be “either” in the above text? Does the potentially ambiguous construct ever take on both meanings simultaneously?~~ - see 2450 and http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/0416.html

~~Section 5.1.2 uses “ought” when discussing definitions for new authentication schemes. See comments above re use of this term.The same section also uses the phrase “need to” twice, where MUST seems appropriate.~~ - see http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/0411.html

~~The Security Considerations section (6) is about one page in length. It references the SC sections in two in I-Ds: draft-ietf-httpbis-p1-messaging-24 and draft-ietf-httpbis-p2-semantics-24. Both of these I-Ds have non-trivial SC sections, but one cannot say that this document has an acceptable SC section until those documents are finalized. They are both normative references, so this doc will nor progress independently, but there will still be a need to revisit this SC when those SCs are finalized.~~

~~The SC section here addresses only two issues: purging credentials in clients and user agents, and protection spaces. The discussion of the former topic does not discuss how credential purging applies to proxies. Also, it is not clear that a user control for credential purging will have the desired effect given a potentially complex GUI environment. The discussion of protection spaces provides useful suggestions on how to minimize credential exposure.~~

~~I was a bit surprised that there was no advice deprecating the use of passwords as credentials, if only to make a statement on this topic.~~ - see http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/0412.html

to:

Stephen Kent:

I reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG.These comments were written primarily for the benefit of the security area directors.Document editors, WG chairs and ADs should treat these comments just like any other last call comments.

The document obsoletes RFC 2616 and updates 2617. It says that it “defines HTTP/1.1 access control and authentication.” I have not been tracking httpbis closely enough to know the specific motivations for generating this doc, so my review is unbiased by that context.

~~I see that “ought” is used in two places on page 6, but not in uppercase as per RFC 6919. The authors should revisit the use of this term here.~~ - see http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/0411.html

~~Also on page 6 it appears that the phrase “receipt of” was omitted in two places:~~

Upon <> a request for a protected resource that omits credentials

Likewise, upon <> a request that requires authentication by proxies - see 2449

Later on page 6 the text says:

The HTTP protocol does not restrict applications to this simple challenge-response framework for access authentication. Additional mechanisms MAY be used, such as encryption at the transport level or via message encapsulation, and with additional header fields specifying authentication information. However, such additional mechanisms are not defined by this specification.

Encryption is not, per se, an authentication mechanism. Please revise this text.

In Section 2.2 the text says:

The protection space determines the domain over which credentials can be automatically applied. If a prior request has been authorized, the user agent MAY reuse the same credentials for all other requests within that protection space for a period of time determined by the authentication scheme, parameters, and/or user preference.

~~I’m not clear how user preferences fit into this process. It would seem that the server would decide whether a prior authorization is valid for later requests, not a user.~~ - see http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/0426.html

~~The end of Section 2.2 includes the word “might” but not uppercase, as per RFC 6919. I again suggest that the authors reconsider using this term in this context.~~ - see http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/0411.html

In Section 4.3, the text says:

A proxy MAY relay the credentials from the client request to the next proxy if that is the mechanism by which the proxies cooperatively authenticate a given request.

If, as stated here, a set of proxies cooperatively authenticate a request, then isn’t this a MUST vs. a MAY?

In Section 4.4 the text says:

Note: The challenge grammar production uses the list syntax as well. Therefore, a sequence of comma, whitespace, and comma can be considered both as applying to the preceding challenge, or to be an empty entry in the list of challenges. In practice, this ambiguity does not affect the semantics of the header field value

~~Should “both” be “either” in the above text? Does the potentially ambiguous construct ever take on both meanings simultaneously?~~ - see 2450 and http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/0416.html

~~Section 5.1.2 uses “ought” when discussing definitions for new authentication schemes. See comments above re use of this term.The same section also uses the phrase “need to” twice, where MUST seems appropriate.~~ - see http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/0411.html

~~The Security Considerations section (6) is about one page in length. It references the SC sections in two in I-Ds: draft-ietf-httpbis-p1-messaging-24 and draft-ietf-httpbis-p2-semantics-24. Both of these I-Ds have non-trivial SC sections, but one cannot say that this document has an acceptable SC section until those documents are finalized. They are both normative references, so this doc will nor progress independently, but there will still be a need to revisit this SC when those SCs are finalized.~~

~~The SC section here addresses only two issues: purging credentials in clients and user agents, and protection spaces. The discussion of the former topic does not discuss how credential purging applies to proxies. Also, it is not clear that a user control for credential purging will have the desired effect given a potentially complex GUI environment. The discussion of protection spaces provides useful suggestions on how to minimize credential exposure.~~

~~I was a bit surprised that there was no advice deprecating the use of passwords as credentials, if only to make a statement on this topic.~~ - see http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/0412.html

mnot commented 10 years ago

julian.reschke@gmx.de changed description from:

Stephen Kent:

I reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG.These comments were written primarily for the benefit of the security area directors.Document editors, WG chairs and ADs should treat these comments just like any other last call comments.

The document obsoletes RFC 2616 and updates 2617. It says that it “defines HTTP/1.1 access control and authentication.” I have not been tracking httpbis closely enough to know the specific motivations for generating this doc, so my review is unbiased by that context.

~~I see that “ought” is used in two places on page 6, but not in uppercase as per RFC 6919. The authors should revisit the use of this term here.~~ - see http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/0411.html

~~Also on page 6 it appears that the phrase “receipt of” was omitted in two places:~~

Upon <> a request for a protected resource that omits credentials

Likewise, upon <> a request that requires authentication by proxies - see 2449

Later on page 6 the text says:

The HTTP protocol does not restrict applications to this simple challenge-response framework for access authentication. Additional mechanisms MAY be used, such as encryption at the transport level or via message encapsulation, and with additional header fields specifying authentication information. However, such additional mechanisms are not defined by this specification.

Encryption is not, per se, an authentication mechanism. Please revise this text.

In Section 2.2 the text says:

The protection space determines the domain over which credentials can be automatically applied. If a prior request has been authorized, the user agent MAY reuse the same credentials for all other requests within that protection space for a period of time determined by the authentication scheme, parameters, and/or user preference.

~~I’m not clear how user preferences fit into this process. It would seem that the server would decide whether a prior authorization is valid for later requests, not a user.~~ - see http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/0426.html

~~The end of Section 2.2 includes the word “might” but not uppercase, as per RFC 6919. I again suggest that the authors reconsider using this term in this context.~~ - see http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/0411.html

In Section 4.3, the text says:

A proxy MAY relay the credentials from the client request to the next proxy if that is the mechanism by which the proxies cooperatively authenticate a given request.

If, as stated here, a set of proxies cooperatively authenticate a request, then isn’t this a MUST vs. a MAY?

In Section 4.4 the text says:

Note: The challenge grammar production uses the list syntax as well. Therefore, a sequence of comma, whitespace, and comma can be considered both as applying to the preceding challenge, or to be an empty entry in the list of challenges. In practice, this ambiguity does not affect the semantics of the header field value

~~Should “both” be “either” in the above text? Does the potentially ambiguous construct ever take on both meanings simultaneously?~~ - see 2450 and http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/0416.html

~~Section 5.1.2 uses “ought” when discussing definitions for new authentication schemes. See comments above re use of this term.The same section also uses the phrase “need to” twice, where MUST seems appropriate.~~ - see http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/0411.html

~~The Security Considerations section (6) is about one page in length. It references the SC sections in two in I-Ds: draft-ietf-httpbis-p1-messaging-24 and draft-ietf-httpbis-p2-semantics-24. Both of these I-Ds have non-trivial SC sections, but one cannot say that this document has an acceptable SC section until those documents are finalized. They are both normative references, so this doc will nor progress independently, but there will still be a need to revisit this SC when those SCs are finalized.~~

~~The SC section here addresses only two issues: purging credentials in clients and user agents, and protection spaces. The discussion of the former topic does not discuss how credential purging applies to proxies. Also, it is not clear that a user control for credential purging will have the desired effect given a potentially complex GUI environment. The discussion of protection spaces provides useful suggestions on how to minimize credential exposure.~~

~~I was a bit surprised that there was no advice deprecating the use of passwords as credentials, if only to make a statement on this topic.~~ - see http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/0412.html

to:

Stephen Kent:

I reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG.These comments were written primarily for the benefit of the security area directors.Document editors, WG chairs and ADs should treat these comments just like any other last call comments.

The document obsoletes RFC 2616 and updates 2617. It says that it “defines HTTP/1.1 access control and authentication.” I have not been tracking httpbis closely enough to know the specific motivations for generating this doc, so my review is unbiased by that context.

~~I see that “ought” is used in two places on page 6, but not in uppercase as per RFC 6919. The authors should revisit the use of this term here.~~ - see http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/0411.html

~~Also on page 6 it appears that the phrase “receipt of” was omitted in two places:~~

Upon <> a request for a protected resource that omits credentials

Likewise, upon <> a request that requires authentication by proxies - see 2449

Later on page 6 the text says:

The HTTP protocol does not restrict applications to this simple challenge-response framework for access authentication. Additional mechanisms MAY be used, such as encryption at the transport level or via message encapsulation, and with additional header fields specifying authentication information. However, such additional mechanisms are not defined by this specification.

Encryption is not, per se, an authentication mechanism. Please revise this text.

In Section 2.2 the text says:

The protection space determines the domain over which credentials can be automatically applied. If a prior request has been authorized, the user agent MAY reuse the same credentials for all other requests within that protection space for a period of time determined by the authentication scheme, parameters, and/or user preference.

~~I’m not clear how user preferences fit into this process. It would seem that the server would decide whether a prior authorization is valid for later requests, not a user.~~ - see http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/0426.html

~~The end of Section 2.2 includes the word “might” but not uppercase, as per RFC 6919. I again suggest that the authors reconsider using this term in this context.~~ - see http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/0411.html

In Section 4.3, the text says:

A proxy MAY relay the credentials from the client request to the next proxy if that is the mechanism by which the proxies cooperatively authenticate a given request.

~~If, as stated here, a set of proxies cooperatively authenticate a request, then isn’t this a MUST vs. a MAY?~~ - see http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/0436.html

In Section 4.4 the text says:

Note: The challenge grammar production uses the list syntax as well. Therefore, a sequence of comma, whitespace, and comma can be considered both as applying to the preceding challenge, or to be an empty entry in the list of challenges. In practice, this ambiguity does not affect the semantics of the header field value

~~Should “both” be “either” in the above text? Does the potentially ambiguous construct ever take on both meanings simultaneously?~~ - see 2450 and http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/0416.html

~~Section 5.1.2 uses “ought” when discussing definitions for new authentication schemes. See comments above re use of this term.The same section also uses the phrase “need to” twice, where MUST seems appropriate.~~ - see http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/0411.html

~~The Security Considerations section (6) is about one page in length. It references the SC sections in two in I-Ds: draft-ietf-httpbis-p1-messaging-24 and draft-ietf-httpbis-p2-semantics-24. Both of these I-Ds have non-trivial SC sections, but one cannot say that this document has an acceptable SC section until those documents are finalized. They are both normative references, so this doc will nor progress independently, but there will still be a need to revisit this SC when those SCs are finalized.~~

~~The SC section here addresses only two issues: purging credentials in clients and user agents, and protection spaces. The discussion of the former topic does not discuss how credential purging applies to proxies. Also, it is not clear that a user control for credential purging will have the desired effect given a potentially complex GUI environment. The discussion of protection spaces provides useful suggestions on how to minimize credential exposure.~~

~~I was a bit surprised that there was no advice deprecating the use of passwords as credentials, if only to make a statement on this topic.~~ - see http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/0412.html

mnot commented 10 years ago

Stephen Kent:

I reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG.These comments were written primarily for the benefit of the security area directors.Document editors, WG chairs and ADs should treat these comments just like any other last call comments.

The document obsoletes RFC 2616 and updates 2617. It says that it “defines HTTP/1.1 access control and authentication.” I have not been tracking httpbis closely enough to know the specific motivations for generating this doc, so my review is unbiased by that context.

~~I see that “ought” is used in two places on page 6, but not in uppercase as per RFC 6919. The authors should revisit the use of this term here.~~ - see http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/0411.html

~~Also on page 6 it appears that the phrase “receipt of” was omitted in two places:~~

Upon <> a request for a protected resource that omits credentials

Likewise, upon <> a request that requires authentication by proxies - see 2449

Later on page 6 the text says:

The HTTP protocol does not restrict applications to this simple challenge-response framework for access authentication. Additional mechanisms MAY be used, such as encryption at the transport level or via message encapsulation, and with additional header fields specifying authentication information. However, such additional mechanisms are not defined by this specification.

Encryption is not, per se, an authentication mechanism. Please revise this text.

In Section 2.2 the text says:

The protection space determines the domain over which credentials can be automatically applied. If a prior request has been authorized, the user agent MAY reuse the same credentials for all other requests within that protection space for a period of time determined by the authentication scheme, parameters, and/or user preference.

~~I’m not clear how user preferences fit into this process. It would seem that the server would decide whether a prior authorization is valid for later requests, not a user.~~ - see http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/0426.html

~~The end of Section 2.2 includes the word “might” but not uppercase, as per RFC 6919. I again suggest that the authors reconsider using this term in this context.~~ - see http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/0411.html

In Section 4.3, the text says:

A proxy MAY relay the credentials from the client request to the next proxy if that is the mechanism by which the proxies cooperatively authenticate a given request.

~~If, as stated here, a set of proxies cooperatively authenticate a request, then isn’t this a MUST vs. a MAY?~~ - see http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/0436.html

In Section 4.4 the text says:

Note: The challenge grammar production uses the list syntax as well. Therefore, a sequence of comma, whitespace, and comma can be considered both as applying to the preceding challenge, or to be an empty entry in the list of challenges. In practice, this ambiguity does not affect the semantics of the header field value

~~Should “both” be “either” in the above text? Does the potentially ambiguous construct ever take on both meanings simultaneously?~~ - see 2450 and http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/0416.html

~~Section 5.1.2 uses “ought” when discussing definitions for new authentication schemes. See comments above re use of this term.The same section also uses the phrase “need to” twice, where MUST seems appropriate.~~ - see http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/0411.html

~~The Security Considerations section (6) is about one page in length. It references the SC sections in two in I-Ds: draft-ietf-httpbis-p1-messaging-24 and draft-ietf-httpbis-p2-semantics-24. Both of these I-Ds have non-trivial SC sections, but one cannot say that this document has an acceptable SC section until those documents are finalized. They are both normative references, so this doc will nor progress independently, but there will still be a need to revisit this SC when those SCs are finalized.~~

~~The SC section here addresses only two issues: purging credentials in clients and user agents, and protection spaces. The discussion of the former topic does not discuss how credential purging applies to proxies. Also, it is not clear that a user control for credential purging will have the desired effect given a potentially complex GUI environment. The discussion of protection spaces provides useful suggestions on how to minimize credential exposure.~~

~~I was a bit surprised that there was no advice deprecating the use of passwords as credentials, if only to make a statement on this topic.~~ - see http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/0412.html

to:

Stephen Kent:

I reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG.These comments were written primarily for the benefit of the security area directors.Document editors, WG chairs and ADs should treat these comments just like any other last call comments.

The document obsoletes RFC 2616 and updates 2617. It says that it “defines HTTP/1.1 access control and authentication.” I have not been tracking httpbis closely enough to know the specific motivations for generating this doc, so my review is unbiased by that context.

~~I see that “ought” is used in two places on page 6, but not in uppercase as per RFC 6919. The authors should revisit the use of this term here.~~ - see http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/0411.html

~~Also on page 6 it appears that the phrase “receipt of” was omitted in two places:~~

Upon <> a request for a protected resource that omits credentials

Likewise, upon <> a request that requires authentication by proxies - see 2449

Later on page 6 the text says:

The HTTP protocol does not restrict applications to this simple challenge-response framework for access authentication. Additional mechanisms MAY be used, such as encryption at the transport level or via message encapsulation, and with additional header fields specifying authentication information. However, such additional mechanisms are not defined by this specification.

~~Encryption is not, per se, an authentication mechanism. Please revise this text.~~ - see http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/0437.html

In Section 2.2 the text says:

The protection space determines the domain over which credentials can be automatically applied. If a prior request has been authorized, the user agent MAY reuse the same credentials for all other requests within that protection space for a period of time determined by the authentication scheme, parameters, and/or user preference.

~~I’m not clear how user preferences fit into this process. It would seem that the server would decide whether a prior authorization is valid for later requests, not a user.~~ - see http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/0426.html

~~The end of Section 2.2 includes the word “might” but not uppercase, as per RFC 6919. I again suggest that the authors reconsider using this term in this context.~~ - see http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/0411.html

In Section 4.3, the text says:

A proxy MAY relay the credentials from the client request to the next proxy if that is the mechanism by which the proxies cooperatively authenticate a given request.

~~If, as stated here, a set of proxies cooperatively authenticate a request, then isn’t this a MUST vs. a MAY?~~ - see http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/0436.html

In Section 4.4 the text says:

Note: The challenge grammar production uses the list syntax as well. Therefore, a sequence of comma, whitespace, and comma can be considered both as applying to the preceding challenge, or to be an empty entry in the list of challenges. In practice, this ambiguity does not affect the semantics of the header field value

~~Should “both” be “either” in the above text? Does the potentially ambiguous construct ever take on both meanings simultaneously?~~ - see 2450 and http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/0416.html

~~Section 5.1.2 uses “ought” when discussing definitions for new authentication schemes. See comments above re use of this term.The same section also uses the phrase “need to” twice, where MUST seems appropriate.~~ - see http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/0411.html

~~The Security Considerations section (6) is about one page in length. It references the SC sections in two in I-Ds: draft-ietf-httpbis-p1-messaging-24 and draft-ietf-httpbis-p2-semantics-24. Both of these I-Ds have non-trivial SC sections, but one cannot say that this document has an acceptable SC section until those documents are finalized. They are both normative references, so this doc will nor progress independently, but there will still be a need to revisit this SC when those SCs are finalized.~~

~~The SC section here addresses only two issues: purging credentials in clients and user agents, and protection spaces. The discussion of the former topic does not discuss how credential purging applies to proxies. Also, it is not clear that a user control for credential purging will have the desired effect given a potentially complex GUI environment. The discussion of protection spaces provides useful suggestions on how to minimize credential exposure.~~

~~I was a bit surprised that there was no advice deprecating the use of passwords as credentials, if only to make a statement on this topic.~~ - see http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/0412.html

mnot commented 10 years ago

julian.reschke@gmx.de commented:

From 2457:

add an example for a realm-related user preference (see #510)

mnot commented 10 years ago

julian.reschke@gmx.de commented:

From 2463:

Rephrase statement about additional methods to authenticate (see #510)

mnot commented 10 years ago

julian.reschke@gmx.de changed description from:

Stephen Kent:

I reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG.These comments were written primarily for the benefit of the security area directors.Document editors, WG chairs and ADs should treat these comments just like any other last call comments.

The document obsoletes RFC 2616 and updates 2617. It says that it “defines HTTP/1.1 access control and authentication.” I have not been tracking httpbis closely enough to know the specific motivations for generating this doc, so my review is unbiased by that context.

~~I see that “ought” is used in two places on page 6, but not in uppercase as per RFC 6919. The authors should revisit the use of this term here.~~ - see http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/0411.html

~~Also on page 6 it appears that the phrase “receipt of” was omitted in two places:~~

Upon <> a request for a protected resource that omits credentials

Likewise, upon <> a request that requires authentication by proxies - see 2449

Later on page 6 the text says:

The HTTP protocol does not restrict applications to this simple challenge-response framework for access authentication. Additional mechanisms MAY be used, such as encryption at the transport level or via message encapsulation, and with additional header fields specifying authentication information. However, such additional mechanisms are not defined by this specification.

~~Encryption is not, per se, an authentication mechanism. Please revise this text.~~ - see http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/0437.html

In Section 2.2 the text says:

The protection space determines the domain over which credentials can be automatically applied. If a prior request has been authorized, the user agent MAY reuse the same credentials for all other requests within that protection space for a period of time determined by the authentication scheme, parameters, and/or user preference.

~~I’m not clear how user preferences fit into this process. It would seem that the server would decide whether a prior authorization is valid for later requests, not a user.~~ - see http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/0426.html

~~The end of Section 2.2 includes the word “might” but not uppercase, as per RFC 6919. I again suggest that the authors reconsider using this term in this context.~~ - see http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/0411.html

In Section 4.3, the text says:

A proxy MAY relay the credentials from the client request to the next proxy if that is the mechanism by which the proxies cooperatively authenticate a given request.

~~If, as stated here, a set of proxies cooperatively authenticate a request, then isn’t this a MUST vs. a MAY?~~ - see http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/0436.html

In Section 4.4 the text says:

Note: The challenge grammar production uses the list syntax as well. Therefore, a sequence of comma, whitespace, and comma can be considered both as applying to the preceding challenge, or to be an empty entry in the list of challenges. In practice, this ambiguity does not affect the semantics of the header field value

~~Should “both” be “either” in the above text? Does the potentially ambiguous construct ever take on both meanings simultaneously?~~ - see 2450 and http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/0416.html

~~Section 5.1.2 uses “ought” when discussing definitions for new authentication schemes. See comments above re use of this term.The same section also uses the phrase “need to” twice, where MUST seems appropriate.~~ - see http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/0411.html

~~The Security Considerations section (6) is about one page in length. It references the SC sections in two in I-Ds: draft-ietf-httpbis-p1-messaging-24 and draft-ietf-httpbis-p2-semantics-24. Both of these I-Ds have non-trivial SC sections, but one cannot say that this document has an acceptable SC section until those documents are finalized. They are both normative references, so this doc will nor progress independently, but there will still be a need to revisit this SC when those SCs are finalized.~~

~~The SC section here addresses only two issues: purging credentials in clients and user agents, and protection spaces. The discussion of the former topic does not discuss how credential purging applies to proxies. Also, it is not clear that a user control for credential purging will have the desired effect given a potentially complex GUI environment. The discussion of protection spaces provides useful suggestions on how to minimize credential exposure.~~

~~I was a bit surprised that there was no advice deprecating the use of passwords as credentials, if only to make a statement on this topic.~~ - see http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/0412.html

to:

Stephen Kent:

I reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG.These comments were written primarily for the benefit of the security area directors.Document editors, WG chairs and ADs should treat these comments just like any other last call comments.

The document obsoletes RFC 2616 and updates 2617. It says that it “defines HTTP/1.1 access control and authentication.” I have not been tracking httpbis closely enough to know the specific motivations for generating this doc, so my review is unbiased by that context.

~~I see that “ought” is used in two places on page 6, but not in uppercase as per RFC 6919. The authors should revisit the use of this term here.~~ - see http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/0411.html

~~Also on page 6 it appears that the phrase “receipt of” was omitted in two places:~~

Upon <> a request for a protected resource that omits credentials

Likewise, upon <> a request that requires authentication by proxies - see 2449

Later on page 6 the text says:

The HTTP protocol does not restrict applications to this simple challenge-response framework for access authentication. Additional mechanisms MAY be used, such as encryption at the transport level or via message encapsulation, and with additional header fields specifying authentication information. However, such additional mechanisms are not defined by this specification.

~~Encryption is not, per se, an authentication mechanism. Please revise this text.~~ - see thread starting at http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/0437.html and 2463

In Section 2.2 the text says:

The protection space determines the domain over which credentials can be automatically applied. If a prior request has been authorized, the user agent MAY reuse the same credentials for all other requests within that protection space for a period of time determined by the authentication scheme, parameters, and/or user preference.

~~I’m not clear how user preferences fit into this process. It would seem that the server would decide whether a prior authorization is valid for later requests, not a user.~~ - see http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/0426.html

~~The end of Section 2.2 includes the word “might” but not uppercase, as per RFC 6919. I again suggest that the authors reconsider using this term in this context.~~ - see http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/0411.html

In Section 4.3, the text says:

A proxy MAY relay the credentials from the client request to the next proxy if that is the mechanism by which the proxies cooperatively authenticate a given request.

~~If, as stated here, a set of proxies cooperatively authenticate a request, then isn’t this a MUST vs. a MAY?~~ - see http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/0436.html

In Section 4.4 the text says:

Note: The challenge grammar production uses the list syntax as well. Therefore, a sequence of comma, whitespace, and comma can be considered both as applying to the preceding challenge, or to be an empty entry in the list of challenges. In practice, this ambiguity does not affect the semantics of the header field value

~~Should “both” be “either” in the above text? Does the potentially ambiguous construct ever take on both meanings simultaneously?~~ - see 2450 and http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/0416.html

~~Section 5.1.2 uses “ought” when discussing definitions for new authentication schemes. See comments above re use of this term.The same section also uses the phrase “need to” twice, where MUST seems appropriate.~~ - see http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/0411.html

~~The Security Considerations section (6) is about one page in length. It references the SC sections in two in I-Ds: draft-ietf-httpbis-p1-messaging-24 and draft-ietf-httpbis-p2-semantics-24. Both of these I-Ds have non-trivial SC sections, but one cannot say that this document has an acceptable SC section until those documents are finalized. They are both normative references, so this doc will nor progress independently, but there will still be a need to revisit this SC when those SCs are finalized.~~

~~The SC section here addresses only two issues: purging credentials in clients and user agents, and protection spaces. The discussion of the former topic does not discuss how credential purging applies to proxies. Also, it is not clear that a user control for credential purging will have the desired effect given a potentially complex GUI environment. The discussion of protection spaces provides useful suggestions on how to minimize credential exposure.~~

~~I was a bit surprised that there was no advice deprecating the use of passwords as credentials, if only to make a statement on this topic.~~ - see http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/0412.html

mnot commented 10 years ago

julian.reschke@gmx.de changed severity from In WG Last Call to In IETF LC

mnot commented 10 years ago