Subject: Re: Use of NFKC in SASLprep

From: Simon Josefsson <[email-masked]>
Date: Sat, 01 May 2004 12:43:06 +0200

"Kurt D. Zeilenga" <[email-masked]> writes:

> It's my opinion that that this issue, aside from noting its
> existence, should be addressed in NFKC by the UTC, then in
> Stringprep by the IETF, and lastly in SASLprep by this WG.
> But we shouldn't wait for this, we should publish what we
> have as being "good enough" and then revise once the upstream
> specifications have been appropriately revised.

Without qualifying this, this means abandoning the invariant
SASLprep2(SASLprep(X)) = SASLprep(X), and given the details of PR-29
even abandoning SASLprep(SASLprep(X)) = SASLprep(X), in a few cases.
In an earlier discussion about SASLprep the argument was, as far as I
can recall, that my proposed text regarding storing SASLprep strings
in databases was not needed, because the invariant was implied by
other specifications.  I just hope everyone pushing this forward is
able to visualize the entire long-term puzzle, as I know I'm having
difficulties with the SASLprep piece.

Another comment on PR-29: it may be that the problematic INPUT code
points to NFKC do not occur naturally, but as far as security is
concerned there is another question: the OUTPUT code points must also
not occur naturally.  Otherwise, someone may be able to use
"unnatural" code points to bypass the first security perimeter, and
have the input changed (NFKC) into some "natural" code point once
inside the security system.  Also, simply having NFKC(NFKC(x)) !=
NFKC(x) may generate weird corner cases that could be exploited.

Thanks,
Simon

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Sat, 01 May 2004 07:48:57 -0700

Simon,

As you don't appear to support my suggestion, I wonder
alternative you suggest we undertake.  Wait?

Kurt

---

From: Simon Josefsson <[email-masked]>
Date: Sat, 01 May 2004 18:55:55 +0200

> alternative you suggest we undertake.  Wait?

Short term: Evaluate the completeness of the problem sequences
described in PR-29, and prohibit them in SASLprep output.  As I
understand it, this would be sufficient to make SASLprep idempotent.
A system where the user identifiers change several times after
repeated use of SASLprep, i.e. non-idempotent SASLprep, is not robust
and is difficult to analyze.

Medium term: Describe the usage of SASLprep in detail.  If necessary,
it might be possible to do this even after the actual SASLprep
algorithm has been published.  If the invariant
SASLPrep2(SASLprep(X))=SASLPrep2(X) is not written into SASLprep as a
commitment to the future, I'd like to open the question of not using
the AllowUnassigned flag, as removing it would simplify the SASLprep
usage.  It is a telling sign that, as far as I can tell, none of the
current SASL mechanism documents discuss when to set the flag.  If
removal isn't an option, the use of the flag should be discussed in
the documents.

Long term: Write a requirements document based on the non-technical
needs internationalized users have, and implement a solution to those
requirements.  My impression is that SASLprep has been driven by
technical goals, with a world view centered around a StringPrep
solution from the start.

Hope this helps,
Simon

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Sat, 01 May 2004 11:32:53 -0700

At 09:55 AM 5/1/2004, Simon Josefsson wrote:
>described in PR-29,

I rather leave that to the UTC.

>and prohibit them in SASLprep output.

How?  Stringprep prohibit step is designed to prohibit on
a per code point basis.  We'd effectively have to design
a new prohibit step for the algorithm.  Why should that be
done in a SASLprep-specific manner?  If the most appropriate
thing to do is prohibit certain sequences in the short term,
wouldn't it make better sense to update stringprep so that
all stringprep profiles do it in a like way?

Kurt

---

From: Simon Josefsson <[email-masked]>
Date: Sat, 01 May 2004 21:04:00 +0200

"Kurt D. Zeilenga" <[email-masked]> writes:

> a new prohibit step for the algorithm.

Right.

> Why should that be done in a SASLprep-specific manner?  If the most
> appropriate thing to do is prohibit certain sequences in the short
> term, wouldn't it make better sense to update stringprep so that all
> stringprep profiles do it in a like way?

I'm not sure.  It is conceivable that what makes sense for SASLprep
does not make sense for Stringprep in general.  If the authors
responsible for the Stringprep revision think what you propose makes
sense, then I would agree.  (I wouldn't call that a short term
solution, though.)  But if not, and if they don't have another
solution in mind, I believe idempotency is important enough, for
security reasons, that SASLprep should fixed, instead of being
published as-is.  I'm told the Stringprep authors are preparing a
statement on this issue, though, which might give other alternatives.

