"Eric J. Schwertfeger" <[EMAIL PROTECTED]> writes:
> As promised, I've rolled up everything I know about how to use lsh so far
> (assuming the user knows how to use rsh/rlogin) into an HTML document.
> The rough draft is available at http://cybernut.com/lsh.html and while
> I've gotten rid of almost all the red text (for those of you that have
> already looked at it), I do have just a few known issues left. Feel free
> to inform me of anything I might have overlooked. I'm an lsh newbie, but I
> think I've got the concepts down.
Thanks. Some comments:
Section "What LSH is": http://www.lysator.liu.se/~nisse/lsh is not really an
lsh "site". It's a gateway to my cvs repository. At top level, it
displays the README file and a directory listing.
Section "The concept of public key encryption": Note that lsh and
secsh doesn't really use public key _encryption_. It only uses digital
signatures, and diffie-hellman keyexchange.
> I was under the impression that SECSH had made it to rfc status, but all I
> can find defining it are expired drafts. Has it not made it to rfc status
> yet, or is www.normos.org not up to date? I don't know which would be
> worse, that we're coding to expired drafts, which aren't supposed to be
> used as reference material to begin with, or that my favorite place to
> search for RFC's is out of date. Hmmm. just found the SECSH-charter
> homepage, and they list everything as drafts (though the last-modified
> date is June 99), so it looks like that is the case.
There's no RFC. Latest drafts are from last summer. I'm sad to say
that the IETF working group is not very active. But there seems to be
work going on elsewhere; the latest drafts appeared and addressed some
problems in earlier drafts, although there were almost no discussion
on the wg mailing list. Feel free to prod the wg chair (Perry Metzger)
and the Security Area directors (Jeffrey Schiller and Marcus Leech).
Information about the wg is at
http://www.ietf.org/html.charters/secsh-charter.html.
> How stable do most people find recent lsh snapshots? Do you trust lsh to
> provide security? I know the documentation says not to trust it, but I
> think that's a little out of date. Aside from potential exploits
> (potential as in I haven't proven that they don't exist, not as in they're
> there, but haven't been exploited yet), lsh seems to offer complete enough
> an implementation of SECSH to be quite useful.
If there is any serious security problem in lsh, I would expect it to
be of one of this types:
1. Standard buffer overflow bugs. I think there are none (strings are
represented with an explicit length, and the C library string
functions are not used much. But there could still be bugs.
2. Subtly flaws, say a bug in the randomness code that causes all keys
to be hashes of fixed or easily guessable data. An earlier version
had bugs in the MAC generation and verification that totally
destroyed that part of the security.
3. Denial of service attacks, attacks that cause lshd to crash r bog
down the system.
Of these, I think (2) is the worst kind, because you won't find it by
ordinary testing. The program just works, it can be really stable, and
it still does not provide security. Ideas on how to test this is
appreciated. For instance, the MAC bug above could have been
discovered by running a lsh connection through a proxy that flips some
bits. The test is considered successful if both sides can detect this
as a MAC error and disconnect.
> What is the current status of port forwarding?
Not tested for a while. At least not by me.
> What is the best way to confirm that you've captured the correct host key,
> if you don't have the fingerprint generated from the host's public key?
> At this time, I'm recommending that the user authorize their identity,
> then reconnect, on the possibly wrong assumption that unless that identity
> has been compromised, any man-in-the-middle attack would have to change
> the fingerprint of the public key given to the server, causing public key
> authentication to fail. Of course, this fails if someone is pretending to
> be the server, rather than doing a man-in-the-middle attack.
It is an interesting observation that you get some protection from
MITM-attacks by using authorized user keys and sloppy host
authentication.
But it is not what I would recommend. For a start, the usual way to
authorize a user key is to copy some data from the client to the
server. The transfer need not use encryption, but it *must* use proper
authentication. So you usually need a properly authenticated
connection to the server first.
For me, the typical scenario is that I have an account on some site
that uses ssh/lsh. Then I want to connect to that site from a trusted
but unrelated machine somewhere else (perhaps at home, at work, or at
some friend). In this case, I know beforehand which site I will want
to connect to, so I could print out the related fingerprints on paper
and keep it in my wallet. And once I have the key or fingerprint for
one machine in the site, I can use that to get hostkeys from its
neighbors.
In the longer term, certificates can make this a little less
cumbersome.
> Oh, and out of curiosity, how do people normally capitalize lsh? Do you
> treat it as a normal word, with the L capitalized when at the start of a
> sentance? don't ask me why it's bothering me, but I was horribly
> inconsistent within my document, until the last revision, where I decided
> that any time I referred to the set of programs that make up lsh, I'd
> capitalize the whole think, and if I was referring to the client program
> lsh, I'd put it in lower case. That seemed to work since I never started
> a sentance with lsh the program.
Sonds reasonable. When "lsh" refers to the client program, I think I'd
write it in all lowercase and perhaps in a fixed typewriter font. Even
at the start of a sentence.
/Niels
