Adding a krb5_get_change_password_message() function?
nico at cryptonector.com
Wed Apr 25 13:02:22 EDT 2012
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
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
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.
More information about the krbdev