theory behind unique SPNs

[Greg Hudson]

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().