From owner-ietf-ssh@clinet.fi  Tue May  4 22:25:41 1999
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 WAA18042;
	Tue, 4 May 1999 22:25:41 +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 WAA08156;
	Tue, 4 May 1999 22:25:40 +0300 (EEST)
Received: (from majordom@localhost)
	by lohi.clinet.fi (8.9.1/8.9.0) id WAA07758
	for ietf-ssh-outgoing; Tue, 4 May 1999 22:25:24 +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 WAA07751
	for <ietf-ssh@clinet.fi>; Tue, 4 May 1999 22:25:21 +0300 (EEST)
Received: from viper ([192.168.0.16]) by mail.vandyke.com
          (Netscape Messaging Server 3.01)  with SMTP id 298
          for <ietf-ssh@clinet.fi>; Tue, 4 May 1999 13:22:21 -0600
Message-ID: <001501be9662$b14df430$1000a8c0@viper>
From: "Jeff P. Van Dyke" <jpv@vandyke.com>
To: <ietf-ssh@clinet.fi>
Subject: secsh-userauth-05 and sechsh-transport-05
Date: Tue, 4 May 1999 13:16:56 -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: 2564
Lines: 100

Issue #1
--------

>From draft-ietf-secsh-userauth-05, section 4, three
packet descriptions are given as follows:

#1

  byte      SSH_MSG_USERAUTH_REQUEST
  string    user name
  string    service
  string    "publickey"
  boolean   FALSE
  string    public key algorithm name
  string    public key blob


#2

  byte      SSH_MSG_USERAUTH_PK_OK
  string    public key algorithm name from the request
  string    public key blob from the request


#3

  byte      SSH_MSG_USERAUTH_REQUEST
  string    user name
  string    service
  string    "publickey"
  boolean   TRUE
  string    public key algorithm name
  string    public key to be used for authentication
  string    signature


#1 has "public key blob", #2 has "public key blob from
the request", and #3 has "public key to be used for
authentication"

Are all three of these the same format?

If so, I think it would be clearer if they were all simply
"public key blob".  I don't think the extra verbiage in the
packet description is necessary.  And, having different
verbiage for 3 strings of the same format could be confusing.

  
Issue #2
--------

>From draft-ietf-secsh-transport-05, section 4.6:

  Certificates and public keys are encoded as:

    uint32   combined length of the format identifier and associated data
    string   certificate or public key format identifier
    byte[n]  key/certificate data

  The certificate part may have be a zero length string, but a public key
  is required. This is the public key that will be used for
  authentication; the certificate sequence contained in the certificate
  blob can be used to provide authorization.

  The "ssh-dss" key format has the following specific encoding:

    uint32    length
    string    "ssh-dss"
    mpint     p
    mpint     q
    mpint     g
    mpint     y

  Here the "p", "q", "g", and "y" parameters form the signature key blob.


