Subject: rfc2222bis-08 comments

From: Hallvard B Furuseth <[email-masked]>
Date: Fri, 1 Oct 2004 15:59:44 +0200

These are rather rather hurried comments, since Kurt said reviews are
needed but soon.  So I have only made a cursory check if these issues
have been discussed before; I don't know how much they would have been
delayed if I were to check properly.  Sorry about that.

> Abstract

I had trouble getting into SASL the first time I read the draft - mostly
things that did not make sense to me at first, only when I got to a
closer explanation later in the draft.  I'm beginning to figure out why
now, though I'm guessing a bit about what it was I didn't get.  Starting
with the Abstract: I didn't get that at all, though I don't really see
why, given the second paragraph.  "So I have a protocol here, and an
authentication mechanism there, and somehow if I include SASL, the two
will be able to talk to each other.  Um...?"  It's better now, but I
still suggest:

>    The Simple Authentication and Security Layer (SASL) is a framework
>    for providing authentication and data security services in
>    connection-oriented protocols via replaceable

authentication

[nothing in the abstract says that's the kind of mechanisms it is
talking about.]

>    mechanisms.  It
>    provides structured interface between protocols and

such SASL

>    mechanisms.

Or maybe "...and mechanisms that adhere to SASL", but that's probably
more wordy than necessary.

The same change would be nice in the Introduction section, though of
course the diagram there helps.

Personally I would also have found an asymmetric definition easier to
relate to: SASL defines a common interface to authentication mechanisms
for protocols.  (Is that the right way to put it?)  But maybe that's not
at all the view SASL intends to convey.  Is the protocol profile the
common interface to protocols for authentication mechanisms?

> 2.    Introduction

>    The implementors will also need to understand a
>    specification of a

SASL

>    profile specific to the protocol,

> 3.1.  Authentication protocol exchange

This phrase looks to me like it is about an authentication protocol -
i.e. part of SASL - and not the protocol which uses SASL.  I don't see
anything in the following section to correct that notion.

Also,

>    A SASL mechanism is responsible for conducting an authentication
>    protocol exchange.

I don't think so.  It's the protocol which conducts the _exchange_,
and (below) which transmits anything.

>    During the authentication protocol exchange, the mechanism performs

I suggest s/performs/can perform/, since not all of them need be done.

>    authentication, transmits an authorization identity (frequently known
>    as a userid) from the client to server,

This sounds like the authorization identity is independent of the
authentication.  See below.

> 3.2.  Authorization and authentication identities

>    The processing model is as follows.  A server, upon completion of the
>    authentication mechanism, uses the results produced by the
>    authentication mechanism, the client-provided authorization identity
>    value (which may be the empty string), and local policy information
>    to derive an authorization identity.

As above.  As described, the authorization ID appears not to be part of
the 'results produced by the authentication mechanism', only something
which is grabbed after completion of the authentication.  When I first
read about this, I was left wondering when the server checks if the
authentication ID has the authorization ID's access.  Each time one
tries to access something after the authentication?

Please clarify that the authorization ID is checked during the
authentication (as section 3.2.1 says).  And local policy is used to
either derive the authorization identity or check it.  But it looks a
little strange to use that local policy during the exchange if the user
provides it, but after the exchange if it is derived.  Should both be
done during the exchange instead?

>    The authorization identity may be an empty (zero length) string.  In
>    this case, the server derives an authorization identity from the
>    client's authentication identity.

I wonder a little why the authorization ID is explicitly said to be
provided by the client, when the authentication ID is not.

>    Any normalization of the authentication identity is defined by a
>    particular SASL mechanism, the protocol profile doesn't influence it.

That's a bit misleading from the protocol's point of view.  From
discussions elsewhere I gather the protocol may normalize the ID as it
pleases for its own use, including when it locates the server-side
secret matching the authentication ID, as long as this does not affect
the ID which the authentication mechanism sees.

>    The mechanism MUST preserve Unicode codepoint when transferring
>    authorization identity (e.g. the mechanism cann't apply any form of
>    normalization).

The () part does not seem say the same as the preceding sentence: 'when
transferring...' sounds like only the client-side part of the mechanism
must preserve the ID, while the () sounds like the server side also must
preserve it.

> 3.2.1.  Authorization identities and proxy authentication

>    The server SHOULD verify that a received authorization identity is in
>    the correct form. Protocol profiles whose authorization identities
>    are simple user names (e.g. IMAP [RFC 3501]) SHOULD use "SASLprep"
>    profile [SASLprep] of the "stringprep" algorithm [StringPrep] to
>    prepare these names for matching. The profiles MAY use a stringprep
>    profile that is more strict than "SASLprep". 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.

In that case there can be authorization IDs which one can only get by
sending an empty authorization ID: IDs that are derived from the
authentication ID but would be invalid if specified explicitly.
Seems strange.

> 3.2.2.  Authorization Identity Format

>    An authorization identity is a string of zero or more Unicode
>    [Unicode] coded characters.  The NUL <U+0000> character is not
>    permitted in authorization identities.

But a NUL octet in a multibyte character is OK?
(Does not apply to UTF-8, of course.)

> 3.3.  Security layers

>    The security layer takes effect
>    immediately following the last response of the authentication
>    exchange for data sent by the client and the completion indication
>    for data sent by the server. The exact position MUST be defined by
>    the protocol profile (see section 4 part 5).

When does it stop having effect, if the protocol supports multiple
authentication?

>    Note that all SASL mechanisms that are unable to negotiate a security
>    layer automatically select no security layer.

Without checking up the 'selects no security layer' thread, I still
can't tell if this says that such a mechanism cancels an old security
layer or if it says that it doesn't affect it.  I'll check that later,
unless someone replies first.

-- 
Hallvard