Date: Tue, 28 Nov 2000 22:17:19 -0400 From: "Jeroen C. van Gelderen" <jeroen@vangelderen.org> To: Niels Provos <provos@citi.umich.edu> Cc: Kris Kennaway <kris@FreeBSD.ORG>, "Brian F. Feldman" <green@FreeBSD.ORG>, security@FreeBSD.ORG Subject: Re: OpenSSH 2.3.0 pre-upgrade Message-ID: <3A24672F.5758FBF4@vangelderen.org> References: <20001127145655.07C53207C1@citi.umich.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
Niels Provos wrote:
>
> In message <3A21954C.F9E9D25F@vangelderen.org>, "Jeroen C. van Gelderen" writes
> :
> >Or at a more basic level: Are cooked primes a problem in
> >this setting?[1] If not, you want to mention this as a
> >non-issue in the "Security Considerations" section. If
> >cooked primes are indeed a problem the protocol needs to
> >be enhanced to counter them. Either way, the draft needs
> >a couple of extra words IMHO.
>
> That is not an issue. You need to trust the server anyway. If you
> have any helpful wording that could be added to the draft, I will be
> more than happy to include it.
I'm still thinking about it, bear with me...
I was worried about cooked primes because it makes it easier
to compromise an sshd without it ever being noticed. Disabling
encryption or leaking information from the server are both
easy to detect with -say- tcpdump. Installing a cooked prime
OTOH is likely to go unnoticed forever as:
a. the protocol will seem to work correctly;
b. it's impossible (for all but the most trivial cases)
to look at just the prime and detect whether it is
cooked or not. (You need some assurance, see below.)
I thought that installing a cooked prime(s) is the kind of
thing that a mole in ones organisation (or a disgruntled
employee) would do without running the risk of ever getting
caught :-)
Depending on your attack model and protocol design goals it is
a vulnerability or a non-issue. If it's a non-issue I would
mention just that in the "security considerations" section:
"Cooked primes are deemed to be a non-issue, thanks." If it
is considered to be vulnerability it would need to be dealt
with in the protocol.
One way of doing so is to mandate that primes are generated
from a seed which is run trough a hash. Servers would send
the seed in addition to the prime. Clients could (if they
chose to do so) verify that the received seed indeed expands
to the prime the server sent:
byte SSH_MSG_KEX_DH_GEX_GROUP
string seed
mpint p, safe prime
mpint g, generator for subgroup in GF(p)
The seed could (should?) be optional. A paranoid client could
refuse those primes that are not accompanied by a seed.
Am I being dense, overcomplicated or overly paranoid?
(Yes, I am smoking crack, thanks...)
> >Anyway, my assumption that dh-group-exchange is non-standard
> >still holds as far as I can see so I'd still recommend not
> >enabling this feature by default for now.
>
> There are a couple of implementations besides OpenSSH that support it.
> Of course, you could still disable it, but you should think about it
> carefully.
Mea culpa, I really couldn't find any references to it but
I only searched for a couple of minutes. I still think it's
premature for our sshd do send out such packets given that
it doesn't really add to security at this point in time.
> >What steps have to taken to have this standardized? Is this
> >proposal being considered by the IETF secsh working group?
>
> We are working on it, it takes time though.
Red tape... I understand. Put it on openssh.com in the
meantime?
Cheers,
Jeroen
--
Jeroen C. van Gelderen - jeroen@vangelderen.org
"It is not utopian to work for a society without taxation;
it is utopian to think that the power to tax won't be abused
once it is granted." -- Murray N. Rothbard (1926-1995)
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3A24672F.5758FBF4>