[jdev] saslprep and nodeprep
Waqas Hussain
waqas20 at gmail.com
Wed Sep 26 16:15:19 UTC 2012
On Wed, Sep 26, 2012 at 8:38 PM, Peter Saint-Andre <stpeter at stpeter.im> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 9/26/12 9:29 AM, Waqas Hussain wrote:
>> On Tue, Sep 25, 2012 at 11:50 PM, Peter Saint-Andre
>> <stpeter at stpeter.im> wrote:
>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>>>
>>> Just FYI, I compared SASLprep (RFC 4013) and Nodeprep (RFC 3920)
>>> recently and it seems that any XMPP localpart that conforms to
>>> Nodeprep also conforms to SASLprep
>>
>> Correct. A localpart conforming to nodeprep also conforms to
>> saslprep.
>>
>>> , so there is no need to perform separate SASLprep processing in
>>> XMPP client and server code. If you disagree with my conclusions,
>>> please let me know. :)
>>>
>>> Peter
>>
>> Not true. SASLprep maps non-ASCII space characters [StringPrep,
>> C.1.2] to SPACE (U+0020). Nodeprep forbids C.1.2 characters.
>
> Right, so a string that passes Nodeprep will not include non-ASCII
> space characters. Thus there's no need to map those characters to
> U+0020 as in SASLprep, since they won't be in the string.
>
>> A string with non-ASCII space characters needs to be saslprepped
>> before it can pass nodeprep.
>
> Why would you saslprep a string before nodeprepping it? It seems more
> natural to nodeprep a string before saslprepping it (since this is
> XMPP and you'll need to nodeprep it anyway at some point), in which
> case you can just do nodeprepping and not worry about saslprepping.
>
You have to apply SASLprep as part of the SASL layer, which passes the
extracted authentication string to the XMPP (or other) layer, which
then applies NODEprep. However, all of this is moot given how ASCII
spaces are not allowed in XMPP localparts in the first place. So, yes,
you can skip SASLprep if you apply NODEprep.
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.
--
Waqas Hussain
More information about the JDev
mailing list