From owner-ietf-ssh@clinet.fi  Wed Oct 28 21:06:17 1998
Return-Path: <owner-ietf-ssh@clinet.fi>
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 <ietf-ssh@clinet.fi>; 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 <ietf-ssh@clinet.fi>; 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 <fcusack@iconnet.net>
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 <user> expired.\nEnter the new password: "
S: FALSE

C: (prompt user for new password ONCE)
C: SSH_MSG_USERAUTH_PASSWD_INFO_RESPONSE
C: "<new password>"

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: "<new password>"

**************

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: <owner-ietf-ssh@clinet.fi>
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 <ietf-ssh@clinet.fi>; 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 <ietf-ssh@clinet.fi>; 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 <fcusack@iconnet.net>
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: <owner-ietf-ssh@clinet.fi>
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 <ietf-ssh@clinet.fi>; 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 <siggi@undo.com>
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: <owner-ietf-ssh@clinet.fi>
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 <ietf-ssh@clinet.fi>; 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 <mjos@ssh.fi>
To: Sigurdur Asgeirsson <siggi@undo.com>
cc: ietf-ssh@clinet.fi, "Timo J. Rinne" <tri@ssh.fi>
Subject: Re: Two ambiguities in transport protocol spec
In-Reply-To: <36383118.CBEB606E@undo.com>
Message-ID: <Pine.OSF.4.03.9810291218390.7552-100000@torni.ssh.fi>
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 <mjos@ssh.fi>, SSH Communications Security Ltd


From owner-ietf-ssh@clinet.fi  Fri Oct 30 12:04:32 1998
Return-Path: <owner-ietf-ssh@clinet.fi>
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 <ietf-ssh@clinet.fi>; 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 <siggi@undo.com>
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: <owner-ietf-ssh@clinet.fi>
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 <ietf-ssh@clinet.fi>; 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 <mjos@ssh.fi>
To: Sigurdur Asgeirsson <siggi@undo.com>
cc: ietf-ssh@clinet.fi
Subject: Re: Another comment on transport protocol spec
In-Reply-To: <36398E60.3FEBEF1@undo.com>
Message-ID: <Pine.OSF.4.03.9810301755350.12230-100000@torni.ssh.fi>
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 <mjos@ssh.fi>, SSH Communications Security Ltd


From owner-ietf-ssh@clinet.fi  Fri Oct 30 22:46:25 1998
Return-Path: <owner-ietf-ssh@clinet.fi>
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 <ietf-ssh@clinet.fi>; 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 <Chris.Newman@INNOSOFT.COM>
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 <siggi@undo.com>
Cc: ietf-ssh@clinet.fi
Message-id: <Pine.SOL.3.95.981030084541.20512B-100000@elwood.innosoft.com>
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: <owner-ietf-ssh@clinet.fi>
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 <ietf-ssh@clinet.fi>; 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 <siggi@undo.com>
Reply-To: siggi@undo.com
X-Mailer: Mozilla 4.5b2 (Macintosh; I; PPC)
MIME-Version: 1.0
To: Markku-Juhani Saarinen <mjos@ssh.fi>,
        "ietf-ssh@clinet.fi" <ietf-ssh@clinet.fi>
Subject: Re: Another comment on transport protocol spec
References: <Pine.OSF.4.03.9810301755350.12230-100000@torni.ssh.fi>
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.
