Re: Normalization of passwords in SASL and SSH

["Kurt D. Zeilenga" <Kurt%OpenLDAP.org@localhost>]

These are the changes (in unified diff form) I propose to make to
the sasl-plain I-D to address this concern.  Note that change impacts
authcids as well as passwords.

-- Kurt


 The presented authentication identity and password strings are not
-to be compared directly with stored strings.  The server SHALL first
-prepare authentication identity and password strings using the
-[SASLPrep] profile of the [StringPrep] algorithm.  Per Section 7
-of [StringPrep], unassigned code points may appear in prepared
-presented (query) strings but are prohibited in stored strings.  If
-preparation fails or results in an empty string, verification SHALL
-fail.  If the server stores only the hash of expected string, the
-string MUST be prepared before generation of the hash.
+to be compared directly with stored strings.  The server SHOULD
+first prepare authentication identity and password strings using
+the [SASLPrep] profile of the [StringPrep] algorithm as detailed
+below.  When preparing using [SASLprep] or other [StringPrep] based
+algorithm, per Section 7 of [StringPrep], unassigned code points
+may appear in prepared presented (query) strings but are prohibited
+in stored strings.  If only the output of a non-invertible function
+of expected string is stored, the string MUST be prepared before
+input to that function.
+
+The SASLprep preparation is recommended to improve the likelihood
+that comparisons behave in an expected manner.  It is not mandatory
+to allow the server to employ other preparation algorithms (including
+none) as necessary to interoperate with external systems.
+
+Regardless of the preparation algorithm, if preparation fails or
+results in an empty string, verification SHALL fail.


At 08:27 PM 11/29/2004, Sam Hartman wrote:

>Hi.  A discussion in the IETF 61 secsh meeting re-opened the issue of
>how to handle password normalization for passwords received by the
>server.  The ssh protocol had adopted a significantly different
>solution to this problem than the sasl plain mechanism.  This concerns
>me; I want to either solve the problem of password normalization in a
>consistent manner or to understand why the ssh requirements are
>different than the sasl requirements.  
>
>As a result of that discussion I've been talking to several people
>about the issue.  Now I think I understand things well enough to
>propose a solution to both working groups.
>
>First, I'd like to revisit the motivation behind normalization.  There
>are a variety of semantically equivalent sequences of characters that
>have multiple representations in Unicode.  The simplest example is
>accented characters where one code point represents the accented
>character and another series of code points represents the
>semantically equivalent character plus a combining accent.  Other
>examples exist.  Which sequence of code points gets used tends to
>depend on the input method used to enter the characters.  That means
>that it tends to depend on the OS, application and version of software
>used.  So, telling users to type their password the same way is not a
>sufficient answer to guarantee that you end up with the same sequence
>of code points; the user may not have a choice of input methods.
>
>The IDN working group developed an architecture called Stringprep
>which allows protocol-specific profiles of rules for mapping some
>semantically equivalent strings into the same sequences of code
>points.  It is not perfect; as with any normalization discussion the
>question of where to draw boundaries between equivalence classes is
>difficult.  The SASL working group developed a profile of Stringprep
>called Saslprep; this profile is targeted at simple usernames and
>passwords.  Everyone I talked to over the past two weeks believes that
>if you are going to normalize passwords for ssh or the SASL plain
>mechanism, Saslprep is a reasonable profile to use.  Saslprep has the
>advantage of already being in the rfc editor queue.
>
>We'd like to tell people to normalize passwords all the time.  If they
>actually did that then it would improve interoperability and the user
>experience.  However most systems we use do not store plaintext
>passwords.  Instead, they tend to store some function of the password
>or to call out to something like PAM or RADIUS to do password
>authentication.  Normalizing a password before you check it but not
>when new passwords are stored may be very problematic.  
>
>For example, consider an environment where the input method tends to
>produce separate base character and accent code points. Without
>normalization, when passwords containing accents are stored, any
>computed hash will include both the base character and the accent.
>However Saslprep will normalize such a string to use a single code
>point when possible.  Thus in such an environment, normalizing only
>when checking passwords would decrease interoperability because
>accented characters would never work in passwords.
>
>I'm proposing the following approach to address this situation.  For
>both ssh and sasl plain, normalization should be done on the server if
>at all.  Only the server knows what the password store technology in
>use is.  We recommend normalizing when passwords can be normalized
>both as they are set and as they are compared.  In environments where
>passwords may not be normalized as they are set, implementations may
>want to try comparing against both the normalized and supplied form of
>the password.  Doing so may improve interoperability because it means
>there is a password that if successfully set will work when used with
>any input method.  However in many environments such as when a server
>calls out to PAM or RADIUS, even the server cannot try multiple
>passwords without incrementing failed password counters or having
>other similar side effects.  Here are some examples of how I see these
>recommendations working.
>
>A sasl plain implementation that manages its own password database
>would always normalize when setting a password and when checking
>passwords.  
>
>A Windows ssh service  that managed its own authentication database
>and provided the only tool for setting passwords  would normalize both
>for setting passwords and for comparing them.
>
>An ssh implementation that used a unix password file would not
>normalize passwords for comparison.  This is true even if the ssh
>implementation sometimes was used to set passwords, because the passwd
>command could be used independently of the ssh implementation.
>
>An ssh implementation that called out to PAM or RADIUS would not
>normalize passwords.  However some of the modules eventually doing the
>password comparison might well do normalization if appropriate for the
>password store in question.
>
>Does this seem like a reasonable approach to people?  If so, we can
>work on appropriate text.