gss_accept_sec_context server principal

[Cesar Garcia]

Hi,

I'm am trying to change the behavior of a functioning GSS-enabled
application server such that the server principal and corresponding
keytab entry used by gss_accept_sec_context is determined dynamically
based on the server principal named in the client's ticket (implicitly
specified by the input token to gss_accept_sec_context).

There are various reasons for wanting to do this. Migrating to DNS is
one - we would like to isolate applications from naming changes on the
client hosts (or the server hosts for that matter) so that application
servers can accept tickets for either:

<service>/<short_name>@MS.COM
<service>/<short_name>.ms.com at MS.COM

thereby, allowing various client/hosts to migrate to DNS independently.

<service> is generally the name of the application. <short_name>
is the short name (our current hostname resolution renders short
names). This short name could either be an actual host name or a one
of several VCS service name. In other words, there could be many
permutations, and I would like avoid any brute force approaches where
I try every possible server principal name.

[of course, I would populate the application server's keytab file with
all of the necessary keytab entries so that it can assume any of the
above identities - in fact this works already for kshd/klogind, which
of course are not written with GSSAPI]

My first attempt was to specify GSS_C_NO_CREDENTIAL for the verifier
credential handle. This appeared to reveal a bug in
gss_accept_sec_context():

(I'll send a separate email to krb5-bugs at mit.edu about this).

== start bug description ==
  krb5_gss_accept_sec_context acquires a default cred via
  krb5_gss_acquire_cred, if the supplied verifier_cred handle is
  GSS_C_NO_CREDENTIAL - which is places in the variable "cred_handle" 

  It then proceeds to try to validate verifier_cred_handle, which in my
  case is GSS_C_NO_CREDENTIAL, rather than the new obtained credential
  (cred_handle). So this fails unnecessarily. So I fix this so that it
  validates cred_handle (which it obtains) rather than verifier_cred_handle
  (GSS_C_NO_CREDENTIAL).
== end bug description ==

Nonetheless, in obtaining a credential handle, krb5_gss_acquire_cred
will determine the server principal name. As invoked by
krb5_gss_accept_sec_context, it will obtain a handle to the credential
based on logic for GSS_C_NO_NAME and GSS_C_ACCEPT (cred_usage supplied
by krb5_gss_accept_sec_context).

In doing so, it invokes krb5_sname_to_principal, which determine the
default principal name based on hostname and sname arguments (both
NULL). This results in a server principal name constructed from an
sname of "host" and a hostname based on gethostname which is then
resolved via gethostbyname/gethostbyaddr. krb5_gss_acquire_cred then
attempts to extract the keytab entry for this principal.

Of course, this is not what I want.

Calling gss_acquire_cred from my application using GSS_C_NO_NAME has
the same affect.

Has anyone attempted to write a GSS-enabled application server that
can assume more than one different identities, based on the server
principal name specified in the client's ticket. Is there another
approach that will allow me to do this?

The only other thought I have is to try to extract the server
principal name for the token supplied by the client. This, however,
seems like I am breaking rules by not treating tokens as opaque
objects. I haven't investigated this approach yet, I was hoping there
was a more natural approach than this.

Any suggestions are highly appreciated.

Thanks,
Cesar