From owner-freebsd-security Sun Jan 2 14:12: 3 2000 Delivered-To: freebsd-security@freebsd.org Received: from folly.informatik.uni-erlangen.de (nbgdi3-145-253-131-130.arcor-ip.net [145.253.131.130]) by hub.freebsd.org (Postfix) with ESMTP id 8202A14D24; Sun, 2 Jan 2000 14:11:59 -0800 (PST) (envelope-from markus.friedl@informatik.uni-erlangen.de) Received: by folly.informatik.uni-erlangen.de (Postfix, from userid 31451) id B383AC00; Sun, 2 Jan 2000 23:11:47 +0100 (CET) Date: Sun, 2 Jan 2000 23:11:46 +0100 From: Markus Friedl To: Brian Fundakowski Feldman Cc: David Rankin , "Michael H. Warfield" , Dug Song , security@FreeBSD.org, openssh-unix-dev@mindrot.org, niels@openbsd.org Subject: Re: OpenSSH protocol 1.6 proposal Message-ID: <20000102231146.C10118@folly.informatik.uni-erlangen.de> References: <20000102151208.A21548@folly.informatik.uni-erlangen.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.7i In-Reply-To: Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sun, Jan 02, 2000 at 02:46:49PM -0500, Brian Fundakowski Feldman wrote: > My concern here is, how much does it convolute the code? I believe > that it's probably not as useful to make the old SSH 1.X protocol > as infinitely more secure as it is useful to make OpenSSH support > the 2.X protocol. i don't think the patch 'convolutes' the code, it just replaces the CRC with a real authenticating MAC, hmac-sha1 in this case. > I really don't see why we should need sequence numbers if we do > a continuous SHA-1 hash of the entire stream. Are you proposing > just one use per SHA_CTX, each packet having its own independent > hash and sequence number? yes, each packet has an independent MAC that depends on the current packet and current packet number. this number is not transmitted. i don't know a protocol that uses a continuous hash for authentication. both ipsec and ssh2 use hmacs. usage of hmac is common practice for authentication (hmac-sha1 is required for SSH2). > > session_id := MD5 (host_key_n |session_key_n| > > supported_ciphers|supported_authentications| > > client_flags|server_flags| > > client_version_string|server_version_string| > > cookie); > > That does sound better, although I wouldn't know ow much better than > before. it _authenticates_ the cleartext parameters that are transmitted before the session key can be used for authentication/encrytion. -markus To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message