Subject: [kitten] RFC-5802 (SCRAM): authorization identity passed through stringprep

From: Jehan Pagès <[email-masked]>
Date: Fri, 2 Sep 2011 04:46:13 +0900

Hi,

I just noticed that the SCRAM RFC does not ask that the authorization
identity (a=) if present be prepared by the SASLprep profile of the
stringprep algorithm. I would think though that it should follow the
same preparation as the authentication identity (n=).

Unless there was a reason to this which I am willing to read, I would
like to propose an errata which updates:
«
The syntax of this field is the same as that of the "n" field
with respect to quoting of '=' and ','.
»
into:
«
The syntax of this field is the same as that of the "n" field
with respect to preparing the username using the "SASLprep" profile of
the "stringprep" algorithm and to quoting of '=' and ','.
»

May I propose this errata?
Thanks.

Jehan

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 01 Sep 2011 22:21:57 +0100

>Hi,
Hi Jehan,

>the "stringprep" algorithm and to quoting of '=' and ','.
Per RFC 4422 syntax and normalization of authorization identities is 
controlled by protocol spec, not SASL mechanism specs. So if, for 
example, XMPP spec says that all authorization identities need to be 
SASLpreped, then this would apply to SCRAM as well.

>May I propose this errata?
As per above, I think the document is correct in this respect.

---

From: Jehan Pagès <[email-masked]>
Date: Mon, 5 Sep 2011 22:46:16 +0900

Hi,

2011/9/2 Alexey Melnikov <[email-masked]>:
> controlled by protocol spec, not SASL mechanism specs. So if, for example,
> XMPP spec says that all authorization identities need to be SASLpreped, then
> this would apply to SCRAM as well.

Indeed it seems that you are right. It is said in various places in
RFC-4422 that this is protocol specific.

In any case, I find a little annoying that authentication and
authorization identity are processed differently. Actually I now see
the have the opposite bother: I don't see why we pass the authcid
through stringprep. Why didn't we stop to ',' and '=' escaping there
too and let the protocol (XMPP for instance) enforce this on its side?
I don't understand the double standard here.
Keeping the XMPP example, the server will also process authcid through
stringprep (but Nodeprep profile now, so the authcid would be
stringprep-ed both to Nodeprep and SASLprep) and work is going on
passing away from stringprep in RFC-6122.
I think then we should have released this stringprep processing on
authcid. Is there a reason we make this processing?

Moreover it is written in RFC-5802: «the client SHOULD prepare the
username using the "SASLprep" profile». If we really wanted to do
this, why isn't it a MUST? We might get into cases where the same
authentication identity can be transferred in 2 forms by 2 clients,
whether it has been stringprep-ed or not.
Isn't there even more lack of consistency here?

> As per above, I think the document is correct in this respect.

I think you are right. Now, as you read, I would rather propose the
opposite change by releasing away this stringprep processing from
authcid (rather than adding it on authzid) for consistency.
Doesn't it make sense?

Thanks.

Jehan

---

From: Nico Williams <[email-masked]>
Date: Tue, 6 Sep 2011 12:35:56 -0500

> I don't understand the double standard here.

Authcid and authzid belong to different and unrelated entities
(mechanism and application, respectively).  Therefore they will
necessarily have different treatments (unless all mechs and all apps
were to have the same treatment).  SCRAM is a mechanism, therefore
SCRAM gets to specify how authcids for it are handled.  SCRAM is not
an application, therefore it doesn't get to say anything about authzid
-- authzid is opaque to SCRAM.

> authcid. Is there a reason we make this processing?

Yes: we have to do something to make it possible to handle Unicode
normalization.

We could have specified that the server does matching however it likes
provided that authcid is effectively normalization insensitive, and
that certain characters are mapped in such and such ways, and so on.
But here's the thing: that can only work for authcid, nor for
passwords.  We could also have said that passwords must be ASCII, but
we'd not have had consensus for that, not then anyways.

> authcid (rather than adding it on authzid) for consistency.

No, not to me.  See above.

