theory behind unique SPNs

[Ben H]

Thanks all.  Continued appreciation for your contributions and guidance.

On Sat, Apr 25, 2015 at 10:29 AM, Greg Hudson <ghudson at mit.edu> wrote:

> On 04/24/2015 06:05 PM, Ben H wrote:
> > So from a privilege separation perspective, are we talking more from a
> > hardening perspective?  E.g. if I can compromise serviceA that would
> > give me the key to serviceB?
>
> Yes.
>
> > While that is a valid concern - if we were to guarantee (theoretically)
> > that serviceA couldn't be breached (or there was another way to breach
> > serviceB through serviceA) - then would this be mostly a moot point?
>
> Yes, it is easy to imagine circumstances where privilege separation
> isn't important.  For instance, if a single protected resource can be
> accessed in the same ways by two different protocols (say, HTTP and
> IMAP) then there isn't really a benefit to using different keys for the
> two protocols.
>
> Conversely, there are cases where server privilege separation might make
> sense where the Kerberos protocol doesn't support it.  A server host
> might have two different HTTP servers running as different users on
> different ports, and there's not really a good way to make those servers
> use different keys.  (Microsoft does put a port number in some kinds of
> service principals, but it's not traditionally done.)
>
> > Or is there something else at the "protocol" level that makes this
> > criteria important?
>
> No, but the client is going to pick the service principal to use,
> usually based on the protocol and server hostname.  So you're usually
> much stuck with having different SPNs for each protocol.
>
> > My understanding is that in traditional kerberos there would be a single
> > SPN per principal...or IOW each SPN is a separate "account" with its own
> > password.  I thought my reading of this project:
> > http://k5wiki.kerberos.org/wiki/Projects/Unicode_and_case_folding
> > inferred that there was some work getting done on assigning more than
> > one SPN in the form of an Alias, so that host/myserver could also have
> > an alias of nfs/ ... but maybe I am misreading the intent of this?
>
> http://k5wiki.kerberos.org/wiki/Projects/Aliases might be more directly
> applicable.  MIT krb5 supports aliases in the LDAP KDB module, although
> they must be maintained directly with LDAP, not with kadmin.
>
> It is also worth noting that, since MIT krb5 1.7, server processes can
> try all of the keys in their keytabs to decrypt an AP-REQ ticket,
> ignoring the server principal name sent by the client.  This behavior
> depends on how the server process invokes gss_accept_sec_context() or
> krb5_rd_req().
>