Since "ssh-dss" key format shown above seems to be equivalent
to the "public key blob" used in draft-ietf-secsh-userauth-05
(see the 3 examples above in Issue #1).

Because the certificate and public key encoding requires a
"certificate or public key format identifier" it seems redundant
for the SSH_MSG_USERAUTH_REQUEST and SSH_MSG_USERAUTH_PK_OK
packets to include 

  string    public key algorithm name
  
And, in fact, it appears that the latest SSH client and server
from Datafellows (SSH-1.99-2.0.12 F-SECURE SSH) doesn't send
this string.  Should the draft be changed to reflect the
current implementation?


Jeff P. Van Dyke
jpv@vandyke.com
Van Dyke Technologies, Inc.




From owner-ietf-ssh@clinet.fi  Wed May  5 18:41:12 1999
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 SAA16295;
	Wed, 5 May 1999 18:41:11 +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 SAA21582;
	Wed, 5 May 1999 18:41:11 +0300 (EEST)
Received: (from majordom@localhost)
	by lohi.clinet.fi (8.9.1/8.9.0) id SAA16636
	for ietf-ssh-outgoing; Wed, 5 May 1999 18:43:59 +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 SAA16623
	for <ietf-ssh@clinet.fi>; Wed, 5 May 1999 18:43:55 +0300 (EEST)
Received: from viper ([192.168.0.16]) by mail.vandyke.com
          (Netscape Messaging Server 3.01)  with SMTP id 281
          for <ietf-ssh@clinet.fi>; Wed, 5 May 1999 09:40:53 -0600
Message-ID: <000801be970c$eb8e0ef0$1000a8c0@viper>
From: "Jeff P. Van Dyke" <jpv@vandyke.com>
To: <ietf-ssh@clinet.fi>
Subject: public key authentication and file formats
Date: Wed, 5 May 1999 09:34:50 -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: 1058
Lines: 38

>From draft-ietf-secsh-userauth, section 4:

  The only REQUIRED authentication method is public key authentication.
  All implementations MUST support this method; 

Because of this requirement, it seems to me that the public key
(and possibly private key) file format should be documented in
order to achieve interoperability between different vendor
implementations.

For example, consider:

  ssh2 client from vendor A
  ssh2 keygen from vendor A

  ssh2 server from vendor B
  ssh2 keygen from vendor B

either the server needs to be able to read the public key file
generated by vendor A's keygen.  Or, the client needs to be
able to read the private key file generated by vendor B's keygen.

Should a specification of the file formats be incorporated
into the current set of drafts ?

Or, should a new draft be created to document these formats?

Or, are the formats already documented elsewhere?  If so,
should a reference to these documents be added to the current
drafts?

Thank you.

Jeff P. Van Dyke
jpv@vandyke.com
Van Dyke Technologies, Inc.


From owner-ietf-ssh@clinet.fi  Wed May  5 18:48:28 1999
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 SAA07368;
	Wed, 5 May 1999 18:48:27 +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 SAA21624;
	Wed, 5 May 1999 18:48:27 +0300 (EEST)
Received: (from majordom@localhost)
	by lohi.clinet.fi (8.9.1/8.9.0) id SAA17820
	for ietf-ssh-outgoing; Wed, 5 May 1999 18:54:40 +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 SAA17815
	for <ietf-ssh@clinet.fi>; Wed, 5 May 1999 18:54:37 +0300 (EEST)
Received: from viper ([192.168.0.16]) by mail.vandyke.com
          (Netscape Messaging Server 3.01)  with SMTP id 475
          for <ietf-ssh@clinet.fi>; Wed, 5 May 1999 09:51:31 -0600
Message-ID: <001501be970e$68348000$1000a8c0@viper>
From: "Jeff P. Van Dyke" <jpv@vandyke.com>
To: <ietf-ssh@clinet.fi>
Subject: draft-ietf-secsh-transport-05 and SSH_MSG_SERVICE_ACCEPT
Date: Wed, 5 May 1999 09:45:59 -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: 550
Lines: 24

>From draft-ietf-secsh-transport-05.txt, section 8:

  If the server supports the service (and permits the client to use it),
  it MUST respond with

    byte      SSH_MSG_SERVICE_ACCEPT
    string    service name


It appears the SSH 2.0.12 doesn't send the service name.

Is this in an error in the draft?  Or, in the 2.0.12 implementation?

Since the request being accepted includes the service name,
it isn't clear to me why the service name would need to be
sent back.

Thank you.

Jeff P. Van Dyke
jpv@vandyke.com
Van Dyke Technologies, Inc.


From owner-ietf-ssh@clinet.fi  Wed May  5 19:32:57 1999
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 TAA17839;
	Wed, 5 May 1999 19:32:56 +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 TAA21871;
	Wed, 5 May 1999 19:32:56 +0300 (EEST)
Received: (from majordom@localhost)
	by lohi.clinet.fi (8.9.1/8.9.0) id TAA23771
	for ietf-ssh-outgoing; Wed, 5 May 1999 19:38:57 +0300 (EEST)
X-Authentication-Warning: lohi.clinet.fi: majordom set sender to owner-ietf-ssh@clinet.fi using -f
Received: from watsun.cc.columbia.edu (IDENT:cu51491@watsun.cc.columbia.edu [128.59.39.2])
	by lohi.clinet.fi (8.9.1/8.9.0) with ESMTP id TAA23760
	for <ietf-ssh@clinet.fi>; Wed, 5 May 1999 19:38:51 +0300 (EEST)
Received: (from jaltman@localhost)
	by watsun.cc.columbia.edu (8.8.5/8.8.5) id MAA10854;
	Wed, 5 May 1999 12:29:26 -0400 (EDT)
Date: Wed, 5 May 99 12:29:26 EDT
From: Jeffrey Altman <jaltman@watsun.cc.columbia.edu>
Reply-To: jaltman@columbia.edu
To: "Jeff P. Van Dyke" <jpv@vandyke.com>
Cc: <ietf-ssh@clinet.fi>
Subject: Re: public key authentication and file formats
In-Reply-To: Your message of Wed, 5 May 1999 09:34:50 -0600
Message-ID: <CMM.0.90.4.925921766.jaltman@watsun.cc.columbia.edu>
Sender: owner-ietf-ssh@clinet.fi
Precedence: bulk
Content-Length: 1896
Lines: 56

> >From draft-ietf-secsh-userauth, section 4:
> 
>   The only REQUIRED authentication method is public key authentication.
>   All implementations MUST support this method; 
> 
> Because of this requirement, it seems to me that the public key
> (and possibly private key) file format should be documented in
> order to achieve interoperability between different vendor
> implementations.
> 
> For example, consider:
> 
>   ssh2 client from vendor A
>   ssh2 keygen from vendor A
> 
>   ssh2 server from vendor B
>   ssh2 keygen from vendor B
> 
> either the server needs to be able to read the public key file
> generated by vendor A's keygen.  Or, the client needs to be
> able to read the private key file generated by vendor B's keygen.
> 
> Should a specification of the file formats be incorporated
> into the current set of drafts ?
> 
> Or, should a new draft be created to document these formats?
> 
> Or, are the formats already documented elsewhere?  If so,
> should a reference to these documents be added to the current
> drafts?
> 
> Thank you.
> 
> Jeff P. Van Dyke
> jpv@vandyke.com
> Van Dyke Technologies, Inc.
> 
> 

While I agree that there is a strong benefit from having a common 
infrastructure for storing the keys I believe that how the keys are
stored is a feature of the implementation.  It is not safe to store
keys in unencrypted form in a file on most client operating systems.  
Therefore, how that information is protected and whether it even is
kept in a file is up to the vendor and the user.  I for instance 
might want to keep this information in the Windows Registry or on a
smart card.



    Jeffrey Altman * Sr.Software Designer * Kermit-95 for Win32 and OS/2
                 The Kermit Project * Columbia University
              612 West 115th St #716 * New York, NY * 10025
  http://www.kermit-project.org/k95.html * kermit-support@kermit-project.org


From owner-ietf-ssh@clinet.fi  Wed May  5 20:53:48 1999
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 UAA29345;
	Wed, 5 May 1999 20:53:44 +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 UAA22315;
	Wed, 5 May 1999 20:53:44 +0300 (EEST)
Received: (from majordom@localhost)
	by lohi.clinet.fi (8.9.1/8.9.0) id UAA03712
	for ietf-ssh-outgoing; Wed, 5 May 1999 20:59:10 +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 UAA03700
	for <ietf-ssh@clinet.fi>; Wed, 5 May 1999 20:59:06 +0300 (EEST)
Received: from viper ([192.168.0.16]) by mail.vandyke.com
          (Netscape Messaging Server 3.01)  with SMTP id 476;
          Wed, 5 May 1999 11:56:03 -0600
Message-ID: <003a01be971f$cdca2530$1000a8c0@viper>
From: "Jeff P. Van Dyke" <jpv@vandyke.com>
To: <jaltman@columbia.edu>
Cc: <ietf-ssh@clinet.fi>
Subject: Re: public key authentication and file formats
Date: Wed, 5 May 1999 11:50:31 -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: 3217
Lines: 85

>> >From draft-ietf-secsh-userauth, section 4:
>> 
>>   The only REQUIRED authentication method is public key authentication.
>>   All implementations MUST support this method; 
>> 
>> Because of this requirement, it seems to me that the public key
>> (and possibly private key) file format should be documented in
>> order to achieve interoperability between different vendor
>> implementations.
>> 
>> For example, consider:
>> 
>>   ssh2 client from vendor A
>>   ssh2 keygen from vendor A
>> 
>>   ssh2 server from vendor B
>>   ssh2 keygen from vendor B
>> 
>> either the server needs to be able to read the public key file
>> generated by vendor A's keygen.  Or, the client needs to be
>> able to read the private key file generated by vendor B's keygen.
>> 
>> Should a specification of the file formats be incorporated
>> into the current set of drafts ?
>> 
>> Or, should a new draft be created to document these formats?
>> 
>> Or, are the formats already documented elsewhere?  If so,
>> should a reference to these documents be added to the current
>> drafts?
>> 
>> Thank you.
>> 
>> Jeff P. Van Dyke
>> jpv@vandyke.com
>> Van Dyke Technologies, Inc.
>> 
>> 
>
>While I agree that there is a strong benefit from having a common 
>infrastructure for storing the keys I believe that how the keys are
>stored is a feature of the implementation.  It is not safe to store
>keys in unencrypted form in a file on most client operating systems.  
>Therefore, how that information is protected and whether it even is
>kept in a file is up to the vendor and the user.  I for instance 
>might want to keep this information in the Windows Registry or on a
>smart card.

Thanks for responding.

I agree that the client should be able to store the private
key where and how ever it wants.  However, in the case of the
public key, the server needs a copy.  The current SSH-2.0.12
implementation stores this in a file on the server in the
user's ~/.ssh2 directory.  It seems to me that this file format
needs to be documented so that a client can generate its own
public/private key pair and then place the public key on the
server.  Now, I suppose we could have a mechanism to do this
other than using a file.  But, since the Datafellows server
uses a file, I figured at the very least this mechanism should
be supported.

For interoperability between vendors, I think some mechanism
for moving public keys to the server must be defined.  Without
such a mechanism, I don't believe it would be possible to
validate the interoperability of different vendors' clients
and servers using the required public key user authentication.
As far as I can tell, right now, there is no such mechanism
specified.

I think some mechanism for exporting/importing public/private
key pairs between clients would be very useful.  For example,
some of our customers would prefer to only have one key pair
for both their UNIX and Windows SSH clients.  I think the
current file format is one candidate for interchange, but I
would be open to an alternative mechanism.

BTW, the current private key file format used by SSH-2.0.12
supports encryption to protect the private key.

Jeff P. Van Dyke
jpv@vandyke.com
Van Dyke Technologies, Inc.


From owner-ietf-ssh@clinet.fi  Wed May  5 21:14:46 1999
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 VAA29622;
	Wed, 5 May 1999 21:14:45 +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 VAA22377;
	Wed, 5 May 1999 21:14:45 +0300 (EEST)
Received: (from majordom@localhost)
	by lohi.clinet.fi (8.9.1/8.9.0) id VAA06018
	for ietf-ssh-outgoing; Wed, 5 May 1999 21:20:41 +0300 (EEST)
X-Authentication-Warning: lohi.clinet.fi: majordom set sender to owner-ietf-ssh@clinet.fi using -f
Received: from watsun.cc.columbia.edu (IDENT:cu51491@watsun.cc.columbia.edu [128.59.39.2])
	by lohi.clinet.fi (8.9.1/8.9.0) with ESMTP id VAA05998
	for <ietf-ssh@clinet.fi>; Wed, 5 May 1999 21:20:35 +0300 (EEST)
Received: (from jaltman@localhost)
	by watsun.cc.columbia.edu (8.8.5/8.8.5) id OAA15701;
	Wed, 5 May 1999 14:11:12 -0400 (EDT)
Date: Wed, 5 May 99 14:11:11 EDT
From: Jeffrey Altman <jaltman@watsun.cc.columbia.edu>
Reply-To: jaltman@columbia.edu
To: "Jeff P. Van Dyke" <jpv@vandyke.com>
Cc: <ietf-ssh@clinet.fi>
Subject: Re: public key authentication and file formats
In-Reply-To: Your message of Wed, 5 May 1999 11:50:31 -0600
Message-ID: <CMM.0.90.4.925927871.jaltman@watsun.cc.columbia.edu>
Sender: owner-ietf-ssh@clinet.fi
Precedence: bulk
Content-Length: 2531
Lines: 54

> I agree that the client should be able to store the private
> key where and how ever it wants.  However, in the case of the
> public key, the server needs a copy.  The current SSH-2.0.12
> implementation stores this in a file on the server in the
> user's ~/.ssh2 directory.  It seems to me that this file format
> needs to be documented so that a client can generate its own
> public/private key pair and then place the public key on the
> server.  Now, I suppose we could have a mechanism to do this
> other than using a file.  But, since the Datafellows server
> uses a file, I figured at the very least this mechanism should
> be supported.
> 
> For interoperability between vendors, I think some mechanism
> for moving public keys to the server must be defined.  Without
> such a mechanism, I don't believe it would be possible to
> validate the interoperability of different vendors' clients
> and servers using the required public key user authentication.
> As far as I can tell, right now, there is no such mechanism
> specified.
> 
> I think some mechanism for exporting/importing public/private
> key pairs between clients would be very useful.  For example,
> some of our customers would prefer to only have one key pair
> for both their UNIX and Windows SSH clients.  I think the
> current file format is one candidate for interchange, but I
> would be open to an alternative mechanism.
> 
> BTW, the current private key file format used by SSH-2.0.12
> supports encryption to protect the private key.
> 

This opens up a whole big can of worms.  While the SSH-2.0.12 file
format may support encryption (you and I) because we are U.S. 
based would be restricted from using strong encryption if we want to
be able to export our implementations.  DataFellows may choose to 
encrypt using IDEA but we would want to use TwoFish or 3DES because 
of patent issues.

Standard methods of distributing public keys brings up the issues of
how do you trust the source of the key and providing methods to
revoke them as well.  The typical reasons why I think public key
authentication should not be used for end user verification.  If
anything is going to be adopted in this area it really should be
borrowed from the PKIX or CAT working groups' efforts.




    Jeffrey Altman * Sr.Software Designer * Kermit-95 for Win32 and OS/2
                 The Kermit Project * Columbia University
              612 West 115th St #716 * New York, NY * 10025
  http://www.kermit-project.org/k95.html * kermit-support@kermit-project.org


From owner-ietf-ssh@clinet.fi  Thu May  6 10:41:58 1999
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 KAA18526;
	Thu, 6 May 1999 10:41:57 +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 KAA27389;
	Thu, 6 May 1999 10:41:57 +0300 (EEST)
Received: (from majordom@localhost)
	by lohi.clinet.fi (8.9.1/8.9.0) id KAA24881
	for ietf-ssh-outgoing; Thu, 6 May 1999 10:46:08 +0300 (EEST)
X-Authentication-Warning: lohi.clinet.fi: majordom set sender to owner-ietf-ssh@clinet.fi using -f
Received: from hutcs.cs.hut.fi (kivinen@hutcs.cs.hut.fi [130.233.192.7])
	by lohi.clinet.fi (8.9.1/8.9.0) with ESMTP id AAA26801
	for <ietf-ssh@clinet.fi>; Thu, 6 May 1999 00:26:50 +0300 (EEST)
Received: (from kivinen@localhost) by hutcs.cs.hut.fi (8.8.8/8.8.8) id AAA10056; Thu, 6 May 1999 00:15:25 +0300 (EET DST)
Date: Thu, 6 May 1999 00:15:25 +0300 (EET DST)
Message-Id: <199905052115.AAA10056@hutcs.cs.hut.fi>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
From: Tero Kivinen <kivinen@iki.fi>
To: "Jeff P. Van Dyke" <jpv@vandyke.com>
Cc: <ietf-ssh@clinet.fi>
Subject: public key authentication and file formats
In-Reply-To: <000801be970c$eb8e0ef0$1000a8c0@viper>
References: <000801be970c$eb8e0ef0$1000a8c0@viper>
X-Mailer: VM 6.33 under Emacs 19.34.1
Organization: Helsinki University of Technology
X-Edit-Time: 4 min
X-Total-Time: 4 min
Sender: owner-ietf-ssh@clinet.fi
Precedence: bulk
Content-Length: 890
Lines: 20

Jeff P. Van Dyke writes:
> Should a specification of the file formats be incorporated
> into the current set of drafts ?

I don't think so. The file formats are not relevant for the protocol
point of view. They are implementation details that doesn't cause any
kind of protocol interoperability problems. 

> Or, should a new draft be created to document these formats?

If so, I don't think it should be done in the IETF environment. File
formats used by client/keygen etc are not protocol issue. Ssh might
want to document them, and put that documentation out along with the
ssh2, but thats just one document about how one implementation stores
public/private keys in the files. 
-- 
kivinen@iki.fi                               Work : +358-9-4354 3218
SSH Communications Security                  http://www.ssh.fi/
SSH IPSEC Toolkit                            http://www.ssh.fi/ipsec/

From owner-ietf-ssh@clinet.fi  Thu May  6 10:41:59 1999
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 KAA18876;
	Thu, 6 May 1999 10:41:59 +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 KAA27393;
	Thu, 6 May 1999 10:41:59 +0300 (EEST)
Received: (from majordom@localhost)
	by lohi.clinet.fi (8.9.1/8.9.0) id KAA24961
	for ietf-ssh-outgoing; Thu, 6 May 1999 10:46:39 +0300 (EEST)
X-Authentication-Warning: lohi.clinet.fi: majordom set sender to owner-ietf-ssh@clinet.fi using -f
Received: from hutcs.cs.hut.fi (kivinen@hutcs.cs.hut.fi [130.233.192.7])
	by lohi.clinet.fi (8.9.1/8.9.0) with ESMTP id AAA28373
	for <ietf-ssh@clinet.fi>; Thu, 6 May 1999 00:41:52 +0300 (EEST)
Received: (from kivinen@localhost) by hutcs.cs.hut.fi (8.8.8/8.8.8) id AAA10275; Thu, 6 May 1999 00:33:44 +0300 (EET DST)
Date: Thu, 6 May 1999 00:33:44 +0300 (EET DST)
Message-Id: <199905052133.AAA10275@hutcs.cs.hut.fi>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
From: Tero Kivinen <kivinen@iki.fi>
To: jaltman@columbia.edu
Cc: "Jeff P. Van Dyke" <jpv@vandyke.com>, <ietf-ssh@clinet.fi>
Subject: Re: public key authentication and file formats
In-Reply-To: <CMM.0.90.4.925927871.jaltman@watsun.cc.columbia.edu>
References: <CMM.0.90.4.925927871.jaltman@watsun.cc.columbia.edu>
X-Mailer: VM 6.33 under Emacs 19.34.1
Organization: Helsinki University of Technology
X-Edit-Time: 12 min
X-Total-Time: 12 min
Sender: owner-ietf-ssh@clinet.fi
Precedence: bulk
Content-Length: 2578
Lines: 54

Jeffrey Altman writes:
> This opens up a whole big can of worms.  While the SSH-2.0.12 file
> format may support encryption (you and I) because we are U.S. 
> based would be restricted from using strong encryption if we want to
> be able to export our implementations.  DataFellows may choose to 
> encrypt using IDEA but we would want to use TwoFish or 3DES because 
> of patent issues.

If we think about public keys stored in the file, I don't think there
is need to encrypt public keys. For example the SSH-2.0.12 public keys
cannot be encrypted, only the private keys files may be encrypted. 

> Standard methods of distributing public keys brings up the issues of
> how do you trust the source of the key

For example in the current ssh2 it is very simple. All keys allowed to
login for that user must be mentioned in the users configuration file.
If the user puts that filename in the configuration file then ssh2
trusts that the user has received that key from the trusted source
(usually user generated it somewhere and copied it to the target
system). 

> and providing methods to revoke them as well.

Revokation is also easy, just remove the public key from the list of
authorized keys for that user... This even allows you to revoke only
some use of that key, which you cannot do with PKIX or X.509
certificates. You can for example remove the key from the root's
configuration file, but still keep it in your own configuration file.
This revokes the key to be accepted when logging in as root, but not
when logging in as user x. 

> The typical reasons why I think public key authentication should not
> be used for end user verification.

Public key authentication, and certificates etc are completely
different thing, even if the they use common technology. 

> If anything is going to be adopted in this area it really should be
> borrowed from the PKIX or CAT working groups' efforts.

No, I don't think PKIX will be usefull for the per user authorization.
It is useful when authenticating the host key, then you can trust that
if that host has a certificate signed by our universities host-CA key,
then I can trust it is really that host it claims to be...

You have to remember that authentication and authorization are
completely different things. In the ssh2 the public key authentication
is really a public key authorization, not authentication. 
-- 
kivinen@iki.fi                               Work : +358-9-4354 3218
SSH Communications Security                  http://www.ssh.fi/
SSH IPSEC Toolkit                            http://www.ssh.fi/ipsec/

From owner-ietf-ssh@clinet.fi  Thu May  6 00:45:44 1999
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 AAA29870;
	Thu, 6 May 1999 00:45:42 +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 AAA23388;
	Thu, 6 May 1999 00:45:42 +0300 (EEST)
Received: (from majordom@localhost)
	by lohi.clinet.fi (8.9.1/8.9.0) id AAA29115
	for ietf-ssh-outgoing; Thu, 6 May 1999 00:50:19 +0300 (EEST)
X-Authentication-Warning: lohi.clinet.fi: majordom set sender to owner-ietf-ssh@clinet.fi using -f
Received: from watsun.cc.columbia.edu (IDENT:cu51491@watsun.cc.columbia.edu [128.59.39.2])
	by lohi.clinet.fi (8.9.1/8.9.0) with ESMTP id AAA29095
	for <ietf-ssh@clinet.fi>; Thu, 6 May 1999 00:50:09 +0300 (EEST)
Received: (from jaltman@localhost)
	by watsun.cc.columbia.edu (8.8.5/8.8.5) id RAA23456;
	Wed, 5 May 1999 17:40:40 -0400 (EDT)
Date: Wed, 5 May 99 17:40:39 EDT
From: Jeffrey Altman <jaltman@watsun.cc.columbia.edu>
Reply-To: jaltman@columbia.edu
To: Tero Kivinen <kivinen@iki.fi>
Cc: "Jeff P. Van Dyke" <jpv@vandyke.com>, <ietf-ssh@clinet.fi>
Subject: Re: public key authentication and file formats
In-Reply-To: Your message of Thu, 6 May 1999 00:33:44 +0300 (EET DST)
Message-ID: <CMM.0.90.4.925940439.jaltman@watsun.cc.columbia.edu>
Sender: owner-ietf-ssh@clinet.fi
Precedence: bulk
Content-Length: 966
Lines: 24


Allowing the user to manually delete their public key from all of the
hosts to which it was installed is not a very scalable solution to the
theft of the private key.

> You have to remember that authentication and authorization are
> completely different things. In the ssh2 the public key authentication
> is really a public key authorization, not authentication. 

Excuse me?  You can not have authorization until you have 
authentication.  What you are doing is using implied authentication
based upon the authorization inherent in the existence of the public
key exchange.  In other words, you are performing authentication based
upon a plaintext user name and the public key exchange.




    Jeffrey Altman * Sr.Software Designer * Kermit-95 for Win32 and OS/2
                 The Kermit Project * Columbia University
              612 West 115th St #716 * New York, NY * 10025
  http://www.kermit-project.org/k95.html * kermit-support@kermit-project.org


From owner-ietf-ssh@clinet.fi  Fri May  7 12:48:17 1999
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 MAA12143;
	Fri, 7 May 1999 12:48:17 +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 MAA07113;
	Fri, 7 May 1999 12:48:16 +0300 (EEST)
Received: (from majordom@localhost)
	by lohi.clinet.fi (8.9.1/8.9.0) id MAA20804
	for ietf-ssh-outgoing; Fri, 7 May 1999 12:48:25 +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.29.146])
	by lohi.clinet.fi (8.9.1/8.9.0) with ESMTP id MAA20797
	for <ietf-ssh@clinet.fi>; Fri, 7 May 1999 12:48:08 +0300 (EEST)
