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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-sasl-gs2-18
Reviewer: Spencer Dawkins
Review Date: 2009-11-30
IETF LC End Date: 2009-11-18 (oops!)
IESG Telechat date: 2009-12-03

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.

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.

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/

  [RFC4121], and has a number of problems that lead us to desire a new

Spencer (nit): s/lead/led/

  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.

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

3.3.  Examples

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

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

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

  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?

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

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

  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/

  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/

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

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

  is that the truncated output for distinct inputs are different for
practical input values.
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]