WG Last Call Summary: Simple Authentication and Security Layer (SASL)

[Tom Yu <tlyu@xxxxxxx>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Only few issues appear to have arisen during Working Group Last Call.
Several of these issues can be resolved by fairly minimal edits.
Editors: please submit another draft resolving these issues.

After the draft resolving these issues is published, I will conclude
that the Working Group has reached consensus, and I will submit this
document to the IESG for consideration as a Proposed Standard.  Please
let me know if you have feedback concerning this course of action, or
about the issues identified below.

Issues (0), (1), and (2) are minor editorial issues which I feel are
not exceptionally contentious.  Issues (3), (4), and (5) involve
optional fields in the authentication request and the authentication
outcome message.  I believe that issue (3) is moderately complex, but
only requires a reasonably simple change.  Issue (6) is a potential
interoperability problem on which I would like opinions.

ISSUES
======

(0) The draft does not display its expiration date in explicit form;
    the Internet-Draft Guidelines state that the text "expires in six
    months" is not acceptable.

(1) Hallvard Furuseth notes that in Section 4, "authentication
    identity" appears to be erroneously written where "authorization
    identity" is meant in the following text:

> 4.  Protocol Requirements

>     Where the specification does not precisely prescribe how identities
>     in SASL relate to identities used elsewhere in the protocol, for
>     instance in access control policy statements, it may be appropriate
>     for the protocol to provide a facility by which the client can
>     discover information (such as the representation of the
>     authentication identity used in making access control decisions)
>     ^^^^^^^^^^^^^^^^^^^^^^^
>     about established identities for these uses.

    I believe the above change is reasonable, and that there is
    consensus to make this change.

(2) Discussion indicates that text describing credentials could be
    more explicit about the relationship of the authentication
    identity to the credentials.  Jeffrey Hutzelman's suggested text
    appears to be reasonable:

>>>>> "jhutz" == Jeffrey Hutzelman <jhutz@xxxxxxx> writes:

jhutz> OLD TEXT:
jhutz>   The server is responsible for verifying the client's credentials and
jhutz>   verifying that the client is allowed to act as the authorization
jhutz>   identity.  A SASL exchange fails if either (or both) of these
jhutz>   verifications fails.  (The SASL exchange may fail for other reasons,
jhutz>   such as service authorization failure.)

jhutz> NEW TEXT:
jhutz>   The server is responsible for verifying the client's credentials,
jhutz>   extracting the client's authentication identity (in a manner which
jhutz>   depends on the mechanism being used), and verifying that the client
jhutz>   is allowed to act as the requested authorization identity.  A SASL
jhutz>   exchange fails if either verification (or both) fails.  (The SASL
jhutz>   exchange may also fail for other reasons, such as service
jhutz>   authorization failure).

    I saw no objections to the above text.

(3) Hallvard notes a more complex issue involving some ambiguity in
    the definition "initial response" in the context of optional data
    provided in the application protocol's authentication request.  I
    agree with Hallvard that the usage in Section 5 is inconsistent
    with the usage elsewhere in the document, and that the intended
    usage of "initial response" is "first authentication data
    transmitted by the client".  I suggest the following changes:

> 5.  Mechanism Requirements

[...]

>   2) A definition of the server-challenges and client-responses of the
>      authentication exchange, as well as:

>      a) An indication whether mechanism is client-first, variable, or
>         server-first.  If a SASL mechanism is defined as client-first
>         and the client does not send an initial response, then the first

    Insert "in the authentication request" after "initial response".

>         server challenge MUST be empty (the EXTERNAL mechanism is an
>         example of this case).  If a SASL mechanism is defined as
>         variable, then the specification needs to state how the server
>         behaves when the initial client response is omitted (the

    Insert "from the authentication request" after "is omitted".

>         DIGEST-MD5 mechanism [DIGEST-MD5] is an example of this case).
>         If a SASL mechanism is defined as server-first then the client
>         MUST NOT send an initial client response (the CRAM-MD5 mechanism

    Insert "in the authentication request" after "initial client
    response".

>         [CRAM-MD5] is an example of this case).

(4) Discussion initiated by Hallvard suggests that text describing
    optional initial response (in the authentication request) or
    optional additional final data (in the authentication outcome)
    could use additional clarification.  My evaluation of the
    discussion suggests the following interpretations:

    (a) Within the authentication request, an application protocol may
        optionally support a field containing an initial client
        response.  It is optional for an implementation to actually
        send this initial client response field, but implementations
        of such an application protocol must accept this initial
        response field.

    (b) Within the authentication outcome message, an application
        protocol may optionally a field containing additional data
        from the server.  It is optional for an implementation to
        actually use this additional data field, but implementations
        of such an application protocol must accept this additional
        data field.

    I do not have specific recommended text to address this issue.

(5) Addressing a minor editorial issue brought up by Hallvard, I
    suggest (based on discussion) to change the following text in
    Section 3:

>   Where mechanisms specify the first data sent in the exchange is from
>   the client to the server and additional data is sent to the client
>   along with indicating a successful outcome, and the protocol provides
>   fields supporting both, the exchange can be shorted by two
>   round-trips:

    by replacing "the exchange ... round-trips:" with "then the
    exchange takes two fewer round trips:".

(6) I have found a potential interoperability problem.  In the course
    of my own review of the document, I noticed that Section 4
    requires that an application protocol providing a field for
    initial client response data in the authentication request must
    have a means for distinguishing an empty initial response from an
    absent initial response.  There is a similar requirement on the
    additional data field in the authentication outcome.

    I think this is a potential interoperability trap.  It seems to me
    that text as it stands probably provides adequate warning about
    this problem, but perhaps additional text emphasizing this
    requirement should appear in other places (e.g., Section 3)
    mentioning the optional initial response and additional data
    fields.  I would like additional opinions on this subject, but
    this issue may not be sufficiently serious to hold up the
    document.

==========

Again, please let me know if you have feedback about the results of
this Last Call.

 --- Tom Yu, SASL WG co-chair
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (SunOS)

iD8DBQFDwfsDSO8fWy4vZo4RAuNhAJ42SRS7Adu18zmlo5gPMMgkT09oFgCg5BIV
w2doefQjozsW5jkUYObcecs=
=sSNK
-----END PGP SIGNATURE-----