Subject: RE: set-passwd protocol and stringpreps, again

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Sat, 17 Jul 2004 17:37:08 -0700

Comments:

1) operation change-pw should be changed to be transactional, until a
commit command is executed, the password should not be changed. That is
we need to define the behavior when the password change is done when the
client already times out on the TCP connection. 

we need to enforce password policy on the server side, and the
change-keys-then-commit operations are not sufficient.

2) I am really concerned about the large # of prohibited code points
defined in stringprep/saslprep. How can a windows user figure out why
the new password is not illegal?  How do you display a meaningful,
possibly localized, message to the user so that he/she knows how to
choose a different new password? Is this solved by having the client
issue a separate Req-get-pw-policy operation, but that won't tell us
which part of the policy specifically was violated.

3) we need to define a list of errors that the client can understand (so
that the KDC can choose to send a more generic error when it knows the
client won't know a new error code).  I understand this can be archived
via the protocol version negotiation, but I would imagine we do not want
to revise the protocol version every time we add a new error code.

Thanks,

Larry

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Sam Hartman
Sent: Saturday, July 17, 2004 3:14 PM
To: [email-masked]
Subject: Re: set-passwd protocol and stringpreps, again

>>>>> "Nicolas" == Nicolas Williams <[email-masked]> writes:

    Nicolas> Ok, I'll make some quick surgery on the text...

    Nicolas> I think the relevant strings will have to be a CHOICE so
    Nicolas> we can have them be tagged as "encoding what's that?,"
    Nicolas> clarifications (IA5String) and extensions (UTF8String w/
    Nicolas> SASLprep).

Was there some reason stringprep running on the server is insufficient?

I don't think we care about anything that cannot be represented in
Unicode.

---

From: Nicolas Williams <[email-masked]>
Date: Sun, 18 Jul 2004 19:25:41 -0500

> change-keys-then-commit operations are not sufficient.

Done.

> which part of the policy specifically was violated.

For interop reasons we must stick to stringprep profiles, and,
specifically, we must stick to SASLprep (unless we decided after all
that we want some other profile, but I doubt that will happen).

This means that, yes, some codepoints won't be permitted.  Servers
should state so in their replies, and the messages should be
comprehensible to users...

And note the suggested-pw field in the rejected password error: the
server could replace prohibited codepoints in the requested password
with their closest analogs or a sequence of characters with similar
meaning and suggest the resulting password -- this could work well for
ideographic characters.  Client GUIs could properly display tables of
permitted/prohibited characters too, and so guide users.

There are so many possible reasons for rejecting a password that I gave
up trying to list them all and instead there's a single generic error
code for this along with explanatory text.

For humans this is more than good enough.

For non-humans (e.g., SSPI apps that use passwords as acceptor creds,
your favourite problem :) this isn't all that good, BUT, such apps could
use machine-generated (client- or server-generated) all ASCII passwords;
put in enough entropy and all such passwords should pass all quality
policies.

I'm not sure that having specific password quality policy error codes
will help such clients pick better passwords, and I'm pretty sure that
it would hurt vendors' ability to have more interesting pw quality
policies.

Q:  So how should service princs for SSPI apps deal with password
    quality errors?  

A1:  Set more appropriate policies on such principals;

A2:  Try again with a different randomly generated password, up to N
     times, then fail and tell the sysadmin to set a better policy on
     the given principal (see A1).

> to revise the protocol version every time we add a new error code.

The error codes are extensible, so future minor versions can have more
specific errors.  And see above.

That said, I'll add a set of password quality policy hint codes that
could be used by sufficiently smart clients...  These can't be very
specific, so for humans the policy description text is better.

Nico
--

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 19 Jul 2004 11:32:22 -0400

> which part of the policy specifically was violated.

The code points prohibited by SASLprep consist largely of control 
characters and other code points that users will never be able to type:

- Non-ASCII space characters are mapped to 0x20, so even though they
  are prohibited in the _output_ of saslprep, they can appear in its
  input.

- Non-character code points -- these are defined in Unicode as not
  representing characters of any kind, so users can be expected not
  to be able to type them.

- Surrogate code points - these are reserved in Unicode for representing
  non-plane-0 code points in UTF-16.  They only appear legitimately as
  part of UTF-16 encoding, and thus cannot be typed by users.

- Inappropriate for plain text
  Annotation markers and replacement characters.  These should not be
  typable by users.

- Change display properties or are deprecated
  U+0340, U+0341, and U+206A..U+206F are deprecated.
  U+200E, U+200F, U+202A..U+202E are bidirectional display control.
  None of these should be directly entered by users.

- Tagging characters
  These are invisible characters used for tagging text.

That leaves us with three categories that may be typable by users:

- Control characters
  ISTR we've come to the conclusion that control characters in passwords
  are a bad idea.  Which ones are typable varies a lot from one platform
  to the next and maybe even from one application to the next.  I know
  that some platforms like to use control as a bucky-bit and completely
  prevent actually typing control characters into most text entry fields.

- Private-use characters
  The subject of massive debate last time we were in Minneapolis.
  I think we came to the conclusion that these would be prohibited in
  principal names, passwords, and other things using SASLprep, but I'll
  leave determination of concensus on that issue to the SASL WG chairs.

- Inappropriate for canonical representation
  The category description says it all.  These appear to be the combining
  characters used to construct ideographic glyphs.  Maybe someone more
  expert than I can recall whether these would be normalized into some
  other form, making their prohibition in output moot.

In any case, I believe Nico's assertion is directly on point - if we're 
going to use SASLprep in Kerberos, we should also be using it in 
set-passwd.  Otherwise we're going to have some real interesting problems.

-- Jeff

---

From: "Simon Josefsson" <[email-masked]>
Date: Wed, 21 Jul 2004 17:40:52 +0200 (CEST)

> characters and other code points that users will never be able to type:

On the other hand, SASLPrep is Unicode 3.2 only.

Unicode 4.0 introduce new characters, which if I understand correctly,
cannot be used in Kerberos until SASLPrep2 is available, and the Kerberos
base specification is updated to reference it.

In other words, expect to be stuck with Unicode 3.2 in Kerberos for some
time.

I believe it would be possible to be forward compatible with Unicode 4, by
allowing unassigned code points through, instead of rejecting them.  Alas,
I don't recall that the intended usage of SASLPrep in Kerberos wrt
unassigned code points is crystal clear, so perhaps this approach is not
intended.  And I don't recall any Stringprep profile versioning
discussions at all in Kerberos.

Regards,
Simon

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 21 Jul 2004 10:55:01 -0500

> discussions at all in Kerberos.

IIRC unassigned code points are allowed in _query_ strings.

Nico
--

---

From: "Simon Josefsson" <[email-masked]>
Date: Wed, 21 Jul 2004 18:28:19 +0200 (CEST)

> IIRC unassigned code points are allowed in _query_ strings.

Right, that's the Stringprep terminology.

What constitue a query string in various protocols is something for those
protocols to define, however; something which I believe has not been done
for Kerberos or set-passwd yet.  In several situations (i.e., server side
handling of password from remote databases used for CRAM-MD5), it could be
argued either way whether a string should be regarded as a query string or
stored string.  That's why it is important for the protocol to define
exactly which processing is required, and not to leave it up to
interpretation of the term "query string" in different contexts or
implementations.

If SASLPrep is used at all by set-passwd, I believe it can be useful to
regard set-passwd passwords as query strings, in the client.  Or even
allow any UTF-8 to be sent by the client, and have the server perform all
verification.  This would simplify client implementations as well, but
might require the server to send back the "real" or "computed" password
somehow.  I'm not sure if that's a good idea.

If there is a point to all this, it is that the details of how SASLPrep is
used within set-passwd are almost as important as whether SASLPrep is used
at all.  In other words, it is difficult to assess whether using SASLPrep
is a good idea, without knowing how it will be used, since the details
affect future compatibility a lot, and future compatibility should be a
deciding factor on whether to use SASLPrep or not.

Regards,
Simon

---

From: Jeffrey Altman <[email-masked]>
Date: Wed, 21 Jul 2004 12:43:15 -0400

Attached is proposed text describing the use of strings which Jeff 
Hutzelman and I worked on
last November for Extensions.

Jeffrey Altman

Internationalization of the Kerberos 5 protocol for use in [@EXTENSIONS]

Guiding Principals

Kerberos 5 is a wire protocol which is designed to be independent of operating 
system, networking protocols, and naming services.  The goal is to provide the
utmost flexibility in the use of characters while specifying the necessary
restrictions to ensure future extensions to the protocol can operate in a 
backward compatible manner.

It must be clearly recognized that the Kerberos protocol has no means to 
identify the source or meaning of principal name components.  Therefore, the
protocol must specify a single set of rules for the use of preparing and 
interpreting internationalized strings.  Although when Kerberos is used on 
the Internet common practice is to generate principals utilizing components
derived from DNS names, it is not possible for the Kerberos protocol to
recognize this.  

There are three ways strings can be used within a protocol: storing, querying, 
and displaying.  Each of these uses of a string requires different properties.  

A "storage string" is a string transmitted within the protocol for the explicit 
purpose of being stored into a database for subsequent comparisons during query 
operations.  

A "query string" is a string used for comparison against strings stored in a 
database.  

Neither "storage strings" nor "query strings" are meant for visual display to 
an end-user.  The only strings in a protocol which are meant for end-user 
interaction are "display strings".                                                 

NOTE: the Kerberos protocol does not utilize any "storage strings".  This is 
because the creation of principals, how they are stored in a database, and 
how passwords are set or changed is outside the scope of the protocol.  These
decisions are left up to implementors and administrators.  

NOTE: A credential cache of tickets is not a database

There has been much discussion of the need for ensuring that Kerberos strings
are compatible with the internationalized strings used within other protocols
(e.g., internationalized domain names.)  The demand for this functionality is 
derived from a failure on the part of other protocol designers to properly 
enforce the distinctions between strings used for storage, queries, and 
end-user display.  In particular, IDNA [RFC3490] specifically requires the 
leakage of storage and query string for use as display strings.  This leakage
has the side-effect of imposing the IDNA String Preparation rules onto some
potential sources of input when applications generate strings for use in the
Kerberos protocol.  To ensure compatibility between applications which accept
IDN wire representations as input and those which do not, it will be necessary
for there to be "best common practices" specified as recommendations for 
implementors and administrators to use.  However, these BCPs must not be 
restrictions imposed on the Kerberos protocol because the Kerberos string 
space is not equivalent to the IDN string space.  In fact, it is much broader. 

KerberosString

   The original specification of the Kerberos protocol in RFC 1510 uses
   GeneralString in numerous places for human-readable string data.
   Historical implementations of Kerberos cannot utilize the full power
   of GeneralString.  This ASN.1 type requires the use of designation
   and invocation escape sequences as specified in ISO-2022/ECMA-35
   [ISO-2022/ECMA-35] to switch character sets, and the default
   character set that is designated as G0 is the ISO-646/ECMA-6
   [ISO-646,ECMA-6] International Reference Version (IRV) (aka U.S.
   ASCII), which mostly works.

   ISO-2022/ECMA-35 defines four character-set code elements (G0..G3)
   and two Control-function code elements (C0..C1). DER prohibits the
   designation of character sets as any but the G0 and C0 sets.
   Unfortunately, this seems to have the side effect of prohibiting the
   use of ISO-8859 (ISO Latin) [ISO-8859] character-sets or any other
   character-sets that utilize a 96-character set, since it is
   prohibited by ISO-2022/ECMA-35 to designate them as the G0 code
   element. This side effect is being investigated in the ASN.1
   standards community.

   In practice, many implementations treat GeneralStrings as if they
   were 8-bit strings of whichever character set the implementation
   defaults to, without regard for correct usage of character-set
   designation escape sequences. The default character set is often
   determined by the current user's operating system dependent locale.
   At least one major implementation places unescaped UTF-8 encoded
   Unicode characters in the GeneralString. This failure to adhere to
   the GeneralString specifications results in interoperability issues
   when conflicting character encodings are utilized by the Kerberos
   clients, services, and KDC.

   This unfortunate situation is the result of improper documentation of
   the restrictions of the ASN.1 GeneralString type in prior Kerberos
   specifications.

   In [@CLARIFICATIONS] the type KerberosString, defined below, was a
   GeneralString that is constrained to only contain characters in
   IA5String

      KerberosString  ::= GeneralString (IA5String)

   US-ASCII control characters should in general not be used in
   KerberosString, except for cases such as newlines in lengthy error
   messages. Control characters SHOULD NOT be used in principal names or
   realm names.

   For compatibility, implementations MAY choose to accept GeneralString
   values that contain characters other than those permitted by
   IA5String, but they should be aware that character set designation
   codes will likely be absent, and that the encoding should probably be
   treated as locale-specific in almost every way. Implementations MAY
   also choose to emit GeneralString values that are beyond those
   permitted by IA5String, but should be aware that doing so is
   extraordinarily risky from an interoperability perspective.

   Some existing implementations use GeneralString to encode unescaped
   locale-specific characters. This is a violation of the ASN.1
   standard. Most of these implementations encode US-ASCII in the left-
   hand half, so as long the implementation transmits only US-ASCII, the
   ASN.1 standard is not violated in this regard. As soon as such an
   implementation encodes unescaped locale-specific characters with the
   high bit set, it violates the ASN.1 standard.

   Other implementations have been known to use GeneralString to contain
   a UTF-8 encoding. This also violates the ASN.1 standard, since UTF-8
   is a different encoding, not a 94 or 96 character "G" set as defined
   by ISO 2022.  It is believed that these implementations do not even
   use the ISO 2022 escape sequence to change the character encoding.
   Even if implementations were to announce the change of encoding by
   using that escape sequence, the ASN.1 standard prohibits the use of
   any escape sequences other than those used to designate/invoke "G" or
   "C" sets allowed by GeneralString.

   In [@EXTENSIONS] the type KerberosString, defined below, is extended to 
   support internationalized strings:

        -- used for names and for error messages
            KerberosString	::= CHOICE {
            ia5		GeneralString (IA5String),
            utf8	UTF8String,  -- normalized
            ...		-- no extension may be sent
		            -- to an rfc1510 implementation --
        }

   Note that applying a new constraint to a previously unconstrained
   type constitutes creation of a new ASN.1 type. In this particular
   case, the change does not result in a changed encoding under DER.
   This allows for a redefinition of the KerberosString type as a 
   migration strategy provided that appropriate constraints are applied
   to restrict the KerberosString to either IA5String or UTF8String
   as appropriate to protocol messages defined in [@CLARIFICATIONS]
   or newly defined in this protocol.

NOTE FOR ASN.1: The comment that utf8 is normalized should be removed.
KerberosStrings used for display are not normalized although they must
be validated for shortest form utf8.

Normalization Requirements of I18N KerberosStrings

   KerberosStrings are used within the Kerberos protocol to represent Realms,
   PrincipalNames, Salts, and Error Text.  These strings can be used in one 
   of three ways.   As part of query/response, as input to a storage device, or 
   as output intended for display purposes only.  Different string utilizations
   have different requirements for string preparation.  

   The requirements for string preparation are described in "Preparation of 
   Internationalized Strings (stringprep)" [RFC3454].  In brief, a string 
   preparation process attempts to ensure that two strings entered at 
   different times via different user interfaces which are intended
   to be identical will be recognized as such.  This requirement is especially
   true of a complex character-set such as Unicode which allows for multiple
   sequences which are logically identical.

   The following String Preparation profile will be used by the Kerberos 
   protocol for preparing Kerberos strings:

     * SASLprep [@SASLPREP]

KerberosQueryString

    KerberosQueryString := KerberosString (UTF8: sender prepared)

    Kerberos Query strings are prepared with SASLprep on the sender and are 
    not otherwise modified     by the receiver.  This permits a Kerberos sender
    utilizing a newer StringPrep profile than the receiver to transmit query 
    strings containing code points unassigned in the version of SASLprep 
    utilized by the receiver.  The result of the use of such a string when 
    querying against a Kerberos database will simply be a failure to match.

KerberosDisplayString
   
    KerberosDisplayString := KerberosString 

    A Display string is neither used for Querying against a database or for
    storing into a database.  As such there are no canonicalization 
    requirements on display strings, string preparation is not performed on
    strings sent for the purpose of display to the end user.  In 
    general, Display Strings are only used to represent Error Text within the
    the Kerberos protocol

    (?) Perhaps we should recommend that KerberosDisplay strings when being 
    logged to a file or other storage medium SHOULD be SASLprep'd prior to
    storage.

KerberosStorageString

    KerberosStorageString := KerberosString (UTF8: sender and receiver prepared)

    Kerberos Storage Strings are prepared with SASLprep by the sender.  As this 
    string is meant to be stored for long time use there is a requirement that the 
    string be recognizable to both the sender and the receiver.  

    The send must prepare the string to verify that the string contains no
    unassigned code points according to its version of the string prep 
    algorithm.  If an unassigned code point is detected an error should be 
    returned.  The sender then transmits the unprepared string to the receiver.  

    The receiver of the string must prepare the string and ensure that the
    received string contains no unassigned code points in its version of the
    string prep algorithm.  If the receiver detects unassigned code points the
    string an error message: KRB_ERR_INCOMPATIBLE_STRINGPREP is returned to
    the sender.  The error text should include "SASLprep" and the SASLprep
    version number specified in the IANA StringPrep registry.  Perhaps 
    including the unassigned code points. (?)

    NOTE: this mechanism provides the KDC 

KerberosUnpreparedQueryString

    KerberosUnpreparedString := KerberosString (UTF8: receiver prepared)

    Kerberos Unprepared Strings are sent unprepared and must be prepared 
    by the receiver.  This string type is similar to a Query String except 
    that the source of the input string is a protocol which does not 
    implement SASLprep normalization but which is capable of transmitting 
    internationalized UTF-8 strings.

KerberosPasswordString

    KerberosPasswordString := KerberosQueryString

    Passwords are not transmitted within the Kerberos protocol.  However,  
    they are used as input to cryptographic operations which require 
    unique and identical representations on both the Kerberos client and
    the KDC.  Kerberos Passwords are therefore treated as Kerberos Query
    Strings on the client requiring preparation via SASLprep prior to 
    use.

    (?) Representation of password strings in a Kerberos Database are 
    left up to implementors.  However, prior to using a password string
    as input to a cryptographic operating defined by [@KCRYPTO] the 
    string must be prepared via SASLprep.

KerberosSaltString

    KerberosSaltString := KerberosQueryString

    Salts used in conjunction with the Kerberos protocol must be prepared
    at the time they are inserted into the Kerberos database.

PrincipalQueryString
    
    PrincipalQueryString := KerberosQueryString

PrincipalStorageString

    PrincipalStorageString := KerberosStorageString

    (?) This string type is not utilized within [@EXTENSIONS] but is provided
    for reference by protocols which rely on [@EXTENSIONS]

RealmQueryString

    RealmQueryString := KerberosQueryString

RealmStorageString

    RealmStorageString := KerberosStorageString

    (?) This string type is not utilized within [@EXTENSIONS] but is provided
    for reference by protocols which rely on [@EXTENSIONS]

(?) All references within the ASN.1 to Principal, Realm, Salt, or ErrorText 
are to be replaced with references to PrincipalQueryString, RealmQueryString,
KerberosSaltString, or KerberosDisplayString as appropriate.

Migration Strategy for KerberosString utilization between [@CLARIFICATIONS] 
and [@EXTENSIONS] 

Kerberos protocol messages compatible with [@CLARIFICATIONS] are constrained to
utilizing KerberosString drived types in their GeneralString (IA5String) 
form.  Kerberos protocol messages newly defined in [@EXTENSIONS], this 
document, are constrained to utilizing KerberosString derived types in their 
UTF8String form.

Interoperability between mixed environments of [@CLARIFICATIONS] and 
[@EXTENSIONS] in ensured only when the principal and realm names involved in 
the protocol operations are representable without modification in the 
GeneralString (IA5String).

If a [@EXTENSIONS] KDC needs to send a KRB_AS_REP to an old client, and the 
salt cannot be represented, KDC_ERR_ETYPE_NOSUPP is returned.

[@CLARIFICATIONS] Service and [@EXTENSIONS] Client.  If the client has a 
principal which cannot be represented in a downgrade to the old service.  In 
this case a [new] error KDC_ERR_SERVICE_TOO_OLD will be sent.

When performing cross realm operations between a mixture of [@CLARIFICATIONS] 
and [@EXTENSIONS], if there may be a need to downgrade the contents of the 
transited realm field to [@CLARIFICATIONS] compatible message forms.  During a 
downgrade operation, if the contents of the transited realm field cannot be 
represented in a GeneralString (IA5String), then a [new] error 
KRB_ERR_TRANSITED_REALM_TRANSLATION will be sent.

Note For Implementors who used GeneralString as OctetString (Just Send Eight):

Implementations of [@EXTENSIONS] which receive messages from [@CLARIFICATIONS] 
peers which treat GeneralString as OctetString must perform string preparation
on the received query strings derived from KerberosString.  First, the string 
is converted from the locale specific character-set in use to Unicode.  The 
Unicode string is then prepared with SASLprep before further use.

{??? how is the [@EXTENSIONS] implementation supposed to know how to apply
 NamePrep to domain name labels ???}

If there are any characters which cannot be converted from the locale-specific
character-set to Unicode; or if string preparation fails, an Error must be sent.

Best Common Practice Recommendations for the Processing of Internationalized 
Domain-Style Realm Names:

Domain Style Realm names are defined as all realm names whose components are 
separated by Full Stop (0x002E) (aka periods, '.') and contain neither colons, 
':', nor forward slashes, '/'.  When establishing a new domain-style realm 
name containing one or more internationalized characters (not included in 
US-ASCII), this procedure must be used to :

 * the realm name must be a valid domain name as per the rules of IDNA [RFC3490]

 * the following string preparation routine must be followed:

   - separate the string into components separated by any of the Full 
     Stop characters
   
   - fold all Full Stop characters to Full Stop (0x002E)

   - for each component (perform all steps):

      . if the component begins with an ACE prefix as registered with IANA,
        the prefix will be removed and the rest of the component will be 
        converted from the ACE representation to Unicode [need reference]
      
      . if the component consists of one or more internationalized characters 
        separately apply the NamePrep and SASLprep string preparation methods. 
      
      . if the output of the two methods match, continue on to the next 
        component; otherwise reject the realm name as invalid

   - the result of a valid realm name is the joining of the individual 
     string prepared components separated by the Full Stop (0x002E)

In [@CLARIFICATIONS], the recommendation is that all domain style realm 
names be represented in uppercase.  This recommendation is modified in the 
following manner.  All components of domain style realm names not including 
internationalized characters should be upper-cased.  All components of domain  
style realm names including internationalized characters must be 
lower-cased.  (The lower case representation of internationalized components 
is enforced by the requirement that the output of NamePrep and StringPrep 
string preparation must be equivalent.)

Best Common Practice Recommendations for the Processing of Principal Names 
Consisting of Internationalized Domain Names:

Kerberos principals are often created for the purpose of authenticating a 
service located on a machine identified by an domain name.  Unfortunately,
once a principal name is created it is impossible to know the source from 
which the resulting KerberosString was derived.  It is therefore required
that principal names containing internationalized domain names be processed 
via the following procedure:

 * ensure that the IDN component must be a valid domain name as per the 
   rules of IDNA [RFC3490] 

 * separate the IDN component into labels separated by any of the Full Stop
   characters
   
 * fold all Full Stop characters to Full Stop (0x002E)

 * for each label (perform all steps):

      . if the label begins with an ACE prefix as registered with IANA,
        the prefix will be removed and the rest of the label will be 
        converted from the ACE representation to Unicode [need reference]
      
      . if the label consists of one or more internationalized characters 
        separately apply the NamePrep and then the SASLprep string preparation methods. 

      . if the label consists of zero internalizationalized characters, the
        label is to be lower-cased
      
      . if the output of the two methods match, continue on to the next 
        label; otherwise reject the principal name as invalid

   - the result of a valid principal name component derived from an IDN is the 
     joining of the individual string prepared labels separated by the 
     Full Stop (0x002E)

Negative Authorization Database - Security Considerations

Proposal: KDC Should Perform Normalization on Query Strings and perform 
necessary operations 

Internationalization Considerations Section: (should be mandatory)
  * When displaying i18n principal names the bidi rules must be applied
    (UAX 9 - not perfect) [see IRI recommended text]

TO DO: Verify matching semantics of "Unicode Variation Selectors" which for 
the most part are mapped to nothing in SASLPrep.

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 21 Jul 2004 11:52:11 -0500

> interpretation of the term "query string" in different contexts or

Since set-passwd v2 is limited by [clarifications] at this time this is
not much of an issue.  Once extensions comes along I think we can have a
very minor update to set-passwd v2 to deal with this.  That said, one of
the things to review set-passwd for is just how minor an update it will
require for extensions.

Passwords are (should be) query strings in set-passwd v2, but, in
pre-auth/AS contexts Kerberos V passwords should be treated as storage
strings, as there's not peer who can properly normalize/lookup a
passwords.

> verification.

Yup.

>                This would simplify client implementations as well, but

It should suffice for the server to return an error indicating that the
client improperly prepared the password.  If the client didn't know how
to do it for set-passwd then it won't know how to do it for pre-auth,
nor would it remember server-massaged version (that'd be the user's
job), so there's no point in the server telling the client what the
correctly prepared form of a given password is.

> deciding factor on whether to use SASLPrep or not.

Yes, but these details will not be in the set-passwd v2 I-D unless we
want to aim for it to depend on [extensions].

Nico
--

---

From: Sam Hartman <[email-masked]>
Date: Wed, 21 Jul 2004 13:01:09 -0400

>>>>> "Nicolas" == Nicolas Williams <[email-masked]> writes:

    Nicolas> Passwords are (should be) query strings in set-passwd v2, 

Huh, what?  Passwords should be storage strings; you don't want
unassigned codepoints getting into the database or you won't be able
to use them if they normalize out to something else later.

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 21 Jul 2004 12:03:45 -0500

> strings, as there's not peer who can properly normalize/lookup a

To clarify, the notes that Jeff Altman just resent say that passwords
are query strings.  This is correct, not the above.

But in contexts other than set-passwd there will be no difference, for
valid passwords, between being query or storage strings since set-passwd
servers won't accept new passwords with unassigned code points.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 21 Jul 2004 12:06:24 -0500

> to use them if they normalize out to something else later.

The set-passwd server is the gatekeeper.

---

From: Sam Hartman <[email-masked]>
Date: Wed, 21 Jul 2004 14:37:44 -0400

>>>>> "Nicolas" == Nicolas Williams <[email-masked]> writes:

    Nicolas> On Wed, Jul 21, 2004 at 11:52:11AM -0500, Nicolas
    Nicolas> Williams wrote:
    >> Passwords are (should be) query strings in set-passwd v2, but,
    >> in pre-auth/AS contexts Kerberos V passwords should be treated
    >> as storage strings, as there's not peer who can properly
    >> normalize/lookup a passwords.

    Nicolas> To clarify, the notes that Jeff Altman just resent say
    Nicolas> that passwords are query strings.  This is correct, not
    Nicolas> the above.

I thought Jeff's notes were targeted at Kerberos not at set-password.

I believe an implementation of set-password MUST insure that no
unassigned codepoints are used in passwords that are stored in the
database.

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 21 Jul 2004 14:38:37 -0500

> unassigned codepoints are used in passwords that are stored in the

As Jeff's notes point out, passwords are not often not stored as such.

Let me refine a bit:

 - AS clients should treat passwords as query strings for input to
   string2key().  If this is wrong (and I can imagine arguments against
   this) then passwords should always be treated as storage strings, in
   all contexts, with attendant difficulties when using passwords made
   for revised versions of SASLprep with extensions/set-passwd
   implementations that use version 1 of SASLprep.

 - For set-passwd, if the above holds, clients passwords are query
   strings, but for servers they are storage strings:

    - in set-passwd, passwords sent on the wire (encrypted) by the
      client should be query strings

    - in set-passwd, passwords sent on the wire (encrypted) by the
      server (e.g., server-generated passwords) should be storage
      strings

    - in set-passwd, servers must reject passwords sent by the client
      that use unassigned code points

Nico
--

---

From: Sam Hartman <[email-masked]>
Date: Wed, 21 Jul 2004 15:56:03 -0400

>>>>> "Nicolas" == Nicolas Williams <[email-masked]> writes:

    Nicolas> On Wed, Jul 21, 2004 at 02:37:44PM -0400, Sam Hartman
    Nicolas> Williams wrote:
    >> >> Passwords are (should be) query strings in set-passwd v2,
    >> but, >> in pre-auth/AS contexts Kerberos V passwords should be
    >> treated >> as storage strings, as there's not peer who can
    >> properly >> normalize/lookup a passwords.
    >> 
    >> unassigned codepoints are used in passwords that are stored in
    >> the database.

    Nicolas> As Jeff's notes point out, passwords are not often not
    Nicolas> stored as such.

    Nicolas> Let me refine a bit:

    Nicolas>  - AS clients should treat passwords as query strings for
    Nicolas> input to string2key().  If this is wrong (and I can

Agreed.

    Nicolas>  - For set-passwd, if the above holds, clients passwords
    Nicolas> are query strings, but for servers they are storage
    Nicolas> strings:

I agree they are storage strings; see below.

    Nicolas>     - in set-passwd, passwords sent on the wire
    Nicolas> (encrypted) by the client should be query strings

No, don't they need to be unnormalized strings so servers can deal
with legacy  support?
    Nicolas>     - in set-passwd, servers must reject passwords sent
    Nicolas> by the client that use unassigned code points

and MUST normalize (saslprep for extensions) such passwords.

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 21 Jul 2004 16:11:00 -0500

> No, don't they need to be unnormalized strings so servers can deal

Do you mean just-send-8 by "legacy?"  If so, I disagree.  Either
set-passwd servers should reject new legacy passwords, or should the
protocol messages should be explicit about differentiating between
legacy and SASLprep'ed passwords.

> and MUST normalize (saslprep for extensions) such passwords.

The client MUST and the server MUST reject unnormalized passwords.  The
client MAY use unassigned code points and the server MUST reject them.

Nico
--

---

From: Sam Hartman <[email-masked]>
Date: Wed, 21 Jul 2004 17:21:43 -0400

>>>>> "Nicolas" == Nicolas Williams <[email-masked]> writes:

    Nicolas> - in set-passwd, passwords sent on the wire (encrypted)
    Nicolas> by the client should be query strings
    >>  No, don't they need to be unnormalized strings so servers can
    >> deal with legacy support?

    Nicolas> Do you mean just-send-8 by "legacy?"  If so, I disagree.
    Nicolas> Either set-passwd servers should reject new legacy
    Nicolas> passwords, or should the protocol messages should be
    Nicolas> explicit about differentiating between legacy and
    Nicolas> SASLprep'ed passwords.

Or ISO 2222 if it existed.

Consider the case where the password contains a code point the legacy
implementation does not normalize but that saslprep does normalize.

You want the pre-normalized form on the server so you can set up both
keys so old clients continue to work.  I do agree that only UTF8
should be sent to a password servers.  I do agree that the server MUST
reject anything that doesn't fully normalize with its version of
saslprep.

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 21 Jul 2004 16:55:05 -0500

On Wed, Jul 21, 2004 at 04:48:43PM -0500, Nicolas Williams wrote:
> Sam,
> 
> If we wish to continue to support new legacy passwords in an extended
> Kerberos V world then I think I would insist on using OCTET STRING and
> an optional encoding type identifier for non-UTF-8, non-SASLprep'ed,
> non-ASCII passwords.

While continuing to use UTF8String for non-legacy passwords, of course.

I.e., make the set-password string type(s) ::= CHOICE {
    utf8 UTF8String,
    legacy SEQUENCE {
	string OCTET STRING,
	encoding StrignEncoding OPTIONAL,
    ...
    },
...
}

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 21 Jul 2004 16:48:43 -0500

Sam,

Nico
--

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 21 Jul 2004 18:07:44 -0400

> an optional encoding type identifier for non-UTF-8, non-SASLprep'ed,

<sigh>  I think you are talking past each other.

No one is proposing that the set-passwd protocol use any encoding other 
than UTF-8.  No one is proposing that there will ever be a just-send-8 
set-passwd client.

However, a set-passwd server may be associated with a KDC which needs to 
continue to support just-send-8 Kerberos clients.  It may be associated 
with a KDC which needs to continue to support Kerberos clients which send 
unnormalized UTF-8 tagged as GeneralString.

For this to work, the KDC (and thus, the set-passwd server) needs to have 
access to the unnormalized password.  If it expects to support legacy 
just-send-8 clients, it will presumably reencode in whatever the local 
character set is.  If it expects to support legacy Microsoft clients, then 
it will use the unnormalized UTF-8 as-is.

-- Jeff

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 21 Jul 2004 17:31:53 -0500

> than UTF-8.  No one is proposing that there will ever be a just-send-8 

1)  I'm not sure that legacy passwords can always be converted to UTF-8.

2)  I don't see how you can convert from UTF-8 to legacy encodings
    without knowing what the legacy encoding is!

    So how does sending legacy passwords converted to UTF-8 help legacy
    clients?!

