Early look at draft-alvestrand-idna-bidi-00

Simon Josefsson jas at extundo.com
Sat Oct 14 17:00:46 CEST 2006


Hi!

I've looked at draft-alvestrand-idna-bidi-00.  I didn't have time to
review both drafts under the 24h deadlined, so I focused on the
smaller document.

I understand that you are approaching this problem from the IDNA point
of view, and that this will later distill into some changes to
StringPrep.  That is a problematic approach, since it may fail to
maintain important design aspects of StringPrep.  StringPrep is used
for non-IDNA purposes too.  I'm in particular thinking of how it is
used in SASLprep to process username and passwords in security
systems.

One important concern, from the point of view of SASLprep, is
backwards compatibility.  The SASL WG in the IETF designed and used
SASLprep in protocols (e.g., SASL PLAIN) under the assumption that
future changes to SASLprep will be backwards compatible.  It is thus
important that any modification to StringPrep discuss how it will
affect backwards compatibility.

I'd further argue that it is important that backwards compatibility is
not only discussed, but also, possibly through some additional
mechanism, maintained in a new version of StringPrep.  If this is not
maintained, SASLprep may likely stay with the current StringPrep
revision, and solve the backwards compatibility problem in a different
way than is done here.  I recall that this approach was proposed as a
safety-gauge in the SASL WG if your efforts end up changing StringPrep
too much.  A StringPrep fork would be problematic for StringPrep
implementers, and detrimental to deployment.

My recommendation for this document is to discuss how the changes
affect security sensitive applications of StringPrep.  Providing a
mechanism to allow for safe upgrading would be useful.

There are two problems to discuss: interoperability and
security/stability.

Interoperability:
-----------------

A client that use one version of StringPrep may derive strings that
are different from what another client that use another version of
StringPrep would derive.  That would be bad.  If the only problem is
that one of them will get a "string rejected" error, the problem is
not as bad, but there is no indication that this holds.  I suspect it
doesn't, but I don't have time to derive example code point strings
now.

In some protocol implementations (e.g., DIGEST-MD5), the StringPrep'ed
password is stored in a hashed form, and you don't have access to the
original input string.  Alternatively, the password may only be
accessible in RFC 3454 StringPrep form.  Discussing the semantics and
guaranteed properties of RFC3454bisStringPrep(RFC3454StringPrep(X))
would be useful.

Security/stability:
-------------------

If one component of a security system uses one version of StringPrep
for authentication, and the authorization component of the system uses
another version of StringPrep, there may be security breaches where
you can bypass the authentication system and gain authorization as
someone else.  Even subtle things such as idempotency of the function
matters here, systems may fail if idempotency of the StringPrep
operation doesn't hold through the chain.  One example of this is when
Kerberos is used in SASL: Kerberos provides authentication, and may be
improved to use one version of SASLprep, while SASL provides
authorization and can use another version of SASLprep.  Coupling a new
revision of Kerberos with a new release of SASL within the IETF would
be a big challenge.


This note was written hastily, and I didn't have time to think the big
issues over, but focused on my pet problem in this area, so take it
for what it's worth.

Thanks,
Simon


More information about the Idna-update mailing list