Received: (from sjl@localhost)
	by asgard.tky.hut.fi (8.9.2/8.9.2) id OAA02268;
	Fri, 7 May 1999 14:33:48 +0300 (EEST)
From: Sami Lehtinen <sjl@iki.fi>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Date: Fri,  7 May 1999 14:33:48 +0300 (EEST)
To: "Jeff P. Van Dyke" <jpv@vandyke.com>
Cc: <ietf-ssh@clinet.fi>
Subject: draft-ietf-secsh-transport-05 and SSH_MSG_SERVICE_ACCEPT
In-Reply-To: <001501be970e$68348000$1000a8c0@viper>
References: <001501be970e$68348000$1000a8c0@viper>
X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs  Lucid
Message-ID: <14130.52969.125042.369586@asgard.tky.hut.fi>
Sender: owner-ietf-ssh@clinet.fi
Precedence: bulk
Content-Length: 922
Lines: 26

Jeff P. Van Dyke writes:
  : >From draft-ietf-secsh-transport-05.txt, section 8:
  : 
  :   If the server supports the service (and permits the client to use it),
  :   it MUST respond with
  : 
  :     byte      SSH_MSG_SERVICE_ACCEPT
  :     string    service name
  : 
  : 
  : It appears the SSH 2.0.12 doesn't send the service name.
  : 
  : Is this in an error in the draft?  Or, in the 2.0.12 implementation?

