Subject: A different thought on saslprep

From: Paul Hoffman / IMC <[email-masked]>
Date: Mon, 12 Jan 2004 15:17:45 -0800

Greetings again. Sorry for coming in so late on this, but three 
issues were just pointed out to me about this document and I thought 
they might be worthy of discussion.

The first is an implementation issue. In order to use saslprep on the 
shared secret, the application needs to know the text encoding used 
to enter the shared secret. Until now, that has always been ASCII, so 
no big problem there. However, once we open up to the Unicode 
character set, we also open up to a zillion odd text encodings 
(UTF-8, BIG5, ISO 8859-7, ...). Is anyone worried that that programs 
will get the conversion from what the user entered for the shared 
secret into Unicode code points wrong?

The second is shared secrets that aren't text. Is the shared secret 
always text, or is there a pure binary form? If so, you can't 
saslprep the pure binary form. I'm assuming this is a non-issue, but 
I might have not found the right place in the SASL draft.

The second is a security consideration. Running saslprep over a 
shared secret reduces the entropy of the shared secret by eliminating 
some characters and mapping others. Not a big deal, but it does make 
an attacker's job easier.

--Paul Hoffman, Director
--Internet Mail Consortium

---

From: [email-masked]
Date: Mon, 12 Jan 2004 18:22:20 -0800 (PST)

> secret into Unicode code points wrong?

I for one am worried about it. But I don't think there's much we can do to fix
it.

Here's a specific example that illustrates why I'm worried. The ISO-2022-JP
charset is based on four coded character sets: ASCII, JIS X 0201-1976,
JIS X 0208-1978, and JIS X 0208-1983. However, in practice we sometimes
see ISO-2022-JP encoding and labelling applied to CP932, Microsoft's
"extended" version of JIS 0208. But only only does CP932 extend JIS 0208
to include various additional character like circled digits, it also
differs from JIS 0208 in some positions.

As you might have guessed, this is a real world example, not an academic
one.

				Ned

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 21 Jan 2004 15:01:46 -0800

At 03:17 PM 1/12/2004, Paul Hoffman / IMC wrote:
>Greetings again. Sorry for coming in so late on this, but three issues were just pointed out to me about this document and I thought they might be worthy of discussion.

Sorry for the delayed response...

>The first is an implementation issue. In order to use saslprep on the shared secret, the application needs to know the text encoding used to enter the shared secret.  Until now, that has always been ASCII, so no big problem there.

Most of the mechanisms using SASLprep have supported UTF-8 encoded
Unicode passwords for many years.  The introduction of SASLprep
doesn't make the problem any worse.  (It might make it better as
it, in many cases, requires the client (which is more likely to
know what character set/encoding the character data is in) to
do more with the data.)

>However, once we open up to the Unicode character set, we also open up to a zillion odd text encodings (UTF-8, BIG5, ISO 8859-7, ...). Is anyone worried that that programs will get the conversion from what the user entered for the shared secret into Unicode code points wrong?

Not terribly.

I will not that we use to have lots of similar problems in LDAP.
Clients use to send character data values in whatever character
set/encoding suited them.  Once we implemented UTF-8 validation
in the servers, the client developers got their acts together.
I suspect the same has/is/will happen in SASL as well.

>The second is shared secrets that aren't text. Is the shared secret always text, or is there a pure binary form? If so, you can't saslprep the pure binary form. I'm assuming this is a non-issue, but I might have not found the right place in the SASL draft.

SASLprep is not applicable to usernames/passwords which are not
composed of Unicode character data.

The interesting case is where you have a protocol which supports
octet-string passwords where those passwords may at times be
character data.  LDAP simple bind is an example of such.  The
current proposal for improving interoperability when the password
is character data is to, in this case and only this case, require
transcoding to Unicode, preparation with SASLprep, and transfer
as UTF-8.  This approach, though it does have a few problems,
seems to be the best we can do (without changing the octet-string
password aspect of the protocol/data model).

>The second is a security consideration. Running saslprep over a shared secret reduces the entropy of the shared secret by eliminating some characters and mapping others. Not a big deal, but it does make an attacker's job easier.

In theory, yes.  But one could argue that, in practice, the
introduction of SASLprep will make more of the password space
usable hence making the attacker's job harder.

Kurt

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Thu, 22 Jan 2004 10:10:56 -0800

At 3:01 PM -0800 1/21/04, Kurt D. Zeilenga wrote:
>Unicode passwords for many years.

Ah, good. I wasn't aware of that.

>I suspect the same has/is/will happen in SASL as well.

Sounds OK to me if other SASL implementers agree.

>  >The second is shared secrets that aren't text. Is the shared 
>secret always text, or is there a pure binary form? If so, you can't 

That absolutely needs to be clarified in the document. Right now, it 
says "It may be applicable elsewhere simple user names and passwords 
are used." To me, a bunch of hex values is a "simple" password.

>shared secret reduces the entropy of the shared secret by 
>eliminating some characters and mapping others. Not a big deal, but 
>it does make an attacker's job easier.
>

But you said above that most SASL mechanisms have already been using 
UTF-8, so that doesn't make sense. I believe that you have to add a 
security consideration about this.

--Paul Hoffman, Director

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 22 Jan 2004 11:09:40 -0800

At 10:10 AM 1/22/2004, Paul Hoffman / IMC wrote:
>But you said above that most SASL mechanisms have already been using UTF-8, so that doesn't make sense. I believe that you have to add a security consideration about this.

The mechanisms have long supported UTF-8 (with no significant
code point restrictions)... and non-ASCII passwords are certainly
in use, but due to interoperability problems, much of the password
space is not terrible usable.   An attacker today would be wise
to first search the ASCII-only part of the space, then the
portion of the UTF-8 space which is use, and then maybe try to
exhaust the complete space.

I agree that the introduction of SASLprep reduces the size of
the complete space.  My point was that the introduction will
increase the portion of practically usable space, and that will
make it much harder on the attacker.

Kurt

---

From: [email-masked]
Date: Mon, 12 Jan 2004 18:22:20 -0800 (PST)

Ned

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 21 Jan 2004 15:01:46 -0800

Not terribly.

Kurt

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Thu, 22 Jan 2004 10:10:56 -0800

--Paul Hoffman, Director

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 22 Jan 2004 11:09:40 -0800

Kurt