Good procedure?

[Alexander Wuerstlein]

On 2018-08-21T14:48, Stef Bon <stefbon at gmail.com> wrote:
> Op di 21 aug. 2018 om 14:43 schreef Alexander Wuerstlein <arw at cs.fau.de>:
> >
> > On 2018-08-21T06:21, Stef Bon <stefbon at gmail.com> wrote:
> 
> > > The user dos not do that, the localhost computer does this behind the scenes.
> >
> > Sounds like you are reinventing Kerberos.
> >
> 
> Thats good! Kerberos is proof of concept.
> But serieus, Uber does it like this (or simular< see:
> https://medium.com/uber-security-privacy/introducing-the-uber-ssh-certificate-authority-4f840839c5cc)

There are huge differences to what you described. First, Uber uses just
SSH, you mentioned e.g. internet access or print services which aren't
easily SSH-tunneled without tons of headaches. Kerberos is already
integrated into file services like NFS, SMB or WebDAV, print services
like LPR or IPP and proxy servers like Squid. You just have to enable it
and it will work. Whereas with SSH, you could tunnel all that, but you
will have to adapt all the mentioned client services for that. And you
get additional problems because the SSH-Tunnels authentication is not
bound to the authentication of the inner protocol (say IPP), which means
that you have yet another set of authentication credentials or none at
all. All of which makes authorisation problematic or broken, except in
the most trivial case (where you only have the two classes "is allowed
everything" and "is denied").

Second, the article describes an automatic SSH-CA for longer-lived keys,
e.g. "If an employee loses access (e.g. they leave the company)". What
you describe is intended as per-session-keys, which has another ton of
headaches, because of short expiry periods and frequent key changes.
It's doable, but not very easily, because sessions start and end all the
time, and their expiry isn't just given by an expiry date in the
SSH-Certificate (decentrally checked by each sshd) but by the user
exiting the session (centrally signalled to the magic session db and
then read/polled/waited for by all services using the session).

Also, authentication is just performed using the SSH-key in Uber's case,
you intend to pass around the password as well which is a really bad
idea. Passwords should never be cached, remembered or passed around,
decades of experience show that this will only lead to compromise.




Ciao,

Alexander Wuerstlein.