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