> unnormalized UTF-8 tagged as GeneralString.

I don't [yet?] agree that we want to allow _new_ legacy passwords in
extended Kerberos V.  All-ASCII passwords should continue to interop all
around.  If we agree on this view then the only interop issue is how to
represent old legacy passwords when changing them to non-legacy new
passwords.

> it will use the unnormalized UTF-8 as-is.

See (2) above.  Access to unnormalized UTF-8 that results from
converting from a legacy encoding does not mean access to the original,
thus it doesn't help.

Cheers,

Nico
--

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 21 Jul 2004 19:35:56 -0400

> 1)  I'm not sure that legacy passwords can always be converted to UTF-8.

Anything that can be represented in Unicode can be encoded in UTF-8.
Anything in any of the ISO-8859-* character sets is in Unicode.
I think we can ignore things that aren't in Unicode.

>     without knowing what the legacy encoding is!

Well, yes, of course you need to know that.  I expect that in the majority 
of cases, there is a single obvious 8-bit character set in use in any given 
realm.  Yes, the KDC administrator will have to do some configuration to 
continue to support his just-send-8 clients.

>> with a KDC which needs to continue to support Kerberos clients which
>> send  unnormalized UTF-8 tagged as GeneralString.
>
> around.

Saying "you must use a new system to change your password" is not that big 
a burden.  We did it here, when we converted to krb5 and "old" systems used 
the ancient v4 password-changing protocol which sent the server only a key.

