Subject: WG Last Call (third time's the charm?) for SSH core drafts

From: Bill Sommerfeld <[email-masked]>
Date: Mon, 04 Feb 2002 17:04:24 -0500

A Working Group Last Call begins today and will end in one week for
the following four drafts:

	draft-ietf-secsh-architecture-12.txt
	draft-ietf-secsh-transport-12.txt
	draft-ietf-secsh-userauth-14.txt
	draft-ietf-secsh-connect-15.txt

I believe that these documents represent the current consensus of the
working group and should be submitted to the IESG for consideration
for publication as a Proposed Standard RFC.

Comments regarding the content of these documents should be sent to
the working group mailing list, <[email-masked]>.  If you believe
a change to a document is necessary, please include revised wording
along with your comment.

This Last Call period extends until February 11th, 2002.

---

From: "Joseph Galbraith" <[email-masked]>
Date: Mon, 4 Feb 2002 15:43:48 -0700

What about x.509?

- Joseph

---

From: Bill Sommerfeld <[email-masked]>
Date: Mon, 04 Feb 2002 17:46:55 -0500

> What about x.509?

i do not want to hold up the core drafts waiting for folks to figure
out how to use x.509 with ssh.

					- Bill

---

From: "Joseph Galbraith" <[email-masked]>
Date: Mon, 4 Feb 2002 15:56:28 -0700

> out how to use x.509 with ssh.

The current draft is woefully
underspecified.

I think we either have to take
it out and put it in it's own
document, or add some language
that specifies more explicitly
how to encode the certificate
and signatures into the SSH
protocol.

If we want to put it in it's
own document, that's fine --
but I think it would be a mistake
to proceed with it in the main
document as underspecified as
it is.  A poor, ambiguous specification
is worse than none at all.

- Joseph

---

From: Bill Sommerfeld <[email-masked]>
Date: Mon, 04 Feb 2002 18:01:47 -0500

> but I think it would be a mistake to proceed with it in the main
> document as underspecified as it is.  A poor, ambiguous
> specification is worse than none at all.

so, until recently, we had clear consensus to go forward with the
admittedly woefully underspecified x.509 wording pending actual
implementation experience.

do we want more delay?

					- Bill

---

From: "Joseph Galbraith" <[email-masked]>
Date: Mon, 4 Feb 2002 16:04:13 -0700

> implementation experience.

We agreed to change the draft in August but
it didn't get done, and now there doesn't
currently appear to be consensus.

I would say create a new working group
document for x.509 and remove it
from the transport draft.

I'll edit it unless Darren wants to.

- Joseph

---

From: Derek Fawcus <[email-masked]>
Date: Mon, 4 Feb 2002 23:46:11 +0000

I've got a slightly different issue with the userauth spec,  section 3 states:

   Message numbers of 80 and higher are reserved for protocols running
   after this authentication protocol, so receiving one of them before
   authentication is complete is an error, to which the server MUST
   respond by disconnecting (preferably with a proper disconnect message
   sent first to ease troubleshooting).

Maybe I'm missing something,  but I can't see the need to disconnect in this
case,  as opposed to simply discarding these messages.  At the moment an
extra RTT is required to wait for the SSH_MSG_USERAUTH_SUCCESS,  assuming
that the log in method succeeds.  Given that I happen to frequently log
into machines over long slow (long RTT) links,  it gets painful.

Unless there is a valid security reason for disconnecting,  I'd suggest
a change to:

   Message numbers of 80 and higher are reserved for protocols running
   after this authentication protocol, so any of these messages received
   before authentication has completed cannot be processed;  if this
   situation occurs the server MUST silently discard those messages.

An alternative would be to generate some sort of error response to the
messages.  However silent discard serves the purpose of allowing one to
pipeline the initial connection protocol messages after a USERAUTH_REQUEST
on the assumption that it will succeed,  and still automatically deal
with the request failing.  The failure response indicating that the
subsequent higher level protocol messages have been discarded.

DF

---

From: Frank Cusack <[email-masked]>
Date: Mon, 4 Feb 2002 18:32:42 -0800

> 	draft-ietf-secsh-connect-15.txt

What about keyboard-interactive?  I should have an updated draft in a day's
time for review.  There is unlikely to be any [serious] contentious issues.

/fc

---

From: Damien Miller <[email-masked]>
Date: Tue, 5 Feb 2002 13:17:04 +1100 (EST)

> from the transport draft.

I support this approach. The current spec is too vague to implement.

-d

---

From: "Andersson, Mats" <[email-masked]>
Date: Tue, 5 Feb 2002 09:29:50 +0100 (CET)

On Mon, 4 Feb 2002, Joseph Galbraith wrote:
> I would say create a new working group document for x.509 and remove
> it from the transport draft.

I'm in favour of this too (if needed I can help editing it). In there we
can iron out the ambiguities with the format of the signature including
explicit referral to rfc2459/pkcs1 (see my earlier post on this).

However, I think that at least the generic format of signatures should be
explicitly stated in the current transport-draft(rfc) the same as the
generic format for keys/certs are.

Also, the paragraph which starts with the ("buggy") sentence: "The
certificate part may have be a zero length string,..." should be clarified
to say something like:

...
  byte[n]  key/certificate data

	The key/certificate data here is a format specific encoding of the 
        public key or certificate.
...

Apart from the sentence not beeing correct english (not that I'm the
person to write perfect english... :-) it also hints something about a
"zero length string" which is not otherwise defined (as Markus has stated
previously). Also, why public key AND certificate? A certificate is a
public key which has been signed, in which situation would it be useful to
have both? (see earlier discussion on possible implementation pitfalls
with public key AND certificate, though that might not be an issue).

Since the format of signatures has been discussed it's clearly something
not obvious from the spec. The ambiguity comes from the explicitly stated
format for public keys/certs along with the fact that the signatures for
ssh-dss/ssh-rsa are explicitly given and are "hinting" on a similar
encoding of signatures too:

On the subject of keys/certs it now says:

...
   Certificates and public keys are encoded as follows:

     string   certificate or public key format identifier
     byte[n]  key/certificate data
...

But it doesn't say anything explicitly about signatures, IMHO we should
EITHER add:

...
   Signatures are encoded as follows:

     string   signature format identifier (same as public key/cert format)
     byte[n]  signature blob in format specific encoding
...

OR explicitly write something like:

...
   Signatures are encoded in an algorithm specific format not
   necessarily including the format identifier such as:

   byte[n]  signature in format specific encoding.
...

Just to avoid the speculations about how signatures should be encoded
(apart from the discussion about the specific case of x509 on how it
should be encoded).

Cheers,

/Mats

---

From: Markus Friedl <[email-masked]>
Date: Tue, 5 Feb 2002 09:42:43 +0100

> implementation experience.

since the existing x509 implementations are kind of broken,
we should not care right now.

> do we want more delay?

NO.

---

From: [email-masked] (Sami J. Lehtinen)
Date: 08 Feb 2002 15:14:11 +0200

> I support this approach. The current spec is too vague to implement.

I second this.

-- 
[[email-masked]          --  Sami J. Lehtinen  --           [email-masked]]
[work:+358 20 5007425][gsm:+358 40 864 3001][http://www.iki.fi/~sjl]
[SSH Communications Security Corp               http://www.ssh.com/]