Adding a krb5_get_change_password_message() function?

[Nico Williams]

On Wed, Apr 25, 2012 at 11:23 AM, Greg Hudson <ghudson at mit.edu> wrote:
> I'm a little conflicted.  We don't do a lot of converting structured
> data into strings in libkrb5, and when we have, it has often created
> problems.  On the other hand, smoothing over interoperability issues is
> a good role for libkrb5, and AD ought to be returning a UTF-8 string if
> it followed RFC 3244.  (But on the third hand, a displayable string in
> the protocol is a fundamentally non-localizable design.  And on the
> fourth hand, it's not really possible to describe password change errors
> in a structured fashion without making assumptions about the kind of
> password checks involved, so localization can really only be done on the
> server, which is usually poor design, although it's envisioned by
> draft-ietf-krb-wg-kerberos-set-passwd.)

That's the trade-off: either come up with a language that describes
90% of the password policies one might want to apply, or localize on
the server, or send a structure containing a printf-like format string
and encoded arguments and hope that the client can localize the format
string (and any arguments that need localization).  A fourth
alternative would be to send a URL to point the user to a password
policy, or better! use a web interface to do password changes ;)  (I
know, PAM and such can't make use of that, but then, see my blog posts
re: PAM).

The only reason that server-side localization sucks is the lack of
suitable interfaces in the Unix world.  Windows, however, does have
suitable L10N APIs IIRC.  All that's required is a thread-specific
setlocale(), or a variant of gettext() that takes a locale argument
(or both, since retrofitting all APIs that produce user-readable
strings to take locale arguments will take a long time).

The third alternative described above requires infrastructure to
distribute custom message catalogs.  Not exactly interop-friendly, and
yet another ancillary protocol for Kerberos.  Yuck.

Taking care of 90% of the cases is a good compromise, but allowing the
server to localize in the remaining 10% of cases is also a good
compromise, as long as it's optional.

> So, I'm not wild about the idea, but it seems reasonable enough, and I
> don't have a better alternative.  If you implement this, please include
> test cases (just a C program to feed some krb5_data values to the API
> and verify the results) and choose a shorter name for the API, like
> krb5_chpw_message() (similar to krb5_chpw_result_code_string()).

I completely agree with the sentiment, but I'd rather this structure
data be used to give the user useful feedback.

Nico
--