This is an error in the implementation. The service name must be in
the reply, because the client can send multiple requests for services, 
and if there were no 'service name' field in the
SSH_MSG_SERVICE_ACCEPT reply, the client wouldn't know which request
was accepted.

This will be fixed.

-- 
[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/]
From owner-ietf-ssh@clinet.fi  Mon May 10 15:50:43 1999
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 PAA00037;
	Mon, 10 May 1999 15:50: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 PAA01560;
	Mon, 10 May 1999 15:50:42 +0300 (EEST)
Received: (from majordom@localhost)
	by lohi.clinet.fi (8.9.1/8.9.0) id PAA20032
	for ietf-ssh-outgoing; Mon, 10 May 1999 15:54:17 +0300 (EEST)
X-Authentication-Warning: lohi.clinet.fi: majordom set sender to owner-ietf-ssh@clinet.fi using -f
Received: from hutcs.cs.hut.fi (kivinen@hutcs.cs.hut.fi [130.233.192.7])
	by lohi.clinet.fi (8.9.1/8.9.0) with ESMTP id XAA07092
	for <ietf-ssh@clinet.fi>; Sat, 8 May 1999 23:13:16 +0300 (EEST)
Received: (from kivinen@localhost) by hutcs.cs.hut.fi (8.8.8/8.8.8) id XAA26672; Sat, 8 May 1999 23:04:50 +0300 (EET DST)
Date: Sat, 8 May 1999 23:04:50 +0300 (EET DST)
Message-Id: <199905082004.XAA26672@hutcs.cs.hut.fi>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
From: Tero Kivinen <kivinen@iki.fi>
To: jaltman@columbia.edu
Cc: "Jeff P. Van Dyke" <jpv@vandyke.com>, <ietf-ssh@clinet.fi>
Subject: Re: public key authentication and file formats
In-Reply-To: <CMM.0.90.4.925940439.jaltman@watsun.cc.columbia.edu>
References: <CMM.0.90.4.925940439.jaltman@watsun.cc.columbia.edu>
X-Mailer: VM 6.33 under Emacs 19.34.1
Organization: Helsinki University of Technology
X-Edit-Time: 9 min
X-Total-Time: 8 min
Sender: owner-ietf-ssh@clinet.fi
Precedence: bulk
Content-Length: 2127
Lines: 43

