Subject: My concerns about a SRP SASL mechanism

From: [email-masked] (Sam Hartman)
Date: Fri, 4 Apr 2003 16:08:46 -0500 (EST)

I've been asked to clarify my objections to an SRP SASL mechanism.

The basic objection is that mechanism designers should write GSSAPI
mechanisms not SASL mechanisms unless they have a good reason to do
otherwise.

If the SRP mechanism was a GSSAPI mechanism then it could be used
   unmodified within SSH, NFS V4 and other protocols that support
   GSSAPI for security within the IETF and within other areas.  It
   could also be used with all the protocols that use SASL.  

If SRP is useful, then people will want to use it with other protocols
and so we should try to make sure it is useful with all those
protocols.  The IETF is busy and reviewing security documents takes
time.  So we should find the solution that involves minimizing review
within the IETF while maximizing the number of situations where the
technology is useful.  

Here are some objections I can see to writing the SRP SASL mechanism
in the form of a GSSAPI mechanism:

1)  We're almost done with the existing draft.

    Up until now the document has not received significant review
    within the IETF.  It has not been a work product of a working
    group  and has not been last called before.  When a document is
    submitted to the IETF for the standards track, the IETF receives
    change control and needs the opportunity to  make (potentially
    significant) changes to the document.

2)  GSSAPI  libraries are hard to deal with and multi-mechanism GSSAPI
    support is weak

    There is no requirement that you use a GSSAPI library or even  the
    GSSAPI within your program to implement a SASL GSSAPI mechanism.
    You simply need to  have a compatible wire encoding, but you can
    actually implement the mechanism the same as you would implement
    other SASL mechanisms if you find that an easier implementation
    choice.

Here's roughly what would need to happen to turn a SASL mechanism into
a standards track GSSAPI mechanism

1) You need to use the GSSAPI initial context token format.  this
   means you need to include an OID and a bit of header at the
   beginning of the authentication messages.

2)  You need to assign an OID to your mechanism.

3) You may need to think about name formats for principal names a bit.

4) There may be some issues involving out-of-order delivery of
   messages you need to think about.

5) You should organize the document so it will be clear both to people
   implementing as a SASL mechanism and as a GSSAPI mechanism.