Subject: Re: SASLprep in rfc2222bis-06

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 23 Feb 2004 16:43:43 -0800

At 10:04 AM 2/17/2004, Simon Josefsson wrote:

>Hello all.  I've read the latest document, and in general it looks
>good (I've sent a couple of editorial changes to Alexey).  However, I
>find the SASLprep discussions not as clear.
>
>I tried to separate my issues into several e-mail, but eventually I
>was unable to do so.  The issues are closely intertwined, and
>resolving one question modify the assumptions for other questions.  So
>forgive this longish e-mail.  I have tried to separate the focus;
>first to matters that affect mechanism specifications, then profile
>specifications, and then to SASL library implementations.
>
>I'm sure that most of my issues could be solved by elaborating the
>text, so the reader can understand what the intended general
>philosophy is.  Mostly I have refrained from suggesting specific
>solutions, and below I only try to understand the current document.
>My hope is that these ramblings can be turned into specific pointers
>to where the document could be improvement, so that other people don't
>have to ask the same questions I do.
>
>In 5.2 "Mechanism profile guidelines" there is this paragraph:
>
>   Authentication mechanisms SHOULD encode character strings in UTF-8
>   [UTF-8] (see [CHARSET-POLICY] for IETF policy regarding character
>   sets in IETF protocols).  In order to avoid interoperability problems
>   due to differing normalizations, when a mechanisms specifies that
>   character data is to be used as input to a cryptographic and/or
>   comparison function, the mechanism specification MUST detail how the
>   data is to be represented, including any normalizations or other
>   preparations, to ensure proper function.  Designers of mechanisms
>   SHOULD use the "SASLprep" profile [SASLprep] of the "stringprep"
>   algorithm [StringPrep] where applicable.
>
>I fail to understand several things here.
>
>First, does 'character strings' include the authorization identity?
>Defining the term 'character string', or at least giving examples,
>would help.

No.  I believe the text should be clarified.  Mechanisms should be
capable of exchanging the authorization identity, but its handling
(in particular for comparison) is specific to the application-level
protocol which has profiled use of SASL as an authentication method.

>Second, is the 'MUST' conditioned on the 'when', or is the 'when' only
>there to give the rationale behind the 'MUST'?  In other words, is the
>intention that all mechanisms MUST detail the normalization etc steps,
>regardless of whether they input the strings to
>cryptographic/comparison functions?

I believe its conditional.  It likely should be reworded for clarity.

>Third, similarly, does the 'SHOULD' apply to all mechanisms, or just
>those that actually use the 'character strings' as input to
>cryptographic operations?

It applies to "applicable" character strings.  SASLprep is
not applicable to all character strings.

>For the sake of argument, I'm assuming the authorization identity is
>considered a character string (this is my experience with deployed
>tools, the administrator just types in the authorization identity).

As noted above, I think this text should be clarified as not applying
to the authorization identity.

Even though most of the rest of your comments depend on your
assumption, I went ahead and injected a few comments here and there.

>Further, mechanisms MUST specify normalization, and SHOULD use
>SASLprep "where applicable", for the processing of all character
>strings, including the authorization identity. 

Ignoring the "including the authorization identity", yes.

>The "where applicable" qualifier mostly invalidate the keywords.

I think not.  The statement says designers should consider whether use
of SASLprep, if applicable, is appropriate.  That implies that they
should consider both the applicability of SASLprep and, if applicable,
its appropriateness.

The "where applicable" was added because we didn't want designers to
think they SHOULD use SASLprep for all character strings.  They
SHOULD use SASLprep for kinds of character strings which SASLprep
was designed to be used with.

>When is SASLprep applicable or not?

That's discussed in the SASLprep I-D, namely in Section 1 but also in
Section 2 and 3.

>That seems rather subjective to me.

Consideration of a "SHOULD" is always subjective.

>Otherwise, I believe this SHOULD, without any verifiable
>technical consequences, should be removed.

I disagree.

>Let's go the section 5.1 "Protocol profile requirements":
>   8) A protocol profile MAY further refine the definition of an
>   authorization identity by adding additional syntactic restrictions
>   and protocol-specific semantics. A protocol profile MUST specify the
>   form of the authorization identity (since it is protocol specific, as
>   opposed to the authentication identity, which is mechanism specific)
>   and how authorization identities are to be compared. 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.
>
>This says the form of the authorization identity is protocol specific.
>Given the recommendations in 5.2 for mechanism specification to modify
>the form of the authorization identity, it appears to be in conflict.