Jeffrey Altman writes:
> Allowing the user to manually delete their public key from all of the
> hosts to which it was installed is not a very scalable solution to the
> theft of the private key.

I consider myself quite active user of ssh and rsa public key
authentication, and my public key is stored in about 10 different
adminstrative domains (few hundreds of machines, but only 10 different
home directories). If my private key is ever stolen I am sure I am not
going to wait for some CA vendor to issue CRL for that, I go and
change those public keys immediately.

For single user it is quite workable system. 

> > You have to remember that authentication and authorization are
> > completely different things. In the ssh2 the public key authentication
> > is really a public key authorization, not authentication. 
> Excuse me?  You can not have authorization until you have 
> authentication.

Why not? That is really the normal case. If I give my house key to my
friend when I am on vacation, the lock that protects my house, doesn't
do any kind of authentication, it just sees the authorization (the
key) I have given to my friend and allows him to open the door.

Same thing hapens to in the computers. The public key really doesn't
authenticate you. It doesn't say who the user of it is. When I put my
public key to authorized_keys file, I don't tell that anyone who is
authenticated as Tero Kivinen can login, I am sending that anybody who
posesses the private key of this public key is authorized to login.

> What you are doing is using implied authentication based upon the
> authorization inherent in the existence of the public key exchange.
> In other words, you are performing authentication based upon a
> plaintext user name and the public key exchange.