Saying "once you change your password, you stop being able to log in from 
old systems" is really not OK.  Faced with this restriction, administrators 
will avoid upgrading their KDC's in order to prevent breaking things for 
the old clients that are too numerous to get rid of any time soon.

Imagine a situation where if you upgrade the Windows domain controllers to 
"Windows 2007 server", any user who changes his password stops being able 
to log in from his existing Windows XP machine.  That would be totally 
unacceptable.

> If we agree on this view then the only interop issue is how to

Maybe I'm confused.  What's a "legacy password"?  What's a "non-legacy new 
password"?  What does "changing" mean in this case?

If by "legacy" you mean "encoded in a legacy character set", you eliminate 
this problem in set-passwd by decreeding that the only character set which 
will ever be used with set-passwd is Unicode.

>> For this to work, the KDC (and thus, the set-passwd server) needs to
>> have  access to the unnormalized password.  If it expects to support
>> legacy  just-send-8 clients, it will presumably reencode in whatever the
>> local  character set is.  If it expects to support legacy Microsoft
>> clients, then  it will use the unnormalized UTF-8 as-is.
>

What conversion from a legacy encoding?  Who said anything about legacy 
encodings ever appearing as part of set-passwd?  The only character set 
that set-passwd needs is Unicode.

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 21 Jul 2004 21:38:17 -0500

