[jdev] When to apply the SASLprep stringprep profile?

Kurt Zeilenga Kurt.Zeilenga at Isode.com
Mon Dec 1 11:04:46 CST 2008

On Nov 30, 2008, at 9:49 AM, Tobias Markmann wrote:

> Hi,
> when do i have to apply SASLprep and on what? The RFC, http://www.ietf.org/rfc/rfc4013.txt 
>  , just says it's applied on usernames and passwords.

It applies where it's called for, generally by protocol specifications  
saying "SASLprep this username" or "SASLprep this password".

There are a few specifications which do so, name RFC 4616 (SASL/PLAIN)  
and various LDAPv3 specifications (RFC4510).

DIGEST-MD5 will not be revised to do SASLprep.  It will instead be  
deprecated in favor of SCRAM (hopefully).

> So I'm asking:
> 	• Do I need to apply SASLprep as server for all possible SASL  
> mechanism or just Digest-MD5?

Well, for Challenge/Response mechanisms, both sides need to agree on  
how to handle the password.  For instance, with CRAM-MD5, the  
specification (RFC 2195) just says the client/server implementations  
hash the password.  But is that password Unicode or some other  
character set? Is it UTF-8?  Should some code points be mapped to  
others?  How should it be normalized?  What code points are  
disallowed?  etc.

Now, most implementations of CRAM-MD5 just agree (a priori) that the  
password is US-ASCII represented with in a single octet with zero  
parity, no-normalization, only printable characters allowed, etc.

Likewise for many other mechanisms, including DIGEST-MD5 (though the  
advertised character set is not US-ASCII).

> 	• Does everything still work if clients doen't apply SASLprep  
> profile at all?

If they stick to the above agreement.

> 	• At what point to do SASLprep on username and password? I mean do  
> I use the prepped string for response string calculation or the non- 
> prepped?

Generally, the username need not be prep'ed by the client.  The server  
will prep it as needed to find the user data.  And generally, that  
means applying jid specific preparation in XMPP.

For passwords, well, moving beyond the above agreement is hard.  But  
SASLprep is relatively safe in that, for US-ASCII printable password,  
it produces the same output as the above agreement.

-- Kurt

> Cheers,
> Tobias
> _______________________________________________
> JDev mailing list
> FAQ: http://www.jabber.org/discussion-lists/jdev-faq
> Forum: http://www.jabberforum.org/forumdisplay.php?f=20
> Info: http://mail.jabber.org/mailman/listinfo/jdev
> Unsubscribe: JDev-unsubscribe at jabber.org
> _______________________________________________

More information about the JDev mailing list