Subject: Comments on draft-burdis-cat-srp-sasl-08.txt

From: Nicolas Williams <[email-masked]>
Date: Tue, 22 Jul 2003 18:20:35 -0500

The following comments all pertain to the GSS-API mechanism defined in
section 8 of draft-burdis-cat-srp-sasl-08.txt except where otherwise
noted:

1.  Mutual Authentication & SRP GSS Principal Naming

   The I-D claims to provide mutual authentication, but does not provide
   for naming acceptors.

   While I appreciate that SRP provides mutual authentication, unless
   one can bind the SRP password and verifier to an acceptor name then
   the acceptor name MUST be of type GSS_C_NT_ANONYMOUS.

   Sam Hartman has proposed appending, prepending or otherwise stirring
   the acceptor name into the password as a way to achieve mutual
   authentication with non-anonymous acceptors.

   The I-D should explain the limitations of its mutual authentication
   provision and/or add acceptor naming to the protocol.  (See questions
   below.)

   Initiator naming should also be discussed.

   Additional questions:

   Should services be able to use this mechanism as initiators?

   How about optionally running the SRP protocol in both directions so
   that the initiator and acceptor can mutually authenticate without
   having to stir GSS-API names into the password/verifier?  The two
   exchanges would have to be mutually bound, sure, perhaps in the last
   message of the double exchange.  (In this case the verifiers could
   even be published, as long as they are distributed in a secure
   fashion.)

2.  Channel Bindings

   I imagine that the I-D authors may have thought that GSS channel
   bindings are an esoteric, barely used feature of the GSS-API.  A few
   months ago they have been correct.

   This is about to change; the use of GSS-API channel bindings is
   being formalized and given new life, see:

   http://www.ietf.org/internet-drafts/draft-ietf-nfsv4-ccm-01.txt

   If the protocol can be extended to accommodate integrity protected
   channel bindings I highly encourage you to do so.

   You can always define the encoding of the channel bindings by
   reference to RFC1964, module choice of hash function (this is how
   we're defining them for SPKM in draft-ietf-nfsv4-ccm-01.txt).

3.  No Error Token Is Specified

   The GSS-API does, apparent widely spread assumptions notwithstanding,
   support the use of error tokens - i.e., output tokens emitted by
   gss_init_sec_context() or gss_accept_sec_context() when they also
   return a major status code other than GSS_S_COMPLETE or
   GSS_S_CONTINUE_NEEDED.

   This problem is significant.  Please fix.

4.  Obsoleted RFCs Do Not Make for Good Normative References

   This I-D references RFC2078 instead of RFC2743.  Please fix.  :)

Cheers,

Nico
--