> >><sigh>  I think you are talking past each other.

Now I'm talking past both of you :)

> I think we can ignore things that aren't in Unicode.

By "things" I take it you mean characters.

Not unreasonable, but still, why do conversion to UTF-8 at all if you're
looking to have the long-term key derived from the original non-UTF-8,
non-ASCII?  What's the point?

> continue to support his just-send-8 clients.

The client could be dealing with a "legacy" password in some multi-byte
encoding other than UTF-8.  Or it could be UTF-8, but with no
normalization, no stringprep -- how would the client indicate this to
the server?

I'm skeptical that legacy passwords can be converted to UTF-8 and back
to the original reliably.  So if we want to still be able to set legacy
passwords in an extensions world, then we need to have the set-passwd
protocol accomodate this carefully.

> the ancient v4 password-changing protocol which sent the server only a key.

Er, no, old systems will keep working, for rfc3244, MIT's set-passwd v1,
kadmind changepw, and interop will continue to be feasible with
all-ASCII passwords.

We do not guarantee interop for non-ASCII passwords now, so why the
sudden urge to continue to allow non-ASCII _legacy_ (i.e.,
non-SASLprepped, maybe not even UTF-8) passwords??  I'm dumbfounded.
Please explain why.

> old systems" is really not OK.

1)  We know that non-ASCII Kerberos V passwords are not interoperable
    _today_.

