[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