Subject: Are we still on track for last call? (was Re: minutes from the SECSH working group meeting at the 48th IETF)

From: "Jeff P. Van Dyke" <[email-masked]>
Date: Mon, 2 Oct 2000 17:01:46 -0600

> Schedule
> 
> Sep 00   Finalization of core drafts
> Oct 00   Last calls
> Oct 00   Submit core drafts to IESG
> Oct 00   Determine schedule for extensions
> Nov 00   Submit extension drafts for discussion
> Dec 00   Meet in SD
> Sep 01   Submit core drafts for publication as draft standard

Can we expect a revised set of core drafts to be
published soon?

Are last calls on the core drafts still a possibility
for October?

Thanks.

Jeff P. Van Dyke
[email-masked]

---

From: [email-masked] (Niels M�ller)
Date: 06 Oct 2000 16:25:54 +0200

Bill Sommerfeld <[email-masked]> writes:

> Minutes of the secsh working group
> Wednesday, August 2, 2000

> il8n of usernames
> 
> A comment to the list was made that multiple representations could happen, do
> we need canonicalization.
> 
> Niels Moller suggested waiting for il8n strategy from the DNS people and using 
> that.

One approach is to adopt draft-duerst-i18n-norm-04.txt, saying that
usernames and passwords MUST be encoded in utf8, "Early Uniform
Normalization according to Unicode Normalization Form C, Canonical
Composition (NFC)".

> Tero: I think canonicalization should be done at server, since it
>       knows internal format it wants to use.

This makes sense (as I admitted on the list earlier). However, using
the rules of draft-duerst-i18n-norm-04.txt may well make the job
easier for most internal representations a server might want to use,
and reduce the amount unicode-knowledge reqiured by the server. For
instance, I think we get rid of all "strange" canonical equivalents to
ascii, like "(1)".

/Niels

---

From: [email-masked] (Niels M�ller)
Date: 06 Oct 2000 16:09:00 +0200

I'm rereading the minutes, and have a few more comments (which I'll
send in separate messages).

> draft-ietf-secsh-connect-07.txt		
> 	signal encoding
> 		- extend format, include optional string with 
> 		  signal name w/o SIG prefix.
> 		SIGBUS -> "BUS"

As far as I can tell, there's no standard whatsoever assigning
numerical signal numbers to signals. (Some) symbolic signal names are
defined by posix. In practice, numbers 1-15 seems to be the same
everywhere, while higher numbers mean different things on different
systems. 

I don't know te motivation for adding an optional signal name, but it
doesn't solve the problem.

In lsh, I use the concept of "network signal numbers" which are a
somewhat arbitrary numbering that local numbers are translated to and
from when transmitted in the protocol (in the "exit-signal" and
"signal" SSH_MSG_CHANNEL_REQUEST:s). I use the following numbering

{ network number, local number }

  { 1, SIGHUP },
  { 2, SIGINT },
  { 3, SIGQUIT },
  { 4, SIGILL },
  { 5, SIGTRAP },
  { 6, SIGABRT },
  /* IOT is the mnemonic for the PDP-11 instruction used by the abort() function */
  { 7, SIGEMT },
  { 8, SIGFPE },
  { 9, SIGKILL },
  { 10, SIGBUS },
  { 11, SIGSEGV },
  { 12, SIGSYS },
  { 13, SIGPIPE },
  { 14, SIGALRM },
  { 15, SIGTERM },
  /* Signals beyond 15 does not have the same meaning everywhere */
  { 16, SIGURG },
  { 17, SIGSTOP },
  { 18, SIGTSTP },
  { 19, SIGCONT },
  { 20, SIGCHLD },
  { 21, SIGTTIN },
  { 22, SIGTTOU },
  { 23, SIGIO },
  { 23, SIGPOLL }, /* SysV name for SIGIO */
  { 24, SIGXCPU },
  { 25, SIGXFSZ },
  { 26, SIGVTALRM },
  { 27, SIGPROF },
  { 28, SIGWINCH },
  { 29, SIGLOST },
  { 30, SIGUSR1 },
  { 31, SIGUSR2 }

