From owner-ietf-ssh@clinet.fi Thu Apr 8 21:43:43 1999 Return-Path: Received: from ssh.fi (muuri.ssh.fi [192.168.2.254]) by torni.ssh.fi (8.9.1/8.9.1/EPIPE-1.13) with ESMTP id VAA11848; Thu, 8 Apr 1999 21:43:43 +0300 (EET DST) Received: from lohi.clinet.fi (majordom@lohi.clinet.fi [194.100.0.7]) by ssh.fi (8.9.1/8.9.1/EPIPE-1.15) with ESMTP id VAA04361; Thu, 8 Apr 1999 21:43:43 +0300 (EEST) Received: (from majordom@localhost) by lohi.clinet.fi (8.9.1/8.9.0) id VAA03797 for ietf-ssh-outgoing; Thu, 8 Apr 1999 21:43:32 +0300 (EEST) X-Authentication-Warning: lohi.clinet.fi: majordom set sender to owner-ietf-ssh@clinet.fi using -f Received: from portofix.ida.liu.se (portofix.ida.liu.se [130.236.177.25]) by lohi.clinet.fi (8.9.1/8.9.0) with ESMTP id VAA03791 for ; Thu, 8 Apr 1999 21:43:27 +0300 (EEST) Received: from mir3 (mir3.ida.liu.se [130.236.176.33]) by portofix.ida.liu.se (8.8.8/8.8.8) with ESMTP id UAA22584 for ; Thu, 8 Apr 1999 20:39:02 +0200 (MET DST) Received: by mir3 (8.8.8+Sun/ida.slave-V1.0b6d6S2) id UAA29346; Thu, 8 Apr 1999 20:39:02 +0200 (MET DST) Date: Thu, 8 Apr 1999 20:39:02 +0200 (MET DST) Message-Id: <199904081839.UAA29346@mir3> To: ietf-ssh@clinet.fi From: Nahid Shahmehri Subject: Reminder: 1999 WET-ICE Enterprise Security Workshop MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Content-Length: 713 Lines: 34 Dear Colleague, This mail is to remind you of the upcomming, extended deadline for submissions to the Fourth International Workshop on Enterprise Security, to be held as a part of IEEE WET-ICE '99 on June 16-18, 1999 at Stanford University, California, USA. Extended deadline for paper submissions is April 12, 1999. Electronic submissions are accepted. Please see the workshop web page http://www.ida.liu.se/conferences/WETICE/SECWK/ for the full Call For Papers and further details. Please accept my apologies if you receive this message more than once. Sincerely, Nahid Shahmehri Program Co-Chair Dept. of Computer and Information Science Linköping University SE-581 83 Linköping Sweden From owner-ietf-ssh@clinet.fi Fri Apr 9 23:59:23 1999 Return-Path: Received: from ssh.fi (muuri.ssh.fi [192.168.2.254]) by torni.ssh.fi (8.9.1/8.9.1/EPIPE-1.13) with ESMTP id XAA28129; Fri, 9 Apr 1999 23:58:52 +0300 (EET DST) Received: from lohi.clinet.fi (majordom@lohi.clinet.fi [194.100.0.7]) by ssh.fi (8.9.1/8.9.1/EPIPE-1.15) with ESMTP id XAA15648; Fri, 9 Apr 1999 23:58:52 +0300 (EEST) Received: (from majordom@localhost) by lohi.clinet.fi (8.9.1/8.9.0) id XAA23626 for ietf-ssh-outgoing; Fri, 9 Apr 1999 23:59:07 +0300 (EEST) X-Authentication-Warning: lohi.clinet.fi: majordom set sender to owner-ietf-ssh@clinet.fi using -f Received: from muncher.math.uic.edu (muncher.math.uic.edu [131.193.178.181]) by lohi.clinet.fi (8.9.1/8.9.0) with SMTP id XAA23589 for ; Fri, 9 Apr 1999 23:58:49 +0300 (EEST) Received: (qmail 3559 invoked by uid 1001); 9 Apr 1999 20:53:56 -0000 Date: 9 Apr 1999 20:53:56 -0000 Message-ID: <19990409205356.26002.qmail@cr.yp.to> From: "D. J. Bernstein" To: ietf-ssh@clinet.fi Subject: faster packet authentication Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Content-Length: 533 Lines: 18 I have a secure MAC that's faster than HMAC-MD5 for all input sizes on all processors that I've tried. It could be used in ssh in combination with 3DES; it is then provably as difficult to break as 3DES. For the alpha release of the code see http://pobox.com/~djb/hash127.html A brief description of the algorithm appears at http://pobox.com/~djb/papers/hash127-abs.dvi Please send any questions or comments to the hash127 mailing list. To subscribe, send an empty message to hash127-subscribe@list.cr.yp.to ---Dan From owner-ietf-ssh@clinet.fi Tue Apr 13 08:56:05 1999 Return-Path: Received: from ssh.fi (muuri.ssh.fi [192.168.2.254]) by torni.ssh.fi (8.9.1/8.9.1/EPIPE-1.13) with ESMTP id IAA11991; Tue, 13 Apr 1999 08:56:04 +0300 (EET DST) Received: from lohi.clinet.fi (majordom@lohi.clinet.fi [194.100.0.7]) by ssh.fi (8.9.1/8.9.1/EPIPE-1.15) with ESMTP id IAA10060; Tue, 13 Apr 1999 08:56:04 +0300 (EEST) Received: (from majordom@localhost) by lohi.clinet.fi (8.9.1/8.9.0) id HAA09495 for ietf-ssh-outgoing; Tue, 13 Apr 1999 07:51:51 +0300 (EEST) X-Authentication-Warning: lohi.clinet.fi: majordom set sender to owner-ietf-ssh@clinet.fi using -f Received: from mail.vandyke.com (mail.vandyke.com [204.134.9.1]) by lohi.clinet.fi (8.9.1/8.9.0) with ESMTP id HAA09445 for ; Tue, 13 Apr 1999 07:51:23 +0300 (EEST) Received: from boa ([192.168.0.31]) by mail.vandyke.com (Netscape Messaging Server 3.01) with SMTP id 285 for ; Mon, 12 Apr 1999 22:50:59 -0600 Message-ID: <003e01be8568$05229cc0$1f00a8c0@boa.vandyke.com> From: "Jeff P. Van Dyke" To: Subject: draft-ietf-secsh-transport-05.txt Date: Mon, 12 Apr 1999 22:41:43 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Content-Length: 1835 Lines: 61 The following two issues were originally posted on 1/26/99 by Joseph Galbraith based on draft-ietf-secsh-transport-04.txt. The new draft doesn't seem to clarify these issues. Can anyone shed some light on these two issues? Thank you. Jeff P. Van Dyke jpv@vandyke.com Van Dyke Technologies, Inc. 1. In section 6 it is unclear to me whether length fields should be included in the hash used to generate the session id during key exchange. When describing Diffie-Hellman Key Exchange, the draft states in item 2 that 'H = hash( V_C || V_S || I_C || I_S || K_S || e || f || K' When describing SSH_MSG_KEXDH_REPLY, it states: 'The hash H is computed as the HASH hash of the concatenation of the following: string V_C string V_S string I_C string I_S string K_S mpint e mpint f mpint K which seems to indicate that a length field should be included. Is this correct? Should each of the V_C, V_S, ..., K fields be inserted into the hash as a uint32 followed by the actual data? 2. In section 5, it is also unclear whether a length field for K should be included when hashing during key derivation. The draft states (for example): 'Encryption keys MUST be computed as HASH of a known value and K as follows: o Initial IV client to server: HASH( K || "A" || session_id ) o ...' should K be inserted into the hash as a mpint or simply the raw data? (If it is the raw data, how should leading zeros be treated?) Also, what about the session_id? Again, should it be inserted with a length field or without? It seems clearer to me that session id shouldn't have a length field... it isn't an mpint, and isn't described as an mpint any place else in the draft. From owner-ietf-ssh@clinet.fi Tue Apr 13 08:56:08 1999 Return-Path: Received: from ssh.fi (muuri.ssh.fi [192.168.2.254]) by torni.ssh.fi (8.9.1/8.9.1/EPIPE-1.13) with ESMTP id IAA08725; Tue, 13 Apr 1999 08:56:03 +0300 (EET DST) Received: from lohi.clinet.fi (majordom@lohi.clinet.fi [194.100.0.7]) by ssh.fi (8.9.1/8.9.1/EPIPE-1.15) with ESMTP id IAA10055; Tue, 13 Apr 1999 08:56:03 +0300 (EEST) Received: (from majordom@localhost) by lohi.clinet.fi (8.9.1/8.9.0) id HAA10038 for ietf-ssh-outgoing; Tue, 13 Apr 1999 07:58:08 +0300 (EEST) X-Authentication-Warning: lohi.clinet.fi: majordom set sender to owner-ietf-ssh@clinet.fi using -f Received: from mail.vandyke.com (mail.vandyke.com [204.134.9.1]) by lohi.clinet.fi (8.9.1/8.9.0) with ESMTP id HAA10010 for ; Tue, 13 Apr 1999 07:57:32 +0300 (EEST) Received: from boa ([192.168.0.31]) by mail.vandyke.com (Netscape Messaging Server 3.01) with SMTP id 360; Mon, 12 Apr 1999 22:57:36 -0600 Message-ID: <005801be8568$f15dc560$1f00a8c0@boa.vandyke.com> From: "Jeff P. Van Dyke" To: "J.H.M. Dassen" , "=?iso-8859-1?Q?Niels_M=F6ller?=" Cc: Subject: Re: Ssh bugreport & ssh2 signature support Date: Mon, 12 Apr 1999 22:48:42 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Content-Length: 2017 Lines: 66 What motivated this change? The old format seems to be unambiguous, where the new format will require some additional documentation. Was there a problem with the old format? Is there some proposed language for documenting the new format? Jeff P. Van Dyke jpv@vandyke.com Van Dyke Technologies, Inc. "J.H.M. Dassen" writes: > On Tue, Feb 02, 1999 at 22:14:36 +0100, Balazs Scheidler wrote: > > In the meantime I think I will write support for ssh2-style signatures and > > make it a configure-time option. > > The updated IETF secsh drafts have changes in the transport layer. It would > be interesting to know if the draft now prescribes SSH2's behaviour. The new definition is uint32 length string "ssh-dss" string dss_signature_blob This is incompatible with *both* the old draft and the current ssh2 behaviour. Furthermore, the format of "dss_signature_blob" is not described at all in the new draft, at least I have not been able to find it anywhere. *sigh* Any ideas about how to interpret it? My guess is that we have 20 octets representing r and 20 octets representing s. But that is just a guess, nothing more. I would be most grateful if someone could enligten me as to what the new signature format (i.e. the signature blod) really is. And of course, I'm also curious about why the format in the previous draft (which was simple, unambigously described, and easy to implement) was abandoned. For reference, the old format was uint32 length string "ssh-dss" mpint r mpint s The format used by current ssh2 versions, as far as I know, is something like uint32 length string r string s where the strings are expected to always have length 20 (160 bits), and where the strings are interpreted as non-negative numbers. (i.e. the strings may have leading zero octets, if that is necessary to make them 20 octets long, and the most significant bit can be 1 without implying a negative sign). Regards, /Niels Möller From owner-ietf-ssh@clinet.fi Tue Apr 13 09:33:03 1999 Return-Path: Received: from ssh.fi (muuri.ssh.fi [192.168.2.254]) by torni.ssh.fi (8.9.1/8.9.1/EPIPE-1.13) with ESMTP id JAA16752; Tue, 13 Apr 1999 09:33:03 +0300 (EET DST) Received: from lohi.clinet.fi (majordom@lohi.clinet.fi [194.100.0.7]) by ssh.fi (8.9.1/8.9.1/EPIPE-1.15) with ESMTP id JAA10391; Tue, 13 Apr 1999 09:33:02 +0300 (EEST) Received: (from majordom@localhost) by lohi.clinet.fi (8.9.1/8.9.0) id JAA24479 for ietf-ssh-outgoing; Tue, 13 Apr 1999 09:35:48 +0300 (EEST) X-Authentication-Warning: lohi.clinet.fi: majordom set sender to owner-ietf-ssh@clinet.fi using -f Received: from samantha.lysator.liu.se (root@samantha.lysator.liu.se [130.236.254.202]) by lohi.clinet.fi (8.9.1/8.9.0) with ESMTP id JAA24466 for ; Tue, 13 Apr 1999 09:35:45 +0300 (EEST) Received: from sanna.lysator.liu.se (nisse@sanna.lysator.liu.se [130.236.254.206]) by samantha.lysator.liu.se (8.8.7/8.8.7) with ESMTP id IAA26038; Tue, 13 Apr 1999 08:30:39 +0200 (MET DST) Received: (from nisse@localhost) by sanna.lysator.liu.se (8.8.8/8.8.7) id IAA08479; Tue, 13 Apr 1999 08:30:35 +0200 (MET DST) To: "Jeff P. Van Dyke" Cc: "J.H.M. Dassen" , =?ISO-8859-1?Q?=22Niels_?= =?ISO-8859-1?Q?M=F6ller=22?= , Subject: Re: Ssh bugreport & ssh2 signature support References: <005801be8568$f15dc560$1f00a8c0@boa.vandyke.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit From: nisse@lysator.liu.se (Niels =?ISO-8859-1?Q?M=F6ller?=) Date: 13 Apr 1999 08:30:34 +0200 In-Reply-To: "Jeff P. Van Dyke"'s message of "Mon, 12 Apr 1999 22:48:42 -0600" Message-ID: X-Mailer: Gnus v5.4.59/Emacs 19.34 Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Content-Length: 3108 Lines: 88 "Jeff P. Van Dyke" writes: > What motivated this change? The old format seems to be unambiguous, > where the new format will require some additional documentation. I'm also a little annoyed with this change. I really hope that it is a mistake that can be rectified; although I don't know what to do about it (I haven't seen anyone more involved in the ietf process than me even comment the issue). *sigh* As for documentation of the new format, someone at ssh/datafellows (sorry, I don't remember who right now) gave me some hints about how to interpret the new format. The "signature blob" should be 2k octets, for some k. The first k octets are r, encoded as an *unsigned* number in network byte order, and the rest is s, also unsigned, in network byte order. As this encoding is very different from the format for numbers specified in section 4 of the architecture spec, all implementations have to implement yet another set of bignum encoding rules. > Was there a problem with the old format? Not that I know of. > Is there some proposed language for documenting the new format? Not that I know of. I guess you ask this because the new format doesn't fit at all with the types and presentation language used in the spec. Regards, /Niels > "J.H.M. Dassen" writes: > > > On Tue, Feb 02, 1999 at 22:14:36 +0100, Balazs Scheidler wrote: > > > In the meantime I think I will write support for ssh2-style signatures and > > > make it a configure-time option. > > > > The updated IETF secsh drafts have changes in the transport layer. It would > > be interesting to know if the draft now prescribes SSH2's behaviour. I wrote, some time ago: > The new definition is > > uint32 length > string "ssh-dss" > string dss_signature_blob > > This is incompatible with *both* the old draft and the current ssh2 > behaviour. Furthermore, the format of "dss_signature_blob" is not > described at all in the new draft, at least I have not been able to > find it anywhere. *sigh* > > Any ideas about how to interpret it? My guess is that we have 20 > octets representing r and 20 octets representing s. But that is just a > guess, nothing more. > > I would be most grateful if someone could enligten me as to what the > new signature format (i.e. the signature blod) really is. And of > course, I'm also curious about why the format in the previous draft > (which was simple, unambigously described, and easy to implement) was > abandoned. > > For reference, the old format was > > uint32 length > string "ssh-dss" > mpint r > mpint s > > The format used by current ssh2 versions, as far as I know, is > something like > > uint32 length > string r > string s > > where the strings are expected to always have length 20 (160 bits), > and where the strings are interpreted as non-negative numbers. (i.e. > the strings may have leading zero octets, if that is necessary to make > them 20 octets long, and the most significant bit can be 1 without > implying a negative sign). > > Regards, > /Niels Möller From owner-ietf-ssh@clinet.fi Thu Apr 15 04:27:52 1999 Return-Path: Received: from ssh.fi (muuri.ssh.fi [192.168.2.254]) by torni.ssh.fi (8.9.1/8.9.1/EPIPE-1.13) with ESMTP id EAA24294; Thu, 15 Apr 1999 04:27:52 +0300 (EET DST) Received: from lohi.clinet.fi (majordom@lohi.clinet.fi [194.100.0.7]) by ssh.fi (8.9.1/8.9.1/EPIPE-1.15) with ESMTP id EAA00693; Thu, 15 Apr 1999 04:27:51 +0300 (EEST) Received: (from majordom@localhost) by lohi.clinet.fi (8.9.1/8.9.0) id EAA13634 for ietf-ssh-outgoing; Thu, 15 Apr 1999 04:27:21 +0300 (EEST) X-Authentication-Warning: lohi.clinet.fi: majordom set sender to owner-ietf-ssh@clinet.fi using -f Received: from THOR.INNOSOFT.COM (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66]) by lohi.clinet.fi (8.9.1/8.9.0) with ESMTP id EAA13630 for ; Thu, 15 Apr 1999 04:27:19 +0300 (EEST) Received: from elvira.innosoft.com ([192.160.253.135]) by INNOSOFT.COM (PMDF V5.2-32 #30494) with ESMTPS id <01JA16ZM5S408WWEBB@INNOSOFT.COM> for ietf-ssh@clinet.fi; Wed, 14 Apr 1999 18:21:01 PDT Received: from CONVERSION-DAEMON by elvira.innosoft.com (PMDF V5.2-32 #13579) id <0FA700901IC1AG@elvira.innosoft.com> for ietf-ssh@clinet.fi; Wed, 14 Apr 1999 18:19:13 -0700 (PDT) Received: from elwood.innosoft.com (ELWOOD.INNOSOFT.COM [192.160.253.235]) by elvira.innosoft.com (PMDF V5.2-32 #13579) with ESMTP id <0FA70076MIC0OM@elvira.innosoft.com>; Wed, 14 Apr 1999 18:19:12 -0700 (PDT) Date: Wed, 14 Apr 1999 18:20:32 -0700 (PDT) From: Chris Newman Subject: Re: Ssh bugreport & ssh2 signature support In-reply-to: Originator-info: login-id=chris; server=THOR.INNOSOFT.COM To: Niels =?ISO-8859-1?Q?M=F6ller?= Cc: IETF Secure Shell list Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=iso-8859-1 Content-transfer-encoding: 8BIT Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Content-Length: 869 Lines: 19 On Tue, 13 Apr 1999, Niels Möller wrote: > I'm also a little annoyed with this change. I really hope that it is a > mistake that can be rectified; although I don't know what to do about > it (I haven't seen anyone more involved in the ietf process than me > even comment the issue). *sigh* I've been lurking for a while, and I recall a discussion where it was observed that the old format was not what the SSH-v2 code and most DSA libraries implemented. The fact that the new format isn't adequately specified would be sufficient to block the document moving forward if it is ever reaches IETF last call. Personally, I think the new format is aestheticly less satisfying than the old format but I'm trying to avoid quibbling over syntax as it's easier to write the code to convert syntax than it is to try to change someone's position on a syntax issue. - Chris From owner-ietf-ssh@clinet.fi Wed Apr 21 12:54:40 1999 Return-Path: Received: from ssh.fi (muuri.ssh.fi [192.168.2.254]) by torni.ssh.fi (8.9.1/8.9.1/EPIPE-1.13) with ESMTP id MAA25903; Wed, 21 Apr 1999 12:54:36 +0300 (EET DST) Received: from lohi.clinet.fi (majordom@lohi.clinet.fi [194.100.0.7]) by ssh.fi (8.9.1/8.9.1/EPIPE-1.15) with ESMTP id MAA17346; Wed, 21 Apr 1999 12:54:36 +0300 (EEST) Received: (from majordom@localhost) by lohi.clinet.fi (8.9.1/8.9.0) id MAA08051 for ietf-ssh-outgoing; Wed, 21 Apr 1999 12:57:37 +0300 (EEST) X-Authentication-Warning: lohi.clinet.fi: majordom set sender to owner-ietf-ssh@clinet.fi using -f Received: from asgard.tky.hut.fi (asgard.tky.hut.fi [130.233.20.115]) by lohi.clinet.fi (8.9.1/8.9.0) with ESMTP id MAA08042 for ; Wed, 21 Apr 1999 12:57:33 +0300 (EEST) Received: (from sjl@localhost) by asgard.tky.hut.fi (8.9.2/8.9.2) id OAA27391; Wed, 21 Apr 1999 14:45:14 +0300 (EEST) From: Sami Lehtinen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 21 Apr 1999 14:45:13 +0300 (EEST) To: "Jeff P. Van Dyke" Cc: Subject: draft-ietf-secsh-transport-05.txt In-Reply-To: <003e01be8568$05229cc0$1f00a8c0@boa.vandyke.com> References: <003e01be8568$05229cc0$1f00a8c0@boa.vandyke.com> X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Message-ID: <14109.45995.581131.654093@asgard.tky.hut.fi> Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Content-Length: 2153 Lines: 57 Jeff P. Van Dyke writes: : 1. In section 6 it is unclear to me whether : length fields should be included in the hash : used to generate the session id during key exchange. : : When describing Diffie-Hellman Key Exchange, the draft : states in item 2 that 'H = hash( V_C || V_S || I_C || : I_S || K_S || e || f || K' : : When describing SSH_MSG_KEXDH_REPLY, it states: : 'The hash H is computed as the HASH hash of the : concatenation of the following: : : string V_C : string V_S : string I_C : string I_S : string K_S : mpint e : mpint f : mpint K : : which seems to indicate that a length field should be included. : : Is this correct? Should each of the V_C, V_S, ..., K fields : be inserted into the hash as a uint32 followed by the actual : data? Yes. They are encoded as stated under SSH_MSG_KEXDH_REPLY. : 2. In section 5, it is also unclear whether a length field for : K should be included when hashing during key derivation. : The draft states (for example): : : 'Encryption keys MUST be computed as HASH of a known value : and K as follows: : : o Initial IV client to server: HASH( K || "A" || session_id ) : o ...' : : should K be inserted into the hash as a mpint or simply : the raw data? (If it is the raw data, how should leading : zeros be treated?) : : Also, what about the session_id? Again, should it be inserted : with a length field or without? It seems clearer to me that : session id shouldn't have a length field... it isn't an mpint, : and isn't described as an mpint any place else in the draft. The K is encoded as mpint. "A" is encoded as byte and session_id are encoded as raw data (session_id's length depend's on the hash algorithm used) -- [sjl@ssh.fi -- Sami J. Lehtinen -- sjl@iki.fi] [work:+358 9 43543214][gsm:+358 50 5170 258][http://www.iki.fi/~sjl] [SSH Communications Security Ltd. http://www.ssh.fi/]