theory behind unique SPNs
Ben H
bhendin at gmail.com
Fri Apr 24 18:07:42 EDT 2015
Thanks Simo - I think that your explanation mostly answers the first part
from my reply!
On Fri, Apr 24, 2015 at 5:05 PM, Ben H <bhendin at gmail.com> wrote:
> Greg -
>
> 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?
> 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?
> Or is there something else at the "protocol" level that makes this
> criteria important?
>
> You are definitely correct regarding AD in that all services registered to
> a principal will use the same key. In fact computer accounts usually just
> register "host/" and the KDC will automatically alias this to a whole list
> of common services (cifs, ldap, etc.).
>
> 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?
>
> Nico - I'm not sure I understand your redirection statement. Is this
> from a "man-in-the-middle" type perspective? The fact that each
> application communicates over a specific port would be enough to direct to
> the correct service, no?
>
> Thanks guys!
>
> On Fri, Apr 24, 2015 at 3:46 PM, Greg Hudson <ghudson at mit.edu> wrote:
>
>> On 04/24/2015 03:37 PM, Ben H wrote:
>> > Why not simply use host/serverA.domain.com <http://servera.domain.com/> for
>> both services?
>>
>> At a protocol level, it's to support privilege separation on the server.
>> The CIFS server doesn't need access to the LDAP server key and vice
>> versa.
>>
>> Of course you only get this benefit if (a) the two services use
>> different keys, and (b) the two service implementations are sufficiently
>> isolated on the server host. In a normal AD deployment (as I understand
>> it) the first constraint isn't true, but the client shouldn't assume that.
>>
>
>
> On Fri, Apr 24, 2015 at 4:21 PM, Nico Williams <nico at cryptonector.com>
> wrote:
>
>> On Fri, Apr 24, 2015 at 04:46:55PM -0400, Greg Hudson wrote:
>> > On 04/24/2015 03:37 PM, Ben H wrote:
>> > > Why not simply use host/serverA.domain.com for both services?
>> >
>> > At a protocol level, it's to support privilege separation on the server.
>> > The CIFS server doesn't need access to the LDAP server key and vice
>> versa.
>>
>> And, to a lesser extent, to prevent users from getting redirected from
>> one service to another.
>>
>> Nico
>> --
>>
>
>
More information about the Kerberos
mailing list