Nico
--

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 06 Sep 2011 12:59:17 -0600

On 9/6/11 11:35 AM, Nico Williams wrote:

> We could also have said that passwords must be ASCII, but

That reminds me, I need to post to the [email-masked] list about the
handling of non-ASCII characters in passwords (in relation to the PRECIS
WG, see draft-ietf-precis-framework).

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Jehan Pagès <[email-masked]>
Date: Wed, 7 Sep 2011 04:30:25 +0900

Hi,

> we'd not have had consensus for that, not then anyways.

I agree. That's why I only propose it for authcid and not for the
normalization made on the password which should probably stay. That's
more authcid (usually the "login" part of a protocol, visually
provided to users), whose syntax *in a general point of view* should
be defined *only* in the protocol, not in SASL or the mechanisms in my
opinion, because every protocol has its own view about what its login
should look like (for instance XMPP and emails have similarly looking
syntax but in reality are quite different) though they may all use
SASL for authentication.

Also you did not answer about the part where I was wondering why this
normalization is a SHOULD on authcid, which has the bad consequence of
maybe authenticating different authcid depending on the implementation
you enter them. I think that if we want to do this normalization on
SASL side (before it reaches the application), at least make it a
MUST, not a SHOULD, which basically is some kind of "random".

Finally I wont' insist too must on this all anyway. I am in particular
interested in XMPP myself, and I have just compared Nodeprep from XMPP
and SASLprep. Apparently there can't be too much harm in this specific
case at least (whether or not the SASL client did the SASLprep or
not). So if nobody agrees with me now, that's not that annoying for
now.
I'll have a look later again when we go away from stringprep (in the
RFC which will replace RFC-6122) but that's probably in a long time
for now.
Thanks for the answer.

Jehan

---

From: Sam Hartman <[email-masked]>
Date: Fri, 23 Sep 2011 16:43:56 -0400

>>>>> "Jehan" == Jehan Pagès <[email-masked]> writes:
>>>>> "Jehan" == Jehan Pagès <[email-masked]> writes:

    Jehan> I agree. That's why I only propose it for authcid and not for
    Jehan> the normalization made on the password which should probably
    Jehan> stay. That's more authcid (usually the "login" part of a
    Jehan> protocol, visually provided to users), whose syntax *in a
    Jehan> general point of view* should be defined *only* in the
    Jehan> protocol, not in SASL or the mechanisms in my opinion,
    Jehan> because every protocol has its own view about what its login
    Jehan> should look like (for instance XMPP and emails have similarly
    Jehan> looking syntax but in reality are quite different) though
    Jehan> they may all use SASL for authentication.

Both the SASL framework and I disagree with you.  One of the major
points of SASL in a platform context is that you can reuse
authentication across protocols.  Your AUTHCID is *not* your email
address or your jid. IIt's a scram-specific identifier not a protocol
specific identifier.  Your authorization ID is a JID or email address.
The application (or hopefully the platform) needs to map your authcid
into the protocol specific authzid.
This mapping may be simple or very complex.

To understand why this is important consider a platform like Active
Directory where authentication identifiers are global and independent of
any application.  So, the form of AUTHCIDs very is much is not a matter
for a protocol.

I do not support a change in this handling.

---

From: Jehan Pagès <[email-masked]>
Date: Sun, 25 Sep 2011 15:31:32 +0900

Hi,

On Sat, Sep 24, 2011 at 5:43 AM, Sam Hartman <[email-masked]> wrote:
>>>>>> "Jehan" == Jehan Pagčs <[email-masked]> writes:
>>>>>> "Jehan" == Jehan Pagčs <[email-masked]> writes:
>

Hmmm... Ok. I see your point. Also I don't really know what to think
about this anymore and I don't see much problem in this current use
case. So that's good for me to let it be (that was already good 2
messages before in fact ;-).
Thanks.

Jehan

---

From: Simo Sorce <[email-masked]>
Date: Fri, 23 Sep 2011 16:56:06 -0400

> I do not support a change in this handling.

FWIW I strongly support Sam's position.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York