Re: rdns, past and future

Dameon Wagner <[email protected]>
Newsgroups gmane.comp.encryption.kerberos.general
Organization University of Oxford IT Services
Message-ID <[email protected]>
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
> > <[email protected]> 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           [email protected]
https://mailman.mit.edu/mailman/listinfo/kerberos
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.