Correct.  That's why 5.2 should be clarified as not to apply to
authorization identities.

>In order words: Should the authzid normalization procedure defined by
>the mechanism be run before or after the authzid normalization
>procedure defined by the profile?

There should be no mechanism specific normalization of the authorization
identity.  In regards to the mechanism, both peers should use the
client provided string in all functions.  This likely should be stated
in the mechanism profile requirements.

>I'm assuming here that "server" refer to the actual application, not
>the server part of the generic SASL implementation.

The term "server" refers to the service-providing peer and a "server
implementation" refers to all components which make up that peer
(operating system, libraries, program code, and any and all
supporting external systems on that end).   What is or isn't in
a library is an implementation detail.

>Up until now, at
>least my SASL implementation has not been aware of the protocol that
>uses the library.  The justification for this is the same that SASL
>mechanisms shouldn't contain SASL profile specific behaviour, and vice
>versa:
>
>   A protocol profile SHOULD NOT attempt to amend the definition of
>   mechanisms or make mechanism-specific encodings.  This breaks the
>   separation between protocol and mechanism that is fundamental to the
>   design of SASL. Likewise, SASL mechanisms SHOULD be profile neutral.

I note, this should be s/profile neutral/protocol neutral/.

>Is my interpretation of what "server" refer to here correct?  That
>only the protocol specific part SHOULD verify the authzid form?

It means that the protocol profile is to specify the form of the
authzid (and how to compare it) and the mechanism should just provide
a mechanism for exchanging the authzid.

Kurt

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 25 Feb 2004 18:16:15 +0100

> protocol which has profiled use of SASL as an authentication method.

I see.  Thanks for the reply, I'll review my issues once an updated
draft is available.

Regards,
Simon

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 26 Feb 2004 00:45:27 +0100

Below is an image of how I perceive the normalization in rfc2222bis is
intended to work, after extrapolating how Kurt's suggestions will be
applied to the next version of the document.  The requirement on
mechanisms is to transport F(AuthZId) unmodified to the server.
Profiles may normalize the AuthZId however they want, and mechanism
may normalize authentication identities however they want.  Mechanism
may not normalize the authorization further (even for internal
cryptographic processing).  Is this correct?  (I prefer not to
speculate like this, because it generate long and potentially
irrelevant e-mails, but was asked to do so to speed up the progress of
the draft, please bear with me.)

If so, and here comes my question, if two protocol profiles uses
different normalizations, and a mechanism is implemented by storing a
hash of H(Username|AuthId|AuthZid) (or it works in some similar way),
the mechanism appear to need to select among different password
databases, depending on which protocol is used.  Implementation wise,
the mechanism must know which protocol is used to select the correct
database.  If this is not done, there is the question of which
normalization to use when the server compute H(U|A|Az) when storing it
in the database.  If only one of the protocol normalization steps is
used, then it won't work with the other protocol.  If both
normalizations are stored, without the information on what protocol is
used for each hash, someone might create an authorization identity in
one of the protocols that map to another authorization identity in the
other protocol.  If the database also store which protocol the AuthZId
was normalized for, before the hash, it would work if the mechanism
knew the protocol that is used, but would prevent using the same
database for new protocols using SASL.  The password database is
coupled to the protocol, in general.  This seem to be a different
model than what RFC 2222 used, which will affect implementations.

                     Authentication           Authorization
                        Identity            Identity - AuthZId
                           |                        |
                           |                        |
                           |                       \|/
                          \|/              +-------------------+
                  +--------------------+   |  Protocol profile |
                  |        |           |   |   normalization   |
                  |       \|/          |   +-------------------+
                  |  +---------------+ |            |
                  |  |   Mechanism   | |            |
                  |  | Normalization | |            |
                  |  +---------------+ |            |
                  |        |           |            |
                  |       \|/          |            |    Possibly revised
                  |  +-----------+     |            | authorization identity
                  |  | Mechanism |<----|<-----------+      F(AuthZId)
                  |  +-----------+     |
                  |        |           |
                  |        |           |
                  +--------------------+
                           |
                           |
          Client           |
               ............|..........................
          Server           |
                           |
                          \|/

