[36936] in Kerberos

home help back first fref pref prev next nref lref last post

Re: theory behind unique SPNs

daemon@ATHENA.MIT.EDU (Ben H)
Sun Apr 26 08:09:07 2015

MIME-Version: 1.0
In-Reply-To: <553BB2D6.5030002@mit.edu>
Date: Sun, 26 Apr 2015 07:08:38 -0500
Message-ID: <CAAd7auamOeqou_hXW9X06zRHu5OuircAsqoi6ORf0Gx0kz1gdQ@mail.gmail.com>
From: Ben H <bhendin@gmail.com>
To: Greg Hudson <ghudson@mit.edu>
Cc: kerberos@mit.edu
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: kerberos-bounces@mit.edu

Thanks all.  Continued appreciation for your contributions and guidance.

On Sat, Apr 25, 2015 at 10:29 AM, Greg Hudson <ghudson@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

home help back first fref pref prev next nref lref last post