Patch to ignore service principals when accepting connexions.

[Sam Hartman]

>>>>> "Roland" == Roland C Dowdeswell <elric at imrryr.org> writes:

    >> In general, if an
    >> application is going to use GSS_C_NO_CREDENTIAL, it needs to examine the
    >> service name that was accepted and make an authorization decision.

    Roland> I do not believe that there is an authorisation decision here at
    Roland> all in the normal case.  The client needs to ensure that it is
    Roland> talking to the correct service principal but the server generally
    Roland> just needs to ensure that it is talking to the correct client.
    Roland> The service principal that the client selects is an issue of
    Roland> configuration not of authorisation.  Granted, system admins could
    Roland> put inappropriate keys in their keytabs but this is not really an
    Roland> authorisation problem---it is a security problem with their
    Roland> configuration.
I think we disagree here.
It's common for both nfs and ssh to run as root and thus it would be
reasonable  to store both keys in root's keytab.
However it is not desirable for an authenticator to be reused from NFS
 to ssh.

Something in the system needs to confirm that this is not happening.

Differences in application protocols, replay caches, etc can create
related protocol attacks.  In cases where a machine has identities in
multiple realms there can be significant authorization issues.

So, I am quite certain there are authorization issues.
You can claim that these authorization issues are best handled by
managing the keytab, and that's certainly a position to consider.
    >> We introduced a behavior change in 1.7 so that application no longer
    >> examine the service name encoded in a ticket; instead, they look at
    >> whether the key matches.  This means that you can have KDC-side aliases
    >> either by setting principals to have the same key or by using actual
    >> aliases (as we support with the LDAP backend).  In that environment, you
    >> would have one key in your keytab, but the KDC would issue tickets with
    >> that key for multiple principal names. The KDC configuration is the
    >> layer at which authorization happens;any name that has the key in the
    >> service keytab is authorized.

    Roland> I think that this is aimed at solving a different problem than the
    Roland> one that we have.

As someone involved in the design of that change, I believethat the type
of problem you have is well within the scope of what we were looking at.
We may not have created the facilities you need in order to take useful
advantage of that change yet--it may not be sufficiently easy from an
operational standpoint.  However I think it's fair for us to look into
whether that's true and to consider options that involve making that
easier to deploy as well as alternatives like your patch.

I'd definitely appreciate your help in that.