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


To: Edward Lewis <lewis@tislabs.com>
Cc: keydist@cafax.se
From: Simon Josefsson <simon+keydist@josefsson.org>
Date: Thu, 10 Jan 2002 21:21:12 +0100
In-Reply-To: <v0313030eb8639902f9f4@[199.171.39.21]> (Edward Lewis's messageof "Thu, 10 Jan 2002 14:20:40 -0500")
Sender: owner-keydist@cafax.se
User-Agent: Gnus/5.090005 (Oort Gnus v0.05) Emacs/21.1.50(i686-pc-linux-gnu)
Subject: Re: Is this something to solve

Edward Lewis <lewis@tislabs.com> writes:

> I'd like to collect scenarios of things we would want to solve.  E.g.:
>
> ====
> In SSH, I have a host at my home institution named "beagle."  When I go to
> the IETF, I carry beagle's SSH host key configured in my client.  But while
> I am away, beagle crashes and is down for some time.  But since my home
> institution uses NIS, I could log into "retriever" with the same name and
> password and still get to my home directory.  The problem is that I don't
> have retriever's SSH host key configured because I didn't cover my bases in
> the event of a crash on beagle.
>
> How do I make SSH's "trust" robust in the light of beagle's crash?
> ====
>
> Does this sound like a rational example?

How about a more everyday scenarios?  I'm thinking about the
following:

===
A campus runs SSH and either DNSSEC or TSIG (clients configured with
DNSSEC key or TSIG key) to protect from people that plug in their
laptops and tries to gain unauthorized access using sniffers, spoofing
or whatever.  When contacting SSH hosts the first time, instead of
getting

The authenticity of host 'cc (195.42.214.244)' can't be established.
RSA key fingerprint is 6b:9a:84:7b:1c:8f:a2:7c:51:e9:2a:a4:04:86:6d:b2.
Are you sure you want to continue connecting (yes/no)? 

which basicly asks the user if she wants to shoot herself in the foot
or not (I'm assuming not even 5% checks the fingerprint before typing
'yes' here, which probably is optimistic), the SSH host key is
retrieved from DNS, verified using the DNSSEC or TSIG, and you get
this question instead:

The host key of 'cc (195.42.214.244)' authenticated by DNSSEC root 'kth.se'.
RSA key fingerprint is 6b:9a:84:7b:1c:8f:a2:7c:51:e9:2a:a4:04:86:6d:b2.
Are you sure you want to continue connecting (yes/no)? 

which is alot better.  Users or administrators might even want to
configure their SSH client to always trust SSH host keys which can be
chained back to a certain DNSSEC root (e.g., the university DNSSEC
key).
===


Home | Date list | Subject list