Re: Gen-ART LC Review of draft-ietf-sasl-scram-07
Nicolas Williams wrote: On Fri, Oct 02, 2009 at 06:14:47PM +0100, Alexey Melnikov wrote: On Thu, Sep 24, 2009 at 2:22 AM, Ben Campbell b...@estacado.net wrote: [...] -- 1.2, last bullet: What is the referent for this? Is there perhaps a missing word(s), or maybe this paragraph belongs with the previous bullet? The latter. (This == Hi()) Incidentally, Hi() should be shown as taking the iteration count as an argument. Fixed in my copy. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Gen-ART LC Review of draft-ietf-sasl-scram-07
Nicolas Williams wrote: On Wed, Sep 23, 2009 at 08:22:25PM -0500, Ben Campbell wrote: -- 2nd paragraph: ...increase the iteration count over time. Can you elaborate on how this helps, and possibly offer guidance on how implementations should use it? Good point. With SCRAM as specified, a server cannot increase the iteration count without somehow getting access to the cleartext password. If the server were to store SaltedPassword _and_ U_iteration_count (from Hi()'s internals), then the server could compute a new SaltedPassword and U_iteration_count with a higher iteration count. However, the server isn't intended to store SaltedPassword, rather, the server stores StoredKey and ServerKey, and there's a reason for this: a server that's never authenticated a given user before cannot impersonate that user, but if the server were to store SaltedPassword, then the server could impersonate the user. Thus, to increase the iteration count over time requires, effectively, changing the user's password. This is probably worth pointing out. I tried to clarify that. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Gen-ART LC Review of draft-ietf-sasl-scram-07
Hi Ben, Thank you for your comments. Responding to most of them below (I will respond to the rest in a separate message). On Thu, Sep 24, 2009 at 2:22 AM, Ben Campbell b...@estacado.net wrote: I have been selected as the General Area Review Team (Gen-ART) reviewer for this draft (for background on Gen-ART, please see http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-sasl-scram-07 Reviewer: Ben Campbell Review Date: 2009-08-23 IETF LC End Date: 2009-08-28 IESG Telechat date: (if known) Summary: This draft is almost ready for publication as a proposed standard. I have a few questions and editorial comments that might be worth considering prior to publication. Major issues: None. Minor issues: - Section 2, 1st paragraph: ...addresses the requirements necessary to deploy a challenge- response mechanism more widely than past attempts. What are these requirements? Are they documented somewhere? Do you mean for appendix A or B to express them? Yes. I've added forward references. [...] I'm no crypto expert, so please forgive me if this is silly--but isn't there a movement to phase out sha-1? If so, should that be the default must implement hash for a new mechanism? My understanding is that use of SHA-1 under HMAC is still considered reasonable. The WG debated at length use of SHA-1 versa use of SHA-256, etc. and decided to proceed with SHA-1, because it is more frequently implemented in libraries and hardware. -- section 5.1, definition of r:, It is important that this value be different for each authentication. Are there any best practices for nonce generation that can be mentioned or referenced? The reference to RFC 4086 is already present elsewhere in the document, but I added it here. -- Section 9, 1st paragraph: Can you describe the required properties expected from a strong security layer? (i.e. confidentiality, integrity protection, etc.) I've added (such as TLS with data confidentiality). I hope this is clearer. [...] --3rd paragraph: I gather you are saying that there are techniques that mitigate the damage of a stolen authorization database, but the work group chose not to use them. Can you elaborate on the wg motivation for not doing so? IPR claims on authentication mechanisms such as SRP. Text commenting on IPR was removed as per Pasi's request. Nits/editorial comments: -- 1.1, 2nd bullet: Can you include an informational reference for RADIUS? Added. -- 1.2, last bullet: What is the referent for this? Is there perhaps a missing word(s), or maybe this paragraph belongs with the previous bullet? The latter. (This == Hi()) -- 2, last paragraph: Do you plan for this paragraph to stay in the RFC? Is the work group mail list permanent enough to be published in the RFC? Deleted. -- 5.1, definition of c:, 2nd bullet: (recall: a channel binding flag and an optional authzid.) I'm not sure I follow the sentence. Do you mean to say something like Recall the G2 header contains a... Yes. Changed. -- IDNits reports the following: == Outdated reference: A later version (-03) exists of draft-melnikov-sasl-scram-ldap-02 The two documents would be published simultaneously, so this will go away during editing by the RFC Editor. It also reports a number of false errors about undefined references. I think it's confused by your non-standard reference sections, which I think make sense under the circumstances. Right. Regards, Alexey ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Gen-ART LC Review of draft-ietf-sasl-scram-07
On Thu, Sep 24, 2009 at 2:22 AM, Ben Campbell b...@estacado.net wrote: [...] Minor issues: [...] -- section 4, first paragraph: ...as long as this alternative name doesn’t conflict with any other hash function name from the IANA Hash Function Textual Names registry. What prevents future conflicts if someone registers a name that conflicts with the short name? Good point. Should the short-names be IANA registered to prevent this? This is a good idea. I've added: Such alternative name SHOULD be registered in the IANA Hash Function Textual Names registry. (Should future names be limited to 9 chars?) I would rather not put extra restrictions on another registry due to limitations on SASL mechanism names. I would also note that the likelyhood of registering another SCRAM mechanism name is quite low, and the likelyhood of the conflict described above is even lower, so I wouldn't worry too much about this case anyway. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Gen-ART LC Review of draft-ietf-sasl-scram-07
Hi Alexey, Your responses in this and your other email address all of my comments. Thanks! Ben. On Oct 2, 2009, at 12:31 PM, Alexey Melnikov wrote: On Thu, Sep 24, 2009 at 2:22 AM, Ben Campbell b...@estacado.net wrote: [...] Minor issues: [...] -- section 4, first paragraph: ...as long as this alternative name doesn’t conflict with any other hash function name from the IANA Hash Function Textual Names registry. What prevents future conflicts if someone registers a name that conflicts with the short name? Good point. Should the short-names be IANA registered to prevent this? This is a good idea. I've added: Such alternative name SHOULD be registered in the IANA Hash Function Textual Names registry. (Should future names be limited to 9 chars?) I would rather not put extra restrictions on another registry due to limitations on SASL mechanism names. I would also note that the likelyhood of registering another SCRAM mechanism name is quite low, and the likelyhood of the conflict described above is even lower, so I wouldn't worry too much about this case anyway. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Gen-ART LC Review of draft-ietf-sasl-scram-07
On Fri, Oct 02, 2009 at 06:14:47PM +0100, Alexey Melnikov wrote: On Thu, Sep 24, 2009 at 2:22 AM, Ben Campbell b...@estacado.net wrote: I'm no crypto expert, so please forgive me if this is silly--but isn't there a movement to phase out sha-1? If so, should that be the default must implement hash for a new mechanism? My understanding is that use of SHA-1 under HMAC is still considered reasonable. The WG debated at length use of SHA-1 versa use of SHA-256, etc. and decided to proceed with SHA-1, because it is more frequently implemented in libraries and hardware. This matter has come up elsewhere, such as in the KRB-WG. NIST has not obsoleted the use of HMAC-SHA-1, though I don't have a reference handy at the moment (but a quick search of the KRB-WG mailing list and, maybe, the krb...@mit.edu list should yield one). -- 1.2, last bullet: What is the referent for this? Is there perhaps a missing word(s), or maybe this paragraph belongs with the previous bullet? The latter. (This == Hi()) Incidentally, Hi() should be shown as taking the iteration count as an argument. Nico -- ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Gen-ART LC Review of draft-ietf-sasl-scram-07
On Wed, Sep 23, 2009 at 08:22:25PM -0500, Ben Campbell wrote: -- 2nd paragraph: ...increase the iteration count over time. Can you elaborate on how this helps, and possibly offer guidance on how implementations should use it? Good point. With SCRAM as specified, a server cannot increase the iteration count without somehow getting access to the cleartext password. If the server were to store SaltedPassword _and_ U_iteration_count (from Hi()'s internals), then the server could compute a new SaltedPassword and U_iteration_count with a higher iteration count. However, the server isn't intended to store SaltedPassword, rather, the server stores StoredKey and ServerKey, and there's a reason for this: a server that's never authenticated a given user before cannot impersonate that user, but if the server were to store SaltedPassword, then the server could impersonate the user. Thus, to increase the iteration count over time requires, effectively, changing the user's password. This is probably worth pointing out. Nico -- ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Gen-ART LC Review of draft-ietf-sasl-scram-07
On Fri, Oct 02, 2009 at 01:17:26PM -0500, Nicolas Williams wrote: On Fri, Oct 02, 2009 at 06:14:47PM +0100, Alexey Melnikov wrote: On Thu, Sep 24, 2009 at 2:22 AM, Ben Campbell b...@estacado.net wrote: I'm no crypto expert, so please forgive me if this is silly--but isn't there a movement to phase out sha-1? If so, should that be the default must implement hash for a new mechanism? My understanding is that use of SHA-1 under HMAC is still considered reasonable. The WG debated at length use of SHA-1 versa use of SHA-256, etc. and decided to proceed with SHA-1, because it is more frequently implemented in libraries and hardware. This matter has come up elsewhere, such as in the KRB-WG. NIST has not obsoleted the use of HMAC-SHA-1, though I don't have a reference handy at the moment (but a quick search of the KRB-WG mailing list and, maybe, the krb...@mit.edu list should yield one). http://csrc.nist.gov/groups/ST/toolkit/secure_hashing.html After 2010, Federal agencies may use SHA-1 only for the following applications: hash-based message authentication codes (HMACs); key derivation functions (KDFs); and random number generators (RNGs). Regardless of use, NIST encourages application and protocol designers to use the SHA-2 family of hash functions for all new applications and protocols. Nico -- ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Gen-ART LC Review of draft-ietf-sasl-scram-07
I have been selected as the General Area Review Team (Gen-ART) reviewer for this draft (for background on Gen-ART, please see http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-sasl-scram-07 Reviewer: Ben Campbell Review Date: 2009-08-23 IETF LC End Date: 2009-08-28 IESG Telechat date: (if known) Summary: This draft is almost ready for publication as a proposed standard. I have a few questions and editorial comments that might be worth considering prior to publication. Major issues: None. Minor issues: - Section 2, 1st paragraph: ...addresses the requirements necessary to deploy a challenge- response mechanism more widely than past attempts. What are these requirements? Are they documented somewhere? Do you mean for appendix A or B to express them? -- section 4, first paragraph: ...as long as this alternative name doesn’t conflict with any other hash function name from the IANA Hash Function Textual Names registry. What prevents future conflicts if someone registers a name that conflicts with the short name? Should the short-names be IANA registered to prevent this? (Should future names be limited to 9 chars?) -- section 4, 2nd paragraph: I'm no crypto expert, so please forgive me if this is silly--but isn't there a movement to phase out sha-1? If so, should that be the default must implement hash for a new mechanism? -- section 5.1, definition of r:, It is important that this value be different for each authentication. Are there any best practices for nonce generation that can be mentioned or referenced? -- Section 9, 1st paragraph: Can you describe the required properties expected from a strong security layer? (i.e. confidentiality, integrity protection, etc.) -- 2nd paragraph: ...increase the iteration count over time. Can you elaborate on how this helps, and possibly offer guidance on how implementations should use it? --3rd paragraph: I gather you are saying that there are techniques that mitigate the damage of a stolen authorization database, but the work group chose not to use them. Can you elaborate on the wg motivation for not doing so? Nits/editorial comments: -- 1.1, 2nd bullet: Can you include an informational reference for RADIUS? -- 1.2, last bullet: What is the referent for this? Is there perhaps a missing word(s), or maybe this paragraph belongs with the previous bullet? -- 2, last paragraph: Do you plan for this paragraph to stay in the RFC? Is the work group mail list permanent enough to be published in the RFC? -- 5.1, definition of c:, 2nd bullet: (recall: a channel binding flag and an optional authzid.) I'm not sure I follow the sentence. Do you mean to say something like Recall the G2 header contains a... -- IDNits reports the following: == Outdated reference: A later version (-03) exists of draft-melnikov-sasl-scram-ldap-02 It also reports a number of false errors about undefined references. I think it's confused by your non-standard reference sections, which I think make sense under the circumstances. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
