authenticationencryptionwebrtcstunsasl

What is saslprep ? why its required a stun username password to be used with saslprep?

I have gone through RFC about could not understand the purpose of it can anybody dumb it down for me please.

Solution

  • TLDR:

    Some users, when creating a username or password, will manage to type unicode control characters, "non-breaking" type characters, or other variations of " " (space) that look like ordinary whitespace, but have a different unicode value. Or somehow, illegal unicode characters, bi-directional Hebrew characters, or multiple variations of the "Turkish Letter I" that look identical, but with different ordinal values. Also, unicode has a lot of other weird stuff besides printable characters. Stuff like code points, formatting, etc...

    Most websites, will just blow up and show the user an error if they type anything outside of the ascii range for a username and password when creating an account. Problem solved. No saslprep needed for this.

    But here's a classic example.

    Let's say I email helpdesk asking for help with my internal account named t-bone. But Outlook has this weird feature where it replaces all typed hyphens (-) from the keyboard with an emdash (—) character because it looks more presentable. If the support agent cuts and pastes that string out of the email I sent them an into a support tool, it's going to get looked up as t—bone. Let's compare here:

    vs

    You'd have to squint to see the difference that one's using a hyphen (-) and the other is using an emdash (—). Zoom in with your browser to see if you can see the difference between the two strings above. Same strings again without the monospace treatment:

    vs

    Now you might be able to spot the subtle difference!

    So if that email is "cut and paste" from Outlook into an online help tool used by a support agent, they might have trouble looking up my account.

    That's one of the types of problems saslprep (stringprep) solves. It would require client software to normalize the emdash back to a regular ascii hyphen for purposes of password and username comparison. Similarly, certain unprintable characters get collapsed into nothing. Other characters get collapsed into regular space char (ascii: 0x20). I didn't read the spec to see how it handled precomposed characters, but I would guess it had a policy for that.

    When I implemented Stuntman years back, I remember seeing that in the RFC and reading up on it. And then i just concluded that the server didn't need to care because it was the client's job to normalize the string. And if I had implemented STUN auth into the client command line tool, I likely would have just rationalized that it was up to the user to make sure they submitted a "saslprep" normalized string before typing it. :)

    Another opinion I have is that I think the STUN RFC authors just slammed that SASLprep requirement into their spec - either because they were following the same stuff called out in other RFCs, or they got feedback in peer review that it was a thing.