[38745] in Kerberos
Re: rdns, past and future
daemon@ATHENA.MIT.EDU (Dameon Wagner)
Wed May 27 07:40:56 2020
Date: Wed, 27 May 2020 12:38:08 +0100
From: Dameon Wagner <dameon.wagner@it.ox.ac.uk>
To: <kerberos@mit.edu>
Message-ID: <20200527113808.dtng4jm27rzv3nyc@maia.oucs.ox.ac.uk>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <9d4eb6d7-2aec-47fb-767a-1f3b0855e331@secure-endpoints.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: kerberos-bounces@mit.edu
On Tue, May 26 2020 at 18:59:23 -0400, Jeffrey Altman scribbled
in "Re: rdns, past and future":
> On 5/26/2020 6:31 PM, Ken Dreyer wrote:
> > On Tue, May 26, 2020 at 3:58 PM Jeffrey Altman
> > <jaltman@secure-endpoints.com> wrote:
> >>
> >> 2. Before the existence of DNS SRV records, CNAME records were the
> >> only method of offering a service on multiple hosts. However,
> >> its a poor idea to share the same key across all of the hosts.
> >
> > I'm curious about this. What makes it a poor idea?
> >
> > It seems like a very convenient way to scale a service up and down
> > dynamically quickly when you share a key among all instances.
>
> Because if you hack into one of the hosts you now have the key for
> all of the hosts. The holder of the key can forge tickets for any
> user. Since the key isn't unique the entire distributed service has
> to be shutdown to address the vulnerability. It is also much harder
> to trace where the key was stolen from.
Also, as another simpler example, it can make key management more
involved, rather than more convenient:
Moving and sharing sensitive material around is awkward, but running
`ktadd` on a new cluster member is trivial -- but if you're using a
shared key across all cluster members, you've broken them all except
the newest member (as `ktadd` does an implicit randkey). I've seen
too many fresh sysadmins break things that way...
Cheers.
Dameon.
--
><> ><> ><> ><> ><> ><> ooOoo <>< <>< <>< <>< <>< <><
Dr. Dameon Wagner, Unix Platform Services
IT Services, University of Oxford
><> ><> ><> ><> ><> ><> ooOoo <>< <>< <>< <>< <>< <><
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
