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

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Sun, 18 Jul 2004 18:19:53 -0700

Nicolas Williams wrote:
> 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).

This sounds as a reasonable solution.

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

I am trying to avoid using the minor version to indicate the set of
error codes the client supports.

In complex systems, we just need to deal with new error codes.

> And see above.

No existing systems either sends localized texts or depends on the
remote clients to localized the error text and display it properly. 

> 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.

In fact this is not hard to do, you just need to send an integer by the
client to indicate the largest error code value it can understand, and
stating that if a client understands error code x+1, it must also
understand error code x. what do you think?

Thanks,

Larry

-----Original Message-----
From: Nicolas Williams [mailto:[email-masked]] 
Sent: Sunday, July 18, 2004 5:26 PM
To: Liqiang(Larry) Zhu
Cc: Sam Hartman; [email-masked]
Subject: Re: set-passwd protocol and stringpreps, again

On Sat, Jul 17, 2004 at 05:37:08PM -0700, Liqiang(Larry) Zhu wrote:
> 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.

Done.

> 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.

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).

> 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.

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: Nicolas Williams <[email-masked]>
Date: Sun, 18 Jul 2004 20:40:47 -0500

> remote clients to localized the error text and display it properly. 

Clients cannot be expected to localize messages from the server,
otherwise we'd have to standardize the messages, so that the message
catalogs could be standardized, and we don't want to do this -- we might
as well have an error code for every imaginable pw quality policy
instead.

As for servers and localization, well, with the client sending language
tags to the server the server can, indeed localize its messages,
provided that it has a suitable message catalog.  Presumably server
implementors will take care to include message catalogs for their
messages related to password quality policies.  I don't think this is
unreasonable.

And for many here support for localization could be a requirement (e.g.,
due to the laws of various nations), so this spec had better deal with
the matter, and for extensibility's sake requiring the server to perform
any localization is the way to go.  This is how several other IETF
protocols deal with l10n; for example: SASL, SSHv2.

> understand error code x. what do you think?

See the ASN.1 module in the last version of the draft.  You can see that
the relevant bits are extensible, though the text of the spec limits
extensions to those defined in IETF specs.  And minor version
negotiation is already there, so this should not be an issue.

Nico
--

---

From: Matt Crawford <[email-masked]>
Date: Thu, 22 Jul 2004 08:54:48 -0500

> understand error code x. what do you think?

This has IANA Considerations considerations.  You can't then set aside 
a high-numbered portion of the error code space for local or 
experimental use.  Not a fatal drawback, but an implication of this 
choice.

Alternatively, a server could do something like a multipart/alternative 
message: send a list of increasingly specific error codes and the 
client should use the last one it understands.