Re: [Gen-art] Gen-ART review of draft-ietf-sasl-gs2-18
Spencer Dawkins spen...@wonderhamster.org writes: Summary: This document is almost ready for publication as a Proposed Standard. I did have one minor question about 13.3 (in my LATE review), but it should not be difficult to resolve, if an AD agrees with my question. Hi Spencer. Thank you for your careful review. I'm now applying your comments to the document. I did tag a fair number of nits, but these aren't part of the Gen-ART review, and are simply included as a convenience for anyone else who edits the document. This is appreciated! 1. Introduction The GS1 bridge failed to gain wide deployment for any GSS-API mechanism other than The Kerberos V5 GSS-API mechanism [RFC1964] Spencer (nit): s/The Kerberos/The Kerberos/ Fixed. [RFC4121], and has a number of problems that lead us to desire a new Spencer (nit): s/lead/led/ Fixed. bridge. Specifically: a) GS1 was not round-trip optimized, b) GS1 did not support channel binding [RFC5056]. These problems and the opportunity to create the next SASL password-based mechanism, SCRAM Spencer (nit): please expand SCRAM on first use. Fixed. [I-D.ietf-sasl-scram], as a GSS-API mechanism used by SASL applications via GS2, provide the motivation for GS2. In particular, the current consensus of the SASL community appears to be that SASL security layers (i.e., confidentiality and integrity protection of application data after authentication) are too complex and, since SASL applications tend to have an option to run over a Transport Layer Security (TLS) [RFC5246] channel, redundant and best replaced with channel binding. Spencer (nit): it's a LONG way from too complex to redundant in this sentence ;-) suggest moving redundant before the subclause, just for readability. Fixed. 3.3. Examples The last step translate each decimal value using table 3 in Base32 Spencer (nit): s/translate/translates/? Fixed. [RFC4648]. Thus the SASL mechanism name for the SPKM-1 GSSAPI mechanism is GS2-DT4PIK22T6A. 8. GSS-API Parameters The mutual_req_flag MUST be set. If channel binding is used then the client MUST check that the corresponding ret_flag is set when the context is fully establish, else authentication MUST fail. Spencer (nit): s/establish/established/ This paragraph was rewritten completely due to other changes, so this doesn't apply any more. Use or non-use of deleg_req_flag and anon_req_flag is an implementation-specific detail. SASL and GS2 implementors are encouraged to provide programming interfaces by which clients may choose to delegate credentials and by which servers may receive them. SASL and GS2 implementors are encouraged to provide programming interfaces which provide a good mapping of GSS-API naming options. 11. GSS_Inquire_mech_for_SASLname call To allow SASL clients to more efficiently identify which GSS-API mechanism a particular SASL mechanism name refers to we specify a new GSS-API utility function for this purpose. Spencer (nit): whew! hard to parse. Suggest We specify a new GSS-API utility function to allow SASL clients to more efficiently identify the GSS-API mechanism that a particular SASL mechanism name refers to, or something like that? I agreed, and used your text after a s/clients/implementations/ -- it is not SASL clients that may want to use the new GSS-API interface, but the actual SASL GS2 implementations. SASL clients (e.g., applications) will (hopefully) never need to worry about the GSS-API interface. 13.3. Additional Recommendations If the application requires security layers then it MUST prefer the SASL GSSAPI mechanism over GS2-KRB5 or GS2-KRB5-PLUS. Spencer (minor): If prefer the mechanism is the right way to describe this, I apologize, but I don't know what the MUST means in practice - if this needs to be at MUST strength, I'd expect text like MUST use X and MUST NOT use Y or Z, or MUST use X unless the server doesn't support X. Good point. After reading the discussion between Nico and Alexey, I changed the paragraph into: If the application requires SASL security layers then it MUST use the SASL GSSAPI mechanism [RFC4752] instead of GS2-KRB5 or GS2-KRB5- PLUS. I believe this captures the intent more clearly. 14. GSS-API Mechanisms that negotiate other mechanisms A GSS-API mechanism that negotiate other mechanisms interact badly Spencer (nit): s/negotiate/negotiates/, and probably s/interact/will interact/ ? Fixed. with the SASL mechanism negotiation. There are two problems. The first is an interoperability problem and the second is a security concern. The problems are described and resolved below. 14.1. The interoperability problem If a client implement GSS-API mechanism X, potentially negotiated through a GSS-API mechanism Y, and the server also implement GSS-API Spencer (nit): s/implement/implements/ Fixed. mechanism X
Re: [Gen-art] Gen-ART review of draft-ietf-sasl-gs2-18
Nicolas Williams nicolas.willi...@sun.com writes: In particular, the current consensus of the SASL community appears to be that SASL security layers (i.e., confidentiality and integrity protection of application data after authentication) are too complex and, since SASL applications tend to have an option to run over a Transport Layer Security (TLS) [RFC5246] channel, redundant and best replaced with channel binding. Spencer (nit): it's a LONG way from too complex to redundant in this sentence ;-) suggest moving redundant before the subclause, just for readability. Good point. The and best replaced with channel binding can be a separate sentence too (Use of SASL security layers is best replaced with channel binding to a TLS channel.). I've made this change too. 16. Security Considerations GS2 does not directly use any cryptographic algorithms, therefore it is automatically algorithm agile, or, as agile as the GSS-API mechanisms that are available for use in SASL applications via GS2. The exception is the use of SHA-1 for deriving SASL mechanism names, but no cryptographic properties are required. The required property Spencer (nit): I would suggest SHA-1 is used to derive SASL mechanism names, but no cryptographic properties are required - the current text says we don't use crypto, except when we do :-) :) How about: GS2 does not directly use any cryptographic algorithms for security features, therefore it is automatically algorithm agile, ... GS2 does use SHA-1 for deriving SASL mechanism names from GSS-API mechanism OIDs, but this use of SHA-1 is not security-relevant. Thanks! I used the slightly more verbose: SHA-1 is used to derive SASL mechanism names, but no traditional cryptographic properties are required -- the required property is that the truncated output for distinct inputs are different for practical input values. GS2 does not use any other cryptographic algorithm. Therefor GS2 is algorithm agile, or, as agile as the GSS-API mechanisms that are available for use in SASL applications via GS2. /Simon ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Gen-ART review of draft-ietf-sasl-gs2-18
Hi, Simon (and dropping i...@ietf.org)... I agree with your responses to me, to Nicholas, and to Alexey. Thanks! Spencer - Original Message - From: Simon Josefsson si...@josefsson.org To: Alexey Melnikov alexey.melni...@isode.com Cc: General Area Review Team gen-art@ietf.org; draft-ietf-sasl-...@tools.ietf.org; i...@ietf.org; Nicolas Williams nicolas.willi...@sun.com Sent: Friday, January 08, 2010 6:25 AM Subject: Re: Gen-ART review of draft-ietf-sasl-gs2-18 Alexey Melnikov alexey.melni...@isode.com writes: The I-D says: The original GSS-API-SASL mechanism bridge was specified by [RFC], now [RFC4752]; we shall sometimes refer to the original bridge as GS1 in this document. I don't see anything wrong with that. Very well. I forgot about that. There's good reason, even, to want to use GS1 to refer to RFC4572: RFC/4572's use of GSSAPI to refer to the Kerberos V5 GSS-API mechanism is wrong and confusing. Avoiding confusion is a good thing. Personally I dislike unnecessary indirection, as it allows for extra confusion as well. There is only 1 mechanism in GS1 family (ignoring GSS-SPNEGO), it is called GSSAPI. So I think the original text is actually better, if we add a reference and change prefer to use: If the application requires SASL security layers then it MUST use the SASL GSSAPI mechanism [RFC4572] instead of GS2-KRB5 or GS2-KRB5-PLUS. Opinions? I used this text too. /Simon ___ Ietf mailing list i...@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Gen-ART review of draft-ietf-sasl-gs2-18
Nicolas Williams wrote: On Thu, Dec 03, 2009 at 07:02:53PM +, Alexey Melnikov wrote: Hi Nico, Nicolas Williams wrote: 13.3. Additional Recommendations If the application requires security layers then it MUST prefer the SASL GSSAPI mechanism over GS2-KRB5 or GS2-KRB5-PLUS. Spencer (minor): If prefer the mechanism is the right way to describe this, I apologize, but I don't know what the MUST means in practice - if this needs to be at MUST strength, I'd expect text like MUST use X and MUST NOT use Y or Z, or MUST use X unless the server doesn't support X. Agreed, we should express a MUST NOT instead of a MUST: If a SASL application requires security layers then it MUST NOT use GS2 mechanisms. Such an application SHOULD use a SASL mechanism that does provide security layers, such as GS1 mechanisms. There is no such thing as GS1, it should be GSSAPI. Otherwise the new text is Ok. The I-D says: The original GSS-API-SASL mechanism bridge was specified by [RFC], now [RFC4752]; we shall sometimes refer to the original bridge as GS1 in this document. I don't see anything wrong with that. Very well. I forgot about that. There's good reason, even, to want to use GS1 to refer to RFC4572: RFC/4572's use of GSSAPI to refer to the Kerberos V5 GSS-API mechanism is wrong and confusing. Avoiding confusion is a good thing. Personally I dislike unnecessary indirection, as it allows for extra confusion as well. There is only 1 mechanism in GS1 family (ignoring GSS-SPNEGO), it is called GSSAPI. So I think the original text is actually better, if we add a reference and change prefer to use: If the application requires SASL security layers then it MUST use the SASL GSSAPI mechanism [RFC4572] instead of GS2-KRB5 or GS2-KRB5-PLUS. Opinions? ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Gen-ART review of draft-ietf-sasl-gs2-18
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-gs2-18 Reviewer: Spencer Dawkins Review Date: 2009-11-30 IETF LC End Date: 2009-11-18 (oops!) IESG Telechat date: 2009-12-03 Summary: This document is almost ready for publication as a Proposed Standard. I did have one minor question about 13.3 (in my LATE review), but it should not be difficult to resolve, if an AD agrees with my question. I did tag a fair number of nits, but these aren't part of the Gen-ART review, and are simply included as a convenience for anyone else who edits the document. 1. Introduction The GS1 bridge failed to gain wide deployment for any GSS-API mechanism other than The Kerberos V5 GSS-API mechanism [RFC1964] Spencer (nit): s/The Kerberos/The Kerberos/ [RFC4121], and has a number of problems that lead us to desire a new Spencer (nit): s/lead/led/ bridge. Specifically: a) GS1 was not round-trip optimized, b) GS1 did not support channel binding [RFC5056]. These problems and the opportunity to create the next SASL password-based mechanism, SCRAM Spencer (nit): please expand SCRAM on first use. [I-D.ietf-sasl-scram], as a GSS-API mechanism used by SASL applications via GS2, provide the motivation for GS2. In particular, the current consensus of the SASL community appears to be that SASL security layers (i.e., confidentiality and integrity protection of application data after authentication) are too complex and, since SASL applications tend to have an option to run over a Transport Layer Security (TLS) [RFC5246] channel, redundant and best replaced with channel binding. Spencer (nit): it's a LONG way from too complex to redundant in this sentence ;-) suggest moving redundant before the subclause, just for readability. 3.3. Examples The last step translate each decimal value using table 3 in Base32 Spencer (nit): s/translate/translates/? [RFC4648]. Thus the SASL mechanism name for the SPKM-1 GSSAPI mechanism is GS2-DT4PIK22T6A. 8. GSS-API Parameters The mutual_req_flag MUST be set. If channel binding is used then the client MUST check that the corresponding ret_flag is set when the context is fully establish, else authentication MUST fail. Spencer (nit): s/establish/established/ Use or non-use of deleg_req_flag and anon_req_flag is an implementation-specific detail. SASL and GS2 implementors are encouraged to provide programming interfaces by which clients may choose to delegate credentials and by which servers may receive them. SASL and GS2 implementors are encouraged to provide programming interfaces which provide a good mapping of GSS-API naming options. 11. GSS_Inquire_mech_for_SASLname call To allow SASL clients to more efficiently identify which GSS-API mechanism a particular SASL mechanism name refers to we specify a new GSS-API utility function for this purpose. Spencer (nit): whew! hard to parse. Suggest We specify a new GSS-API utility function to allow SASL clients to more efficiently identify the GSS-API mechanism that a particular SASL mechanism name refers to, or something like that? 13.3. Additional Recommendations If the application requires security layers then it MUST prefer the SASL GSSAPI mechanism over GS2-KRB5 or GS2-KRB5-PLUS. Spencer (minor): If prefer the mechanism is the right way to describe this, I apologize, but I don't know what the MUST means in practice - if this needs to be at MUST strength, I'd expect text like MUST use X and MUST NOT use Y or Z, or MUST use X unless the server doesn't support X. 14. GSS-API Mechanisms that negotiate other mechanisms A GSS-API mechanism that negotiate other mechanisms interact badly Spencer (nit): s/negotiate/negotiates/, and probably s/interact/will interact/ ? with the SASL mechanism negotiation. There are two problems. The first is an interoperability problem and the second is a security concern. The problems are described and resolved below. 14.1. The interoperability problem If a client implement GSS-API mechanism X, potentially negotiated through a GSS-API mechanism Y, and the server also implement GSS-API Spencer (nit): s/implement/implements/ mechanism X negotiated through a GSS-API mechanism Z, the authentication negotiation will fail. 14.2. Security problem If a client's policy is to first prefer GSSAPI mechanism X, then non- GSSAPI mechanism Y, then GSSAPI mechanism Z, and if a server supports mechanisms Y and Z but not X, then if the client attempts to negotiate mechanism X by using a GSS-API mechanism that negotiate Spencer (nit): s/negotiate/negotiates/ other mechanisms (such as SPNEGO), it may end up using mechanism Z Spencer (nit): you provide a
