ietf
[Top] [All Lists]

Re: Gen-ART review of draft-ietf-sasl-gs2-18

2009-12-03 13:59:44
Thanks for your review.

On Mon, Nov 30, 2009 at 03:19:04PM -0500, Spencer Dawkins wrote:
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/

Either the capitalization of "the" or the placement of it outside the
quotes are incorrect.  Leaving it outside the quotes but uncapitalized
should be OK.  We'll fix it one way and let the RFC-Editor apply
whatever style it prefers.

  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.").

3.3.  Examples

  The last step translate each decimal value using table 3 in Base32

Spencer (nit): s/translate/translates/?

Yes.

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?

Sure.

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.

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/ ?

Yes.

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!

Nico
-- 
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf

<Prev in Thread] Current Thread [Next in Thread>