Thanks,
Simon

---

From: Jeffrey Altman <[email-masked]>
Date: Sun, 02 May 2004 11:33:00 -0400

>all stringprep profiles do it in a like way?
Has anyone asked the authors of StringPrep their opinion?

Clearly this problem needs to be addressed not in SASLPrep
but in a revision to StringPrep as it affects all profiles
based on StringPrep.  Modifying SASLPrep will only cause
more problems if the solution adopted for StringPrep is
incompatible.

Jeffrey Altman

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 3 May 2004 12:49:24 -0500

> more problems if the solution adopted for StringPrep is

My take is that this is easy to fix in Unicode itself, as per-the
recommendations in pr-29, in part because there exist Unicode
implementations which do not have this problem and some that do and
there's no better place to fix this than in Unicode where all downstream
consumers of NFKC would benefit automatically.  But see below.

We have:

 - UAX #15 is internally inconsistent,
    - the inconsistency results in NFKC(NFKC(x) != NFKC(x)
    - but only for rather unrealistic instances of 'x'
    - which, nonetheless should cause us some concern

 - But some implementations don't have this problem,
 - and the fix to UAX #15 seems rather simple (but it's possible that
   there's more than meets the untrained eye...)

All of which makes me think that Unicode is the right place to fix the
problem and that we should wait for the Unicode consortium to issue a
corrigendum or other statement before doing much of anything about this.

Until then a security considerations warning about the troublesome input
sequences ought to suffice, methinks.

Mor importantly, rather than discuss this matter at the SASL or KRB or
any other IETF WG I'd prefer to see this discussed more broadly and, if
possible, get some input from the relevant area directors.  Perhaps this
matter should be taken up with the IETF liason to the Unicode
consortium.

Cheers,

Nico
--

---

From: Sam Hartman <[email-masked]>
Date: Mon, 03 May 2004 17:06:45 -0400

>>>>> "Simon" == Simon Josefsson <[email-masked]> writes:

    Simon> "Kurt D. Zeilenga" <[email-masked]> writes:

    >> Stringprep by the IETF, and lastly in SASLprep by this WG.  But
    >> we shouldn't wait for this, we should publish what we have as
    >> being "good enough" and then revise once the upstream

    Simon> Without qualifying this, this means abandoning the
    Simon> invariant SASLprep2(SASLprep(X)) = SASLprep(X), and given
    Simon> the details of PR-29 even abandoning SASLprep(SASLprep(X))
    Simon> = SASLprep(X), in a few cases.  In an earlier discussion
    Simon> about SASLprep the argument was, as far as I can recall,
    Simon> that my proposed text regarding storing SASLprep strings in
    Simon> databases was not needed, because the invariant was implied
    Simon> by other specifications.  

I think the invariant is implied and that it is our job to assume the
invariant shall be maintained regardless of whether it actually is.
We should make sure the authors of stringprep know we're going forward
with the assumption of this invariant and agree doing so is the right
course of action.

If we ever violate this invariant we should do so with the
understanding that the practical consequences of assuming the
invariant and violating it in the manner we actually violate it are
acceptable.

Another point to consider regarding this issue: the IDN working group
set an interesting precedent by choosing not to correct UNicode bugs
in their working group.  They decided they were not qualified to do so
and the IETF was not the appropriate forum.  If we choose to take a
different course of action, we should have strong justification for
why their reasoning does not apply to our circumstance.

--Sam

---

From: Simon Josefsson <[email-masked]>
Date: Sat, 01 May 2004 12:43:06 +0200

Thanks,
Simon

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Sat, 01 May 2004 07:48:57 -0700

Simon,

Kurt

---

From: Simon Josefsson <[email-masked]>
Date: Sat, 01 May 2004 18:55:55 +0200

Hope this helps,
Simon

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Sat, 01 May 2004 11:32:53 -0700

Kurt

---

From: Simon Josefsson <[email-masked]>
Date: Sat, 01 May 2004 21:04:00 +0200

Right.

Thanks,
Simon

---

From: Jeffrey Altman <[email-masked]>
Date: Sun, 02 May 2004 11:33:00 -0400

Jeffrey Altman

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 3 May 2004 12:49:24 -0500

We have:

Cheers,

Nico
--

---

From: Sam Hartman <[email-masked]>
Date: Mon, 03 May 2004 17:06:45 -0400

--Sam