Re: draft minutes from meeting at ietf50..

[Darren Moffat <Darren.Moffat%eng.sun.com@localhost>]

I thought the vulnerabitliy was about the users login password when
using password access rather than publickey, where did su come into it ?

Maybe I'm missing something here but how can any guessing be done about
password length when running the su across the encrypted link ? Surely
this is no different to running ls -l and given the link is encrypted
there should be no way for an attacker to know what it is I'm actually
doing.


>> So, a) don't do that, use ssh -l root,
>
>It is quite common policy to not allow people to log in as root
>directly from the network, but rather *require* that they first log in
>as an ordinary user and then su. I don't know all the pros and cons of
>that policy, but I don't think it is going away soon.

	** OFF TOPIC DISCUSSION **

Not only is it common policy many operating systems make it the default
for telnet/rlogind.  The idea being you don't want the root password
going across the wire, but since the link isn't encrypted it goes across
the wire when you use su anyway.  It also slighly reduces the risk if
the root password is compromised and no user password has been, but only
slightly.

It is a good policy in systems that have an audit id, like Solaris, AIX, SCO
(and I'm sure others as well), since forcing the login as the user first
means the audit trail will be properly setup to say which real user was
doing stuff as root.

Addressing Tom's point about rewriting su, it could be done but then it
wouldn't be su anymore!  For systems that have PAM this could be done
using PAM modules for su but that really has nothing to do with the SSH
protocol.

If this WG is going to find a solution to the problem then it needs to
be an SSH protocol fix or implementation suggestion.


--
Darren J Moffat