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

From: Simon Josefsson <[email-masked]>
Date: Fri, 08 Jan 2010 13:21:49 +0100

"Spencer Dawkins" <[email-masked]> 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 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/

Fixed.

>   other mechanisms (such as SPNEGO), it may end up using mechanism Z
>
> Spencer (nit): you provide a reference for SPNEGO in the next section,
> but this is the first occurance...

I added a pointer to the first occurance too.

>   when it ideally should have used mechanism Y. For this reason, the
>   use of GSS-API mechanisms that negotiate other mechanisms are
>   disallowed under GS2.
>
> 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" :-)

Right, it was a bit backward.  I used this instead:

   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

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 08 Jan 2010 13:24:09 +0100

Nicolas Williams <[email-masked]> writes:

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

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

/Simon

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 08 Jan 2010 13:25:58 +0100

Alexey Melnikov <[email-masked]> writes:

>>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.
>>
> Very well. I forgot about 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.
>>  
>>
> 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":
>
>  SASL "GSSAPI" mechanism [RFC4572] instead of "GS2-KRB5" or "GS2-KRB5-PLUS".
>
> Opinions?

I used this text too.

/Simon