No, I am doing authorization based by the posession of the private key
of the public key stored in the configuration (authorized_keys file).
-- 
kivinen@iki.fi                               Work : +358-9-4354 3218
SSH Communications Security                  http://www.ssh.fi/
SSH IPSEC Toolkit                            http://www.ssh.fi/ipsec/

From owner-ietf-ssh@clinet.fi  Mon May 10 07:13:55 1999
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 HAA19902;
	Mon, 10 May 1999 07:13:54 +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 HAA26124;
	Mon, 10 May 1999 07:13:53 +0300 (EEST)
Received: (from majordom@localhost)
	by lohi.clinet.fi (8.9.1/8.9.0) id HAA22328
	for ietf-ssh-outgoing; Mon, 10 May 1999 07:14:50 +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 HAA22324
	for <ietf-ssh@clinet.fi>; Mon, 10 May 1999 07:14:46 +0300 (EEST)
Received: from boa ([192.168.0.31]) by mail.vandyke.com
          (Netscape Messaging Server 3.01)  with SMTP id 402
          for <ietf-ssh@clinet.fi>; Sun, 9 May 1999 22:10:38 -0600
Message-ID: <002901be9a99$a28372f0$3c00a8c0@boa.vandyke.com>
From: "Jeff P. Van Dyke" <jpv@vandyke.com>
To: <ietf-ssh@clinet.fi>
Subject: SSH_MSG_CHANNEL_OPEN
Date: Sun, 9 May 1999 21:59:33 -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: 591
Lines: 26

>From draft-ietf-secsh-connect-05.txt, section 4.3.2:

  byte      SSH_MSG_CHANNEL_OPEN
  string    "x11"
  uint32    sender channel
  uint32    initial window size
  uint32    maximum packet size
  string    originator address (e.g. "192.168.7.38")
  uint32    originator port


>From the 2.0.12 server, instead of a string and uint32 for the
original address and port, I receive a string of the form:

  X11 connection from 192.168.0.1:51530


Is this in an error in the draft?  Or, in the 2.0.12 implementation?

Thank you.

Jeff P. Van Dyke
jpv@vandyke.com
Van Dyke Technologies, Inc.


From owner-ietf-ssh@clinet.fi  Mon May 10 10:20:46 1999
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 KAA20125;
	Mon, 10 May 1999 10:20: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 KAA27488;
	Mon, 10 May 1999 10:20:42 +0300 (EEST)
Received: (from majordom@localhost)
	by lohi.clinet.fi (8.9.1/8.9.0) id KAA16912
	for ietf-ssh-outgoing; Mon, 10 May 1999 10:24:42 +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 KAA16907
	for <ietf-ssh@clinet.fi>; Mon, 10 May 1999 10:24:39 +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 JAA24684;
	Mon, 10 May 1999 09:12:43 +0200 (MET DST)
Received: (from nisse@localhost)
	by sanna.lysator.liu.se (8.8.8/8.8.7) id JAA13678;
	Mon, 10 May 1999 09:12:39 +0200 (MET DST)
To: Sami Lehtinen <sjl@iki.fi>
Cc: "Jeff P. Van Dyke" <jpv@vandyke.com>, <ietf-ssh@clinet.fi>
Subject: Re: draft-ietf-secsh-transport-05 and SSH_MSG_SERVICE_ACCEPT
References: <001501be970e$68348000$1000a8c0@viper> <14130.52969.125042.369586@asgard.tky.hut.fi>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
From: nisse@lysator.liu.se (Niels =?ISO-8859-1?Q?M=F6ller?=)
Date: 10 May 1999 09:12:38 +0200
In-Reply-To: Sami Lehtinen's message of "Fri,  7 May 1999 14:33:48 +0300 (EEST)"
Message-ID: <nn7lqh5rfd.fsf@sanna.lysator.liu.se>
X-Mailer: Gnus v5.4.59/Emacs 19.34
Sender: owner-ietf-ssh@clinet.fi
Precedence: bulk
Content-Length: 1604
Lines: 47

