[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: kerberos support in ssh/lsh

>>>>> "Mark" == Mark W Eichin <eichin@thok.org> writes:

    >> server tries to get a kerberos ticket on the client's behalf,
    >> and if that succeeds, the client is considered authorized. It's
    >> an extra plus

    Mark> You've fallen into the standard "screensaver" trap, also
    Mark> known as the "Zanarotti Attack".  This design-flaw-exploit
    Mark> goes back to the early (1985 or so) versions of ksu.

    Mark> Basically, getting a TGT and successfully decrypting it
    Mark> *MEANS NOTHING* in regard to security.  The essence of the
    Mark> attack is that at the same time I send the username to the
    Mark> target machine, I flood it with "kdc responses" that are
    Mark> encrypted in a password/key I know.  The server then sends
    Mark> off the TGT request, reads an answer, gets the one I sent;
    Mark> tries to decrypt it with the password I supply, and
    Mark> succeeds.  *boom*.

Thats an interesting attack I never thought of before.

However, my concern for this method is different, and has been bought
up numerous times in the past on comp.protocols.kerberos:

When you give the server the password, and it gets the users
ticket... errr.. well... the server could do anything it likes
with that ticket, including access remote servers that
the user is allowed to access.

This really is not much better then securing the system with a
database like NIS or LDAP. In fact, IIRC, the very same weaknesses
exist in both protocols - authentication can be "stolen" by the
server, etc.

Remember Kerberos is an authentication protocol (normally the server
asks: who is this user?), but here you are really proposing to use it
as an authorisation protocol (ie the server is saying: make me
equivalent to this user), something it was never meant for.

So, please don't break a good authentication system by implementing a
hacked version of the protocol. (If you really wanted to, I think
you could do this via PAM anyway).

Patches exists to do this under openssh (although I am not
sure if this works for the current version of openssh), see

Another alternative, would be to support the SASL library.  Supporting
this, in theory, will mean your code will work with any authentication
method, via plugin modules. The only downside is that it would be
incompatible with the openssh patch (not a big issue as far as I am
Brian May <bmay@csse.monash.edu.au>