Subject: Re: draft minutes from meeting at ietf50..

From: Niels Provos <[email-masked]>
Date: Fri, 20 Apr 2001 15:06:47 -0400

I suggest that the following paragraphs be included in the transport
draft.  They contain recommendations for the size of private exponent
in the DH key exchange, and mention security problems related to
traffic analysis.

Greetings,
  Niels.

Implementation Notes:

To increase the speed of the key exchange, both client and server may
reduce the size of their private exponents. It should be at least
twice as long as the key material that is generated from the shared
secret.  For more details see the paper by van Oorschot and Wiener
[A].

[A]  P. C. van Oorschot and M. J. Wiener, On Diffie-Hellman key
     agreement with short exponents, In Advances in Cryptology -
     EUROCRYPT'96, LNCS 1070, Springer-Verlag, 1996, pp.332-343.

An adversary can listen to SSH network traffic to determine the length
of authentication passwords typed during login and interactive shell
sessions [B].  Using packet timing analysis, it is also possible to
infer the probability of letter combinations in the typed passwords
[C].  SSH servers and clients MAY send SSH_MSG_IGNORE messages to
mitigate the impact of traffic analysis.

[B] OpenWall Security Advisory, Passive Analysis of SSH (Secure
    Shell) Traffic,
    http://www.openwall.com/advisories/OW-003-ssh-traffic-analysis.txt

[C] Dawn Song, David Wagner and Xuqing Tian, Keystroke Analysis and
    SSH Timing Attacks, 10th USENIX Security Symposium, August 2001

---

From: Tom Holroyd <[email-masked]>
Date: Sat, 21 Apr 2001 15:50:10 +0900 (JST)

On Fri, 20 Apr 2001, Niels Provos wrote:

> sessions [B].

Of course SRP authentication fixes that...  The SRP shared secret can also
be used to trigger a key-reexchange, which makes shorter DH parameters
less of a problem.

Tom Wu tells me that Stanford should be issuing the all-clear on SRP any
day now...

Dr. Tom

---

From: Markus Friedl <[email-masked]>
Date: Sat, 21 Apr 2001 17:02:16 +0200

> be used to trigger a key-reexchange, which makes shorter DH parameters

i don't see how SRP makes traffic analysis harder.

could you please provide details.

-m

---

From: Tom Holroyd <[email-masked]>
Date: Mon, 23 Apr 2001 09:54:19 +0900 (JST)

> could you please provide details.

The SRP password is never sent over the network, only some random bignums
of known length, and some hashes, also of known length.  So even if you
can observe traffic you can't get the length of the password/phrase.

OTOH, if you ssh to host A, and then from host A ssh to host B, your
password will be sent over the (encrypted) link from your client to A, so
that may leak password length information.  That can be fixed by running
ssh from your client and either connecting directly to B, or if that's not
possible, forwarding the connection through A (instead of running ssh on
A).

Dr. Tom Holroyd
"I am, as I said, inspired by the biological phenomena in which
chemical forces are used in repetitious fashion to produce all
kinds of weird effects (one of which is the author)."
	-- Richard Feynman, _There's Plenty of Room at the Bottom_

---

From: Mika Kojo <[email-masked]>
Date: Mon, 23 Apr 2001 06:02:22 +0300

Tom, 

I suppose that the question should be

 Q: How could the leakage of information in interactive sessions be 
    made negligible?

If such an improvement exists then (interesting) traffic analysis
becomes impossible as a consequence.

My answer would currently be: there is no such (practical)
improvement. The only robust improvement that I know would require
non-negligible increase in traffic.

Naturally this suggests that the problem is not the protocol. Infact,
SRP is not a protocol fix---it fixes only those applications(*) that
are aware of this feature. Similar effect would be obtained by having
a specific password packet that holds the password in its entirety,
rather than sending it in pieces.

(*) I consider everything above the transportation layer as an
    "application" of the protocol. Sorry for abuse of terminology.

As you suggest it is possible by careful use and implementation of the
applications to make sure that important information is not leaked.

Mika Kojo
SSH Communications Security Corp

---

From: Markus Friedl <[email-masked]>
Date: Mon, 23 Apr 2001 08:31:28 +0200

> can observe traffic you can't get the length of the password/phrase.

this does not fork for 'interactive shell sessions', e.g. if i
login in and type 'su'. the authentication used in the ssh connection
is not relevant.

---

From: Tom Holroyd <[email-masked]>
Date: Mon, 23 Apr 2001 16:22:08 +0900 (JST)

> login in and type 'su'. the authentication used in the ssh connection

True (I believe I mentioned that in the part of my post you didn't quote).
So, a) don't do that, use ssh -l root, or b) is there any way to re-write
"su" so that it connects back to the ssh client machine to request
authentication?  Can su be rewritten to use the ssh-agent?  Do the ssh
protocols allow "sideband" control channels that could be opened from the
remote end?  I like a), plus setting "su" to fail for network users.  But
some of b) has interesting possibilities.

---

From: [email-masked] (Niels M�ller)
Date: 23 Apr 2001 11:29:07 +0200

Tom Holroyd <[email-masked]> writes:

> 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.

/Niels