2)  Nothing we do in extensions will make non-ASCII, _legacy_ Kerberos V
    passwords work reliably tomorrow.

3)  The reason for (1) is the unpredictability of what encoding and
    normalization form a client used when it set a legacy non-ASCII
    password.

Q:  So what can we do in extensions to make non-legacy, non-ASCII
    passwords interop with pre-extensions clients, reliably?

A:  Nothing.  If there was we'd not wait for extensions.

>                                 Faced with this restriction, administrators 

We can't help this.  During migrations users who must use legacy
Kerberos V software will have to constrain themselves to all-ASCII
passwords, as they already must to interop with pre-extensions
implementations.

> to log in from his existing Windows XP machine.  That would be totally 

It's not "any user" but "any user who changes their password and uses
non-ASCII characters."  And this isn't because we don't care.  It's
because KDCs can't tell what encoding and/or normalization forms
pre-extensions clients are using.  How can we help this?

> password"?  What does "changing" mean in this case?

"Legacy password" here means passwords w/ non-ASCII characters set prior
to the advent of extensions.

The sentence you ask about refers to the fact that set-passwd servers
will want proof that an old, legacy password (see above) is the current
password of the principal whose passwords it's being asked to change,
that and the issue of how to represent these passwords.

New passwords are always SASLprepped UTF-8.

