[Freeipa-devel] Re: Encoding of Kerberos principal

Jason Gerard DeRose jderose at redhat.com
Wed Jul 8 09:09:20 UTC 2009


On Tue, 2009-07-07 at 10:08 -0400, Don Davis wrote:
> >
> > Is it safe to assume that the principal is UTF-8 encoded
> > (as far as the MIT Kerberos library is concerned)?
> >    
> 
> hi, jason --
> 
>      the short answer is "no;"  in general, principal names
> are claimed to be encoding-agnostic, meaning that they're
> not null-terminated, and the code is supposed to ignore the
> bytes' internal structure;  a principal-name is just void*+length,
> more-or-less.

Well, as far as the principal and realm, I'm only using it two ways:

1. Client-side I extract the principal/realm from the default credential
cache of the user running the process.

2. Client or server side, I get the default realm (which just comes
from /etc/krb5.conf, AFAIK).

I don't know if the Kerberos standard even allows non-ascii characters
in the realm, so I think the only gotcha is with the user-name portion
of the principal.

Anyway, in the above situations, can I expect any consistency?  Does the
Kerberos server negotiate the character encoding with the client?  Like
what happens if I have non-ascii characters in my user-name and and
authenticating from a Windows box to a Linux authentication server?

>      the long answer is complex, and i can't represent it
> faithfully.  there are places in the code that know about
> ucs2le (a predecessor to utf-16), and there are Windows-
> specific places in the code that know about utf-16 strings
> per se.  also, kerberos handles internationalization of
> passwords, principal-names, and realm-names all
> differently.   it's pretty much what you'd expect for
> legacy code that predates the internationalization effort.

Was the above specific enough?  I don't know if I know Kerberos well
enough to ask the right questions, but I'm also (at the moment) only
concerned with very limited aspects of the libkrb5 API (which I'm using
via the python-krbV bindings).

Thanks for your help!

>      if, as i expect, you have a more-detailed version of
> your question, i'll try to help.
> 
>                                                                  - don
> 
> 
> 
> 
> 
> -




More information about the Freeipa-devel mailing list