RE: Proposed stringprep algorithn from Section 8.1

> [mailto:www-xkms-request@w3.org] On Behalf Of Jose Kahan

> Hello folks,
> 
> After some discussions and feedback, here's a revised 
> proposal for the string2key algorithm in Section 8.1. This 
> proposal takes into account Ed Simon's authentication device 
> remarks and the I18N string concerns. I checked with Martin 
> Duerst from the W3C I18N WG and he says the I18N 
> part is fine with him.

>      Removes the  US-ASCII and ISO-LATIN-1 limitations! Let's
>      a user type a password phrase that s/he can remember with ease
>      or that's easy to type with his/her keyboard configuration.

The problem here is that we quickly get into support issues. I have no means
of entering unrestricted unicode into my computer.

The only way to really remove the restrictions is to go the whole way and
specify a stringprep algorithm for each charset. Simply allowing the use of
the characters is not enough in my view. 



>    This operation consists of mapping and normalizing the 
> characters in 
>    the string, and checking that it doesn't have any 
> forbidden characters.
>    In particular, there's no folding of multiple spaces or of
>    case. Punctuation symbols are not removed either. Tabs are 
>    control characters and thus are considered to be forbidden.

The idea of the algorithm was to get rid of the characters precisely because
I have used too many idiotic password entry forms that make life hard for
asolutely no purpose. The user is typing in a phrase with 128+ bits of
randomness, there is plenty of room there for allowing some human factors
slack.


> Notes:
> 
> 1. My case against case folding
> 
> Summary: I don't see a reason why we should do case or space folding.

I do, it is in there because users have difficulty getting space and case
folding right. That translates into support costs and into people not using
the spec.

Each customer service call costs something like $50 to field. In terms of
selling the product it reduces customer satisfaction. 


I do not believe that a change should be made to a spec because someone does
not see the rationale. Regardless of whether you agree with the rationale I
give, you do not give any alternative justification.


> In 2), SASLprep doesn't propose case folding. I still don't 
> agree with imposing case folding (and reducing the password 
> space) unless there is a good reason. It seems it's a 
> tradition for Internet applications to work with small case 
> strings. This makes sense to me if we are talking about DNS 
> domain names. Some cases where this tradition has never been applied:
> 
>  - HTTP Authentication protocol [2]
>  - Web server passwords in Apache are not caseless.

The reason for case sensitive passwords is that it allegedly provides extra
randomness and avoids a dictionary attack. That does not apply in this
situation, the keys will be distributed from a central service.


> A case where case folding is not enforced, but has caused problems:
> 
>  - URLs of pages. For example, we have to run a special Apache module
>    in our servers to take care of this. However, this is not done
>    transparently; if the user types a password using wrong case, the
>    server returns a redirection to the correctly spelled page.

The only reason that URLs are case sensistive is that the Unix file system
made this mistake. There are many design errors in Unix that are best not
repeated, this is one of them.



> If the WG still wants to push folding, it should give a valid 
> reason why it has to be done. Note that some languages are 
> caseless too.

No, if you want to change a deployed spec you should give the explanation.
We sell SSL certs over this interface.


> 2. About how to apply the SASLprep stringprep profile
> 
> Summary: I think it is better to have the application refuse 
> strings that have forbidden characters rather than just 
> silently removing them.

The objective here is interoperability. 

A much better way to do internationalization would be to retain the basic
mechanism as is and to propose an additional one.

> In my personal experience, having the application silently 
> discard characters is wrong for this context. The user may 
> think that he typed something and that wasn't the case.  If 
> the application prompts the user saying that the string has 
> invalid characters, the user knows that s/he did something 
> wrong, s/he may try again. 

If the user gets anything wrong there is no problem, the service will tell
them that there is an error.

All that is necessary from a security perspective is to prove that they know
the secret. If they hit additional keys it does not matter.



> The only case where I know this works this way is the Unix 
> standard passwords which only support 8 characters and drop 
> the rest.  But it does support control characters. It is 
> recommended not to use control characters because it may be 
> hard typing them over a telnet connection, but this is not 
> enforced. The user is free to type what s/he wants.

These are not passwords, the analogy is entirely inappropriate.

Received on Monday, 27 December 2004 22:04:00 UTC