Sami Lehtinen <sjl@iki.fi> writes:

> Jeff P. Van Dyke writes:
>   : >From draft-ietf-secsh-transport-05.txt, section 8:
>   : 
>   :   If the server supports the service (and permits the client to use it),
>   :   it MUST respond with
>   : 
>   :     byte      SSH_MSG_SERVICE_ACCEPT
>   :     string    service name
>   : 
>   : 
>   : It appears the SSH 2.0.12 doesn't send the service name.
>   : 
>   : Is this in an error in the draft?  Or, in the 2.0.12 implementation?
> 
> This is an error in the implementation. The service name must be in
> the reply, because the client can send multiple requests for services, 
> and if there were no 'service name' field in the
> SSH_MSG_SERVICE_ACCEPT reply, the client wouldn't know which request
> was accepted.

This sounds very reasonable. However, if this is how service requests
are supposed to work, there is another bug. In the specification.
Quoting transport-05.txt:

:   byte      SSH_MSG_SERVICE_REQUEST
:   string    service name
: 
: If the server rejects the service request, it SHOULD send an appropriate
: SSH_MSG_DISCONNECT message and MUST disconnect.

If the server MUST disconnects after rejecting a service request, it
doesn't make much sense for the client to send several service request
messages.

> This will be fixed.

Good. As there seems to be several people working on ssh2
implementations by now, I hope all the bugs in the spec and in
implementations that prevent interoperability can be identified and
fixed. I hope to get the time to write up a summary of the (quite few)
problems I have stumbled upon.

Regards,
/Niels

From owner-ietf-ssh@clinet.fi  Fri May 14 06:01:44 1999
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 GAA05372;
	Fri, 14 May 1999 06:01:44 +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 GAA17237;
	Fri, 14 May 1999 06:01:43 +0300 (EEST)
Received: (from majordom@localhost)
	by lohi.clinet.fi (8.9.1/8.9.0) id FAA12442
	for ietf-ssh-outgoing; Fri, 14 May 1999 05:56:35 +0300 (EEST)
X-Authentication-Warning: lohi.clinet.fi: majordom set sender to owner-ietf-ssh@clinet.fi using -f
Received: from zipcode.corp.home.net (zipcode.corp.home.net [24.0.26.58])
	by lohi.clinet.fi (8.9.1/8.9.0) with ESMTP id FAA12438
	for <ietf-ssh@clinet.fi>; Fri, 14 May 1999 05:56:33 +0300 (EEST)
Received: from dragonfly.eos.home.net (rja@dragonfly.eos.home.net [24.0.17.119])
	by zipcode.corp.home.net (8.9.3/8.9.3) with ESMTP id TAA08294
	for <ietf-ssh@clinet.fi>; Thu, 13 May 1999 19:56:12 -0700 (PDT)
Received: (from rja@localhost)
	by dragonfly.eos.home.net (8.9.1/8.8.5) id TAA26402
	for ietf-ssh@clinet.fi; Thu, 13 May 1999 19:56:11 -0700 (PDT)
From: rja@corp.home.net (Randall Atkinson)
Message-Id: <990513195611.ZM26400@dragonfly.eos.home.net>
Date: Thu, 13 May 1999 19:56:11 -0700
In-Reply-To: Tero Kivinen <kivinen@iki.fi>
        "public key authentication and file formats" (May  6,  0:15)
References: <000801be970c$eb8e0ef0$1000a8c0@viper> 
	<199905052115.AAA10056@hutcs.cs.hut.fi>
X-Mailer: Z-Mail (4.0.1 13Jan97)
To: ietf-ssh@clinet.fi
Subject: Re: public key authentication and file formats
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-ietf-ssh@clinet.fi
Precedence: bulk
Content-Length: 1093
Lines: 33


Jeff P. Van Dyke writes:
> Should a specification of the file formats be incorporated
> into the current set of drafts ?

On May 6  0:15, Tero Kivinen wrote:
% I don't think so. The file formats are not relevant for the protocol
% point of view. They are implementation details that doesn't cause any
% kind of protocol interoperability problems.

> Or, should a new draft be created to document these formats?

% If so, I don't think it should be done in the IETF environment. File
% formats used by client/keygen etc are not protocol issue. Ssh might
% want to document them, and put that documentation out along with the
% ssh2, but thats just one document about how one implementation stores
% public/private keys in the files.

Kero,

	I would request that you all document the file format that you