/Niels

---

From: [email-masked] (Niels M�ller)
Date: 06 Oct 2000 16:17:37 +0200

> Kerberos Authentication (Tatu Ylonen)

Is Tatu's proposal available anywhere? I'm looking into kerberos
support, and my current thinking is that if kerberos is used to
provide mutual authentication (and not simply as a different password
verification mechanism), it should be done as a keyexchange method,
not a userauth method.

So kerberos is an example of a keyexchange method that authenticates
both user and host (other examples are SRP and similar protocols). I
think it makes sense to use this class of keyexchange methods, and
then skip the user authentication on success. I.e. the client can send
a SSH_MSG_SERVICE_REQUEST asking for "ssh-connection", and the server
will associate the userid established during key exchange with any
created sessions, processes etc. Comments?

Are there any security problems here that I have overlooked? I imagine
that the keyexchange has to include some steps to bind the exchange
hash to the negotiated key.

/Niels

---

From: [email-masked] (Niels M�ller)
Date: 06 Oct 2000 16:27:31 +0200

> Improvided password auth
> 
> EKE/SPEKE/SRP interest which ties the password a bit better into the
>       crypto and less succeptible to dictionaries. A volunteer exists
>       to write a draft on this.

Are you referring to my draft on SRP here, or have I missed something?

/Niels

---

From: [email-masked] (Niels M�ller)
Date: 09 Oct 2000 13:27:47 +0200

Tatu Ylonen <[email-masked]> writes:

> The protocol is designed so that host authentication and user
> authentication are different steps.

I'm very aware of that. 

> It is not entirely trivial (and certainly not clean) to modify it so
> that both host authentication and user authentication take place
> using the same external protocol.

I think it is both easy and reasonably clean to skip the userauth step
under some circumstances. What makes me feel a little uneasy about it
is authentication of the keyexchange messages; if there is no hostkey
distributed by a pki or some out-of-band means, the exchange hash has
to be authenticated using the newly negotiated sessino key, which
seems a little circular. 

> I am personally not sure if it is worth the trouble to complicate
> the protocol. How badly are such authentication mechanisms needed?

It is a big improvement in situations where you have a kerberos
infrastructure, but no good means to distribute hostkeys securely. And
similarly in any scenario where SRP makes sense.

Another approach to mutual kerberos authentication (which I consider a
lot less clean than skipping the userauth step) is to perform the
usual dh-based keyexchange, using a hostkey that there is not much
trust in, then perform mutual kerberos authetnication as part of the
userauth protocol, and finally mix the kerberos and the dh session
keys in some way.

> (The same issue comes up with Kerberos mutual authentication.)

The examples I care about are kerberos mutual authentication, and SRP.

A potential problem with kerberos is the size of the session keys. I'm
no kerberos expert, but I'm been told that it is common that you only
get a "des-ticket", i.e. a single 56 bit session key. In this
situation, perhaps it would make sense to use some EKE-like
techniques, first doing kerberos mutual authentication, next use the
kerberos session key as a shared secret for an EKE-like exchange. E.g.
encrypting the dh values using the kerberos key, or deriving the
generator from the kerberos key, or some such.

The goal of that approach would be to base authentication on the short
kerberos key (so that an attacker would have to crack it in more or
less real time to impersonate either party), and still get forward
secrecy so that the real session keys are secret a few hours or
days later when the short kerberos key is cracked. Does that make
sense, or is kerberos with des-tickets too poor to make anything work
securely?

/Niels

---

From: [email-masked] (Niels M�ller)
Date: 10 Oct 2000 10:57:36 +0200

Tatu Ylonen <[email-masked]> writes:

> One possible way to "cleanly" skip userauth is to allow the requested
> service name to be ssh-conn also in the transport layer service
> request.