Old, non-legacy passwords are always ASCII (and so UTF-8).

> will ever be used with set-passwd is Unicode.

See above.

> that set-passwd needs is Unicode.

How does a set-passwd server verify an old (current) password that is
being changed if it is not the actual password but a UTF-8 encoding of a
password that uses non-ASCII codepoints and which was not encoded in
UTF-8 (and/or SASLprepped) when originally set?

Nico
--

---

From: Sam Hartman <[email-masked]>
Date: Thu, 22 Jul 2004 11:34:44 -0400

>>>>> "Nicolas" == Nicolas Williams <[email-masked]> writes:

    Nicolas> On Wed, Jul 21, 2004 at 07:35:56PM -0400, Jeffrey
    Nicolas> Hutzelman wrote:
    >> >>> If we wish to continue to support new legacy passwords in
    >> an extended >>> Kerberos V world then I think I would insist on
    >> using OCTET STRING and >>> an optional encoding type identifier
    >> for non-UTF-8, non-SASLprep'ed, >>> non-ASCII passwords.
    >> >>

    Nicolas> Now I'm talking past both of you :)

Yeah.  If we don't resolve this in one or two more emails perhaps we
should fight it out in person next week;)

    >> >>No one is proposing that the set-passwd protocol use any
    >> encoding other >>than UTF-8.  No one is proposing that there
    >> will ever be a just-send-8 >>set-passwd client.
    >> >
    >> 
    >> Anything that can be represented in Unicode can be encoded in
    >> UTF-8.  Anything in any of the ISO-8859-* character sets is in
    >> Unicode.  I think we can ignore things that aren't in Unicode.

    Nicolas> By "things" I take it you mean characters.

    Nicolas> Not unreasonable, but still, why do conversion to UTF-8
    Nicolas> at all if you're looking to have the long-term key
    Nicolas> derived from the original non-UTF-8, non-ASCII?  What's
    Nicolas> the point?