use in an Informational RFC (title might be something like:
"A File Format for SSH Keys".

	It is useful to get this documented in an online, free, and
archival document series such as RFCs.  I do agree that these file format
aren't appropriate for IETF standards track.

Regards,

Ran


From owner-ietf-ssh@clinet.fi  Tue May 25 12:34:14 1999
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 MAA05219;
	Tue, 25 May 1999 12:34:14 +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 MAA23855;
	Tue, 25 May 1999 12:34:13 +0300 (EEST)
Received: (from majordom@localhost)
	by lohi.clinet.fi (8.9.1/8.9.0) id MAA02215
	for ietf-ssh-outgoing; Tue, 25 May 1999 12:30:08 +0300 (EEST)
X-Authentication-Warning: lohi.clinet.fi: majordom set sender to owner-ietf-ssh@clinet.fi using -f
Received: from relay.gw.tislabs.com (firewall-user@relay.gw.tislabs.com [192.94.214.100])
	by lohi.clinet.fi (8.9.1/8.9.0) with ESMTP id CAA13335
	for <ietf-ssh@clinet.fi>; Tue, 25 May 1999 02:39:12 +0300 (EEST)
Received: by relay.gw.tislabs.com; id TAA28981; Mon, 24 May 1999 19:51:20 -0400 (EDT)
Received: from clipper.gw.tislabs.com(10.33.1.2) by relay.gw.tislabs.com via smap (4.1)
	id xma028876; Mon, 24 May 99 19:51:00 -0400
Received: (from balenson@localhost)
	by clipper.gw.tislabs.com (8.9.1/8.9.1) id TAA10383
	for ietf-ssh@clinet.fi; Mon, 24 May 1999 19:33:34 -0400 (EDT)
Date: Mon, 24 May 1999 19:33:34 -0400 (EDT)
From: "David M. Balenson" <balenson@tislabs.com>
Message-Id: <199905242333.TAA10383@clipper.gw.tislabs.com>
To: ietf-ssh@clinet.fi
Subject: REMINDER: CFP: ISOC Year 2000 Netw. & Distr. Sys. Security Symp. (NDSS 2000)
Sender: owner-ietf-ssh@clinet.fi
Precedence: bulk
Content-Length: 6424
Lines: 162


            C  A  L  L       F  O  R       P  A  P  E  R  S


                          The Internet Society
           Year 2000 Network and Distributed System Security 
                         Symposium (NDSS 2000)

             Catamaran Resort Hotel, San Diego, California
                           February 2-4, 2000


IMPORTANT DATES:

  Paper and panel submissions due: June 16, 1999
  Author notification: August 17, 1999
  Final versions of papers and panels due: October 15, 1999

GOAL: 

  This symposium aims to foster information exchange among researchers
  and practitioners of network and distributed system security
  services.  The intended audience includes those who are interested
  in practical aspects of network and distributed system security,
  with the focus on actual system design and implementation, rather
  than theory. A major goal of the symposium is to encourage and
  enable the Internet community to apply, deploy, and advance the
  state of available security technology.  The proceedings of the
  symposium will be published by the Internet Society.

  Submissions are solicited for, but are not limited to, the
  following topics:

  * Secure Electronic Commerce, e.g., payment, barter, EDI,
    notarization/timestamping, endorsement and licensing.
  * Intellectual Property Protection: protocols, schemas,
    implementations, metering, watermarking, other forms of rights
    management.
  * Implementation, deployment and management of network security
    policies.
  * Integrating Security in Internet protocols: routing, naming,
    TCP/IP, multicast, network management, and, of course, the Web.
  * Attack-resistant protocols and services.
  * Special problems and case studies: e.g. interplay and tradeoffs
    between security and efficiency, usability, reliability and cost.
  * Security for collaborative applications and services: tele- and
    video-conferencing, groupwork, etc.
  * Fundamental services: authentication, data integrity,
    confidentiality, authorization, non-repudiation, and availability.
  * Supporting mechanisms and APIs: key management and certification,
    revocation, audit trails and accountability.
  * Integrating security services with system and application security
    facilities and protocols, e.g., message handling, file
    transport/access, directories, time synchronization, data base
    management, boot services, mobile computing.
  * Security for emerging technologies -- sensor networks, specialized
    testbeds, wireless/mobile (and ad hoc) networks, personal
    communication systems, and large heterogeneous distributed systems.
  * Intrusion Avoidance, Detection, and Response: systems, experiences
    and architectures
  * Network Perimeter Controls: firewalls, packet filters, application
    gateways.

BEST PAPER AWARD:

  A best paper award will be introduced at NDSS 2000. This award will
  be presented at the symposium to the authors of the best paper to
  be selected by the program committee.

GENERAL CHAIR:
  Stephen Welke, Trusted Computer Solutions

PROGRAM CO-CHAIRS:
  Gene Tsudik, USC / Information Sciences Institute
  Avi Rubin, AT&T Labs - Research

TUTORIAL CHAIR:
  Doug Maughan, NSA / DARPA

PROGRAM COMMITTEE:
  Bill Cheswick, Lucent Bell Labs  
  Marc Dacier, IBM Research Zurich 
  Jim Ellis, CMU / CERT
  Carl Ellison, Intel   
  Ed Felten, Princeton  
  Virgil Gligor, UMD College Park 
  Thomas Hardjono, Bay Networks/Nortel
  Cynthia Irvine, Naval Postgraduate School
  Charlie Kaufman,  Iris Associates
  Dave Kormann, AT&T Labs - Research 
  Hugo Krawczyk, Technion and IBM
  Carl Landwehr, Naval Research Lab
  Doug Maughan, NSA / DARPA   
  Gary McGraw, Reliable Software Technologies  
  Sandra Murphy, TIS Labs at Network Associates   
  Clifford Neuman, USC / Information Sciences Institute
  Paul Van Oorschot, Entrust
  Sami Saydjari, DARPA ISO 
  David Wagner, UC Berkeley   
  Bennet Yee, UC San Diego

LOCAL ARRANGEMENTS CHAIR:
  Thomas Hutton, San Diego Supercomputer Center

PUBLICATIONS CHAIR:
  John Kochmar, SEI

PUBLICITY CHAIR:
  David Balenson, TIS Labs at Network Associates   

LOGISTICS CHAIR:
  Carla Rosenfeld, Internet Society

REGISTRATIONS CHAIR
  Beth Strait, Internet Society

SUBMISSIONS: 

  The committee invites both technical papers and panel proposals.
  Technical papers should be at most 20 pages long. Panel proposals
  should be at most two pages and should describe the topic, identify
  the panel chair, explain the format of the panel, and list three
  to four potential panelists.  Technical papers will appear in
  the proceedings. A description of each panel will appear in the
  proceedings, and may -- at the discretion of the panel chair --
  include written position statements from the panelists.

  Each submission must contain a separate title page with the type
  of submission (paper or panel), the title or topic, the names of
  the author(s), organizational affiliation(s), telephone and FAX
  numbers, postal addresses, e-mail addresses, and must specify
  the contact author in case of multi-author submissions. The names
  of authors, affiliations, and other identifying information should
  appear only on the separate title page.

  Submissions must be received by June 16, 1999, and must be made
  via electronic mail in either PostScript or ASCII format.  If
  the committee is unable to print a PostScript submission, a
  hardcopy will be requested. Therefore, PostScript submissions
  must arrive well before the deadline.

  All submissions and program related correspondence (only) should
  be directed to the program chair:

        Gene Tsudik     
        USC Information Sciences Institute      
        4676 Admiralty Way      
        Marina Del Rey, CA 90292        
        Email: ndss00@isi.edu
        TEL: +1 (310) 822-1511 ext 329
        FAX: +1 (310) 823-6714 

  Dates, final call for papers, advance program, and registration
  information will be available soon at the URL: httl//www.isoc.org/ndss2000.

  Each submission will be acknowledged by e-mail.  If acknowledgment
  is not received within seven days, please contact the program
  chair as indicated above.  Authors and panelists will be notified
  of acceptance by August 17, 1999.  Instructions for preparing
  camera-ready copy for the proceedings will be sent at that time.
  The camera-ready copy must be received by October 15, 1999.

