Subject: authentication and authorization identities, and passwords in SASL Mechanisms

From: "Raif S. Naffah" <[email-masked]>
Date: Tue, 1 Apr 2003 21:27:26 +1100

hello there,

can someone calrify the following:

1. why does a SASL Mechanism has to mandate SASLPrep as a needed 
transformation for authentication identities (usernames) and passwords, 
in preference to something like:

   MUST be in Unicode Normalization Form KC [UNICODE-KC]
   without NUL characters.

wouldn't a transformation such as the SASLPrep be part of the SASL 
Profile itself rather than the Mechanism(s)?

2. what is the consensus on specifying/handling authorization identities 
for transportation on the wire?  is [UNICODE-KC] enough?

TIA + cheers;
rsn

---

From: Sam Hartman <[email-masked]>
Date: Tue, 01 Apr 2003 11:29:56 -0500

>>>>> "Raif" == Raif S Naffah <[email-masked]> writes:

    Raif> hello there, can someone calrify the following:

    Raif> 1. why does a SASL Mechanism has to mandate SASLPrep as a
    Raif> needed transformation for authentication identities
    Raif> (usernames) and passwords, in preference to something like:

    Raif>    MUST be in Unicode Normalization Form KC [UNICODE-KC]
    Raif> without NUL characters.

Please read the stringprep document; it has a good discussion of the
elements that go into a stringprep profile and I believe why they are
needed.  If this is insufficient, please look at old minutes of the
IDN working group and their archived mailing list.

Note that mechanisms do not need to use the saslprep profile.  They
need to adopt a stringprep profile that is appropriate for the
mechanism in question.  For example anonymous uses a much less
restrictive profile.

Mechanisms using cryptography will tend to need fairly strong
canonicalization rules to make sure that usernames and passwords typed
with one set of input methods are handled the same when typed with a
different set of methods.

    Raif> wouldn't a transformation such as the SASLPrep be part of
    Raif> the SASL Profile itself rather than the Mechanism(s)?

If by SASL profile, you mean the profile for an application, no.  The
form of authentication identifiers and other mechanism-specific
strings such as passwords is entirely a matter for the mechanism.  As
an example, Kerberos will mandate a particular stringprep profile for
principals and passwords.  In order for things to work, the SASL
GSSAPI mechanism for Kerberos must use the same stringprep profile.

    Raif> 2. what is the consensus on specifying/handling
    Raif> authorization identities for transportation on the wire?  is
    Raif> [UNICODE-KC] enough?

The authorization identity is a matter for the application's SASL
profile.  In many cases, the same constraints will apply to
authorization identities as authentication identities.  The
transformation may end up being server-side rather than client-side,
but will likely still be needed.

I think we would prefer that application profiles seriously consider
the use of saslprep for authorization identifiers, but it is not right
for all environments.

---

From: Keith Burdis <[email-masked]>
Date: Tue, 1 Apr 2003 20:41:28 +0100

It's a fun document :-) You have things like:

  MONGOLIAN TODO SOFT HYPHEN
  OGHAM SPACE MARK
  ARABIC END OF AYAH
  MUSICAL CONTROL CHARACTERS

Seriously, this looks to be a reasonable specification for usernames and 
passwords. Is there any reason why all mechanisms shouldn't use at least this 
set of restrictions? Why for example, would anonymous use a less restrictive 
profile?

  - Keith

---

From: "Raif S. Naffah" <[email-masked]>
Date: Wed, 2 Apr 2003 09:33:44 +1100

On Wednesday 02 April 2003 02:29, Sam Hartman wrote:
> ...
>     Raif> authorization identities for transportation on the wire? 
> is Raif> [UNICODE-KC] enough?
>
> ...
> the use of saslprep for authorization identifiers, but it is not
> right for all environments.

would a sequence of bytes preceded by their count (one additional byte) 
be enough?

cheers;
rsn

---

From: Sam Hartman <[email-masked]>
Date: Fri, 04 Apr 2003 16:11:56 -0500

>>>>> "Raif" == Raif S Naffah <[email-masked]> writes:

    Raif> would a sequence of bytes preceded by their count (one
    Raif> additional byte) be enough?

I don't understand your question.  For a sasl mechanism, I think
limiting authorization identifiers to 255 bytes would be overly
restrictive.

For an application profile, sequence of bytes would be an
underspecified authorization identifier.

---

From: Alexey Melnikov <[email-masked]>
Date: Sat, 05 Apr 2003 14:43:07 -0700

Keith Burdis wrote:

> set of restrictions?

IMHO, all new mechanisms should use the same stringprep profile.

> Why for example, would anonymous use a less restrictive
> profile?

This is required for backward compatibility, as ANONYMOUS allowed for arbitrary
text to be passed.

Regards,
Alexey
__________________________________________
R & D, ACI Worldwide/MessagingDirect
Watford, UK

Work Phone: +44 1923 81 2877
Home Page: http://orthanc.ab.ca/mel

I speak for myself only, not for my employer.
__________________________________________

---

From: "Raif S. Naffah" <[email-masked]>
Date: Sun, 6 Apr 2003 10:23:33 +1000

> underspecified authorization identifier.

the adoption of StringPrep, within the specifications of a SASL 
Mechanism, solves the question of required (canonical) transformations 
for authentication IDs (uersnames) and passwords.  this is because as 
you pointed out --in your last email, and i totally overlooked-- these 
entities are acquired by the mechanism itself and hence are not within 
the scope of the Profile.

the authorization ID on the other hand, is not acquired by the 
Mechanism; at least this is my understanding/interpretation of last 
para in section 4.1 of draft-myers-saslrev-02.txt, which echoes another 
para in section 3 of RFC-2222:

   "During the authentication protocol exchange, the mechanism performs
   authentication, transmits an authorization identity (frequently known
   as a userid) from the client to server, and negotiates the use of a
   mechanism-specific security layer."

in other words, a Profile hands over an authorization ID (or a callback 
mechanism to receive it), which it (the Mechanism) then transmits to 
the peer.  my question is on the encoding of this entity as seen by the 
Mechanism, at that interface point.

draft-myers-saslrev-02, section 4.2 reflects discussions we had in this 
group about this token (authorization ID).  it proposes:

   "An authorization identity is a string of zero or more ISO 10646
   [ISO-10646] coded characters.  The NULL (U+0000) character is not
   permitted in authorization identities."

my question is about reaching a consensus on a choice and wording for 
how this entity is passed between the Mechanism and the Profile.  if a 
string of iso-10646 w/o nulls is not an acceptable option would an 
octet sequence with a length octet be one.  if neither are, what other 
alternatives are there.

cheers;
rsn

---

From: Sam Hartman <[email-masked]>
Date: Tue, 01 Apr 2003 11:29:56 -0500

---

From: Keith Burdis <[email-masked]>
Date: Tue, 1 Apr 2003 20:41:28 +0100

- Keith

---

From: "Raif S. Naffah" <[email-masked]>
Date: Wed, 2 Apr 2003 09:33:44 +1100

cheers;
rsn

---

From: Sam Hartman <[email-masked]>
Date: Fri, 04 Apr 2003 16:11:56 -0500

---

From: Alexey Melnikov <[email-masked]>
Date: Sat, 05 Apr 2003 14:43:07 -0700

Regards,
Alexey

---

From: "Raif S. Naffah" <[email-masked]>
Date: Sun, 6 Apr 2003 10:23:33 +1000

cheers;
rsn