Regards,
Simon

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 25 Feb 2004 17:14:01 -0800

It's my view that the mechanism provides method for transferring
an string representing the authorization identity.  Not only is the
form of this authorization identity protocol specification, but how
to compare two authorization identities is a matter of the protocol
specification.  The protocol specification must detail where any
normalization (in the broadest sense) is to be done.  It could be
done on the client side, or the server side, or a combination.

Hence, it is very important that where a mechanism uses the
authorization identity as input to a cryptographic function that
it uses the precise form transferred (or to be transferred) by
the mechanism.

That is, any and all client side normalization (per the protocol profile)
of the authzid must occur before input to the function and no server
side normalization (per the protocol profile) of the authzid must occur
before input to the function.

 From the protocol perspective,
        user provided authzid -> client side normalization ->
           transfer by mechanism -> server side normalization -> use

 From a mechanism perspective, the protocol normalization (if any)
that is occurring is irrelevant as it's only responsible for its
transfer.  If the mechanism does do anything with the authorization
identity, such as inputs into a cryptographic function, it MUST use
the value as transferred.

So, I think your picture is not correct as it implies normalization
is a client side matter.  That is not necessarily the case.

At 03:45 PM 2/25/2004, Simon Josefsson wrote:
>Profiles may normalize the AuthZId however they want,

including at the client and/or the server.

>and mechanism
>may normalize authentication identities however they want.

including at the client and/or the server.

>Mechanism
>cryptographic processing).  Is this correct?

Yes. mechanisms are responsible only for transferring the a
string which represents, in an protocol specific manner, the
authorization identity.

