ietf-nntp AUTHINFO SASL protocol choices

[Jeffrey M. Vinocur]

As promised...

Opinions welcome.




$Id: protocol-choices,v 1.4 2002/03/14 03:35:16 jeff Exp $


For AUTHINFO SASL, there are several possibilities that come to mind.


Requirements:

- We need to exchange base64-encoded tokens of arbitrary length
  (although we likely can get each SASL mechanism to specify a maximum
  length if necessary, see the proposal at the end of this document).

- RFC 2222 specifies that the command which begins the SASL exchange
  SHOULD have an optional argument which contains an optional "initial
  response" (this is in order to save a round-trip if the mechanism
  requires that the client send data first).


Here are all of the possibilities I can think of, in no particular
order, each with a brief description and an example.  There are some
possibilities I skip that combine the client protocol from one and
server protocol from another; I believe the ones below choose pieces
that seem to fit together reasonably well.  I may have missed something,
though.

The examples are purposefully vague with regard to exact syntax and
response codes, but they should get the idea across.  Uppercase letters
indicate command keywords, lowercase letters indicate freeform
descriptive response text.  I use <...> to indicate a base64-encoded
token, and <.?.> to indicate where the token is optional.

My analysis and opinions are at the end.

========================================================================

1.  Each client token is passed in a multi-line fashion, similar to
POST.  (It can be broken onto separate lines to fit any line length
limit and then reassembled for base64 decoding; I chose two lines for
each token below.)  The server tokens come in multi-line responses.

[C] AUTHINFO SASL START
 S] 3xx go ahead with optional initial token
[C] <.?.>
[C] <.?.>
[C] .
 S] 3xx continue, server token follows
 S] <...>
 S] <...>
 S] .
[C] AUTHINFO SASL CONTINUED
 S] 3xx go ahead
[C] <...>
[C] <...>
[C] .
 S] 3xx continue, server token follows
 S] <...>
 S] <...>
 S] .
[C] AUTHINFO SASL CONTINUED
 S] 3xx go ahead
[C] <...>
[C] <...>
[C] .
 S] 2xx authentication succeeded, final server token follows
 S] <.?.>
 S] <.?.>
 S] .

------------------------------------------------------------------------

2.  Exactly like the above, but without the client needing to wait for
the server's GO AHEAD to send the multi-line (POST-like) blob.

[C] AUTHINFO SASL START
[C] <.?.>
[C] <.?.>
[C] .
 S] 3xx continue, server token follows
 S] <...>
 S] <...>
 S] .
[C] AUTHINFO SASL CONTINUED
[C] <...>
[C] <...>
[C] .
 S] 3xx continue, server token follows
 S] <...>
 S] <...>
 S] .
[C] AUTHINFO SASL CONTINUED
[C] <...>
[C] <...>
[C] .
 S] 2xx authentication succeeded, final server token follows
 S] <.?.>
 S] <.?.>
 S] .

------------------------------------------------------------------------

3.  Each client token is passed in a separate command as one line, and
the server tokens come back in single-line responses:

[C] AUTHINFO SASL START <.?.>
 S] 3xx CONTINUE <...>
[C] AUTHINFO SASL CONTINUED <...>
 S] 3xx CONTINUE <...>
[C] AUTHINFO SASL CONTINUED <...>
 S] 2xx DONE <.?.>

------------------------------------------------------------------------

4.  The optional initial token is passed as a command parameter, and
then the client enters a special mode where the client passes data
directly.  The server tokens come back as part of this special mode as
well, looking like single-line responses.

[C] AUTHINFO SASL START <.?.>
 S] 3xx CONTINUE <...>
[C] <...>
 S] 3xx CONTINUE <...>
[C] <...>
 S] 2xx DONE <.?.>

------------------------------------------------------------------------

5.  Just like above, but with no optional initial response.

[C] AUTHINFO SASL START
 S] 3xx CONTINUE <...>
[C] <...>
 S] 3xx CONTINUE <...>
[C] <...>
 S] 2xx DONE <.?.>

========================================================================

Analysis:

1.  By my reading, this is the only choice that fits the letter and
    spirit of the NNTP spec as it stands.  However, it has a large
    amount of overhead.  This is the "reference protocol" although I
    doubt anyone really wants to see it implemented.

2.  This is not far from following existing practice.  It introduces the
    multi-line client command, which differs from POST in that it does
    not need to way for confirmation from the server before sending the
    additional lines.  Other than that, it's not bad; I don't know how
    people feel about such a change to NNTP.

3.  This requires the line length changes (see below) but is otherwise
    very clean and NNTP-like.

4.  This requires the line length changes (see below).  It involves a
    special mode where the client can send data (not commands) but the
    server sends back things which look like single-line responses (I'm
    not sure that the really are) intermingled with the client data.
    This is not very NNTP-like in my opinion, but it is very much like
    the way other SASL-enabled protocols work (for example, a client
    aborts the exchange by sending something which cannot be valid
    base64-encoded data, such as "*").

5.  This may not require the line length changes, if we continue to
    allow arbitrarily long single-line server responses (as is currently
    being discussed on the ietf-nntp mailing list).  However, it
    violates a SHOULD from RFC 2222 and has all of the non-NNTP-like
    traits of the previous choice.

------------------------------------------------------------------------

Opinions:

I have no objections to the second choice, although I wonder if other
people will (I would in fact be quite happy with the second choice if
everyone else is).

My preference, however, is to the third choice; I think the line length
changes would be a generally good thing to have, and if we have them
then I think the second choice is by far the nicest.

I think benefits of similarity to other protocols in the fourth and
fifth choices do not outweigh the non-NNP-like feeling they give me.

========================================================================

If we need to increase the line length limit, I suggest the following
procedure:

- Stan modifies the extensions mechanism to allow extensions to increase
  the line length limit.  (Chris points out that we have precedent on
  this; see the relevant bit of the ESMTP spec below.) I'd be willing to
  suggest wording for this if necessary.

- We get the SASL spec revised to require that when a mechanism is
  registered, the maximum size of an exchange be given.  Chris can ask
  John Myers to include this in the current draft which revises RFC
  2222; he doesn't think it will be a problem.

- In the AUTHINFO SASL extension, we require an implementation to
  support a line length limit which is based on the max size of an
  exchange in the SASL mechanism (of those it implements) with the
  largest maximum, scaled up to account for base64 overhead.

------------------------------------------------------------------------

Precedent for extensions modifying line length, from RFC 1869:

4.1.2.  Maximum command line length

   This specification extends the SMTP MAIL FROM and RCPT TO to allow
   additional parameters and parameter values.  It is possible that the
   MAIL FROM and RCPT TO lines that result will exceed the 512 character
   limit on command line length imposed by RFC 821.  This limit is
   hereby amended to only apply to command lines without any parameters.
   Each specification that defines new MAIL FROM or RCPT TO parameters
   must also specify maximum parameter value lengths for each parameter
   so that implementors of some set of extensions know how much buffer
   space must be allocated. The maximum command length that must be
   supported by an SMTP implementation with extensions is 512 plus the
   sum of all the maximum parameter lengths for all the extensions
   supported.

========================================================================


-- 
Jeffrey M. Vinocur
jeff at litech.org