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(). ________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
