Patch to ignore service principals when accepting connexions.

[Greg Hudson]

On Wed, 2010-08-25 at 21:40 -0400, Roland C. Dowdeswell wrote:
> Is my proposed name ``check-service-instance'' reasonable or should
> we settle on another name?

How about "ignore-server-hostname"?  Your patch, incidentally, only
seemed to include configuration logic, not the actual implementation of
the flag (looking at
http://mailman.mit.edu/pipermail/krbdev/2010-August/009353.html)

Here's a wide-ranging response:

Case 1: GSS acceptors who use GSS_C_NO_CREDENTIAL (or acquire a cred
with GSS_C_NO_NAME), or krb5 acceptors who pass a null server to
krb5_rd_req.

These acceptors get nicely liberal acceptor behavior.  Unfortunately,
it's difficult or impossible for GSS acceptors to find out what
host-based service was actually used in this case.  (See
http://mailman.mit.edu/pipermail/kerberos/2010-May/016174.html and
following for a little more discussion of this.)  I don't have a
proposal for making this easier.

Case 2: GSS acceptors who import a host-based name but do not specify a
hostname, or krb5 acceptors who call krb5_sname_to_principal with a null
hostname argument.

For these acceptors, krb5_sname_to_principal constructs a principal
"<service>/<localhostname>@<realm>", where <localhostname> is the
DNS-canonicalized result of gethostname() and <realm> is the
host-to-realm result of that hostname using only local configuration (or
the referral realm, aka the empty string, if that realm is
indeterminate).  The keytab must contain an entry for
<service>/<localhostname>@<realm> (or ...@<default-realm> if <realm> is
the referral realm); the client may use any service principal which
matches that keytab entry's key.

I think acceptors in this class should, without any configuration
required, allow any hostname and any realm that the keytab can support.

For an implementation strategy, I tentatively propose that
krb5_sname_to_principal should construct a principal <service>/@, where
both the second component and realm name are empty.  krb5_rd_req would
interpret this principal check against every two-component principal in
the keytab whose first component matches <service>.  The ugly part: the
caller of krb5_sname_to_principal could also be an initiator trying to
talk to a local service, so krb5_get_credentials() would also have to be
able to handle <service>/@ principals.

Case 3: GSS acceptors who import a host-based name with a hostname, or
krb5 acceptors who call krb5_sname_to_principal with a non-null hostname
argument.

Roland wants (and Sam supports) a configuration variable which assumes
the app-provided hostname is bogus for acceptors and should be ignored,
at which point we want behavior equivalent to case 2.

The implementation strategy has to be different from what I propose for
case 2.  krb5_sname_to_principal can't throw out the hostname, because
the caller might be an initiator.  So I think the configuration variable
would have to be checked in krb5_rd_req, which would then throw out the
second component of host-based principals and match any hostname.

Disclaimers: Currently my schedule for the 1.9 release is tight.  I'm
not volunteering to implement any of this.  I can't even guarantee that
I'll have time to review and integrate a patch for 1.9, though I'll try.
I'm not insisting that case 2 and case 3 be implemented at the same
time.