From owner-ietf-ssh@clinet.fi Wed Oct 28 21:06:17 1998 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 VAA15283; Wed, 28 Oct 1998 21:06:17 +0200 (EET) 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 VAA26738; Wed, 28 Oct 1998 21:06:16 +0200 (EET) Received: (from majordom@localhost) by lohi.clinet.fi (8.9.1/8.9.0) id UAA06785 for ietf-ssh-outgoing; Wed, 28 Oct 1998 20:54:52 +0200 (EET) X-Authentication-Warning: lohi.clinet.fi: majordom set sender to owner-ietf-ssh@clinet.fi using -f Received: from ratbert.iconnet.net (ratbert.iconnet.net [209.3.247.87]) by lohi.clinet.fi (8.9.1/8.9.0) with ESMTP id UAA06768 for ; Wed, 28 Oct 1998 20:54:49 +0200 (EET) Received: from iconnet.net (localhost [127.0.0.1]) by ratbert.iconnet.net (8.9.1/8.9.1) with ESMTP id NAA24948 for ; Wed, 28 Oct 1998 13:53:18 -0500 (EST) Message-Id: <199810281853.NAA24948@ratbert.iconnet.net> X-Mailer: exmh version 2.0.2 2/24/98 To: ietf-ssh@clinet.fi Subject: ssh2 protocol deficiency Date: Wed, 28 Oct 1998 13:53:18 -0500 From: Frank Cusack Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Content-Length: 2848 Lines: 95 Hi, Since I can't find any archives of this list, I'll just go ahead and pose my question/suggestion. When using password auth, it might not be known ahead of time that there will only be one piece of information exchanged (the password). eg, a password change request (although this is in the draft). Instead of SSH_MSG_USERAUTH_PASSWD_CHANGEREQ, which is far too specific, and does not define the prompt too well, I suggest the following (cribbed from Kerberos SAM, which is where I am having the problem): "Normally, the server responds to [SSH_MSG_USERAUTH_REQUEST] with success or failure. However, the server MAY also respond with SSH_MSG_USERAUTH_PASSWD_CHANGEREQ." my change: "... respond with SSH_MSG_USERAUTH_PASSWD_INFO_REQ. byte SSH_MSG_USERAUTH_PASSWD_INFO_REQ string prompt (ISO-10646 UTF-8) string language tag (as defined in RFC 1766) boolean echo In this case, the software client SHOULD request additional information from the user, using the prompt given, and echoing the user's response if echo is TRUE, or preventing the user's response from echoing if echo is FALSE. The client SHOULD then send a new request using the following message. byte SSH_MSG_USERAUTH_PASSWD_INFO_RESPONSE string response The server must reply to the response message with SSM_MSG_USERAUTH_SUCCESS, SSH_MSG_USERAUTH_FAILURE, or another SSH_MSG_USERAUTH_PASSWD_INFO_REQ. The meaning of these is as follows: SSH_MSG_USERAUTH_SUCCESS Authentication has been successfully completed. SSH_MSG_USERAUTH_FAILURE Authentication failed. SSH_MSG_USERAUTH_PASSWD_INFO_REQ More information is needed from the user. The following method-specific message numbers are used by the password authentication method. #define SSH_MSG_USERAUTH_PASSWD_INFO_REQ 60 #define SSH_MSG_USERAUTH_PASSWD_INFO_RESPONSE 61 " A password change request would then go like: C: SSH_MSG_USERAUTH_REQUEST C: ... (password sent with request) S: SSH_MSG_USERAUTH_PASSWD_INFO_REQ S: "Password for expired.\nEnter the new password: " S: FALSE C: (prompt user for new password ONCE) C: SSH_MSG_USERAUTH_PASSWD_INFO_RESPONSE C: "" S: SSH_MSG_USERAUTH_PASSWD_INFO_REQ S: "Enter it again: " S: FALSE C: (prompt user again) C: SSH_MSG_USERAUTH_PASSWD_INFO_RESPONSE C: "" ************** This method I believe is much stronger than the PASSWD_CHANGEREQ method, since ssh should not necessarily have (or need to have) any intrinsic notion of how passwords are managed or that they may need to be changed. Password authentication may be backed by PAM or another service and ssh may not even have that type of information available. I have a second issue regarding kerberos authentication, but I need to do more research on it before bringing it up here. ~frank From owner-ietf-ssh@clinet.fi Thu Oct 29 02:04:03 1998 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 CAA15626; Thu, 29 Oct 1998 02:04:03 +0200 (EET) 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 CAA27589; Thu, 29 Oct 1998 02:04:03 +0200 (EET) Received: (from majordom@localhost) by lohi.clinet.fi (8.9.1/8.9.0) id CAA05884 for ietf-ssh-outgoing; Thu, 29 Oct 1998 02:00:40 +0200 (EET) X-Authentication-Warning: lohi.clinet.fi: majordom set sender to owner-ietf-ssh@clinet.fi using -f Received: from ratbert.iconnet.net (ratbert.iconnet.net [209.3.247.87]) by lohi.clinet.fi (8.9.1/8.9.0) with ESMTP id CAA05868 for ; Thu, 29 Oct 1998 02:00:28 +0200 (EET) Received: from iconnet.net (localhost [127.0.0.1]) by ratbert.iconnet.net (8.9.1/8.9.1) with ESMTP id SAA26142 for ; Wed, 28 Oct 1998 18:58:51 -0500 (EST) Message-Id: <199810282358.SAA26142@ratbert.iconnet.net> X-Mailer: exmh version 2.0.2 2/24/98 To: ietf-ssh@clinet.fi Subject: Re: ssh2 protocol deficiency In-reply-to: Your message of "Wed, 28 Oct 1998 13:53:18 EST." <199810281853.NAA24948@ratbert.iconnet.net> Date: Wed, 28 Oct 1998 18:58:51 -0500 From: Frank Cusack Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Content-Length: 2212 Lines: 81 I'd like to modify this: In message <199810281853.NAA24948@ratbert.iconnet.net>, Frank Cusack writes: > my change: > > "... respond with SSH_MSG_USERAUTH_PASSWD_INFO_REQ. > > byte SSH_MSG_USERAUTH_PASSWD_INFO_REQ > string prompt (ISO-10646 UTF-8) > string language tag (as defined in RFC 1766) > boolean echo > byte SSH_MSG_USERAUTH_PASSWD_INFO_REQ boolean banner_present string banner (ISO-10646 UTF-8) int num_prompts string prompt[0] boolean echo[0] ... string prompt[n] boolean echo[n] string language tag (as defined in RFC 1766) b/c gui clients will find it useful to display multiple prompts in the same window (eg password change). If banner_present is TRUE, the banner is present in the message, otherwise it is not. > In this case, the software client SHOULD request additional information > from the user, using the prompt given, and echoing the user's response > if echo is TRUE, or preventing the user's response from echoing if > echo is FALSE. > > The client SHOULD then send a new request using the following message. > > byte SSH_MSG_USERAUTH_PASSWD_INFO_RESPONSE > string response > > The server must reply to the response message with > SSM_MSG_USERAUTH_SUCCESS, SSH_MSG_USERAUTH_FAILURE, or another > SSH_MSG_USERAUTH_PASSWD_INFO_REQ. > > The meaning of these is as follows: > > SSH_MSG_USERAUTH_SUCCESS > Authentication has been successfully completed. > > SSH_MSG_USERAUTH_FAILURE > Authentication failed. > > SSH_MSG_USERAUTH_PASSWD_INFO_REQ > More information is needed from the user. > > The following method-specific message numbers are used by the password > authentication method. > > #define SSH_MSG_USERAUTH_PASSWD_INFO_REQ 60 > #define SSH_MSG_USERAUTH_PASSWD_INFO_RESPONSE 61 > > " > > A password change request would then go like: > > C: SSH_MSG_USERAUTH_REQUEST > C: ... (password sent with request) [...] S: SSH_MSG_USERAUTH_PASSWD_INFO_REQ S: TRUE (banner_present) S: "Your password has expired." S: 2 S: "Enter a new password: " S: FALSE (no echo) S: "Enter it again: " S: FALSE (no echo) S: (language tag) ~frank From owner-ietf-ssh@clinet.fi Thu Oct 29 11:18:01 1998 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 LAA02474; Thu, 29 Oct 1998 11:18:01 +0200 (EET) 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 LAA01246; Thu, 29 Oct 1998 11:18:00 +0200 (EET) Received: (from majordom@localhost) by lohi.clinet.fi (8.9.1/8.9.0) id LAA26788 for ietf-ssh-outgoing; Thu, 29 Oct 1998 11:12:42 +0200 (EET) X-Authentication-Warning: lohi.clinet.fi: majordom set sender to owner-ietf-ssh@clinet.fi using -f Received: from proxyu.oz.is (proxyu.oz.is [193.4.211.81]) by lohi.clinet.fi (8.9.1/8.9.0) with ESMTP id LAA26782 for ; Thu, 29 Oct 1998 11:12:39 +0200 (EET) Received: from undo.com (pc-sigurasg.intranet.oz.is [172.22.1.156]) by proxyu.oz.is (2.5 Build 2640 (Berkeley 8.8.6)/8.8.4) with ESMTP id JAA08785; Thu, 29 Oct 1998 09:12:06 GMT Message-ID: <36383118.CBEB606E@undo.com> Date: Thu, 29 Oct 1998 09:10:48 +0000 From: Sigurdur Asgeirsson X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: ietf-ssh@clinet.fi Subject: Two ambiguities in transport protocol spec Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Content-Length: 2831 Lines: 52 1. The draft document "draft-ietf-secsh-transport-04.txt" section 5, "Key Exchange" contains the following text: "Each side MAY guess which algorithm the other side is using, and MAY send an initial key exchange packet according to the algorithm if appropriate for the preferred method. If all algorithms were guessed right, the optimistically sent packet MUST be handled as the first key exchange packet. However, if the guess was wrong, and a packet was optimistically sent by one or both parties, such packets MUST be ignored (even if the error in the guess would not affect the contents of the initial packet(s)), and the appropriate side MUST send the correct initial packet." The bit that goes "If all algorithms were guessed right" is what I have trouble with. It seem to me that only the key exchange algorithm and the server host key algorithm affect the key exchange, and the SSH unix sources indeed make and verify a guess based on those two only. The text should probably go like: "Each side MAY guess which key exchange algorithm and server key algorithm the other side is using, and MAY send an initial key exchange packet according to the guessed algorithms if appropriate. If both algorithms were guessed right, the optimistically sent packet MUST be handled as the first key exchange packet. However, if the guess was wrong, and a packet was optimistically sent by one or both parties, such packets MUST be ignored (even if the error in the guess would not affect the contents of the initial packet(s)), and the appropriate side MUST send the correct initial packet." 2. The draft document "draft-ietf-secsh-transport-04.txt" section 5.2, "Output from Key Exchange" contains the following text: "The key exchange produces two values: a shared secret K, and an exchange hash H." which implies that the exchange hash and the shared secret are two distinct values. Section 6, "Diffie-Hellman Key Exchange" then goes to great lengths to specify excactly how the exchange hash "H" is computed, but fails to specify the format of "K", which is used in key derivation. After a cursory look at the the SSH unix sources it seems that they use "H" in place of "K" for key derivation. I'm no crypto expert, but it seems to me that for the "diffie-hellman-group1-sha1" kex algorithm, "K" might contain as much as 1024 bits of entropy while "H" cannot possibly contain more than 160 bits. Any key derived from "H", no matter how large, would then be similarily restricted. This probably does't matter today, where none of the specified ciphers uses keys larger than 128 bits, but it seems like an unneccessary restriction. I propose that a paragraph be added to section 6, "Diffie-Hellman Key Exchange" that specifies the format of the shared secret "K" as an mpint for the purposes of key derivation. From owner-ietf-ssh@clinet.fi Thu Oct 29 12:43:48 1998 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 MAA04142; Thu, 29 Oct 1998 12:43:47 +0200 (EET) 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 MAA02246; Thu, 29 Oct 1998 12:43:47 +0200 (EET) Received: (from majordom@localhost) by lohi.clinet.fi (8.9.1/8.9.0) id MAA10988 for ietf-ssh-outgoing; Thu, 29 Oct 1998 12:40:03 +0200 (EET) X-Authentication-Warning: lohi.clinet.fi: majordom set sender to owner-ietf-ssh@clinet.fi using -f Received: from ssh.fi (ssh.fi [194.100.44.97]) by lohi.clinet.fi (8.9.1/8.9.0) with ESMTP id MAA10984 for ; Thu, 29 Oct 1998 12:40:01 +0200 (EET) Received: from torni.ssh.fi (torni.ssh.fi [192.168.2.43]) by ssh.fi (8.9.1/8.9.1/EPIPE-1.15) with ESMTP id MAA02188; Thu, 29 Oct 1998 12:38:00 +0200 (EET) Received: from torni.ssh.fi (torni.ssh.fi [192.168.2.43]) by torni.ssh.fi (8.9.1/8.9.1/EPIPE-1.13) with ESMTP id MAA04706; Thu, 29 Oct 1998 12:37:59 +0200 (EET) Date: Thu, 29 Oct 1998 12:37:59 +0200 (EET) From: Markku-Juhani Saarinen To: Sigurdur Asgeirsson cc: ietf-ssh@clinet.fi, "Timo J. Rinne" Subject: Re: Two ambiguities in transport protocol spec In-Reply-To: <36383118.CBEB606E@undo.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Content-Length: 1628 Lines: 35 On Thu, 29 Oct 1998, Sigurdur Asgeirsson wrote: > The bit that goes "If all algorithms were guessed right" is what I > have trouble with. It seem to me that only the key exchange algorithm > and the server host key algorithm affect the key exchange, and the SSH > unix sources indeed make and verify a guess based on those two only. The > text should probably go like: I think that you are right on this. The spec should be changed a bit. > After a cursory look at the the SSH unix sources it seems that they > use "H" in place of "K" for key derivation. I'm no crypto expert, but it > seems to me that for the "diffie-hellman-group1-sha1" kex algorithm, "K" > might contain as much as 1024 bits of entropy while "H" cannot possibly > contain more than 160 bits. Any key derived from "H", no matter how > large, would then be similarily restricted. This probably does't matter > today, where none of the specified ciphers uses keys larger than 128 > bits, but it seems like an unneccessary restriction. > I propose that a paragraph be added to section 6, "Diffie-Hellman Key > Exchange" that specifies the format of the shared secret "K" as an > mpint for the purposes of key derivation. Yes, there seems to be an inconsistency (and I am to blame). I think that "H" was there at one point, and I changed it to "K" for the entropy reasons you mention, but I somehow failed to change the code. Damn. I think that we'll have to find a way to work around this in the code. btw, we're now introducing twofish in SSH, with 256-bit keys. - mj Markku-Juhani O. Saarinen , SSH Communications Security Ltd From owner-ietf-ssh@clinet.fi Fri Oct 30 12:04:32 1998 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 MAA32187; Fri, 30 Oct 1998 12:04:31 +0200 (EET) 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 MAA13748; Fri, 30 Oct 1998 12:04:31 +0200 (EET) Received: (from majordom@localhost) by lohi.clinet.fi (8.9.1/8.9.0) id MAA28872 for ietf-ssh-outgoing; Fri, 30 Oct 1998 12:03:01 +0200 (EET) X-Authentication-Warning: lohi.clinet.fi: majordom set sender to owner-ietf-ssh@clinet.fi using -f Received: from proxyu.oz.is (proxyu.oz.is [193.4.211.81]) by lohi.clinet.fi (8.9.1/8.9.0) with ESMTP id MAA28829 for ; Fri, 30 Oct 1998 12:02:53 +0200 (EET) Received: from undo.com (pc-sigurasg.intranet.oz.is [172.22.1.156]) by proxyu.oz.is (2.5 Build 2640 (Berkeley 8.8.6)/8.8.4) with ESMTP id KAA09630; Fri, 30 Oct 1998 10:02:09 GMT Message-ID: <36398E60.3FEBEF1@undo.com> Date: Fri, 30 Oct 1998 10:01:04 +0000 From: Sigurdur Asgeirsson X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: ietf-ssh@clinet.fi Subject: Another comment on transport protocol spec Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Content-Length: 812 Lines: 26 Section 4.6, "Public Key Algorithms" contains the following text: --- Signing and verifying using this key format are done according to the Digital Signature Standard [FIPS-186] using the SHA-1 hash. A description can also be found in [Schneier]. The resulting signature is encoded as: uint32 length string "ssh-dss" mpint r mpint s --- The Unix implementation does not seem to follow this signature format, but rather uses a single string to hold both the "r" and "s" parts of the signature. This is consistent with the DSA implementation in the Crypto++ library and presumably, with the DSS standard. I propose that the draft be modified to suit, as follows: --- The resulting signature is encoded as: uint32 length string "ssh-dss" string dss_signature_blob --- From owner-ietf-ssh@clinet.fi Fri Oct 30 18:27:38 1998 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 SAA05349; Fri, 30 Oct 1998 18:27:38 +0200 (EET) 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 SAA17690; Fri, 30 Oct 1998 18:27:37 +0200 (EET) Received: (from majordom@localhost) by lohi.clinet.fi (8.9.1/8.9.0) id SAA27067 for ietf-ssh-outgoing; Fri, 30 Oct 1998 18:25:03 +0200 (EET) X-Authentication-Warning: lohi.clinet.fi: majordom set sender to owner-ietf-ssh@clinet.fi using -f Received: from ssh.fi (ssh.fi [194.100.44.97]) by lohi.clinet.fi (8.9.1/8.9.0) with ESMTP id SAA27062 for ; Fri, 30 Oct 1998 18:25:01 +0200 (EET) Received: from torni.ssh.fi (torni.ssh.fi [192.168.2.43]) by ssh.fi (8.9.1/8.9.1/EPIPE-1.15) with ESMTP id SAA17664; Fri, 30 Oct 1998 18:22:50 +0200 (EET) Received: from torni.ssh.fi (torni.ssh.fi [192.168.2.43]) by torni.ssh.fi (8.9.1/8.9.1/EPIPE-1.13) with ESMTP id SAA18806; Fri, 30 Oct 1998 18:22:49 +0200 (EET) Date: Fri, 30 Oct 1998 18:22:49 +0200 (EET) From: Markku-Juhani Saarinen To: Sigurdur Asgeirsson cc: ietf-ssh@clinet.fi Subject: Re: Another comment on transport protocol spec In-Reply-To: <36398E60.3FEBEF1@undo.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Content-Length: 1017 Lines: 26 On Fri, 30 Oct 1998, Sigurdur Asgeirsson wrote: > The Unix implementation does not seem to follow this signature format, > but rather uses a single string to hold both the "r" and "s" parts of > the signature. This is consistent with the DSA implementation in the > Crypto++ library and presumably, with the DSS standard. Thank you ! We greatly appreciate comments of this sort. We only have limited resources, and bugs of this sort are hard to find without interoperability testing. The FIPS pub 186, that specifies the digital signature standard, does not specify any particular binary encoding for the parameters. The "bob" format has probably emerged as a de facto standard because the signature is encoded in a number of applications this way (incl. PGP). PKIX uses different formatting, but we don't want to bring ASN.1 to SSH. The spec will be changed to match the current implementation (and the de facto standard). - mj Markku-Juhani O. Saarinen , SSH Communications Security Ltd From owner-ietf-ssh@clinet.fi Fri Oct 30 22:46:25 1998 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 WAA08465; Fri, 30 Oct 1998 22:46:24 +0200 (EET) 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 WAA19378; Fri, 30 Oct 1998 22:46:24 +0200 (EET) Received: (from majordom@localhost) by lohi.clinet.fi (8.9.1/8.9.0) id WAA02523 for ietf-ssh-outgoing; Fri, 30 Oct 1998 22:46:07 +0200 (EET) 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 WAA02514 for ; Fri, 30 Oct 1998 22:46:05 +0200 (EET) Received: from elvira.innosoft.com ([192.160.253.135]) by INNOSOFT.COM (PMDF V5.2-29 #30494) with ESMTP id <01J3KQVJJA9C94EW6A@INNOSOFT.COM> for ietf-ssh@clinet.fi; Fri, 30 Oct 1998 08:55:49 PST Received: from elwood.innosoft.com (ELWOOD.INNOSOFT.COM [192.160.253.60]) by elvira.innosoft.com (PMDF V5.2-29 #13579) with SMTP id <0F1N00GKRGBQ58@elvira.innosoft.com> for ietf-ssh@clinet.fi; Fri, 30 Oct 1998 08:55:03 -0800 (PST) Date: Fri, 30 Oct 1998 08:56:03 -0800 (PST) From: Chris Newman Subject: Re: Another comment on transport protocol spec In-reply-to: <36398E60.3FEBEF1@undo.com> Originator-info: login-id=chris; server=THOR.INNOSOFT.COM To: Sigurdur Asgeirsson Cc: ietf-ssh@clinet.fi Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Content-transfer-encoding: 7BIT Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Content-Length: 1047 Lines: 33 On Fri, 30 Oct 1998, Sigurdur Asgeirsson wrote: > --- > Signing and verifying using this key format are done according to the > Digital Signature Standard [FIPS-186] using the SHA-1 hash. A > description can also be found in [Schneier]. > > The resulting signature is encoded as: > > uint32 length > string "ssh-dss" > mpint r > mpint s > --- > > The Unix implementation does not seem to follow this signature format, > but rather uses a single string to hold both the "r" and "s" parts of > the signature. This is consistent with the DSA implementation in the > Crypto++ library and presumably, with the DSS standard. > I propose that the draft be modified to suit, as follows: > --- > The resulting signature is encoded as: > > uint32 length > string "ssh-dss" > string dss_signature_blob > --- I'd prefer if the implementation was fixed instead. The encoding described in the draft is very clean, simple and unambiguous. Let's not muck it up by using more than one format for mpints. - Chris From owner-ietf-ssh@clinet.fi Sat Oct 31 11:24:03 1998 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 LAA11074; Sat, 31 Oct 1998 11:24:03 +0200 (EET) 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 LAA23310; Sat, 31 Oct 1998 11:24:01 +0200 (EET) Received: (from majordom@localhost) by lohi.clinet.fi (8.9.1/8.9.0) id LAA27413 for ietf-ssh-outgoing; Sat, 31 Oct 1998 11:23:34 +0200 (EET) X-Authentication-Warning: lohi.clinet.fi: majordom set sender to owner-ietf-ssh@clinet.fi using -f Received: from islandia.is (hummvee.islandia.is [194.144.156.3]) by lohi.clinet.fi (8.9.1/8.9.0) with ESMTP id LAA27404 for ; Sat, 31 Oct 1998 11:23:22 +0200 (EET) Received: from undo.com (nas526.islandia.is [193.4.143.186]) by islandia.is (8.8.8/8.8.8) with ESMTP id JAA23218; Sat, 31 Oct 1998 09:20:55 GMT Message-ID: <363AD6E1.A5A980D4@undo.com> Date: Sat, 31 Oct 1998 09:22:41 +0000 From: Sigurdur Asgeirsson Reply-To: siggi@undo.com X-Mailer: Mozilla 4.5b2 (Macintosh; I; PPC) MIME-Version: 1.0 To: Markku-Juhani Saarinen , "ietf-ssh@clinet.fi" Subject: Re: Another comment on transport protocol spec References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ssh@clinet.fi Precedence: bulk Content-Length: 1560 Lines: 36 Markku-Juhani Saarinen wrote: > > On Fri, 30 Oct 1998, Sigurdur Asgeirsson wrote: > > > The Unix implementation does not seem to follow this signature format, > > but rather uses a single string to hold both the "r" and "s" parts of > > the signature. This is consistent with the DSA implementation in the > > Crypto++ library and presumably, with the DSS standard. > > Thank you ! We greatly appreciate comments of this sort. We only have > limited resources, and bugs of this sort are hard to find without > interoperability testing. > > The FIPS pub 186, that specifies the digital signature standard, does > not specify any particular binary encoding for the parameters. > > The "bob" format has probably emerged as a de facto standard because the > signature is encoded in a number of applications this way (incl. PGP). > PKIX uses different formatting, but we don't want to bring ASN.1 to SSH. > > The spec will be changed to match the current implementation (and the de > facto standard). > Chris Newman wrote: > > I'd prefer if the implementation was fixed instead. The encoding > described in the draft is very clean, simple and unambiguous. Let's not > muck it up by using more than one format for mpints. > > - Chris I would actually would go with Chris Newman on this one (and retract my proposed change to the draft :-). My understanding was that the DSS standard proscribed a binary format. If this is not the case then the current specification is clean, unambiguous and consistent with the rest of the protocol.