Subject: draft-ietf-sasl-rfc2222bis-02.txt section 4.2

From: Tony Hansen <[email-masked]>
Date: Thu, 06 Nov 2003 12:02:22 -0500

Section "4.2.  Authorization identities and proxy authentication", appears to be
mixing two totally different discussions together in a slightly confusing mess.

The first discussion is about there being two IDs being passed through the
mechanism (the authorization identity and the authentication identity) and how
they are used, including what it means for the authorization identity to be
empty and non-empty.

The second discussion that's intermingled with the first discussion is about the
  format of the two identities.

For example, consider this sentence:

    While some legacy
    mechanisms are incapable of transmitting an authorization identity
    other than the empty string, newly defined mechanisms are expected to
    be capable of carrying the entire Unicode repertoire (with the
    exception of the NUL character).

This sentence starts by saying that some legacy mechanisms don't provide an
authorization identity, but newly defined mechanisms are expected to. But it
never finishes saying that. Instead, it diverts the sentence into discussing
what the authorization identity should look like.

May I suggest that this section be rewritten so that it focusses on the two
topics separately. For example, something like the following below might be
considered.

	Tony Hansen
	[email-masked]

4.2.  Authorization and authentication identities, and proxy authentication

    SASL authentication deals with two identities: the authorization identity and
    the authentication identity. The transmitted authorization identity may be an
    empty string (zero length), but the transmitted authentication identity may
    not be an empty string.

    (While some legacy mechanisms are incapable of transmitting an authorization
    identity other than the empty string, newly defined mechanisms SHOULD be
    capable of transmiting a non-empty authorization identity.)

    The authorization identity is used by the server as the primary identity for
    making access policy decisions.

    With any mechanism, transmitting an authorization identity of the empty
    string directs the server to derive the authorization identity from the
    client's authentication identity.

    If the authorization identity transmitted during the authentication protocol
    exchange is not the empty string, this is typically referred to as "proxy
    authentication".  This feature permits agents such as proxy servers to
    authenticate using their own credentials, yet request the access privileges
    of the identity for which they are proxying.

    The server makes an implementation defined policy decision as to whether the
    authentication identity is permitted to have the access privileges of the
    authorization identity and whether the authorization identity is permitted to
    receive service.  If it is not, the server indicates failure of the
    authentication protocol exchange.

    As a client might not have the same information as the server, clients SHOULD
    NOT themselves try to derive authorization identities from authentication
    identities when clients could instead transmit an authorization identity of
    the empty string.

    The server SHOULD verify the correctness of a received authorization
    identity. Profiles whose authorization identities are simple user names (e.g.
    IMAP [RFC 3501]) are encouraged to employ [SASLPrep] profile [SASLPrep] of
    the "stringprep" algorithm [StringPrep] to prepare these names for matching.
    If the preparation of the authorization identity fails or results in an empty
    string, the server MUST fail the authentication exchange. The only exception
    to this rule is when the received authorization identity is already the empty
    string.

4.x Authorization Identity and Authentication Identity Formats

    An authorization identity and an authentication identity are strings of ISO
    10646 [ISO-10646] coded characters.  The NUL (U+0000) character is not
    permitted in authorization or authentication identities.

    The character encoding scheme used for transmitting an authorization identity
    over a protocol is specified in each authentication mechanism (with the
    authentication mechanism's blob being further restricted/encoded by the
    protocol profile). Per IETF character set policy [CHARSET-POLICY],
    authentication mechanisms SHOULD encode these and other strings in UTF-8
    [UTF-8]. Mechanisms are expected to be capable of carrying the entire Unicode
    repertoire (with the exception of the NUL character). An authorization
    identity of the empty string and and an absent authorization identity MUST be
    treated as equivalent.  However, mechanisms SHOULD NOT allow both (i.e. if an
    authorization identity is allowed to be absent, but one is transferred, it
    SHOULD NOT be an empty string).