On Wed, Apr 05, 2000 at 10:33:05PM -0400, Stefan Mangard
wrote:> My name is Stefan Mangard and I plan to implement an extension to ssh as a
> final project in a cryptography class.
what kind of extension?
> Since I want to use an open source of ssh, I decided to use
> the openssh implementation.
cool.
> I am currently working with openssh-1.2.3, but I'd also like to
implement
> my extension for protocol 2, I wanted to ask you how far the development
> of the implementation of openssh-2 is.
right now i have client+server running on openbsd-current, here is the status:
% cat README.openssh2
$Id: README.openssh2,v 1.18 2000/03/28 19:31:19 markus Exp $
works:
client + some server
basic packet-layer
compression: zlib, none
encryption: blowfish-cbc, 3des-cbc, arcfour, cast128-cbc
mac: hmac-md5, hmac-sha1, (hmac-ripemd160)
transport: proposal exchange, i.e. different enc/mac/comp per direction
secsh-transport: w/o rekey, for client+server
secsh-userauth: passwd only, for client+server
secsh-connection : pty+shell or command, flow control works (window adjust)
tcp-forwarding: -L works for client/server
dss: verification works,
key database in ~/.ssh/known_hosts with bits == 0 hack
dss: signature works, keygen w/ openssl:
$ openssl dsaparam 1024 -out dsa1024.pem
$ openssl gendsa -out /etc/ssh_dsa_key dsa1024.pem -rand /dev/arandom
server: login works, pty, too.
client interops w/ sshd2, lshd
server interops w/ ssh2, lsh, ssh.com's Windows client, SecureCRT
server supports multiple concurrent sessions (e.g. with SSH.com Windows client)
todo:
re-keying
several secsh-connection features:
tcp-forwarding, agent-fwd
auth other than passwd: pubkey, keyboard-interactiv
config
server-auth w/ old host-keys
cleanup
advanced key storage?
keynote
sftp
-markus
$Date: 2000/03/28 19:31:19 $
% cat NOTES
OpenSSH2
=======
The SSH2 protocol is specifies in several IETF drafts (draft-ietf-secsh-*).
It is composed of three layered protocols:
(1) The 'transport layer' provides algorithm negotiation and a key
exchange. The key exchange includes server authentication and
results in a cryptographically secured connection: it provides
integrity, confidentiality and optional compression.
(2) The 'user authentication layer' uses the established connection
and relies on the services provided by the transport layer. It
provides several mechanisms for user authentication. These
include traditional password authentication as well as public-key
or host-based authentication mechanisms.
(3) The 'connection layer' multiplexes many different concurrent
channels over the authenticated connection and allows tunneling
of login sessions and TCP-forwarding. It provides a flow control
service for these channels. Additionally, various channel-specific
options can be negotiated.
The current state of OpenSSH2:
As of today we have both a client and a server with the following
basic functionality working:
(1) The OpenSSH2 transport layer implementation supports the
'diffie-hellman-group1-sha1' key exchange from the IETF drafts
and provides many algorithms for confidentiality (blowfish-cbc,
3des-cbc, arcfour, cast128-cbc) integrity (hmac-md5, hmac-sha1,
hmac-ripemd160) and compression (zlib). Different algorithms
can be negotiated per direction.
(2) Both the client and the server support password authentication
only.
(3) OpenSSH2 supports basic connection layer functionality: remote
shell or command invocation, including pty handling. OpenSSH2's
sshd even allows multiple concurrent login sessions over one
authenticated connection. There is a minimal support for
TCP-forwarding.
Interoperability:
The OpenSSH2 server interoperates with ssh.com's latest Unix and
Windows clients (note that they do not follow the specification
from the IETF drafts), SecureCRT and lsh. The OpenSSH2 client
interoperates with both ssh.com's server and lshd.
The Future:
A number of features are missing from OpenSSH2 and need to be added:
* TCP-forwarding must be extended both on the client and server side.
* Public-key authentication is required by the draft.
* re-keying support in the transport layer. Both client and server
can initiate re-keying.
* keyboard-interactive authentication method is intended for one-time
password authentication.
Apart from these basic features OpenSSH needs
* extended configurability and
* some code cleanup, since both SSH1 and SSH2 code are currently tightly
integrated. OpenSSH2 support both protocol versions (1.5 and 2.0)
in one program.
Another mayor milestone is the need for
* an advanced key managment
system (e.g. keynote policies from RFC 2704 and 2792)
and integration of different PKI's like PGP or X509. Perhaps
it's even possible to reuse the existing keys from SSH1.
* support a SSH2 ssh-agent and agent-forwarding. The protocol used
in ssh.com's implementations are not specified.
* support for a file-transfer protocol. Again, ssh.com's sftp is
not specified.