I think the goal is to improve interoperability and to allow newer
clients to drop support for old methods.  We want to focus all the
evil of just-send-8 legacy support in one place: the KDC and admin
server.

There's an assumption that a single realm has a small number of
encodings in use and that the realm admins know these encodings.  Do
you believe that is a reasonable assumption?

Given that assumption, then the admin server can generate all the
appropriate keys for the password.  It actually could do this with
normalized UTF8 as input.  However that would require generating all
the possible strings that could lead to the normalized output.  Doing
so would be complicated and might lead to a lot of strings.  By giving
the password server pre-normalization input we make its job easier in
the legacy case and don't create significant complexity in the all new
case.

There are several advantages of this scheme .  New password change
clients don't need to know about legacy support.  Once you have
changed your password using the new protocol, you can work both with
old or new clients.

---

From: Jeffrey Altman <[email-masked]>
Date: Thu, 22 Jul 2004 12:35:37 -0400

I think the focus of this discussion is in the wrong place.
The Kebreros Set/Change Password protocol must provide a secure 
mechanism for
setting, querying, and changing passwords in a secure manner.  It must 
meet all of the
requirements of Kerberos Extensions but also provide enough information for
legacy password systems to be able to synchronize to this password if 
the Kerberos
Password service or the KDC provides implementation specific hooks to 
external
password databases.

