[jdev] saslprep and nodeprep

[Joe Hildebrand]

On 9/26/12 10:15 AM, "Waqas Hussain" <waqas20 at gmail.com> wrote:

>This does bring up an interesting side issue: Passwords used in XMPP
>should get SASLprep applied on SASL auth (and SASL PLAIN also forbids
>a zero character password) . However, IBR and ad-hoc based service
>administration allow creating and setting passwords which wouldn't
>allow SASL based login.

We might add a rule to XEP-77 that passwords received in this manner
SHOULD be canonicalized before storage or computation in such a way that
the user can log into the account created using all of the SASL mechanisms
offered by the server.

For example, if you're doing SCRAM and storing only the SaltedPassword,
you MUST SASLprep the password before computing that SaltedPassword for
storage.

However, in this case:

SaltedPassword  := Hi(Normalize(password), salt, i)

<blockquote>
Normalize(str): Apply the SASLprep profile of the "stringprep"
algorithm [RFC3454] as the normalization algorithm to a UTF-8
encoded "str".  The resulting string is also in UTF-8.  When applying
SASLprep, "str" is treated as a "stored strings", which means that
unassigned Unicode codepoints are prohibited (see Section 7 of
[RFC3454]).  Note that implementations MUST either implement
SASLprep or disallow use of non US-ASCII Unicode codepoints in "str".

</blockquote>



So I'm not sure how you'd do this computation *without* SASLprep'ing
first, if you allow non-US-ASCII code points in passwords at all.

-- 
Joe Hildebrand