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

From: Nicolas Williams <[email-masked]>
Date: Thu, 3 Dec 2009 11:33:15 -0600

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

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 03 Dec 2009 19:02:53 +0000

Hi Nico,

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

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 3 Dec 2009 13:38:59 -0600

> There is no such thing as GS1, it should be GSSAPI. Otherwise the new 

The I-D says:

                                                            The original
   GSS-API->SASL mechanism bridge was specified by [RFC2222], now
   [RFC4752]; we shall sometimes refer to the original bridge as GS1 in
   this document.

I don't see anything wrong with that.

There's good reason, even, to want to use "GS1" to refer to RFC4572:
RFC2222/4572's use of "GSSAPI" to refer to the "Kerberos V5 GSS-API
mechanism" is wrong and confusing.  Avoiding confusion is a good thing.

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 07 Dec 2009 10:37:21 +0000

>I don't see anything wrong with that.
Very well. I forgot about that.

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

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 7 Dec 2009 10:32:51 -0600

On Mon, Dec 07, 2009 at 10:37:21AM +0000, Alexey Melnikov wrote:
> >>>>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".
> >>>>       
> >>>>

Well, how about adding a parenthetical to the current text after 'GS1'
saying "(i.e., "GSSAPI")"?