I say this because I hear this request from end user organizations, 
integrators, and
operating system vendors all the time.  This can easily be provided by 
having the
client provide the server with not only a SASLprep'd normalized password but
also an unnormalized display string version.  What the password server 
uses the
display string version for is unimportant.  It can be used to provide 
support for
legacy just send 8 or just send UTF8 Kerberos passwords; or it can be 
used to
synchronize with an NTLM or NIS or SRP or "you name it" password database
if the server implementation chooses to support the necessary hooks.

As such I think we should focus this discussion on a protocol which 
works with
extensions and happens to work with clarifications as one of the many legacy
systems which can be supported as a side effect.

Jeffrey Altman

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 22 Jul 2004 11:36:46 -0500

> should fight it out in person next week;)

Do they allow asbestos suits on airplanes?  Can I buy one in San Diego?

:)

Nico
--

---

From: Sam Hartman <[email-masked]>
Date: Sat, 24 Jul 2004 14:13:46 -0400

>>>>> "Jeffrey" == Jeffrey Altman <[email-masked]> writes:

    Jeffrey> all the time.  This can easily be provided by having the
    Jeffrey> client provide the server with not only a SASLprep'd
    Jeffrey> normalized password but also an unnormalized display
    Jeffrey> string version.  What the password server uses the
    Jeffrey> display string version for is unimportant.  It can be

Why should the client saslprep?  The server cannot trust the saslprep
result from the client so it will have to rerun saslprep.  Also, if
you accept two strings from the client, you have to deal with security
considerations based on whether there really is some reasonable
equality predicate that holds true for the strings.