>(I prefer not to

Huh?  I assume you meant H(authcid|password|authzid) or something similar.

Anyways, it's bogus for the mechanism implementation to do much of
anything with the authzid, except ensuring it is transferred properly,
as its semantics are protocol specific.

The mechanism implementation should likely have stored
H(authcid|password) instead.

>databases, depending on which protocol is used.

No, it just should not include the authzid in that database.  There
should be, logically, a separate database which proxy authentication
(identity assumption) policy.  Note that this database likely keys
off a protocol-specific mapping of the authentication identity.  That
is, off the authzid which would have been derived from the authentication
identity if no authzid has been transferred.  It should be noted that
this mapping requires both knowledge of the mechanism-specific form
of the authentication identity and the protocol-specific form of the
authorization identities.

Of course, implementations might actual use other forms of identities
for access control and other policy decisions... (meaning there may
additional identity mappings going on).

Kurt

>Implementation wise,

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 25 Feb 2004 17:37:23 -0800

>it uses the precise form transferred (or to be transferred) by

I note that DIGEST-MD5 is an example of a mechanism which
uses the transferred authzid value as input to a cryptographic
function.

Kurt

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 26 Feb 2004 10:03:02 +0100

> is a client side matter.  That is not necessarily the case.

The server part wasn't part of the picture, and for the client side
the picture tried to imply that the normalization may be the identity
function ("_Possibly_ revised authorization identity"), so I think we
actually agree.

> Huh?  I assume you meant H(authcid|password|authzid) or something similar.

Yes, sorry.

> as its semantics are protocol specific.

I think this is not clear -- and many implementations do authorization
for you, all suggesting it is a service from the SASL mechanism
framework.

> authorization identities.

This view helps.  A picture with (conceptually) two databases, one
mechanism specific for authentication identities and, and one protocol
specific with authorization identities, would help.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 26 Feb 2004 06:35:40 -0800

>for you, all suggesting it is a service from the SASL mechanism

I think RFC 2222 was quite clear that the form of the authorization
identity is mechanism specific, and in fact, says its the protocol
profiles responsibility to provide:
   5. A specification of how the authorization identity passed from the
      client to the server is to be interpreted.

This should be even clearer in the revised specification and, possibly,
could be made even more clear.

What some so-called SASL developers have done is provide SASL
implementations which interpret the authorization identity in
a fashion consistent with some set of the protocol profiles,
but obviously not all possible (or even all existing) protocol
profiles.  I question however whether saying more actually will
help.  The (inherent) fact is that implementors often write with
binders on (e.g., with a limited set of mechanisms and protocols in
mind) and only realize their false assumptions upon attempts to
adapt their work to other mechanisms/protocols.

I am not saying such implementations are broken (when used in the
set of protocol they were designed to support), just that they
are part implementation and part implementation of a set of
similar protocol profiles.  It should be clear that such
implementations are not readily usable in implementations of
dissimilar protocol profiles.

>specific with authorization identities, would help.

Maybe, but then again many readers will get confused by unnecessary
elaboration.  Saying more (in prose or with pictures) tends to lead
to inconsistencies in the specification, which lead to different
interpretations, and to interoperability problems.  That is, while
I don't necessarily oppose new text (and/or new pictures), I generally
think the specification would be clearer if it were more concise.

Kurt

---

From: Sam Hartman <[email-masked]>
Date: Sat, 28 Feb 2004 03:23:04 -0500

>>>>> "Simon" == Simon Josefsson <[email-masked]> writes:

    Simon> "Kurt D. Zeilenga" <[email-masked]> writes:

    >>> First, does 'character strings' include the authorization
    >>> identity?  Defining the term 'character string', or at least
    >>> giving examples, would help.
    >>  No.  I believe the text should be clarified.  Mechanisms
    >> should be capable of exchanging the authorization identity, but
    >> its handling (in particular for comparison) is specific to the
    >> application-level protocol which has profiled use of SASL as an
    >> authentication method.

The authorization identity is a
string; this is certainly true in 2222bis, and I believe was true in
RFC 2222.

I agree that the comparison and normalization of this string should be
an application or protocol profile matter.

It seems to me that we need to decide what the encoding of the
authorization identity is either in the protocol profile or the
mechanism specification. The base spec does need to be clarified to
say which of these two is responsible for defining the encoding of the
authorization ID.

I also find that the digest-md5 spec is unclear on whether the
authorization ID is UTF8 or is in some unspecified character set.
Perhaps we believe that specification belongs to the protocol profile;
if so we should be more explicit.

Absent a good reason to do otherwise, I'd prefer that the mechanism
specification define the encoding of the authorization ID.  After all
the mechanism must transport it.

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 01 Mar 2004 04:36:19 +0900

Simon Josefsson wrote:

> ...
>
>I think the most important modification that should be done is to
>stress the relationship "authorization identity"<->"protocol profile"
>and "authentication identity"<-> "mechanism".  This isn't clear now,
>but helps with the conceptual understanding.  I wasn't aware of this
>distinction after reading RFC 2222, so it appears to be something new
>in 2222bis.  Perhaps adding the sentences as below could help, if they
>are correct (I'm not sure, correct me if not).
>
>Regards,
>Simon
>
>4.2.  Authorization and authentication identities
>
>   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.
>
>   A mechanisms which are incapable of transmitting an authorization
>   identity must be treated as if it always transmits an authorization
>   identity of an empty string.
>
>   Authentication identity is the identity derived from the client's
>   authentication credentials.  Any normalization of the
>   authentication identity is defined by each mechanism, the profile
>   does not influence it.
>
>   The authorization identity is used by the server as the primary
>   identity for making access policy decisions.  Any normalization of
>   the authorization identity is defined within each SASL protocol
>   profile, and occur before the authorization identity is handed to
>   the mechanism.  The mechanism may not modify (by, e.g.,
>   normalization) the authorization identity.
>
I've integrated the suggested text about normalization.

Alexey

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 23 Feb 2004 16:43:43 -0800

I disagree.

Kurt

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 25 Feb 2004 18:16:15 +0100

Regards,
Simon

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 26 Feb 2004 00:45:27 +0100

Regards,
Simon

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 25 Feb 2004 17:14:01 -0800

Kurt

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 25 Feb 2004 17:37:23 -0800

Kurt

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 26 Feb 2004 10:03:02 +0100

Yes, sorry.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 26 Feb 2004 06:35:40 -0800

Kurt

---

From: Sam Hartman <[email-masked]>
Date: Sat, 28 Feb 2004 03:23:04 -0500

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 01 Mar 2004 04:36:19 +0900

Alexey