Subject: I-D ACTION:draft-weber-secsh-pkalg-none-00.txt

From: [email-masked]
Date: Tue, 24 Jun 2003 06:56:30 -0400

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: Secure Shell 'none' Public Key Algorithm
	Author(s)	: J. Weber
	Filename	: draft-weber-secsh-pkalg-none-00.txt
	Pages		: 4
	Date		: 2003-6-23
	
This document describes the 'none' public key encryption algorithm
for the Secure Shell protocol, which is useful for rekeying when the
server has no keys to support for non-GSSAPI key exchange and when
GSSAPI credentials are expired, or for use in embedded systems where
there is a desire to minimize the overhead of rekeying to prevent
sequence number rollover.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-weber-secsh-pkalg-none-00.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-weber-secsh-pkalg-none-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-weber-secsh-pkalg-none-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 24 Jun 2003 07:45:01 -0700

draft-ietf-secsh-gsskeyex-06 allows for hosts to give clients their host
keys in a secure manner, which makes it possible for subsequent re-keys
to work even when the client's GSS-API credentials are expired.

Nico
--

---

From: "Joel N. Weber II" <[email-masked]>
Date: Tue, 24 Jun 2003 17:06:57 -0400

> to work even when the client's GSS-API credentials are expired.

However, when you use a client that supports both GSS and
pgp-sign-{rsa,dss} and a server that also supports both of these and
has a pgp-sign-{rsa,dss} host key, the server will send the
pgp-sign-{rsa,dss} host key, and it is possible that the client will
decide that according to whatever trust model and trust values it
happens to be using, the key isn't trusted, and cause the connection
to fail.  You could special case it to not consult the trust model
when rekeying, I guess...

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 24 Jun 2003 14:26:13 -0700

I have thought that the gss keyex spec should allow the server to send
its public host keys (as opposed to one public host key).

I think that would be the right thing to do and the right fix.  I don't
mind this none keyex too much though and it may be the easiest way to
resolve your problem.

Cheers,

Nico
--

---

From: "Joel N. Weber II" <[email-masked]>
Date: Tue, 24 Jun 2003 20:14:47 -0400

> its public host keys (as opposed to one public host key).

Do you have a reasonable way to implement this that doesn't break
interoperability?  Are there implementations in the wild that send
the host's public key?

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 25 Jun 2003 08:09:46 -0700

> interoperability?  Are there implementations in the wild that send

No, and I don't know.  Anyone else?

Nico
--

---

From: "Joel N. Weber II" <[email-masked]>
Date: Thu, 26 Jun 2003 13:06:23 -0400

I think in the long run it would be useful for KEX_MSG_KEXINIT to
support negotiating additional features by adding more strings to the
end, with each string having a tag indicating the name of the feature
that string is negotiating.  This would allow you to provide an
alternate list of host key algorithms and key exchange algorithms that
would use a new negotiation algorithm, for example, as well as
negotiating the format of SSH_MSG_KEXGSS_HOSTKEY as to whether it
contains multiple host keys.  (I'm not convinced we should have that
multiple host key support, but if the protocol doesn't allow it to be
negotiated in an interoperable fashion when someone wants to add the
feature late in the game, it's somewhat poorly designed.)
Alternatively, there could be a seprate field for negotiating which
host key algorithm to use for the key sent with
SSH_MSG_KEXGSS_HOSTKEY.

The last field of KEX_MSG_KEXINIT is

     uint32    0 (reserved for future extension)

with no real explaination of how this should be used, as far as I can tell.

It looks to me like openssh-3.6.1p2 prints the reserved value with a
call to debug2 and otherwise ignores it, and will probably ignore
anything that appears after that field.  I have no idea what other
implementations will do if there's extra data after that reserved
value.

I bet if just adding strings at the end of KEX_MSG_KEXINIT would cause
real or potential problems, defining KEX_MSG_KEXINIT2 for additional
strings when both the client and server send 1 as the reserved value
would be likely to allow this to be extended without breaking
interoperability, and would be a far better idea than changing the
protocol version to 2.1.

---

From: "Joel N. Weber II" <[email-masked]>
Date: Thu, 26 Jun 2003 17:30:46 -0400

Thinking about this some more, SSH_MSG_KEXGSS_HOSTKEY feels like the
wrong place to solve the problem that it solves if it is even a
problem worth solving at all.  X.509 certificates can expire, OpenPGP
signatures and subkeys can expire, and OpenPGP trust values can be
changed.  If ``none'' as a public key algorithm is not an acceptable
solution, we should find a solution that also works for X.509 and
OpenPGP.  In general, if you are not using ssh-rsa or ssh-dss as your
host key, you probably want a way to do rekeying using either an
ssh-rsa or ssh-dss key, or no host key.

I don't think I see any reason why we couldn't define a
SSH_MSG_KEX_HOSTKEY which would send a host key along with which
algorithm it uses.  In particular, the transport draft says:

   An implementation MUST respond to all unrecognized messages with an
   SSH_MSG_UNIMPLEMENTED message in the order in which the messages were
   received.  Such messages MUST be otherwise ignored.  Later protocol
   versions may define other meanings for these message types.

It also appears that we could define SSH_MSG_KEXINIT2 and assume that
SSH_MSG_UNIMPLEMENTED will be sent if the client or server on the
other end doesn't recognize that message.