That's exactly what I'm thinking of. 

> (I still think it is kind of kludgy - it needs to pass user
> information from the transport protocol to the connection protocol.
> However, I cannot think of a cleaner solution without major changes in
> the protocols.)

In lsh, I have one object that is responsible for a connection, which
handles all packet-type dispatch as well as other connection-related
information that doesn't fit naturally anywhere else. I store a
user-pointer in that object, and the function initializing the
ssh-connection service checks that the user pointer is non-NULL, but
it doesn't care if a value was installed by the key exchange mechanism
or by the userauth protocol.

> For SRP an ad-hoc mechanism would probably need to be designed. (I
> am not familiar with the details of the SRP protocol though.)

I've tried to do that in draft-nisse-secsh-srp-00.txt, but it needs
careful review.

Regards,
/Niels

---

From: Ken Raeburn <[email-masked]>
Date: 10 Oct 2000 12:24:09 -0400

> get a "des-ticket", i.e. a single 56 bit session key. In this

Currently common, but should become much less so in the near future.
MIT and Heimdal have support for triple-DES keys (168 bits), and
there's a good chance we'll put in AES sometime soon too.  It is
definitely not the intent of Kerberos to provide weak protection; it's
merely that we need time to get existing installations to upgrade.
(And you could take the view that if someone is still using single-DES
Kerberos to authenticate a connection to the host, then they've
expressed a lack of interest in strong protection, or they'd have
upgraded.  That's often how I look at it.)

In the long run, using the Kerberos-supplied session key should be
adequate.  And you can explicitly request a triple-DES or AES key from
a KDC if it's supported by that installation.

Speaking just for myself, I'm not worried about the level of
protection afforded by Kerberos with triple-DES, and pretty much any
machine I care a lot about is protected that way.

> sense, or is kerberos with des-tickets too poor to make anything work

If cracking the DES key doesn't help the attacker crack the session
key because the key exchange routine is strong enough, why factor the
DES key into the session key generation at all (except perhaps as an
*additional* source of pseudo-randomness)?

Also, in most such configurations the server's host key is likely to
be single-DES too, so that'd be the key to go after.  Once that's
cracked, the attacker can get in as any user with a new connection.
It's still difficult to do without significant resources, but this is
the reason for the push to triple-DES and AES.

Ken

---

From: "Jeff P. Van Dyke" <[email-masked]>
Date: Tue, 10 Oct 2000 17:15:37 -0600

What versions of the sftp server support RENAME, packet type 18?

Is OpenSSH the only server supporting this?

Thanks.

Jeff P. Van Dyke
[email-masked]

----- Original Message ----- 
From: "Markus Friedl" <[email-masked]>
To: "Jeff P. Van Dyke" <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, September 13, 2000 5:01 AM
Subject: Re: minutes from the SECSH working group meeting at the 48th IETF

> On Tue, Sep 12, 2000 at 08:05:57PM -0600, Jeff P. Van Dyke wrote:
> > > File transfer
> > > 
> > > Current sftp draft is not in any state.  sftp protocol needs to be
> > > documented, reviewed by the working group.  file listing format should
> > > take a look at what the FTP WG did for directory listings.
> > 
> > I'd very much like to see some progress on getting sftp documented.
> 
> here are my notes on the SFTP protocol. -m
>

---

From: Sami Lehtinen <[email-masked]>
Date: Wed, 11 Oct 2000 03:46:43 +0300 (EEST)

Jeff P. Van Dyke, on October 10. 2000, wrote:
  : What versions of the sftp server support RENAME, packet type 18?
  : 
  : Is OpenSSH the only server supporting this?

ssh-2.2.0 and up from SSH Communications Security.

-- 
[[email-masked]          --  Sami J. Lehtinen  --           [email-masked]]
[work:+358 9 85657425][gsm:+358 50 5170 258][http://www.iki.fi/~sjl]
[SSH Communications Security Corp               http://www.ssh.com/]