Thanks all. Continued appreciation for your contributions and guidance. On Sat, Apr 25, 2015 at 10:29 AM, Greg Hudson <ghud...@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(). > ________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos