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@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf