Subject: Re: Use of authorization identity

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Sun, 03 Jun 2001 15:07:44 -0700

In my opinion, SASL should just provide a framework for
authentication and security services.  The framework itself
shouldn't define the encoding of an authorization identity
or otherwise restrict authorization identity forms.

I agree that it would be nice if more mechanisms were less
restrictive.  Unfornately, most mechanisms are quite
restrictive.  In fact, most mechanisms cannot handle UTF-8
strings without significant restrictions.

The problem, as I see it, is that RFC 2222 should have provided
more guidance.  I believe it should say "Mechanisms SHOULD
be capable of transferring authorization identities of arbitrary
form.  Escaping mechanisms SHOULD be provided to encode otherwise
non-transferable octets into a transferable form.  That is,
DIGEST-MD5 (and other limiting mechanisms) should provide an
escaping mechanism. 

> Authorization ids are character strings

I assume by character strings you mean UTF-8 encoded
ISO 10646 character strings.  I note that many existing
mechanisms cannot transfer arbitrary non-NUL UTF-8 strings.
So, either further restrictions or escaping mechanisms will be
needed here.  As soon as you provide an escaping mechanism,
you might as well support arbitrary octet strings as any
decent escaping mechanism will support such.  And if you are
going to allow arbitrary octet strings via escaping, you
might as well allow mechanisms which don't need such escaping
to carry the octets without any escaping.

Kurt

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Sun, 03 Jun 2001 15:17:39 -0700

BTW, do we actually have two independently developed
interoperable implementations of SASL proxy authorization
features?

Kurt

---

From: John Gardiner Myers <[email-masked]>
Date: Mon, 04 Jun 2001 14:26:49 -0700

"Raif S. Naffah" wrote:
> of course.  but this is not the issue.  the issue, is how a protocole
> passes the contents of the authorization-id to a mechanism.
> 
> to wit, consider the case of Protocole P1 that uses mechanism M, and
> another Protocole P2 that uses the same mechanism; ie. M.

In a direct-mail exchange, you clarified that P1, P2, and M are
implementations, not protocol profiles.

> furthermore, P1
> mandates the use of UTF-8 as the encoding of its authorization-id, while
> P2, mandates ASCII.

It is not the place of implementations to make such across-the-board
mandates.  While P1 and P2 may be designed to use particular encodings
internally, whenever they communicate with some external code they need
to use the encoding that is specified by the interface through wich they
communicate.

> since mechanisms have to provide, on one side of a
> communication channel an authorization-id, they should accept such a value
> from the other side at some time during their life-time; probably at their
> instantiation/start of a session.
> 
> now how does the API for such a mechanism look like?
> 
> should it be UTF-8, ASCII, both?

This is something that is defined by the SASL API those implementations
choose.

> remember, we cannot just say it's a
> "string" since a C string does not mean the same thing as a Java string for
> example.

It doesn't make sense to talk about a Java application directly calling
a C implementation.  Similarly, it doesn't make sense to talk about a
Sparc binary directly calling an X86 binary.  String encodings are the
least of your worries here.

> which also means that P1 cannot use inter-changeably a C
> implementation of M with a Java one (eg. through CORBA/IDL).

For a Java implementation to call C code, it must go through some sort
of inter-language mapping layer.  Such a layer has to deal with a number
of language mapping issues, including differing string representations
and ownership models.

> it's for this reason that i am arguing for a clear text in the
> specifications that state that Mechanisms should handle authorization-ids
> as possibly null octet sequences.

This does not follow.  Even if we were to break with longstanding IETF
design principles and mandate that all implementations internally
represent certain strings in a certain way, there is no argument offered
that such strings need to be defined as octet sequences.

---

From: John Gardiner Myers <[email-masked]>
Date: Mon, 04 Jun 2001 15:07:39 -0700

> or otherwise restrict authorization identity forms.

The framework itself needs to provide enough of a definition of
"authorization identity" to provide interoperability.

> strings without significant restrictions.

Could you list the mechanisms you are talking about?  CRAM-MD5, LOGIN,
and ANONYMOUS cannot handle any non-empty authorization id, they don't
count. 
 
> more guidance.

This is precisely what we are trying to fix.

> I believe it should say "Mechanisms SHOULD
> form.

"Arbitrary form" does not work.  Octet strings and character strings are
like apples and oranges.  We need to pick one, the other, or some as yet
unproposed other option.

> Escaping mechanisms SHOULD be provided to encode otherwise

Adding an escaping mechanism to DIGEST-MD5 is not sufficient.  Each of
the changes I listed previously is necessary in order to make
authorization ids be octet strings.  If authorization ids are octet
strings, then mechanisms cannot specify a charset for the authorization
id and any such specifications need to be removed.

> ISO 10646 character strings.

No.  I mean ordered sequences of characters.  The characters do come
from the ISO 10646 character set, but the base specification has no need
of the integer mapping of the ISO 10646 coded character set.  The UTF-8
character encoding scheme is not relevant to the base SASL
specification.

> I note that many existing
> decent escaping mechanism will support such.

It does not make sense talking about including octets in character
strings.  Octets are not characters.

---

From: John Gardiner Myers <[email-masked]>
Date: Mon, 04 Jun 2001 15:11:16 -0700

> interoperable implementations of SASL proxy authorization

I recall being informed that we do.  I believe Lawrence Greenfield
volunteered to put together the implementation report.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 04 Jun 2001 16:15:50 -0700

>"authorization identity" to provide interoperability.

Interoperability at what level?  At the protocol level, it
really needed same much as it is the mechanism which defines
how to encode the authzid.  Mechanisms can place all kinds
of restrictions upon their values (such as length limits).

>and ANONYMOUS cannot handle any non-empty authorization id, they don't

SecureID [RFC2808] and OTP [RFC2444] restricts authorization
identity to "printable" UTF-8 and has a length limit of 255 octets.
PLAIN is similar, but only discourages "non-visible" characters.

DIGEST-MD5 (RFC2831) supports arbitrary UTF-8 characters (including NUL).

EXTERNAL and GSSAPI, of course, support arbitrary octet strings.

>This is precisely what we are trying to fix.

Guidance is fine, it's a defining a SASL-wide authorization
identity encoding I have problem with.

>"Arbitrary form" does not work.

It works just fine.

>Octet strings and character strings are
>like apples and oranges.

Yes, so?  An octet string can be encoded as a character string.
A character string can be encoded as an octet string.  

>We need to pick one, the other, or some as yet
>unproposed other option.

What is important is that each mechanism be able to transfer a profile
specific authorization identity.

>character encoding scheme is not relevant to the base SASL

Likewise, the base specification could say the authorization
identity is an octet string as it quite irrelevant to the base SASL
specification as to what the octets represent.

Kurt

---

From: John Gardiner Myers <[email-masked]>
Date: Mon, 04 Jun 2001 17:30:58 -0700

"Kurt D. Zeilenga" wrote:
> Interoperability at what level?

Implementations and protocol profiles need to know what kind of values
can be transmitted by mechanisms.  If a protocol profile expects to be
able to transmit an octet string, implementations of that protocol
profile will not work when used with mechanisms that expect to transmit
character strings.

> At the protocol level, it
> how to encode the authzid.

I cannot parse this sentence.

> Mechanisms can place all kinds

This perhaps argues that such limits (or minimum maximums) be specified
in the base spec.

> PLAIN is similar, but only discourages "non-visible" characters.

This can hardly be considered "quite restrictive".  Printability and
normalization constraints probably belong in the base specification. 
The base specification should probably also recommend a minumum maximum
length.

> identity encoding I have problem with.

We have to define it as something.  Right now, the choices are octet
strings or character strings.

> >"Arbitrary form" does not work.

It does not work, as shown in the following text.
 
> A character string can be encoded as an octet string.

One can be encoded in the other, but to do so one has to specify the
encoding.  In either direction, there are many possible encodings to
use.

If some protocol or interface has a field that takes an octet string,
you cannot put a character string in that field without specifying the
method of encoding the character string as an octet string.  Similarly,
if some protocol or interface has a field that takes a character string,
you cannot put an octet string in that field without specifying the
method of encoding the octet string as a character string.

If a protocol or interface has a field that you want to put a character
string into, you need to know whether that field is a character string,
octet string, or something else so that you know what kind of encoding,
if any, you need to specify and apply.  Protocols cannot have fields of
arbitrary form--there must be some common understanding of base type for
communication to be possible.

> specific authorization identity.

To do that, mechanisms and protocols need to have a common understanding
of what the bounds are on the set of possible authorization identities. 
If a protocol profile expects to supply octet strings, but a mechanism
expects to transfer character strings, things will not work.  Neither
will be responsible for doing the necessary encoding.

> specification as to what the octets represent.

The text you were replying to was listing the changes needed if we
decide that authorization ids are character strings.  In that context,
"authorization ids are character strings" is a postulate.

The section of that message that takes the postulate "authorization ids
are octet strings" is later in that message, under the heading
"Authorization ids are octet strings:".

So for necessary changes, for either choice, we probably need the base
specification to address length restrictions that mechanisms impose on
the authorization id.  We also need to address nonprintable characters
and normalization--for the "character string" case this needs to be done
in the base spec, for the "octet string" case this needs to be done in
each protocol profile that encodes characters into the authorization id.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 04 Jun 2001 17:53:52 -0700

Just for clarity, I believe the base specification should
say that the form of an authorization identity is profile
specific and mechanisms should be prepared to transfer
an sequence of octets representing the authorization identity.

Kurt

---

From: John Gardiner Myers <[email-masked]>
Date: Mon, 04 Jun 2001 18:15:41 -0700

> an sequence of octets representing the authorization identity.

This is equivalent to saying that the authorization identity is an octet
string.

Please review my message of last Wednesday listing the changes necessary
for each alternative.  I've also listed additional changes for each
alternative in my previous message.  I would like to at least get
consensus on the following points:

* The need to make a decision

* The two alternatives

* The set of changes needed to implement each alternative

Once we have that, we can then evaluate each alternative and hopefully
come to a decision by the end of the London IETF.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 04 Jun 2001 18:43:24 -0700

>come to a decision by the end of the London IETF.

This seems like a reasonable approach.  I note that a
SASL BOF has been approved (we'll met as a WG if we get
that approval prior to IETF#51).  Once we get a scheduled,
I'll post more info.

What concerns me most is scope.  We need to be sure we are fixing
SASL, not codifying limitations of certain mechanisms, profiles,
and implementations thereof.

I will again review you past post and respond more with what
changes I believe are needed for each approach to the problem
(as opposed to entering into a debate over which approach is
more appropriate).

Kurt

Kurt

---

From: John Gardiner Myers <[email-masked]>
Date: Thu, 07 Jun 2001 14:40:06 -0700

> and implementations thereof.

Sometimes fixing a standard involves codifying the behavior of the
installed base.

Our scope is to move SASL and some of its mechanisms to Draft Standard,
recycling documents at Proposed only if there is strong reason to do so.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Tue, 12 Jun 2001 14:52:40 -0700

At 05:02 PM 5/30/2001, John Gardiner Myers wrote:

>I believe the following are the changes necessary for each of the
>proposed solutions to the authorization id problem:

I have added other changes I believe are needed:

>Authorization ids are character strings:

 * Define the character set to be ISO 10646.
 * Recommend that mechanisms use UTF-8 encoding of character
   strings.
 * Recommend that mechanisms provide escaping or other method
   to allow transfer of authorization identities to include
   arbitrary (non-NUL) characters.
 * Recommend that mechanisms against using encoding which
   can only represent a subset of the character set (e.g. UCS-2).

>* Add to SASL section 4.2 a specification that the authorization
>identity is a character string.  NUL characters not permitted.

 * Update profiles which allow NUL characters in authzIds.

>* Make SASL requirement 5.5 optional to the protocol profile.

 * Update mechanisms to implement above recommendations.
   Add restriction to GSSAPI and EXTERNAL
   Add escaping mechanism to most every other mechanism.

>Authorization ids are octet strings:
>
>* Revert additions to SASL-GSSAPI and EXTERNAL, removing the
>specification that the authorization id is in UTF-8.
>
>* Extend DIGEST-MD5, OTP, SECURID, and PLAIN to carry non-UTF-8
>authorization
>ids.  OTP, SECURID, and PLAIN will likely remain incapable of carrying 0
>octets in authorization ids.

A simple escaping mechanism can be used.

>* Add to the POP, IMAP, ACAP, etc. protocol profiles a specification
>that the authorization ID is in UTF-8.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Sun, 03 Jun 2001 15:07:44 -0700

Kurt

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Sun, 03 Jun 2001 15:17:39 -0700

Kurt

---

From: John Gardiner Myers <[email-masked]>
Date: Mon, 04 Jun 2001 14:26:49 -0700

---

From: John Gardiner Myers <[email-masked]>
Date: Mon, 04 Jun 2001 15:07:39 -0700

---

From: John Gardiner Myers <[email-masked]>
Date: Mon, 04 Jun 2001 15:11:16 -0700

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 04 Jun 2001 16:15:50 -0700

It works just fine.

Kurt

---

From: John Gardiner Myers <[email-masked]>
Date: Mon, 04 Jun 2001 17:30:58 -0700

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 04 Jun 2001 17:53:52 -0700

Kurt

---

From: John Gardiner Myers <[email-masked]>
Date: Mon, 04 Jun 2001 18:15:41 -0700

* The two alternatives

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 04 Jun 2001 18:43:24 -0700

Kurt

Kurt

---

From: John Gardiner Myers <[email-masked]>
Date: Thu, 07 Jun 2001 14:40:06 -0700

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Tue, 12 Jun 2001 14:52:40 -0700