From owner-ietf-ssh@clinet.fi  Tue Aug 10 21:31:38 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 VAA29206;
	Tue, 10 Aug 1999 21:31:38 +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 VAA04851;
	Tue, 10 Aug 1999 21:31:37 +0300 (EEST)
Received: (from majordom@localhost)
	by lohi.clinet.fi (8.9.1/8.9.0) id VAA18728
	for ietf-ssh-outgoing; Tue, 10 Aug 1999 21:28:49 +0300 (EEST)
X-Authentication-Warning: lohi.clinet.fi: majordom set sender to owner-ietf-ssh@clinet.fi using -f
Received: from sobolev.mit.edu (RLE-VLSI.MIT.EDU [18.62.0.210])
	by lohi.clinet.fi (8.9.1/8.9.0) with ESMTP id VAA18724
	for <ietf-ssh@clinet.fi>; Tue, 10 Aug 1999 21:28:47 +0300 (EEST)
Received: from krylov.MIT.EDU (KRYLOV.MIT.EDU [18.62.0.216])
	by sobolev.mit.edu (8.9.0/8.9.0) with ESMTP id OAA02419
	for <ietf-ssh@clinet.fi>; Tue, 10 Aug 1999 14:27:27 -0400 (EDT)
Received: by krylov.MIT.EDU 
	id OAA21199; Tue, 10 Aug 1999 14:27:28 -0400
Date: Tue, 10 Aug 1999 14:27:28 -0400
Message-Id: <199908101827.OAA21199@krylov.MIT.EDU>
From: Geoffrey Coram <gjcoram@RLE-VLSI.MIT.EDU>
To: ietf-ssh@clinet.fi
Subject: ssh for dump
Reply-to: gjcoram@RLE-VLSI.MIT.EDU
Sender: owner-ietf-ssh@clinet.fi
Precedence: bulk
Content-Length: 680
Lines: 20

Hi-
I'm trying to make my backup script more secure.
Presently, it uses dump (and restore), which has a
call to "rcmd", which uses the rshd daemon.  I
would like to disable rsh and move completely to
ssh.  However, I don't know of an "scmd" drop-in
replacement for rcmd -- and I don't even have
source code except for the linux dump.  rcmd not
only makes the connection, but returns sockets so
that the local dump program can interact with the
remote "rmt" command for controlling the magnetic
tape.

Perry Metzger suggested I ask on this group if
anyone has any experience using ssh, possibly with
"-f -" , or perhaps -R and -L port forwarding,
to do backups.

Thanks.
-Geoffrey
From owner-ietf-ssh@clinet.fi  Fri Aug 13 22:32:19 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 WAA07949;
	Fri, 13 Aug 1999 22:32:19 +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 WAA16882;
	Fri, 13 Aug 1999 22:32:18 +0300 (EEST)
Received: (from majordom@localhost)
	by lohi.clinet.fi (8.9.1/8.9.0) id WAA04945
	for ietf-ssh-outgoing; Fri, 13 Aug 1999 22:29:37 +0300 (EEST)
X-Authentication-Warning: lohi.clinet.fi: majordom set sender to owner-ietf-ssh@clinet.fi using -f
Received: from mule.aciri.org (mule.aciri.org [192.150.187.28])
	by lohi.clinet.fi (8.9.1/8.9.0) with ESMTP id WAA04938
	for <ietf-ssh@clinet.fi>; Fri, 13 Aug 1999 22:29:35 +0300 (EEST)
Received: (from yinzhang@localhost)
	by mule.aciri.org (8.9.3/8.9.2) id MAA38522
	for ietf-ssh@clinet.fi; Fri, 13 Aug 1999 12:27:54 -0700 (PDT)
	(envelope-from yinzhang)
From: Yin Zhang <yinzhang@aciri.org>
Reply-To: yinzhang@aciri.org
Organization: ACIRI
To: ietf-ssh@clinet.fi
Subject: SSH packet length
Date: Fri, 13 Aug 1999 12:26:00 -0700
X-Mailer: KMail [version 1.0.21]
Content-Type: text/plain
MIME-Version: 1.0
Message-Id: <99081312275400.38519@mule.aciri.org>
Content-Transfer-Encoding: 8bit
Sender: owner-ietf-ssh@clinet.fi
Precedence: bulk
Content-Length: 1277
Lines: 34

Hi,

I am new to SSH.  I have a question about SSH packet length:

>From a tcpdump trace, I found that a significant portion of tcp packets
sent to port 22 have either 20 or 52 bytes of data (excluding the ip 
and tcp header).  More specifically, among all packets that have at 
least 1 byte of data, 31% has 20 bytes of data, 41% has 52 bytes of 
data.

However, according to SSH Transport Layer Protocol, SSH packet has
format:

  uint32      packet_length
  byte          padding_length
  byte[n1]  payload; n1 = packet_length - padding_length - 1
  byte[n2]  random padding; n2 = padding_length
  byte[m]    mac (message authentication code); m = mac_length

4 + 1 + n1 + n2 is required to be >= 16 and be a multiple of 
max(8, cipher block size).  For all the encrytion scheme for SSH
that I'm aware of, cipher block size is either 1, 8 or 16.    Meanwhile,
the mac_length m is typically 0, 8, 12, 16, or 20.

Given these requirements, 20 seems to be an invalid length.  Can any
one tell me what these packets are?  

Thank you very much for helping me out!

-- Yin
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Yin Zhang, ACIRI            Tel: (510) 642-4274 x 154
Berkeley, CA 94704        Email: yinzhang@aciri.org
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
From owner-ietf-ssh@clinet.fi  Sun Aug 22 20:22:29 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 UAA13960;
	Sun, 22 Aug 1999 20:22:28 +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 UAA14210;
	Sun, 22 Aug 1999 20:22:28 +0300 (EEST)
Received: (from majordom@localhost)
	by lohi.clinet.fi (8.9.1/8.9.0) id UAA14907
	for ietf-ssh-outgoing; Sun, 22 Aug 1999 20:15:25 +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 UAA14903
	for <ietf-ssh@clinet.fi>; Sun, 22 Aug 1999 20:15:22 +0300 (EEST)
Received: from boa ([192.168.0.51]) by mail.vandyke.com
          (Netscape Messaging Server 3.62)  with SMTP id 143
          for <ietf-ssh@clinet.fi>; Sun, 22 Aug 1999 11:22:16 -0600
Message-ID: <000401beecc0$8cbbb3a0$3300a8c0@vandyke.com>
From: "Jeff P. Van Dyke" <jpv@vandyke.com>
To: <ietf-ssh@clinet.fi>
Subject: Where is SSH-AGENT?
Date: Sun, 22 Aug 1999 11:03:49 -0600
MIME-Version: 1.0
Content-Type: text/plain;
	charset="Windows-1252"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Sender: owner-ietf-ssh@clinet.fi
Precedence: bulk
Content-Length: 465
Lines: 19

>From draft-ietf-secsh-connect-06.txt, section 4.4:

  4.4.  Authentication Agent Forwarding

  It is RECOMMENDED that authentication agent forwarding is allowed even
  when either or both parties do not support the SSH authentication agent
  protocol [SSH-AGENT].

The References section of the draft does not include SSH-AGENT.

Does this document exist?  If so, where can I get a copy?

Thank you.

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


From owner-ietf-ssh@clinet.fi  Thu Aug 26 18:20:51 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 SAA28882;
	Thu, 26 Aug 1999 18:20:47 +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 SAA04310;
	Thu, 26 Aug 1999 18:20:45 +0300 (EEST)
Received: (from majordom@localhost)
	by lohi.clinet.fi (8.9.1/8.9.0) id SAA21629
	for ietf-ssh-outgoing; Thu, 26 Aug 1999 18:14:20 +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 SAA21624
	for <ietf-ssh@clinet.fi>; Thu, 26 Aug 1999 18:14:17 +0300 (EEST)
Received: from sanna.lysator.liu.se (nisse@sanna.lysator.liu.se [130.236.254.206])
	by samantha.lysator.liu.se (8.9.3/8.9.3) with ESMTP id RAA23030;
	Thu, 26 Aug 1999 17:12:54 +0200 (MET DST)
Received: (from nisse@localhost)
	by sanna.lysator.liu.se (8.8.8/8.8.7) id RAA16240;
	Thu, 26 Aug 1999 17:12:49 +0200 (MET DST)
To: psst@net.lut.ac.uk, ietf-ssh@clinet.fi, map@stacken.kth.se,
        lha@stacken.kth.se
Subject: Making host authentication more convenient
MIME-Version: 1.0
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 8bit
From: nisse@lysator.liu.se (Niels Mller)
Date: 26 Aug 1999 17:12:49 +0200
Message-ID: <nnemgq7ez2.fsf@sanna.lysator.liu.se>
X-Mailer: Gnus v5.4.59/Emacs 19.34
Sender: owner-ietf-ssh@clinet.fi
Precedence: bulk
Content-Length: 3082
Lines: 62

During the CCC meeting, I talked a lot with some of the kth-krb
people. Of course, we spent some time debating the superiority of
kerberos vs ssh. And it seems quite clear that the biggest Problem
with ssh, as it is used today, is the lousy host authentication. That
is, the "Unknown host key, continue anyway?" question that one answers
yes to all too often. More precisely, a common scenario is as
follows:

I have some home-system where I keep most of the files and stuff I
need. I visit some place with net-connectivity and ssh installed (the
guest-system). I have not had any previous contact with the
guest-system, but I have some level of trust in its security (it may
be operated by a friend, conference organizer, whatever). I want to
use this system to securely log in to my home system.

With Kerberos, I'm told, I would run the kauth program, type my
password, and get a (time-limited) ticket that provides _mutual_
authentication between me and my home system.

With typical ssh usage, I just connect, store the hostkey the first
time, and have no real protection at all against MITM attacks. Which
is not really acceptable.

One simple and reasonably practical solution is the use of
fingerprints: I make a hard-copy of the fingerprint of my home system
and keep in my wallet. And I make sure to verify the fingerprint of
the received hostkey before I trust it. Note that I really need only
one fingerprint; once I have the authentic hostkey of my home system, I
can download my known_hosts file from there, or use some kind of
certificates. This would work, and I'll implement support for it in lsh
some day, but it still seems a little low-tech and cumbersome.

It would be convenient to be able to use a short password to
authenticate the home system (which one of the things kauth provides).
So how to do that? There are several possibilities.

One is to simply use kauth to get a ticket, and somehow use it for
_mutual_ authentication during ssh keyexchange. If you are already
running kerberos, I guess this is what you would want to do. For
someone not running kerberos (e.g. me), it seems inconvenient to
kerberize the home system just to use ssh from guest-systems, in
particular as that would require sysadm work.

And I also think kerberos is overkill when you want to authenticate
one single message (in this case, a public hostkey).

Another option is to provide a mechanism to download a hostkey from a
system, authenticating it using a small shared secret (i.e. a
password). You probably can't use your ordinary unix password, as I
suspect that all such protocols would require the server to know the
cleartext password.

Or one could integrate that mechanism into the ssh-protocol, as a
separate key-exchange algorithm, that you would use when you don't
have the remote system's hostkey in the known_hosts file.

I have to think more about this, but I'd appreciate some feedback. Are
these approaches reasonable, and is any one of them preferable over
the others? Do you know of any existing protocols that could be used
to solve the problem? 

/Niels
From owner-ietf-ssh@clinet.fi  Thu Aug 26 19:58:18 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 TAA18085;
	Thu, 26 Aug 1999 19:58: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 TAA05444;
	Thu, 26 Aug 1999 19:58:17 +0300 (EEST)
Received: (from majordom@localhost)
	by lohi.clinet.fi (8.9.1/8.9.0) id TAA03656
	for ietf-ssh-outgoing; Thu, 26 Aug 1999 19:56:06 +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 TAA03642
	for <ietf-ssh@clinet.fi>; Thu, 26 Aug 1999 19:56:00 +0300 (EEST)
Received: (from jaltman@localhost)
	by watsun.cc.columbia.edu (8.8.5/8.8.5) id MAA09998;
	Thu, 26 Aug 1999 12:54:34 -0400 (EDT)
Date: Thu, 26 Aug 99 12:54:34 EDT
From: Jeffrey Altman <jaltman@watsun.cc.columbia.edu>
Reply-To: jaltman@columbia.edu
To: nisse@lysator.liu.se
Cc: psst@net.lut.ac.uk, ietf-ssh@clinet.fi, map@stacken.kth.se,
        lha@stacken.kth.se, krbdev@MIT.EDU
Subject: Re: Making host authentication more convenient
In-Reply-To: Your message of 26 Aug 1999 17:12:49 +0200
Message-ID: <CMM.0.90.4.935686474.jaltman@watsun.cc.columbia.edu>
Sender: owner-ietf-ssh@clinet.fi
Precedence: bulk
Content-Length: 8168
Lines: 169

The SSH mutual authentication problem which you describe is only one
of many problems that I see with the SSH authentication methods.

You are someone who knows what security is.  Therefore, you know
better than to simply click 'ok' and accept the host key when the
dialog pops up.  The problem is that most users do not know anything
about host keys.  All they know is that they want to connect to the
host.  They don't care about security nor want to be bothered with it.
Therefore, they will click 'ok' on anything as long as it connects
them to the host.  From the perspective of the security manager for a
large population this is unacceptable.

>From my perspective there are several things that we want for a secure
connection:

(1) mutual authentication of the client and host on every connection
    without the user being involved in the decision.  

(2) the client's password should never be transmitted to the host

(3) client secrets should never be stored on disk even if encrypted
    if the quality of the pass phrase cannot be verified by the
    system adminstrator

(4) client credentials must be revokable by the system adminstrator
    and recycling of credentials must not be allowed.

These things must be done for the following reasons:

(1) the end user has no basis upon which to determine whether or not
    a given host is the one they want to connect to.  No matter what
    system we use for secure login's we will not be able to prevent
    host's from becoming root compromised.  

    When a system is root compromised it is possible for the attacker
    to steal the host's credentials for use is faking out a client.
    In the case of Kerberos it is possible to issue new host
    credentials every day without affecting the ability of clients
    to mutually authenticate.  With SSH public key pairs, changing
    the host public key appears to the user as if an attack is taking
    place.

(2) Because a host may be compromised it is not acceptable for an
    end user's credentials in the form of a password to be sent to 
    to a host.  Sending a password over an encrypted mutually 
    authenticated channel only prevents the password from being
    read in transit.  It does not prevent a compromised host from
    sending the credentials somewhere else.

    This is solved by Kerberos using the password to communicate
    via encrypted messages with a trusted third party.  SSH public
    key authorization also avoids sending of the password.  But
    when public key is not being used the password is sent across
    the encrypted wire.

    Secure Remote Password would allow a password to be used with
    out transmitting any revealing data to the host.

(3) In general user's choose really poor pass phrases and store their
    private keys on insecure systems (windows, mac, ...).  When 
    private key files are stolen from insecure systems or even when
    stolen from secure systems after they are root compromised,
    access to the keys in most cases becomes a simple dictionary 
    attack.  The quality of the encryption algorithm used to 
    protect them becomes irrelevant.

    Kerberos does not store pass phrases on disk and its credentials
    expire in a short period of time in those situations where they
    must be.  Kerberos allows the quality of the pass phrase to be
    enforced centrally by the system administrator.

(4) When a host is compromised and the private keys and lists of hosts
    on which they have been used have been stolen, it is imperative 
    that a system adminstrator have the ability to force expiration
    of the pass phrase and prevent its re-use.  Otherwise, it is 
    impossible for the system adminstrator to know that an account
    will be secure after it is reactivated.

    Since users are not security conscious and approach it as a hassle
    to overcome instead of something they should be actively
    considering user's are likely to use the same public key pairs on
    multiple systems.  They are also likely to not change them when
    a host has been compromised (if they are even aware that it was.)

>From my perspective SSH authentication as it currently stands is
wonderful for a single knowledgeable user who wants to implement some
security in an environment that does not support any.  However, the
use of passwords and raw public keys are inappropriate for any large
organization that wants to implement a serious security policy.  In
those environments the SSH authentication mechansims must be replaced
by some thing that is trustworthy and manageable: Kerberos, perhaps
Secure Remote Password, or public key certs if and only if there is an
infrastructure available to issue, distribute, verify, and revoke the
certs.

- Jeffrey Altman


nisse@lysator.liu.se (Niels Mwller) wrote:

During the CCC meeting, I talked a lot with some of the kth-krb
people. Of course, we spent some time debating the superiority of
kerberos vs ssh. And it seems quite clear that the biggest Problem
with ssh, as it is used today, is the lousy host authentication. That
is, the "Unknown host key, continue anyway?" question that one answers
yes to all too often. More precisely, a common scenario is as
follows:

I have some home-system where I keep most of the files and stuff I
need. I visit some place with net-connectivity and ssh installed (the
guest-system). I have not had any previous contact with the
guest-system, but I have some level of trust in its security (it may
be operated by a friend, conference organizer, whatever). I want to
use this system to securely log in to my home system.

With Kerberos, I'm told, I would run the kauth program, type my
password, and get a (time-limited) ticket that provides _mutual_
authentication between me and my home system.

With typical ssh usage, I just connect, store the hostkey the first
time, and have no real protection at all against MITM attacks. Which
is not really acceptable.

One simple and reasonably practical solution is the use of
fingerprints: I make a hard-copy of the fingerprint of my home system
and keep in my wallet. And I make sure to verify the fingerprint of
the received hostkey before I trust it. Note that I really need only
one fingerprint; once I have the authentic hostkey of my home system,
I can download my known_hosts file from there, or use some kind of
certificates. This would work, and I'll implement support for it in
lsh some day, but it still seems a little low-tech and cumbersome.

It would be convenient to be able to use a short password to
authenticate the home system (which one of the things kauth provides).
So how to do that? There are several possibilities.

One is to simply use kauth to get a ticket, and somehow use it for
_mutual_ authentication during ssh keyexchange. If you are already
running kerberos, I guess this is what you would want to do. For
someone not running kerberos (e.g. me), it seems inconvenient to
kerberize the home system just to use ssh from guest-systems, in
particular as that would require sysadm work.

And I also think kerberos is overkill when you want to authenticate
one single message (in this case, a public hostkey).

Another option is to provide a mechanism to download a hostkey from a
system, authenticating it using a small shared secret (i.e. a
password). You probably can't use your ordinary unix password, as I
suspect that all such protocols would require the server to know the
cleartext password.

Or one could integrate that mechanism into the ssh-protocol, as a
separate key-exchange algorithm, that you would use when you don't
have the remote system's hostkey in the known_hosts file.

I have to think more about this, but I'd appreciate some feedback. Are
these approaches reasonable, and is any one of them preferable over
the others? Do you know of any existing protocols that could be used
to solve the problem?

/Niels

    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 Aug 26 20:20:20 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 UAA03844;
	Thu, 26 Aug 1999 20:20:20 +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 UAA05570;
	Thu, 26 Aug 1999 20:20:19 +0300 (EEST)
Received: (from majordom@localhost)
	by lohi.clinet.fi (8.9.1/8.9.0) id UAA06429
	for ietf-ssh-outgoing; Thu, 26 Aug 1999 20:20:02 +0300 (EEST)
X-Authentication-Warning: lohi.clinet.fi: majordom set sender to owner-ietf-ssh@clinet.fi using -f
Received: from om.iobjects.com (IDENT:qmailr@[209.181.88.162])
	by lohi.clinet.fi (8.9.1/8.9.0) with SMTP id UAA06418
	for <ietf-ssh@clinet.fi>; Thu, 26 Aug 1999 20:19:55 +0300 (EEST)
Received: (qmail 19808 invoked from network); 26 Aug 1999 17:18:23 -0000
Received: from unknown (HELO granite2) (192.168.0.175)
  by 209.181.88.162 with SMTP; 26 Aug 1999 17:18:23 -0000
Message-ID: <002101beefe7$0102ff10$af00a8c0@obj>
From: "Kenn Herman" <kennh@iobjects.com>
To: <psst@net.lut.ac.uk>, <ietf-ssh@clinet.fi>, <map@stacken.kth.se>,
        <lha@stacken.kth.se>,
        =?iso-8859-1?Q?Niels_M=F6ller?= <nisse@lysator.liu.se>
References: <nnemgq7ez2.fsf@sanna.lysator.liu.se>
Subject: Re: Making host authentication more convenient
Date: Thu, 26 Aug 1999 10:18:24 -0700
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2014.211
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211
Sender: owner-ietf-ssh@clinet.fi
Precedence: bulk
Content-Length: 3943
Lines: 83

I am not sure that this is apropos for this conversation, but another
scenario that I run into is the fact that I run ssh on my
gateway/router/firewall machine and also port forwarding ssh to intranet
machines.  So depending on the port I use, I ssh into different  boxes
behind the firewall.  SSH seems to give me a warning since it always appears
that I am ssh'ing into the same machine but it has different public keys
(different intranet machines) depending on the port.


Kenn Herman

----- Original Message -----
From: Niels Mller <nisse@lysator.liu.se>
To: <psst@net.lut.ac.uk>; <ietf-ssh@clinet.fi>; <map@stacken.kth.se>;
<lha@stacken.kth.se>
Sent: Thursday, August 26, 1999 8:12 AM
Subject: Making host authentication more convenient


> During the CCC meeting, I talked a lot with some of the kth-krb
> people. Of course, we spent some time debating the superiority of
> kerberos vs ssh. And it seems quite clear that the biggest Problem
> with ssh, as it is used today, is the lousy host authentication. That
> is, the "Unknown host key, continue anyway?" question that one answers
> yes to all too often. More precisely, a common scenario is as
> follows:
>
> I have some home-system where I keep most of the files and stuff I
> need. I visit some place with net-connectivity and ssh installed (the
> guest-system). I have not had any previous contact with the
> guest-system, but I have some level of trust in its security (it may
> be operated by a friend, conference organizer, whatever). I want to
> use this system to securely log in to my home system.
>
> With Kerberos, I'm told, I would run the kauth program, type my
> password, and get a (time-limited) ticket that provides _mutual_
> authentication between me and my home system.
>
> With typical ssh usage, I just connect, store the hostkey the first
> time, and have no real protection at all against MITM attacks. Which
> is not really acceptable.
>
> One simple and reasonably practical solution is the use of
> fingerprints: I make a hard-copy of the fingerprint of my home system
> and keep in my wallet. And I make sure to verify the fingerprint of
> the received hostkey before I trust it. Note that I really need only
> one fingerprint; once I have the authentic hostkey of my home system, I
> can download my known_hosts file from there, or use some kind of
> certificates. This would work, and I'll implement support for it in lsh
> some day, but it still seems a little low-tech and cumbersome.
>
> It would be convenient to be able to use a short password to
> authenticate the home system (which one of the things kauth provides).
> So how to do that? There are several possibilities.
>
> One is to simply use kauth to get a ticket, and somehow use it for
> _mutual_ authentication during ssh keyexchange. If you are already
> running kerberos, I guess this is what you would want to do. For
> someone not running kerberos (e.g. me), it seems inconvenient to
> kerberize the home system just to use ssh from guest-systems, in
> particular as that would require sysadm work.
>
> And I also think kerberos is overkill when you want to authenticate
> one single message (in this case, a public hostkey).
>
> Another option is to provide a mechanism to download a hostkey from a
> system, authenticating it using a small shared secret (i.e. a
> password). You probably can't use your ordinary unix password, as I
> suspect that all such protocols would require the server to know the
> cleartext password.
>
> Or one could integrate that mechanism into the ssh-protocol, as a
> separate key-exchange algorithm, that you would use when you don't
> have the remote system's hostkey in the known_hosts file.
>
> I have to think more about this, but I'd appreciate some feedback. Are
> these approaches reasonable, and is any one of them preferable over
> the others? Do you know of any existing protocols that could be used
> to solve the problem?
>
> /Niels
>

From owner-ietf-ssh@clinet.fi  Thu Aug 26 20:26:30 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 UAA08178;
	Thu, 26 Aug 1999 20:26: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 UAA05619;
	Thu, 26 Aug 1999 20:26:26 +0300 (EEST)
Received: (from majordom@localhost)
	by lohi.clinet.fi (8.9.1/8.9.0) id UAA07163
	for ietf-ssh-outgoing; Thu, 26 Aug 1999 20:26:11 +0300 (EEST)
X-Authentication-Warning: lohi.clinet.fi: majordom set sender to owner-ietf-ssh@clinet.fi using -f
Received: from jupiter.esker.fr (jupiter.esker.fr [194.51.34.253])
	by lohi.clinet.fi (8.9.1/8.9.0) with ESMTP id UAA07158
	for <ietf-ssh@clinet.fi>; Thu, 26 Aug 1999 20:26:07 +0300 (EEST)
Received: from nicolasr.esker.fr (roumiantzeff.esker.fr [194.51.34.63]) by jupiter.esker.fr (/Esker 1.0) with SMTP id SAA20454; Thu, 26 Aug 1999 18:20:49 +0200
Message-ID: <00da01beefe7$2e7bc620$3f2233c2@nicolasr.esker.fr>
From: "Nicolas Roumiantzeff" <nicolasr@esker.fr>
To: <ietf-ssh@clinet.fi>
Cc: <jaltman@columbia.edu>
Subject: Re: Making host authentication more convenient
Date: Thu, 26 Aug 1999 19:19:33 +0200
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
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: 5410
Lines: 113

So what do you think about Microsoft choosing Kerberos (and not a public key
crypto system) for Windows 2000.

Nicolas Roumiantzeff.

-----Message d'origine-----
De : Jeffrey Altman <jaltman@watsun.cc.columbia.edu>
 : nisse@lysator.liu.se <nisse@lysator.liu.se>
Cc : psst@net.lut.ac.uk <psst@net.lut.ac.uk>; ietf-ssh@clinet.fi
<ietf-ssh@clinet.fi>; map@stacken.kth.se <map@stacken.kth.se>;
lha@stacken.kth.se <lha@stacken.kth.se>; krbdev@MIT.EDU <krbdev@MIT.EDU>
Date : jeudi 26 aot 1999 18:01
Objet : Re: Making host authentication more convenient


>The SSH mutual authentication problem which you describe is only one
>of many problems that I see with the SSH authentication methods.
>
>You are someone who knows what security is.  Therefore, you know
>better than to simply click 'ok' and accept the host key when the
>dialog pops up.  The problem is that most users do not know anything
>about host keys.  All they know is that they want to connect to the
>host.  They don't care about security nor want to be bothered with it.
>Therefore, they will click 'ok' on anything as long as it connects
>them to the host.  From the perspective of the security manager for a
>large population this is unacceptable.
>
>>From my perspective there are several things that we want for a secure
>connection:
>
>(1) mutual authentication of the client and host on every connection
>    without the user being involved in the decision.
>
>(2) the client's password should never be transmitted to the host
>
>(3) client secrets should never be stored on disk even if encrypted
>    if the quality of the pass phrase cannot be verified by the
>    system adminstrator
>
>(4) client credentials must be revokable by the system adminstrator
>    and recycling of credentials must not be allowed.
>
>These things must be done for the following reasons:
>
>(1) the end user has no basis upon which to determine whether or not
>    a given host is the one they want to connect to.  No matter what
>    system we use for secure login's we will not be able to prevent
>    host's from becoming root compromised.
>
>    When a system is root compromised it is possible for the attacker
>    to steal the host's credentials for use is faking out a client.
>    In the case of Kerberos it is possible to issue new host
>    credentials every day without affecting the ability of clients
>    to mutually authenticate.  With SSH public key pairs, changing
>    the host public key appears to the user as if an attack is taking
>    place.
>
>(2) Because a host may be compromised it is not acceptable for an
>    end user's credentials in the form of a password to be sent to
>    to a host.  Sending a password over an encrypted mutually
>    authenticated channel only prevents the password from being
>    read in transit.  It does not prevent a compromised host from
>    sending the credentials somewhere else.
>
>    This is solved by Kerberos using the password to communicate
>    via encrypted messages with a trusted third party.  SSH public
>    key authorization also avoids sending of the password.  But
>    when public key is not being used the password is sent across
>    the encrypted wire.
>
>    Secure Remote Password would allow a password to be used with
>    out transmitting any revealing data to the host.
>
>(3) In general user's choose really poor pass phrases and store their
>    private keys on insecure systems (windows, mac, ...).  When
>    private key files are stolen from insecure systems or even when
>    stolen from secure systems after they are root compromised,
>    access to the keys in most cases becomes a simple dictionary
>    attack.  The quality of the encryption algorithm used to
>    protect them becomes irrelevant.
>
>    Kerberos does not store pass phrases on disk and its credentials
>    expire in a short period of time in those situations where they
>    must be.  Kerberos allows the quality of the pass phrase to be
>    enforced centrally by the system administrator.
>
>(4) When a host is compromised and the private keys and lists of hosts
>    on which they have been used have been stolen, it is imperative
>    that a system adminstrator have the ability to force expiration
>    of the pass phrase and prevent its re-use.  Otherwise, it is
>    impossible for the system adminstrator to know that an account
>    will be secure after it is reactivated.
>
>    Since users are not security conscious and approach it as a hassle
>    to overcome instead of something they should be actively
>    considering user's are likely to use the same public key pairs on
>    multiple systems.  They are also likely to not change them when
>    a host has been compromised (if they are even aware that it was.)
>
>>From my perspective SSH authentication as it currently stands is
>wonderful for a single knowledgeable user who wants to implement some
>security in an environment that does not support any.  However, the
>use of passwords and raw public keys are inappropriate for any large
>organization that wants to implement a serious security policy.  In
>those environments the SSH authentication mechansims must be replaced
>by some thing that is trustworthy and manageable: Kerberos, perhaps
>Secure Remote Password, or public key certs if and only if there is an
>infrastructure available to issue, distribute, verify, and revoke the
>certs.
>
>- Jeffrey Altman


From owner-ietf-ssh@clinet.fi  Thu Aug 26 20:33:56 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 UAA24088;
	Thu, 26 Aug 1999 20:33: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 UAA05667;
	Thu, 26 Aug 1999 20:33:53 +0300 (EEST)
Received: (from majordom@localhost)
	by lohi.clinet.fi (8.9.1/8.9.0) id UAA08110
	for ietf-ssh-outgoing; Thu, 26 Aug 1999 20:33:15 +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 UAA08101
	for <ietf-ssh@clinet.fi>; Thu, 26 Aug 1999 20:33:11 +0300 (EEST)
Received: (from jaltman@localhost)
	by watsun.cc.columbia.edu (8.8.5/8.8.5) id NAA18864;
	Thu, 26 Aug 1999 13:31:50 -0400 (EDT)
Date: Thu, 26 Aug 99 13:31:49 EDT
From: Jeffrey Altman <jaltman@watsun.cc.columbia.edu>
Reply-To: jaltman@columbia.edu
To: "Nicolas Roumiantzeff" <nicolasr@esker.fr>
Cc: <ietf-ssh@clinet.fi>, krbdev@MIT.EDU
Subject: Re: Making host authentication more convenient
In-Reply-To: Your message of Thu, 26 Aug 1999 19:19:33 +0200
Message-ID: <CMM.0.90.4.935688709.jaltman@watsun.cc.columbia.edu>
Sender: owner-ietf-ssh@clinet.fi
Precedence: bulk
Content-Length: 1183
Lines: 26

> So what do you think about Microsoft choosing Kerberos (and not a public key
> crypto system) for Windows 2000.

I am very happy that Microsoft chose Kerberos 5 as their
authentication system.  I am not happy about the in ability to easily
use a KDC that resides off the NT machine.  

Since the KDC maintains all of the trust relationships it is
imperative that it not be compromised.  That means that no external 
connections other than Kerberos service requests should be allowed 
to that machine.  By forcing users to use a KDC that is integrated
with 50 million other lines of code the vulnerability of the system is
severely increased.  

Of course, Microsoft's market is mostly small single server
environments where it is not feasible to run multiple separate
servers.  But that is no excuse for compromising the security of large
organizations by refusing to support a multiple server configuration.


    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 Aug 26 21:00:54 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 VAA03855;
	Thu, 26 Aug 1999 21:00:52 +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 VAA05880;
	Thu, 26 Aug 1999 21:00:52 +0300 (EEST)
Received: (from majordom@localhost)
	by lohi.clinet.fi (8.9.1/8.9.0) id UAA11818
	for ietf-ssh-outgoing; Thu, 26 Aug 1999 20:59:49 +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 UAA11808
	for <ietf-ssh@clinet.fi>; Thu, 26 Aug 1999 20:59:44 +0300 (EEST)
Received: (from jaltman@localhost)
	by watsun.cc.columbia.edu (8.8.5/8.8.5) id NAA26023;
	Thu, 26 Aug 1999 13:58:07 -0400 (EDT)
Date: Thu, 26 Aug 99 13:58:07 EDT
From: Jeffrey Altman <jaltman@watsun.cc.columbia.edu>
Reply-To: jaltman@columbia.edu
To: "Kenn Herman" <kennh@iobjects.com>
Cc: <psst@net.lut.ac.uk>, <ietf-ssh@clinet.fi>, <map@stacken.kth.se>,
        <lha@stacken.kth.se>,
        =?iso-8859-1?Q?Niels_M=F6ller?= <nisse@lysator.liu.se>
Subject: Re: Making host authentication more convenient
In-Reply-To: Your message of Thu, 26 Aug 1999 10:18:24 -0700
Message-ID: <CMM.0.90.4.935690287.jaltman@watsun.cc.columbia.edu>
Sender: owner-ietf-ssh@clinet.fi
Precedence: bulk
Content-Length: 910
Lines: 19

> I am not sure that this is apropos for this conversation, but another
> scenario that I run into is the fact that I run ssh on my
> gateway/router/firewall machine and also port forwarding ssh to intranet
> machines.  So depending on the port I use, I ssh into different  boxes
> behind the firewall.  SSH seems to give me a warning since it always appears
> that I am ssh'ing into the same machine but it has different public keys
> (different intranet machines) depending on the port.

In other words you are authenticating against the wrong machine and
SSH doesn't have a method to allow you to authenticate against the
correct one.


    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 Aug 26 21:38:27 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 VAA10645;
	Thu, 26 Aug 1999 21:38: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 VAA06312;
	Thu, 26 Aug 1999 21:38:26 +0300 (EEST)
Received: (from majordom@localhost)
	by lohi.clinet.fi (8.9.1/8.9.0) id VAA16229
	for ietf-ssh-outgoing; Thu, 26 Aug 1999 21:37:07 +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 VAA16223
	for <ietf-ssh@clinet.fi>; Thu, 26 Aug 1999 21:37:05 +0300 (EEST)
Received: from sanna.lysator.liu.se (nisse@sanna.lysator.liu.se [130.236.254.206])
	by samantha.lysator.liu.se (8.9.3/8.9.3) with ESMTP id UAA02195;
	Thu, 26 Aug 1999 20:35:37 +0200 (MET DST)
Received: (from nisse@localhost)
	by sanna.lysator.liu.se (8.8.8/8.8.7) id UAA17053;
	Thu, 26 Aug 1999 20:35:34 +0200 (MET DST)
To: jaltman@columbia.edu
Cc: "Kenn Herman" <kennh@iobjects.com>, <psst@net.lut.ac.uk>,
        <ietf-ssh@clinet.fi>, <map@stacken.kth.se>, <lha@stacken.kth.se>,
        Niels Mller <nisse@lysator.liu.se>
Subject: Re: Making host authentication more convenient
References: <CMM.0.90.4.935690287.jaltman@watsun.cc.columbia.edu>
MIME-Version: 1.0
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 8bit
From: nisse@lysator.liu.se (Niels Mller)
Date: 26 Aug 1999 20:35:31 +0200
In-Reply-To: Jeffrey Altman's message of "Thu, 26 Aug 99 13:58:07 EDT"
Message-ID: <nnd7wa75l7.fsf@sanna.lysator.liu.se>
X-Mailer: Gnus v5.4.59/Emacs 19.34
Sender: owner-ietf-ssh@clinet.fi
Precedence: bulk
Content-Length: 1640
Lines: 36

Jeffrey Altman <jaltman@watsun.cc.columbia.edu> writes:

> > I am not sure that this is apropos for this conversation, but another
> > scenario that I run into is the fact that I run ssh on my
> > gateway/router/firewall machine and also port forwarding ssh to intranet
> > machines.  So depending on the port I use, I ssh into different  boxes
> > behind the firewall.  SSH seems to give me a warning since it always appears
> > that I am ssh'ing into the same machine but it has different public keys
> > (different intranet machines) depending on the port.
> 
> In other words you are authenticating against the wrong machine and
> SSH doesn't have a method to allow you to authenticate against the
> correct one.

Well, it is a little tricky to do this right, as long as ssh isn't
even told which machine you really want to talk to. It would be doable
to add a flag to say "I want to talk to a host with this particular
host key". Or to associate a hostkey with an identity of the type
fw_hostname:port.

Hmm... Perhaps you can even do that today, using aliases in the
.ssh/config file.

I believe the ssh-client uses the hostname exactly as passed on the
command line when looking up hostkeys, and that's it. So you could try
creating an alias "foohost" that maps to a particular port on the fw,
and hope that ssh uses the name foohost when searching for the right
key in .ssh/known_hosts. No, I haven't tried that.

You could get a similar effect by using extra CNAME:s in your dns or
/etc/hosts, I guess, but that's getting pretty kludgy.

Anyway, I think this problem is mostly an implementation issue, not a
protocol one. 

/Niels
From owner-ietf-ssh@clinet.fi  Thu Aug 26 22:00:02 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 VAA22145;
	Thu, 26 Aug 1999 21:59:23 +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 VAA06486;
	Thu, 26 Aug 1999 21:59:23 +0300 (EEST)
Received: (from majordom@localhost)
	by lohi.clinet.fi (8.9.1/8.9.0) id VAA18608
	for ietf-ssh-outgoing; Thu, 26 Aug 1999 21:58:31 +0300 (EEST)
X-Authentication-Warning: lohi.clinet.fi: majordom set sender to owner-ietf-ssh@clinet.fi using -f
Received: from europe.std.com (europe.std.com [199.172.62.20])
	by lohi.clinet.fi (8.9.1/8.9.0) with ESMTP id VAA18600
	for <ietf-ssh@clinet.fi>; Thu, 26 Aug 1999 21:58:27 +0300 (EEST)
Received: from world.std.com (root@world-f.std.com [199.172.62.5])
	by europe.std.com (8.9.3/8.9.3) with ESMTP id OAA01506;
	Thu, 26 Aug 1999 14:57:04 -0400 (EDT)
Received: from dpj (dpj@world.std.com [192.74.137.5])
	by world.std.com (8.9.3/8.9.3) with SMTP id OAA25972;
	Thu, 26 Aug 1999 14:54:24 -0400 (EDT)
Message-Id: <3.0.5.32.19990826145634.007a9860@world.std.com>
X-Sender: dpj@world.std.com
X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (32)
Date: Thu, 26 Aug 1999 14:56:34 -0400
To: nisse@lysator.liu.se (Niels =?iso-8859-1?Q?M=F6ller?= )
From: David Jablon <dpj@IntegritySciences.com>
Subject: Re: Making host authentication more convenient
Cc: psst@net.lut.ac.uk, ietf-ssh@clinet.fi, map@stacken.kth.se,
        lha@stacken.kth.se
In-Reply-To: <nnemgq7ez2.fsf@sanna.lysator.liu.se>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by lohi.clinet.fi id VAA18605
Sender: owner-ietf-ssh@clinet.fi
Precedence: bulk
Content-Length: 1286
Lines: 31

Niels,

If you're thinking about building or modifying a system to take
advantage of the latest methods, and your goal is to provide both
strength *and* convenience, take a look at the zero-knowledge
password protocols.  These were specifically designed for
strong mutual authentication based on a short secret.
EKE, SRP and SPEKE come to mind.

These are available in a variety of forms, and can be used
where the host knows either a password, a hashed password, or
a public-key that corresponds to a password.
The page at www.IntegritySciences.com/links.html lists most
of the research in this area.

At 05:12 PM 8/26/99 +0200, Niels Mller wrote:

>It would be convenient to be able to use a short password to
>authenticate the home system (which one of the things kauth provides).
>So how to do that? There are several possibilities.
[...snip...]
>I have to think more about this, but I'd appreciate some feedback. Are
>these approaches reasonable, and is any one of them preferable over
>the others? Do you know of any existing protocols that could be used
>to solve the problem? 

---------------------------------------------------
David P. Jablon           dpj@IntegritySciences.com
President                 +1 508 898 9024
Integrity Sciences, Inc.  www.IntegritySciences.com

From owner-ietf-ssh@clinet.fi  Thu Aug 26 22:50:52 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 WAA20787;
	Thu, 26 Aug 1999 22:50:52 +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 WAA07198;
	Thu, 26 Aug 1999 22:50:52 +0300 (EEST)
Received: (from majordom@localhost)
	by lohi.clinet.fi (8.9.1/8.9.0) id WAA24322
	for ietf-ssh-outgoing; Thu, 26 Aug 1999 22:49:20 +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 WAA24316
	for <ietf-ssh@clinet.fi>; Thu, 26 Aug 1999 22:49:18 +0300 (EEST)
Received: from sanna.lysator.liu.se (nisse@sanna.lysator.liu.se [130.236.254.206])
	by samantha.lysator.liu.se (8.9.3/8.9.3) with ESMTP id VAA05440;
	Thu, 26 Aug 1999 21:47:59 +0200 (MET DST)
Received: (from nisse@localhost)
	by sanna.lysator.liu.se (8.8.8/8.8.7) id VAA18647;
	Thu, 26 Aug 1999 21:47:55 +0200 (MET DST)
To: David Jablon <dpj@IntegritySciences.com>
Cc: psst@net.lut.ac.uk, ietf-ssh@clinet.fi, map@stacken.kth.se,
        lha@stacken.kth.se
Subject: Re: Making host authentication more convenient
References: <3.0.5.32.19990826145634.007a9860@world.std.com>
MIME-Version: 1.0
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 8bit
From: nisse@lysator.liu.se (Niels Mller)
Date: 26 Aug 1999 21:47:54 +0200
In-Reply-To: David Jablon's message of "Thu, 26 Aug 1999 14:56:34 -0400"
Message-ID: <nnbtbu728l.fsf@sanna.lysator.liu.se>
X-Mailer: Gnus v5.4.59/Emacs 19.34
Sender: owner-ietf-ssh@clinet.fi
Precedence: bulk
Content-Length: 1188
Lines: 27

David Jablon <dpj@IntegritySciences.com> writes:

> If you're thinking about building or modifying a system to take
> advantage of the latest methods, and your goal is to provide both
> strength *and* convenience, take a look at the zero-knowledge
> password protocols.  These were specifically designed for
> strong mutual authentication based on a short secret.
> EKE, SRP and SPEKE come to mind.

Thanks for the advice. I have heard a little about those protocols;
enough to suspect that they may be suitable for ssh, but not enough
to really know what they are like.

> These are available in a variety of forms, and can be used
> where the host knows either a password, a hashed password, or
> a public-key that corresponds to a password.
> The page at www.IntegritySciences.com/links.html lists most
> of the research in this area.

Thanks. I'll try to read up. One quick question: Are any of these
methods free from patent-restrictions? As I'm writing free software, I
really can't use algorithms unless they are either patent-free, or
available on very liberal licensing terms. I suspect IETF-bias is
similar, although I in no way speak for the IETF.

Best regards,
/Niels Mller
From owner-ietf-ssh@clinet.fi  Thu Aug 26 23:35:45 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 XAA13390;
	Thu, 26 Aug 1999 23:35: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 XAA07500;
	Thu, 26 Aug 1999 23:35:44 +0300 (EEST)
Received: (from majordom@localhost)
	by lohi.clinet.fi (8.9.1/8.9.0) id XAA29737
	for ietf-ssh-outgoing; Thu, 26 Aug 1999 23:34:21 +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 XAA29724
	for <ietf-ssh@clinet.fi>; Thu, 26 Aug 1999 23:34:16 +0300 (EEST)
Received: (from jaltman@localhost)
	by watsun.cc.columbia.edu (8.8.5/8.8.5) id QAA05139;
	Thu, 26 Aug 1999 16:32:46 -0400 (EDT)
Date: Thu, 26 Aug 99 16:32:45 EDT
From: Jeffrey Altman <jaltman@watsun.cc.columbia.edu>
Reply-To: jaltman@columbia.edu
To: nisse@lysator.liu.se
Cc: David Jablon <dpj@IntegritySciences.com>, psst@net.lut.ac.uk,
        ietf-ssh@clinet.fi, map@stacken.kth.se, lha@stacken.kth.se
Subject: Re: Making host authentication more convenient
In-Reply-To: Your message of 26 Aug 1999 21:47:54 +0200
Message-ID: <CMM.0.90.4.935699565.jaltman@watsun.cc.columbia.edu>
Sender: owner-ietf-ssh@clinet.fi
Precedence: bulk
Content-Length: 1639
Lines: 42

> David Jablon <dpj@IntegritySciences.com> writes:
> 
> > If you're thinking about building or modifying a system to take
> > advantage of the latest methods, and your goal is to provide both
> > strength *and* convenience, take a look at the zero-knowledge
> > password protocols.  These were specifically designed for
> > strong mutual authentication based on a short secret.
> > EKE, SRP and SPEKE come to mind.
> 
> Thanks for the advice. I have heard a little about those protocols;
> enough to suspect that they may be suitable for ssh, but not enough
> to really know what they are like.
> 
> > These are available in a variety of forms, and can be used
> > where the host knows either a password, a hashed password, or
> > a public-key that corresponds to a password.
> > The page at www.IntegritySciences.com/links.html lists most
> > of the research in this area.
> 
> Thanks. I'll try to read up. One quick question: Are any of these
> methods free from patent-restrictions? As I'm writing free software, I
> really can't use algorithms unless they are either patent-free, or
> available on very liberal licensing terms. I suspect IETF-bias is
> similar, although I in no way speak for the IETF.
> 
> Best regards,
> /Niels Mller
> 

Stanford is no longer enforcing their patent on SRP.

I suggest you contact the author

  Thomas Wu  tjw@cs.stanford.edu


    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 Aug 27 16:17:38 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 QAA29250;
	Fri, 27 Aug 1999 16:17:30 +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 QAA15848;
	Fri, 27 Aug 1999 16:17:29 +0300 (EEST)
Received: (from majordom@localhost)
	by lohi.clinet.fi (8.9.1/8.9.0) id QAA07347
	for ietf-ssh-outgoing; Fri, 27 Aug 1999 16:15:48 +0300 (EEST)
X-Authentication-Warning: lohi.clinet.fi: majordom set sender to owner-ietf-ssh@clinet.fi using -f
Received: from europe.std.com (europe.std.com [199.172.62.20])
	by lohi.clinet.fi (8.9.1/8.9.0) with ESMTP id QAA07338
	for <ietf-ssh@clinet.fi>; Fri, 27 Aug 1999 16:15:44 +0300 (EEST)
Received: from world.std.com (root@world-f.std.com [199.172.62.5])
	by europe.std.com (8.9.3/8.9.3) with ESMTP id JAA20312;
	Fri, 27 Aug 1999 09:14:18 -0400 (EDT)
Received: from dpj (dpj@world.std.com [192.74.137.5])
	by world.std.com (8.9.3/8.9.3) with SMTP id JAA17702;
	Fri, 27 Aug 1999 09:12:18 -0400 (EDT)
Message-Id: <3.0.5.32.19990827090908.00bbb500@world.std.com>
X-Sender: dpj@world.std.com
X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (32)
Date: Fri, 27 Aug 1999 09:09:08 -0400
To: nisse@lysator.liu.se (Niels =?iso-8859-1?Q?M=F6ller?= )
From: David Jablon <dpj@IntegritySciences.com>
Subject: Re: Making host authentication more convenient
Cc: psst@net.lut.ac.uk, ietf-ssh@clinet.fi, map@stacken.kth.se,
        lha@stacken.kth.se
In-Reply-To: <nnbtbu728l.fsf@sanna.lysator.liu.se>
References: <David Jablon's message of "Thu, 26 Aug 1999 14:56:34 -0400">
 <3.0.5.32.19990826145634.007a9860@world.std.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by lohi.clinet.fi id QAA07342
Sender: owner-ietf-ssh@clinet.fi
Precedence: bulk
Content-Length: 1012
Lines: 25

At 09:47 PM 8/26/99 +0200, Niels Mller wrote:
>David Jablon <dpj@IntegritySciences.com> writes:
>> EKE, SRP and SPEKE come to mind.
>> The page at www.IntegritySciences.com/links.html lists most
>> of the research in this area.
>
>Thanks. I'll try to read up. One quick question: Are any of these
>methods free from patent-restrictions [...] or
>available on very liberal licensing terms[?]

The only current in-force patents in the field are the Bellovin & Merritt
EKE patents.  Two organizations with pending patents are Stanford (SRP),
and Integrity Sciences (SPEKE).  Opinions on what it means to be "patent-free"
and "liberal terms" vary widely.  You should contact these organizations
directly to determine their current and future terms, opinions on patent
coverage,
and policies for free use.

-- David

---------------------------------------------------
David P. Jablon           dpj@IntegritySciences.com
President                 +1 508 898 9024
Integrity Sciences, Inc.  www.IntegritySciences.com

From owner-ietf-ssh@clinet.fi  Sat Aug 28 20:06:06 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 UAA08307;
	Sat, 28 Aug 1999 20:06:04 +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 UAA25041;
	Sat, 28 Aug 1999 20:05:57 +0300 (EEST)
Received: (from majordom@localhost)
	by lohi.clinet.fi (8.9.1/8.9.0) id UAA18428
	for ietf-ssh-outgoing; Sat, 28 Aug 1999 20:02:19 +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 UAA18421
	for <ietf-ssh@clinet.fi>; Sat, 28 Aug 1999 20:02:16 +0300 (EEST)
Received: from sanna.lysator.liu.se (nisse@sanna.lysator.liu.se [130.236.254.206])
	by samantha.lysator.liu.se (8.9.3/8.9.3) with ESMTP id TAA27841;
	Sat, 28 Aug 1999 19:00:40 +0200 (MET DST)
Received: (from nisse@localhost)
	by sanna.lysator.liu.se (8.8.8/8.8.7) id TAA05779;
	Sat, 28 Aug 1999 19:00:38 +0200 (MET DST)
To: jaltman@columbia.edu
Cc: psst@net.lut.ac.uk, ietf-ssh@clinet.fi, map@stacken.kth.se,
        lha@stacken.kth.se, krbdev@MIT.EDU
Subject: Re: Making host authentication more convenient
References: <CMM.0.90.4.935686474.jaltman@watsun.cc.columbia.edu>
MIME-Version: 1.0
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 8bit
From: nisse@lysator.liu.se (Niels Mller)
Date: 28 Aug 1999 19:00:38 +0200
In-Reply-To: Jeffrey Altman's message of "Thu, 26 Aug 99 12:54:34 EDT"
Message-ID: <nn671z7scp.fsf@sanna.lysator.liu.se>
X-Mailer: Gnus v5.4.59/Emacs 19.34
Sender: owner-ietf-ssh@clinet.fi
Precedence: bulk
Content-Length: 13311
Lines: 265

Jeffrey Altman <jaltman@watsun.cc.columbia.edu> writes:

> The SSH mutual authentication problem which you describe is only one
> of many problems that I see with the SSH authentication methods.
>
> You are someone who knows what security is.  Therefore, you know
> better than to simply click 'ok' and accept the host key when the
> dialog pops up.  The problem is that most users do not know anything
> about host keys.  All they know is that they want to connect to the
> host.  They don't care about security nor want to be bothered with it.
> Therefore, they will click 'ok' on anything as long as it connects
> them to the host.  From the perspective of the security manager for a
> large population this is unacceptable.

The problem is that _even_ if you know the security implications, you
sometimes goon with an unauthenticated host key (yes, I'm speaking for
myself. This is confession-mode). Sometimes, I have the hostkeys
written down in my calendar, sometimes I do cat /etc/ssh_hostkey after
that I have logged in. The latter doesn't stop a clever MITM-attack,
of course. It's simply too inconvenient to do things right. So my main
objective here is to make security easier for those users who _are_
at least somewhat aware of the security issues.

> >From my perspective there are several things that we want for a secure
> connection:
>
> (1) mutual authentication of the client and host on every connection
>     without the user being involved in the decision.  
> 
> (2) the client's password should never be transmitted to the host
> 
> (3) client secrets should never be stored on disk even if encrypted
>     if the quality of the pass phrase cannot be verified by the
>     system adminstrator
> 
> (4) client credentials must be revokable by the system adminstrator
>     and recycling of credentials must not be allowed.
> 
> These things must be done for the following reasons:

Before commenting on details, let me give a little rant about the
differences between kerberos and ssh, from my point of view. And when
I speak of ssh, I primarily speak about what you can do with the ssh2
protocol, not about current implementations.

First, there are several clue-ness scenarios:

1. clue-less user, clue-less or overworked sysadm.

In this case, we're basically screwed. No one can stop the user from
screwing up the system or giving his keys or passwords away to let
somebody else do it. I'll not say much about it.

2. clue-less user, clue-full sysadm.

This is almost as bad. What the sysadm can do is to limit the amount
of damage the user can cause, and limit the damage the user can cause
for other users on the system. This includes things like eliminating
buffer-overflows that lets the user gain root access, etc. This is
very important, but doesn't have much to do with authentication
mechanisms, so I'll not say much about this either.

3. clue-full user, overworked or clue-less sysadm.

This is one scenario that I think is important. I want to be able to
make secure connections and stuff even if my local sysadm doesn't have
a minute left after (hopefully) patching up known security holes on
the system. And I want this to be _easy_ to do for any user who cares
about it, without requiring lots of non-trivial hackery.

4. clue-full user, clue-full sysadm.

This is an important (but probably quite rare) case. I suspect this is
the case for any large organization that cares about security (or more
precisely: who cares about security, and has any chance of actually
getting some). So this ought to be the case that is most important for
you. 

To me, it seems that kerberos is a unified solution for authentication
(and one with a few known problems). You have to deploy it in an
all-or-nothing fashion. We have the protocols, a centralized
security model, libraries and applications. Deploying it in the
scenario (3) is virtually impossible.

On the other hand, ssh supports scenario (3), for example both ssh and
sshd can be installed by a unprivileged user. [ Password authentication
in sshd won't work for systems with shadow passwords, but I consider
this a bug in the shadow mechanism. There ought to be a way for a user
to get his/her _own_ encrypted password out of the system, or some
more general verify_my_password(a_passwd) function ].

ssh is far from ideal; the support for both (3) and (4) could be a lot
better. To get there is partly an implementation issue, but we may
also need to define new authentication methods to use within the ssh
protocol. That's my interest in all this.

I think one problem with kerberos is that when you want to communicate
between to different sites (or realms, in kerberos-speak), the sysadms
of those realms must have had some previous contacts, and must have
installed a shared key for this realm-pair. Of course, ssh doesn't
quite solve this problem either, but the important difference is that
ssh at least makes it possible for users to solve the problem for
themselves, without any need for cooperation between the respective
sysadms.

> (1) the end user has no basis upon which to determine whether or not
>     a given host is the one they want to connect to.  No matter what
>     system we use for secure login's we will not be able to prevent
>     host's from becoming root compromised.  
> 
>     When a system is root compromised it is possible for the attacker
>     to steal the host's credentials for use is faking out a client.
>     In the case of Kerberos it is possible to issue new host
>     credentials every day without affecting the ability of clients
>     to mutually authenticate.  With SSH public key pairs, changing
>     the host public key appears to the user as if an attack is taking
>     place.

One solution to this is to use certificates, issued by the site's
sysadm, rather than raw hostkeys (I don't know of any ssh
implementations that actually supports this).

Personally, I like SPKI style certificates, and I think that
certificates with a validity field that requires an on-line check
should make it easier to revoke and change hostkeys. Of course, if the
certification key is compromised, we're screwed, but I don't think it
is possible to address this issue without some centralization
(kerberos ticket-granting server, the private key for the site's
certification keys, etc). Any such centralization provides some point
of attack that is more attractive than a random host.

> (2) Because a host may be compromised it is not acceptable for an
>     end user's credentials in the form of a password to be sent to 
>     to a host.  Sending a password over an encrypted mutually 
>     authenticated channel only prevents the password from being
>     read in transit.  It does not prevent a compromised host from
>     sending the credentials somewhere else.
>
>     This is solved by Kerberos using the password to communicate
>     via encrypted messages with a trusted third party.  SSH public
>     key authorization also avoids sending of the password.  But
>     when public key is not being used the password is sent across
>     the encrypted wire.

I think this is a unique feature of kerberos. I see that it can be
important under some circumstances, but I don't think that it is
crucial in the general case. Consider a site with a central
authentication server C (for instance using kerberos), and several
hosts. Now, a user sits down at a random host A, and logs in on
another host B. Now, A and C will see the user's cleartext password,
but not B. So if B was compromised, we're still somewhat safe.

But this is quite useless, unless we have some reason to believe that
it is a lot less likely that A is compromized than B. Under what
circumstances is this true?

As far as I can see, the typical case is that A is a machine in an
office, a lab or terminal room, and B is some kind of cpu- or
file-server. To me it seems a lot easier to ensure the security of B
(for example, you want to restrict who can get physical access to the
machine) than for A. I.e. the opposite of the above hypothesis seems
to be true.

There are of course other scenarios as well, for instance A may be a
reasonably well protected _personal_ computer, but this case is also
the case where it is reasonable to store a private key on A and use
something like ssh's publickey user authentication.

>     Secure Remote Password would allow a password to be used with
>     out transmitting any revealing data to the host.

Regardless of the above, it's a good thing to distribute the password
as little as possible. Ideally, only A should get the password
(there's no way around this, as far as I can see, except for things
like smartcards), and both B and C should stay ignorant. I'd like see
such an authentication protocol with ssh.

> (3) In general user's choose really poor pass phrases and store their
>     private keys on insecure systems (windows, mac, ...).  When 
>     private key files are stolen from insecure systems or even when
>     stolen from secure systems after they are root compromised,
>     access to the keys in most cases becomes a simple dictionary 
>     attack.  The quality of the encryption algorithm used to 
>     protect them becomes irrelevant.
> 
>     Kerberos does not store pass phrases on disk and its credentials
>     expire in a short period of time in those situations where they
>     must be.  Kerberos allows the quality of the pass phrase to be
>     enforced centrally by the system administrator.

Low-entropy passwords tend to be the weakest link in any security
system that relies on passwords. This is tricky; some of the
references in this thread try to address it. I don't know yet how well
one can do.

But I think kerberos is far from ideal here; I suspect you can mount a
dictionary attack [1] after recording some communication between you
and the kerberos server (correct me if this is utterly wrong). And if
the local machine is compromized, it may transmit your password to the
attacker as you type it. I'm willing to take for granted the security
of the local machine, because I don't see how I could get any security
at all without it.

[ NOTE: By a dictionary attack this I mean bruteforcing the passwd
space; I don't imply that you can do massive precomputations like on a
/etc/passwd file with small salt. I think this is about as much as you
can do agaist a reasonable scheme that encrypts a private key or other
_unknown_ data using a passphrase ].

> (4) When a host is compromised and the private keys and lists of hosts
>     on which they have been used have been stolen, it is imperative 
>     that a system adminstrator have the ability to force expiration
>     of the pass phrase and prevent its re-use.  Otherwise, it is 
>     impossible for the system adminstrator to know that an account
>     will be secure after it is reactivated.
> 
>     Since users are not security conscious and approach it as a hassle
>     to overcome instead of something they should be actively
>     considering user's are likely to use the same public key pairs on
>     multiple systems.  They are also likely to not change them when
>     a host has been compromised (if they are even aware that it was.)

ssh doesn't have any mechanism to let the sysadm revoke some keys from
a user's authorized_keys file (or for key revokation in general, for
that matter). This is not a protocol issue, but an implementation
issue. And a difficult one, I don't know how to do it right.

I want to give the user the authority to decide which keys are
authorized for logging into her account. If I don't do this, the
user still has the authority to decide with whome to share her secret
password, or to take instructions from unathorized persons on what to
use her account for.

What I really want to to is to give user's the ability to delegate
*some* of her power to certain keys or certificates. For instance, to
access some subset of her files, or run some programs.

> >From my perspective SSH authentication as it currently stands is
> wonderful for a single knowledgeable user who wants to implement some
> security in an environment that does not support any.  However, the
> use of passwords and raw public keys are inappropriate for any large
> organization that wants to implement a serious security policy.  In
> those environments the SSH authentication mechansims must be replaced
> by some thing that is trustworthy and manageable: Kerberos, perhaps
> Secure Remote Password, or public key certs if and only if there is an
> infrastructure available to issue, distribute, verify, and revoke the
> certs.

I'd like ssh to offer the features needed for large organizations. If
I can find out how.

Two final questions for those of you using kerberos: If you already
have kerberos up and running on your site(s), why would you consider
using ssh at all? If you want to combine them, would one of the
following possibilities suit your needs?

* Use kerberos to create an encrypted connection between your
machines. Run the ssh connection-protocol on top of that tunnel (i.e.
do things like starting shells, forward X and tcp, etc, but don't do
any of the ssh style authorization or encryption).

* Use ssh, but add an authentication algorithm that lets you login
using a kerberos ticket that you obtained earlier.

/Niels
From owner-ietf-ssh@clinet.fi  Sun Aug 29 01:33: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 BAA14941;
	Sun, 29 Aug 1999 01:33:12 +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 BAA25681;
	Sun, 29 Aug 1999 01:33:10 +0300 (EEST)
Received: (from majordom@localhost)
	by lohi.clinet.fi (8.9.1/8.9.0) id BAA12921
	for ietf-ssh-outgoing; Sun, 29 Aug 1999 01:29:27 +0300 (EEST)
X-Authentication-Warning: lohi.clinet.fi: majordom set sender to owner-ietf-ssh@clinet.fi using -f
Received: from horowitz.ne.mediaone.net (horowitz.ne.mediaone.net [24.218.136.87])
	by lohi.clinet.fi (8.9.1/8.9.0) with ESMTP id BAA12917
	for <ietf-ssh@clinet.fi>; Sun, 29 Aug 1999 01:29:24 +0300 (EEST)
Received: (from marc@localhost)
	by horowitz.ne.mediaone.net (8.8.8/8.8.8) id SAA04381;
	Sat, 28 Aug 1999 18:27:08 -0400 (EDT)
From: Marc Horowitz <marc@MIT.EDU>
To: nisse@lysator.liu.se (Niels Mvller)
Cc: jaltman@columbia.edu, psst@net.lut.ac.uk, ietf-ssh@clinet.fi,
        map@stacken.kth.se, lha@stacken.kth.se, krbdev@MIT.EDU
Subject: Re: Making host authentication more convenient
References: <CMM.0.90.4.935686474.jaltman@watsun.cc.columbia.edu> <nn671z7scp.fsf@sanna.lysator.liu.se>
Date: 28 Aug 1999 18:27:07 -0400
In-Reply-To: nisse@lysator.liu.se's message of "28 Aug 1999 19:00:38 +0200"
Message-ID: <t53g113k0ck.fsf@horowitz.ne.mediaone.net>
X-Mailer: Gnus v5.5/Emacs 20.3
Sender: owner-ietf-ssh@clinet.fi
Precedence: bulk
Content-Length: 5315
Lines: 108

nisse@lysator.liu.se (Niels Mvller) writes:

>> I think one problem with kerberos is that when you want to communicate
>> between to different sites (or realms, in kerberos-speak), the sysadms
>> of those realms must have had some previous contacts, and must have
>> installed a shared key for this realm-pair. Of course, ssh doesn't
>> quite solve this problem either, but the important difference is that
>> ssh at least makes it possible for users to solve the problem for
>> themselves, without any need for cooperation between the respective
>> sysadms.

There are proposals for using public keys for interrealm kerberos.
This still likely requires some contact between realms, but publishing
a public key is much easier than sharing highly sensitive secrets.

>> > (2) Because a host may be compromised it is not acceptable for an
>> >     end user's credentials in the form of a password to be sent to 
>> >     to a host.  Sending a password over an encrypted mutually 
>> >     authenticated channel only prevents the password from being
>> >     read in transit.  It does not prevent a compromised host from
>> >     sending the credentials somewhere else.
>> >
>> >     This is solved by Kerberos using the password to communicate
>> >     via encrypted messages with a trusted third party.  SSH public
>> >     key authorization also avoids sending of the password.  But
>> >     when public key is not being used the password is sent across
>> >     the encrypted wire.

Unfortunately, it is common to use ssh agent forwarding with ssh,
which permits an attacker on the compromised target to make use of the
ssh credentials.

>> I think this is a unique feature of kerberos. I see that it can be
>> important under some circumstances, but I don't think that it is
>> crucial in the general case. Consider a site with a central
>> authentication server C (for instance using kerberos), and several
>> hosts. Now, a user sits down at a random host A, and logs in on
>> another host B. Now, A and C will see the user's cleartext password,
>> but not B. So if B was compromised, we're still somewhat safe.
>> 
>> But this is quite useless, unless we have some reason to believe that
>> it is a lot less likely that A is compromized than B. Under what
>> circumstances is this true?
>>
>> As far as I can see, the typical case is that A is a machine in an
>> office, a lab or terminal room, and B is some kind of cpu- or
>> file-server. To me it seems a lot easier to ensure the security of B
>> (for example, you want to restrict who can get physical access to the
>> machine) than for A. I.e. the opposite of the above hypothesis seems
>> to be true.

One of the advantages of kerberos is that it can be used easily to
secure services as well as logins.  If B is a chat server run by
someone I have little trust in, I have no problem using kerberos to
authenticate to this service.  I'm unlikely to want to give it my
password, and with most chat services, login isn't done.

I've never seen ssh used without a login step.  It's not uncommon to
log into (for instance) a mail server, and use an ssh tunnel to send
or receive mail, but this doesn't work for all services.

>> But I think kerberos is far from ideal here; I suspect you can mount a
>> dictionary attack [1] after recording some communication between you
>> and the kerberos server (correct me if this is utterly wrong). 

There are modifications to the kerberos protocol (EKE, SPEKE, and
variants) which make offline brute-forcing impractical for a passive
attacker.  I've never seen a widely deployed implementation,
presumably due to patent issues.

>> And if the local machine is compromized, it may transmit your
>> password to the attacker as you type it. I'm willing to take for
>> granted the security of the local machine, because I don't see how
>> I could get any security at all without it.

This is still true.

>> What I really want to to is to give user's the ability to delegate
>> *some* of her power to certain keys or certificates. For instance, to
>> access some subset of her files, or run some programs.

This is much more of an OS issue than kerberos vs ssh vs other
authentication systems issue.

>> I'd like ssh to offer the features needed for large organizations. If
>> I can find out how.
>> 
>> Two final questions for those of you using kerberos: If you already
>> have kerberos up and running on your site(s), why would you consider
>> using ssh at all? If you want to combine them, would one of the
>> following possibilities suit your needs?
>> 
>> * Use kerberos to create an encrypted connection between your
>> machines. Run the ssh connection-protocol on top of that tunnel (i.e.
>> do things like starting shells, forward X and tcp, etc, but don't do
>> any of the ssh style authorization or encryption).
>> 
>> * Use ssh, but add an authentication algorithm that lets you login
>> using a kerberos ticket that you obtained earlier.

The former seems less clean than the latter, since ssh is designed to
handle different authentication protocols.  Both would work, though.
Practically speaking, since ssh ships with the latter implemented,
it's what I used, often.  The ability to combine kerberos
authentication and ticket forwarding with ssh X and TCP forwarding is
both secure and convenient.

		Marc
From owner-ietf-ssh@clinet.fi  Sun Aug 29 02:06:10 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 CAA14565;
	Sun, 29 Aug 1999 02:06:08 +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 CAA25751;
	Sun, 29 Aug 1999 02:06:01 +0300 (EEST)
Received: (from majordom@localhost)
	by lohi.clinet.fi (8.9.1/8.9.0) id CAA16186
	for ietf-ssh-outgoing; Sun, 29 Aug 1999 02:04:17 +0300 (EEST)
X-Authentication-Warning: lohi.clinet.fi: majordom set sender to owner-ietf-ssh@clinet.fi using -f
Received: from tsx-prime.MIT.EDU (TSX-PRIME.MIT.EDU [18.86.0.76])
	by lohi.clinet.fi (8.9.1/8.9.0) with SMTP id CAA16177
	for <ietf-ssh@clinet.fi>; Sun, 29 Aug 1999 02:04:14 +0300 (EEST)
Received: by tsx-prime.MIT.EDU 
	with sendmail-SMI-8.6/1.2, id TAA10092; Sat, 28 Aug 1999 19:02:26 -0400
Date: Sat, 28 Aug 1999 19:02:26 -0400
Message-Id: <199908282302.TAA10092@tsx-prime.MIT.EDU>
From: "Theodore Y. Ts'o" <tytso@MIT.EDU>
To: Marc Horowitz <marc@MIT.EDU>
CC: nisse@lysator.liu.se, jaltman@columbia.edu, psst@net.lut.ac.uk,
        ietf-ssh@clinet.fi, map@stacken.kth.se, lha@stacken.kth.se,
        krbdev@MIT.EDU
In-reply-to: Marc Horowitz's message of 28 Aug 1999 18:27:07 -0400,
	<t53g113k0ck.fsf@horowitz.ne.mediaone.net>
Subject: Re: Making host authentication more convenient
Address: 1 Amherst St., Cambridge, MA 02139
Phone: (617) 253-8091
Sender: owner-ietf-ssh@clinet.fi
Precedence: bulk
Content-Length: 1545
Lines: 31

   From: Marc Horowitz <marc@MIT.EDU>
   Date: 28 Aug 1999 18:27:07 -0400

   >> But I think kerberos is far from ideal here; I suspect you can mount a
   >> dictionary attack [1] after recording some communication between you
   >> and the kerberos server (correct me if this is utterly wrong). 

   There are modifications to the kerberos protocol (EKE, SPEKE, and
   variants) which make offline brute-forcing impractical for a passive
   attacker.  I've never seen a widely deployed implementation,
   presumably due to patent issues.

And of course you can partionally protect against dictionary attacks by
simply adding a password quality checker to the kadmin daemon so that
lousy passwords can't be used in the first place.  

And before someone points out the recent SRP paper, let me put in a
premptive response.  That paper neglects to mention that the university
the author attacked only recently put in a password quality checker, and
nearly all the passwords he grabbed were ones which predated the
password quality checker.  In fact, most of the captured passwords would
have been rejected by the passowrd quality checker if it had been in use
when the users' passwords were changed.  I talked to the the I/T
administrators at that university, and they were were livid about how
the results were presented, because they were clearly misrepresented.
IMHO, that paper was more a white paper whose main goal was marketing
author's patented technology; I was surprised the program committee
allowed it to be published.

							- Ted

From owner-ietf-ssh@clinet.fi  Sun Aug 29 10:55:02 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 KAA29398;
	Sun, 29 Aug 1999 10:55:01 +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 KAA28921;
	Sun, 29 Aug 1999 10:54:53 +0300 (EEST)
Received: (from majordom@localhost)
	by lohi.clinet.fi (8.9.1/8.9.0) id KAA07871
	for ietf-ssh-outgoing; Sun, 29 Aug 1999 10:50:50 +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 KAA07864
	for <ietf-ssh@clinet.fi>; Sun, 29 Aug 1999 10:50:48 +0300 (EEST)
Received: from sanna.lysator.liu.se (nisse@sanna.lysator.liu.se [130.236.254.206])
	by samantha.lysator.liu.se (8.9.3/8.9.3) with ESMTP id JAA17671;
	Sun, 29 Aug 1999 09:48:52 +0200 (MET DST)
Received: (from nisse@localhost)
	by sanna.lysator.liu.se (8.8.8/8.8.7) id JAA19307;
	Sun, 29 Aug 1999 09:48:51 +0200 (MET DST)
To: Marc Horowitz <marc@MIT.EDU>
Cc: jaltman@columbia.edu, psst@net.lut.ac.uk, ietf-ssh@clinet.fi,
        map@stacken.kth.se, lha@stacken.kth.se, krbdev@MIT.EDU
Subject: Re: Making host authentication more convenient
References: <CMM.0.90.4.935686474.jaltman@watsun.cc.columbia.edu> <nn671z7scp.fsf@sanna.lysator.liu.se> <t53g113k0ck.fsf@horowitz.ne.mediaone.net>
MIME-Version: 1.0
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 8bit
From: nisse@lysator.liu.se (Niels Mller)
Date: 29 Aug 1999 09:48:50 +0200
In-Reply-To: Marc Horowitz's message of "28 Aug 1999 18:27:07 -0400"
Message-ID: <nn4shj6n8d.fsf@sanna.lysator.liu.se>
X-Mailer: Gnus v5.4.59/Emacs 19.34
Sender: owner-ietf-ssh@clinet.fi
Precedence: bulk
Content-Length: 2583
Lines: 56

Marc Horowitz <marc@mit.edu> writes:

> One of the advantages of kerberos is that it can be used easily to
> secure services as well as logins.  If B is a chat server run by
> someone I have little trust in, I have no problem using kerberos to
> authenticate to this service.  I'm unlikely to want to give it my
> password, and with most chat services, login isn't done.

Good point.

> I've never seen ssh used without a login step.  It's not uncommon to
> log into (for instance) a mail server, and use an ssh tunnel to send
> or receive mail, but this doesn't work for all services.

In the ssh2 protocol, it is possible to do user authentication (you
wouldn't want to use ordinary passwd userauth if talking to an
untrusted service), but for a different service than login. I don't
know any implementation that actually does this. Hmm, Datafellow's
sftp probably does just that, but there's no public spec for that as
far as I know. It's also possible to omit the userauth step
completely. 

I wrote:

> >> What I really want to to is to give user's the ability to delegate
> >> *some* of her power to certain keys or certificates. For instance, to
> >> access some subset of her files, or run some programs.
> 
> This is much more of an OS issue than kerberos vs ssh vs other
> authentication systems issue.

The reason I mentioned it is that it seems incompatible with
centralizing the configuration of authentication methods, to give the
sysadm complete control. To give a concrete example: I may want to
give read-only access to some subdirectory in my $HOME, and to use a
lousy but easy to remember password for that service. Then I wouldn't
want any centralized passwd server to complain about my choice of
password. The "security" here is similar to the usage of readably but
hidden or unlistable directories on a ftp or http-server.

And of course, some delegation can be implemented on the application
level, without any OS-support for it. I do agree that it is mostly
orthogonal to authentication methods, though.

> The former seems less clean than the latter, since ssh is designed to
> handle different authentication protocols.  Both would work, though.
> Practically speaking, since ssh ships with the latter implemented,
> it's what I used, often.  The ability to combine kerberos
> authentication and ticket forwarding with ssh X and TCP forwarding is
> both secure and convenient.

What is ticket-forwarding (I could guess, but I would prefer a precise
answer from someone who _knows_)? Does it have the same potential
problems as ssh agent forwarding?

/Niels
From owner-ietf-ssh@clinet.fi  Mon Aug 30 00:15: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 AAA15309;
	Mon, 30 Aug 1999 00:15: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 AAA01297;
	Mon, 30 Aug 1999 00:15:55 +0300 (EEST)
Received: (from majordom@localhost)
	by lohi.clinet.fi (8.9.1/8.9.0) id AAA18511
	for ietf-ssh-outgoing; Mon, 30 Aug 1999 00:12:45 +0300 (EEST)
X-Authentication-Warning: lohi.clinet.fi: majordom set sender to owner-ietf-ssh@clinet.fi using -f
Received: from horowitz.ne.mediaone.net (horowitz.ne.mediaone.net [24.218.136.87])
	by lohi.clinet.fi (8.9.1/8.9.0) with ESMTP id AAA18507
	for <ietf-ssh@clinet.fi>; Mon, 30 Aug 1999 00:12:43 +0300 (EEST)
Received: (from marc@localhost)
	by horowitz.ne.mediaone.net (8.8.8/8.8.8) id RAA06084;
	Sun, 29 Aug 1999 17:10:53 -0400 (EDT)
From: Marc Horowitz <marc@MIT.EDU>
To: nisse@lysator.liu.se (Niels Mvller)
Cc: jaltman@columbia.edu, psst@net.lut.ac.uk, ietf-ssh@clinet.fi,
        map@stacken.kth.se, lha@stacken.kth.se, krbdev@MIT.EDU
Subject: Re: Making host authentication more convenient
References: <CMM.0.90.4.935686474.jaltman@watsun.cc.columbia.edu> <nn671z7scp.fsf@sanna.lysator.liu.se> <t53g113k0ck.fsf@horowitz.ne.mediaone.net> <nn4shj6n8d.fsf@sanna.lysator.liu.se>
Date: 29 Aug 1999 17:10:52 -0400
In-Reply-To: nisse@lysator.liu.se's message of "29 Aug 1999 09:48:50 +0200"
Message-ID: <t53906u2syr.fsf@horowitz.ne.mediaone.net>
X-Mailer: Gnus v5.5/Emacs 20.3
Sender: owner-ietf-ssh@clinet.fi
Precedence: bulk
Content-Length: 4491
Lines: 84

nisse@lysator.liu.se (Niels Mvller) writes:

>> > >> What I really want to to is to give user's the ability to delegate
>> > >> *some* of her power to certain keys or certificates. For instance, to
>> > >> access some subset of her files, or run some programs.
>> > 
>> > This is much more of an OS issue than kerberos vs ssh vs other
>> > authentication systems issue.
>> 
>> The reason I mentioned it is that it seems incompatible with
>> centralizing the configuration of authentication methods, to give the
>> sysadm complete control. To give a concrete example: I may want to
>> give read-only access to some subdirectory in my $HOME, and to use a
>> lousy but easy to remember password for that service. Then I wouldn't
>> want any centralized passwd server to complain about my choice of
>> password. The "security" here is similar to the usage of readably but
>> hidden or unlistable directories on a ftp or http-server.

In the context of authentication systems, random passwords are not
usually used at all; some sort of cryptographic exchange is used
instead.  With both public-key authenticated ssh and kerberos,
passwords are never given to services.  Normally, if you have a
centralized password server, you need an admin to create a new entry
in the database at all, and it doesn't seem like you want that,
either.  I think what you want is outside the scope of an
authentication system as they are usually discussed.

What you said was delegating some power to "keys or certificates".
Some application protocols do this, and this is the right way to do
it, not by distributing weak passwords.  With AFS (Andrew File
System), I can give any set of afs users (which map roughly onto
kerberos principals) any of {read,write,lock,insert,delete,lock,admin}
permission on a directory and the files contained in it.  Users use
their own passwords.  There are also groups and metagroups, so I can
create a group marc:friends, and give them write access to a
directory, or give system:authuser (roughly all users in a kerberos
realm) read access to another directory.  I believe that cyrus imapd
also has similarly powerful authorization semantics for group
mailboxes.

>> > The former seems less clean than the latter, since ssh is designed to
>> > handle different authentication protocols.  Both would work, though.
>> > Practically speaking, since ssh ships with the latter implemented,
>> > it's what I used, often.  The ability to combine kerberos
>> > authentication and ticket forwarding with ssh X and TCP forwarding is
>> > both secure and convenient.
>> 
>> What is ticket-forwarding (I could guess, but I would prefer a precise
>> answer from someone who _knows_)? Does it have the same potential
>> problems as ssh agent forwarding?

The potential for problems can be more limited, but again, most
implementations don't bother.

In kerberos, when you get an initial ticket or a service ticket, it
contains a list of the IP addresses from which it can be used.  It
also contains a number of flags.  If a ticket has the forwardable flag
set, it can be presented to the kdc, with a new set of addresses and
flags (perhaps including forwardable, or not), and the kdc will send
back this ticket.  An application can then forward this ticket to a
remote host.  

Normally, the initial ticket is forwarded, such as for login.  Then,
the remote login has authentication as the user.  If this ticket is
not forwardable, then an attacker on the remote host cannot forward
the ticket.  With ssh agent forwarding, there is no way to prevent
this.  Also, it is possible to forward only an individual service
ticket.  For instance, I could give an ftp server the ticket for a
file service such as AFS, so it could write there on my behalf, but it
could not be used to authenticate to any other service.  Expiration
times can also be reduced for forwarded tickets.  Forwarded tickets
also have a flag set by the KDC which indicates that they are
forwarded, so a paranoid application server can refuse to accept
forwarded credentials.  With ssh, there is no way for a server to
distinguish if the client was given the password, is using a local
ssh-agent, or is using a forwarded ssh agent.

Forwarded tickets also have the advantage and disadvantage that they
can outlive the original ticket, which is useful for scheduling batch
jobs in the future, for instance.  The kerberos protocol has a
mechanism for revocation, but it is not complete and not implemented
that I know of.

		Marc
From owner-ietf-ssh@clinet.fi  Mon Aug 30 01:13:07 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 BAA10071;
	Mon, 30 Aug 1999 01:13:07 +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 BAA01397;
	Mon, 30 Aug 1999 01:13:06 +0300 (EEST)
Received: (from majordom@localhost)
	by lohi.clinet.fi (8.9.1/8.9.0) id BAA04590
	for ietf-ssh-outgoing; Mon, 30 Aug 1999 01:12:37 +0300 (EEST)
X-Authentication-Warning: lohi.clinet.fi: majordom set sender to owner-ietf-ssh@clinet.fi using -f
Received: from oberon.ctd.anl.gov (dns2.anl.gov [146.139.254.3])
	by lohi.clinet.fi (8.9.1/8.9.0) with ESMTP id BAA04584
	for <ietf-ssh@clinet.fi>; Mon, 30 Aug 1999 01:12:32 +0300 (EEST)
Received: from anl.gov (pembroke.ctd.anl.gov [146.137.180.163])
	by oberon.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id RAA15513;
	Sun, 29 Aug 1999 17:10:32 -0500 (CDT)
Message-ID: <37C9AFD9.B70D498B@anl.gov>
Date: Sun, 29 Aug 1999 17:10:33 -0500
From: "Douglas E. Engert" <deengert@anl.gov>
Reply-To: deengert@anl.gov
Organization: Argonne National Laborotory
X-Mailer: Mozilla 4.5 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Marc Horowitz <marc@MIT.EDU>
CC: Niels Mvller <nisse@lysator.liu.se>, jaltman@columbia.edu,
        psst@net.lut.ac.uk, ietf-ssh@clinet.fi, map@stacken.kth.se,
        lha@stacken.kth.se, krbdev@MIT.EDU
Subject: Re: Making host authentication more convenient
References: <CMM.0.90.4.935686474.jaltman@watsun.cc.columbia.edu> <nn671z7scp.fsf@sanna.lysator.liu.se> <t53g113k0ck.fsf@horowitz.ne.mediaone.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-ssh@clinet.fi
Precedence: bulk
Content-Length: 1996
Lines: 54



Marc Horowitz wrote:
> 
> nisse@lysator.liu.se (Niels Mvller) writes:
> 

> 
> This is much more of an OS issue than kerberos vs ssh vs other
> authentication systems issue.
> 
> >> I'd like ssh to offer the features needed for large organizations. If
> >> I can find out how.
> >>
> >> Two final questions for those of you using kerberos: If you already
> >> have kerberos up and running on your site(s), why would you consider
> >> using ssh at all? If you want to combine them, would one of the
> >> following possibilities suit your needs?
> >>
> >> * Use kerberos to create an encrypted connection between your
> >> machines. Run the ssh connection-protocol on top of that tunnel (i.e.
> >> do things like starting shells, forward X and tcp, etc, but don't do
> >> any of the ssh style authorization or encryption).
> >>
> >> * Use ssh, but add an authentication algorithm that lets you login
> >> using a kerberos ticket that you obtained earlier.
> 
> The former seems less clean than the latter, since ssh is designed to
> handle different authentication protocols.  Both would work, though.
> Practically speaking, since ssh ships with the latter implemented,
> it's what I used, often.  The ability to combine kerberos
> authentication and ticket forwarding with ssh X and TCP forwarding is
> both secure and convenient.

In addition to the kerberos authentication which comes in some versions
of SSH, NCSA has mods to ssh-1.2.27 to add GSSAPI authentication. This can 
then be linked with a number of GSSAPI implementations, including the
Kerberos GSSAPI. 

Van Dyke, www.vandyke.com has added these GSSAPI modifications to their
SecureCRT product for Windows, and it works well when you add an additional
DLL. (We told them the wrong calling convention, and DLL name.) Contact
me if you need more information.    

> 
>                 Marc

-- 

 Douglas E. Engert  <DEEngert@anl.gov>
 Argonne National Laboratory
 9700 South Cass Avenue
 Argonne, Illinois  60439 
 (630) 252-5444
From owner-ietf-ssh@clinet.fi  Mon Aug 30 10:09:37 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 KAA31417;
	Mon, 30 Aug 1999 10:09:33 +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 KAA05180;
	Mon, 30 Aug 1999 10:09:28 +0300 (EEST)
Received: (from majordom@localhost)
	by lohi.clinet.fi (8.9.1/8.9.0) id KAA19280
	for ietf-ssh-outgoing; Mon, 30 Aug 1999 10:08:22 +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 KAA19273
	for <ietf-ssh@clinet.fi>; Mon, 30 Aug 1999 10:08:20 +0300 (EEST)
Received: from sanna.lysator.liu.se (nisse@sanna.lysator.liu.se [130.236.254.206])
	by samantha.lysator.liu.se (8.9.3/8.9.3) with ESMTP id IAA24775;
	Mon, 30 Aug 1999 08:59:56 +0200 (MET DST)
Received: (from nisse@localhost)
	by sanna.lysator.liu.se (8.8.8/8.8.7) id IAA07532;
	Mon, 30 Aug 1999 08:59:55 +0200 (MET DST)
To: Marc Horowitz <marc@MIT.EDU>
Cc: jaltman@columbia.edu, psst@net.lut.ac.uk, ietf-ssh@clinet.fi,
        map@stacken.kth.se, lha@stacken.kth.se, krbdev@MIT.EDU
Subject: Re: Making host authentication more convenient
References: <CMM.0.90.4.935686474.jaltman@watsun.cc.columbia.edu> <nn671z7scp.fsf@sanna.lysator.liu.se> <t53g113k0ck.fsf@horowitz.ne.mediaone.net> <nn4shj6n8d.fsf@sanna.lysator.liu.se> <t53906u2syr.fsf@horowitz.ne.mediaone.net>
MIME-Version: 1.0
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 8bit
From: nisse@lysator.liu.se (Niels Mller)
Date: 30 Aug 1999 08:59:54 +0200
In-Reply-To: Marc Horowitz's message of "29 Aug 1999 17:10:52 -0400"
Message-ID: <nn1zcl7nyt.fsf@sanna.lysator.liu.se>
X-Mailer: Gnus v5.4.59/Emacs 19.34
Sender: owner-ietf-ssh@clinet.fi
Precedence: bulk
Content-Length: 1379
Lines: 34

Marc Horowitz <marc@mit.edu> writes:

> nisse@lysator.liu.se (Niels Mvller) writes:
> 
> >> What is ticket-forwarding (I could guess, but I would prefer a precise
> >> answer from someone who _knows_)? Does it have the same potential
> >> problems as ssh agent forwarding?
> 
> The potential for problems can be more limited, but again, most
> implementations don't bother.

  [ ... about kerberos ticket forwarding ... ]

Thanks for the explanation.

> With ssh, there is no way for a server to distinguish if the client
> was given the password, is using a local ssh-agent, or is using a
> forwarded ssh agent.

I haven't seen any spec for the ssh-agent mechanism (and I haven't
implemented it in lsh either). But perhaps it would make sense to
include information about the service being authenticated to,
communication end points, whether or not the server wants to allow
forwarding, etc, in the challenge sent to the agent?

Of course, the server can't know that the agent really pays any
attention to that information, but I think that is a minor problem (if
the user wants to be sloppy, its his problem). But perhaps it could
stop abuse of a forwarded agent by a compromized intermediate host;
the server would include enough information in the challenge for the
local agent to recognize that things are not quite right, and then it
refuses signing the challenge.

/Niels
From owner-ietf-ssh@clinet.fi  Mon Aug 30 10:40:33 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 KAA31936;
	Mon, 30 Aug 1999 10:40:32 +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 KAA05507;
	Mon, 30 Aug 1999 10:40:32 +0300 (EEST)
Received: (from majordom@localhost)
	by lohi.clinet.fi (8.9.1/8.9.0) id KAA24705
	for ietf-ssh-outgoing; Mon, 30 Aug 1999 10:40:19 +0300 (EEST)
X-Authentication-Warning: lohi.clinet.fi: majordom set sender to owner-ietf-ssh@clinet.fi using -f
Received: from horowitz.ne.mediaone.net (horowitz.ne.mediaone.net [24.218.136.87])
	by lohi.clinet.fi (8.9.1/8.9.0) with ESMTP id KAA24692
	for <ietf-ssh@clinet.fi>; Mon, 30 Aug 1999 10:40:17 +0300 (EEST)
Received: (from marc@localhost)
	by horowitz.ne.mediaone.net (8.8.8/8.8.8) id DAA06415;
	Mon, 30 Aug 1999 03:38:19 -0400 (EDT)
From: Marc Horowitz <marc@MIT.EDU>
To: nisse@lysator.liu.se (Niels Mvller)
Cc: jaltman@columbia.edu, psst@net.lut.ac.uk, ietf-ssh@clinet.fi,
        map@stacken.kth.se, lha@stacken.kth.se, krbdev@MIT.EDU
Subject: Re: Making host authentication more convenient
References: <CMM.0.90.4.935686474.jaltman@watsun.cc.columbia.edu> <nn671z7scp.fsf@sanna.lysator.liu.se> <t53g113k0ck.fsf@horowitz.ne.mediaone.net> <nn4shj6n8d.fsf@sanna.lysator.liu.se> <t53906u2syr.fsf@horowitz.ne.mediaone.net> <nn1zcl7nyt.fsf@sanna.lysator.liu.se>
Date: 30 Aug 1999 03:38:18 -0400
In-Reply-To: nisse@lysator.liu.se's message of "30 Aug 1999 08:59:54 +0200"
Message-ID: <t534shh3ehh.fsf@horowitz.ne.mediaone.net>
X-Mailer: Gnus v5.5/Emacs 20.3
Sender: owner-ietf-ssh@clinet.fi
Precedence: bulk
Content-Length: 819
Lines: 17

nisse@lysator.liu.se (Niels Mvller) writes:

>> Of course, the server can't know that the agent really pays any
>> attention to that information, but I think that is a minor problem (if
>> the user wants to be sloppy, its his problem). But perhaps it could
>> stop abuse of a forwarded agent by a compromized intermediate host;
>> the server would include enough information in the challenge for the
>> local agent to recognize that things are not quite right, and then it
>> refuses signing the challenge.

I don't know how you would come up with a set of rules which would
automatically work.  How does the agent or server tell the difference
between me logging into a sensitive machine to do real work, and an
attacker using a compromised agent to log into the same sensitive
machine to do nefarious things?

		Marc
From owner-ietf-ssh@clinet.fi  Mon Aug 30 11:54:52 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 LAA01380;
	Mon, 30 Aug 1999 11:54:51 +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 LAA06764;
	Mon, 30 Aug 1999 11:54:51 +0300 (EEST)
Received: (from majordom@localhost)
	by lohi.clinet.fi (8.9.1/8.9.0) id LAA09202
	for ietf-ssh-outgoing; Mon, 30 Aug 1999 11:54:02 +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 LAA09189
	for <ietf-ssh@clinet.fi>; Mon, 30 Aug 1999 11:54:00 +0300 (EEST)
Received: from sanna.lysator.liu.se (nisse@sanna.lysator.liu.se [130.236.254.206])
	by samantha.lysator.liu.se (8.9.3/8.9.3) with ESMTP id KAA28428;
	Mon, 30 Aug 1999 10:45:33 +0200 (MET DST)
Received: (from nisse@localhost)
	by sanna.lysator.liu.se (8.8.8/8.8.7) id KAA08618;
	Mon, 30 Aug 1999 10:45:32 +0200 (MET DST)
To: Marc Horowitz <marc@MIT.EDU>
Cc: jaltman@columbia.edu, psst@net.lut.ac.uk, ietf-ssh@clinet.fi,
        map@stacken.kth.se, lha@stacken.kth.se, krbdev@MIT.EDU
Subject: Re: Making host authentication more convenient
References: <CMM.0.90.4.935686474.jaltman@watsun.cc.columbia.edu> <nn671z7scp.fsf@sanna.lysator.liu.se> <t53g113k0ck.fsf@horowitz.ne.mediaone.net> <nn4shj6n8d.fsf@sanna.lysator.liu.se> <t53906u2syr.fsf@horowitz.ne.mediaone.net> <nn1zcl7nyt.fsf@sanna.lysator.liu.se> <t534shh3ehh.fsf@horowitz.ne.mediaone.net>
MIME-Version: 1.0
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 8bit
From: nisse@lysator.liu.se (Niels Mller)
Date: 30 Aug 1999 10:45:31 +0200
In-Reply-To: Marc Horowitz's message of "30 Aug 1999 03:38:18 -0400"
Message-ID: <nnyaet64ic.fsf@sanna.lysator.liu.se>
X-Mailer: Gnus v5.4.59/Emacs 19.34
Sender: owner-ietf-ssh@clinet.fi
Precedence: bulk
Content-Length: 3632
Lines: 73

Marc Horowitz <marc@mit.edu> writes:

> nisse@lysator.liu.se (Niels Mvller) writes:
> 
> >> Of course, the server can't know that the agent really pays any
> >> attention to that information, but I think that is a minor problem (if
> >> the user wants to be sloppy, its his problem). But perhaps it could
> >> stop abuse of a forwarded agent by a compromized intermediate host;
> >> the server would include enough information in the challenge for the
> >> local agent to recognize that things are not quite right, and then it
> >> refuses signing the challenge.
> 
> I don't know how you would come up with a set of rules which would
> automatically work.  How does the agent or server tell the difference
> between me logging into a sensitive machine to do real work, and an
> attacker using a compromised agent to log into the same sensitive
> machine to do nefarious things?

Let me think a little. First a scenario:

I run an agent for my private key at a local machine L. I use the
agent to authenticate to two machines, a sensitive server S, and to a
low-security host M.

At first, it may be a really bad idea to forward the agent to M at
all. But we'll assume that I enabled forwarding of the agent to M. We
also assume that I won't ever want to login to S from M (if I did, an
attacker that compromized M could insert commands to my shell on S and
do all sorts of evil things).

Next, let's assume that an attacker gets access to my forwarded agent
on M, and attempts to login to S in my name. He connects to S from
some other host C (its possible but not necessary that C = M. It's
even possible that C = L, which is the most difficult case, I think).

Now S creates a challenge for the attacker. Let the challenge be a
message <random nonce, host (=S), peer (=C), "login-service",
"nisse">. (The C field is not very reliable, as it's based on the peer
ip address). The correct response to the challenge is a signature on
this message, using my private key.

Now, let's look at how I could configure the agent and
agent-forwarding software. It could look at all the fields in the
message before creating a signature. Using the peer field, we can
refuse to sign login-challenges to S unless the peer is L. That was
what I was thinking about in the previous message. This gains a little
security, but fails if the attacker can login to L, or do serious
ip-spoofing.

To get something better, we would need to attach some more information
to the challenge on its way to the agent. My local ssh that manages
the connection L->M could transform it into <challenge received via M,
<random nonce, S, C, "login service">> before passing it on. I think
this can be done in such a way that this side information can be
trusted (at least the information about the first hop from L), assuming
only that the local protection of the agent on L is not by-passed.
So the agent could use this information to deny signing any challenges
that are received via M, and that request login access to S.

Does this make sense? It seems likely that the existing ssh-agent
forwarding don't do this (from the short description of ssh-agent
forwarding in the ssh connection spec, it seems that it provides a raw
connection to the agent with no obvious place to insert the side
information about the path). So the interesting question is if it is a
viable approach, if we were to design a new ssh-auth-forwarding
mechanism from scratch.

And if anybody knows about the inner workings of ssh-agent (preferably
version 2), or even better, has access to the spec. I'd really like to
know what kind of information is included in the challenges.

/Niels

From owner-ietf-ssh@clinet.fi  Mon Aug 30 16:56:16 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 QAA13832;
	Mon, 30 Aug 1999 16:56: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 QAA10404;
	Mon, 30 Aug 1999 16:56:11 +0300 (EEST)
Received: (from majordom@localhost)
	by lohi.clinet.fi (8.9.1/8.9.0) id QAA27357
	for ietf-ssh-outgoing; Mon, 30 Aug 1999 16:54:51 +0300 (EEST)
X-Authentication-Warning: lohi.clinet.fi: majordom set sender to owner-ietf-ssh@clinet.fi using -f
Received: from europe.std.com (europe.std.com [199.172.62.20])
	by lohi.clinet.fi (8.9.1/8.9.0) with ESMTP id QAA27342
	for <ietf-ssh@clinet.fi>; Mon, 30 Aug 1999 16:54:45 +0300 (EEST)
Received: from world.std.com (root@world-f.std.com [199.172.62.5])
	by europe.std.com (8.9.3/8.9.3) with ESMTP id JAA13047;
	Mon, 30 Aug 1999 09:52:47 -0400 (EDT)
Received: from dpj (dpj@world.std.com [192.74.137.5])
	by world.std.com (8.9.3/8.9.3) with SMTP id JAA16300;
	Mon, 30 Aug 1999 09:51:14 -0400 (EDT)
Message-Id: <3.0.5.32.19990830095312.00806ae0@world.std.com>
X-Sender: dpj@world.std.com
X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (32)
Date: Mon, 30 Aug 1999 09:53:12 -0400
To: "Theodore Y. Ts'o" <tytso@MIT.EDU>
From: David Jablon <dpj@IntegritySciences.com>
Subject: Re: Making host authentication more convenient
Cc: Marc Horowitz <marc@MIT.EDU>, nisse@lysator.liu.se, jaltman@columbia.edu,
        psst@net.lut.ac.uk, ietf-ssh@clinet.fi, map@stacken.kth.se,
        lha@stacken.kth.se, krbdev@MIT.EDU
In-Reply-To: <199908282302.TAA10092@tsx-prime.MIT.EDU>
References: <Marc Horowitz's message of 28 Aug 1999 18:27:07 -0400,<t53g113k0ck.fsf@horowitz.ne.mediaone.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ietf-ssh@clinet.fi
Precedence: bulk
Content-Length: 2980
Lines: 66

At 07:02 PM 8/28/99 -0400, Theodore Y. Ts'o wrote:
>   From: Marc Horowitz <marc@MIT.EDU>
>   There are modifications to the kerberos protocol (EKE, SPEKE, and
>   variants) which make offline brute-forcing impractical for a passive
>   attacker. [...]
>
>And of course you can partionally protect against dictionary attacks by
>simply adding a password quality checker to the kadmin daemon so that
>lousy passwords can't be used in the first place.  

Not true.  Just by blocking the first million or so "lousy" passwords, you
still
don't block the next million
not-quite-as-"lousy"-but-still-not-cryptographically-strong
passwords, and so on.  And while you play this loser's game, you make it
harder for many people to remember their passwords.

I see no good reason to endorse any protocol that unnecessarily permits
cracking of  ANY passwords.

>And before someone points out the recent SRP paper, let me put in a
>premptive response.  That paper neglects to mention that the university
>the author attacked only recently put in a password quality checker, and
>nearly all the passwords he grabbed were ones which predated the
>password quality checker.  In fact, most of the captured passwords would
>have been rejected by the passowrd quality checker if it had been in use
>when the users' passwords were changed.  I talked to the the I/T
>administrators at that university, and they were were livid about how
>the results were presented, because they were clearly misrepresented.

This is ridiculous.  Tom presented results that were from a "real world"
setting,
as suggested by the title "A Real World Analysis of Kerberos Password
Security".
(www.Integritysciences.com/links.html#Wu99).  Your statement that "those
passwords would not have been captured if they weren't used" is irrelevant.
Some of them would have been cracked.  And noone can say how well the
cracker would have performed against the changed passwords.

No, it was not an "ideal" world, with perfect password checkers, and
perfect users.
Then again, maybe Tom did focus too exclusively on how strong protocols
solve the
problem, and maybe he ignored the marginal value of password quality checkers.

But I also wonder if your unnamed I/T admins may have been "livid" in part
because of the embarrassment of the situation, or because Kerberos was
so dear to their hearts and yet was so easily cracked.

>IMHO, that paper was more a white paper whose main goal was marketing
>author's patented technology; I was surprised the program committee
>allowed it to be published.

IMHO?  Get off it Ted.  There's nothing particularly H about your O.  You
just hate patents.
Yet still I'm glad that there's no "program committee" reviewing the
Internet, so we
can have these friendly discussions.  :-)

-- David

---------------------------------------------------
David P. Jablon           dpj@IntegritySciences.com
President                 +1 508 898 9024
Integrity Sciences, Inc.  www.IntegritySciences.com

From owner-ietf-ssh@clinet.fi  Mon Aug 30 18:48:05 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 SAA15499;
	Mon, 30 Aug 1999 18:48:04 +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 SAA11990;
	Mon, 30 Aug 1999 18:48:03 +0300 (EEST)
Received: (from majordom@localhost)
	by lohi.clinet.fi (8.9.1/8.9.0) id SAA12482
	for ietf-ssh-outgoing; Mon, 30 Aug 1999 18:47:18 +0300 (EEST)
X-Authentication-Warning: lohi.clinet.fi: majordom set sender to owner-ietf-ssh@clinet.fi using -f
Received: from tsx-prime.MIT.EDU (TSX-PRIME.MIT.EDU [18.86.0.76])
	by lohi.clinet.fi (8.9.1/8.9.0) with SMTP id SAA12477
	for <ietf-ssh@clinet.fi>; Mon, 30 Aug 1999 18:47:15 +0300 (EEST)
Received: by tsx-prime.MIT.EDU 
	with sendmail-SMI-8.6/1.2, id LAA10458; Mon, 30 Aug 1999 11:45:13 -0400
Date: Mon, 30 Aug 1999 11:45:13 -0400
Message-Id: <199908301545.LAA10458@tsx-prime.MIT.EDU>
From: "Theodore Y. Ts'o" <tytso@MIT.EDU>
To: David Jablon <dpj@IntegritySciences.com>
CC: "Theodore Y. Ts'o" <tytso@MIT.EDU>, Marc Horowitz <marc@MIT.EDU>,
        nisse@lysator.liu.se, jaltman@columbia.edu, psst@net.lut.ac.uk,
        ietf-ssh@clinet.fi, map@stacken.kth.se, lha@stacken.kth.se,
        krbdev@MIT.EDU
In-reply-to: David Jablon's message of Mon, 30 Aug 1999 09:53:12 -0400,
	<3.0.5.32.19990830095312.00806ae0@world.std.com>
Subject: Re: Making host authentication more convenient
Address: 1 Amherst St., Cambridge, MA 02139
Phone: (617) 253-8091
Sender: owner-ietf-ssh@clinet.fi
Precedence: bulk
Content-Length: 3091
Lines: 58

   Date: Mon, 30 Aug 1999 09:53:12 -0400
   From: David Jablon <dpj@IntegritySciences.com>

   This is ridiculous.  Tom presented results that were from a "real
   world" setting, as suggested by the title "A Real World Analysis of
   Kerberos Password Security".
   (www.Integritysciences.com/links.html#Wu99).  Your statement that
   "those passwords would not have been captured if they weren't used"
   is irrelevant.  Some of them would have been cracked.  And noone can
   say how well the cracker would have performed against the changed
   passwords.

Tom made the claim that "password quality checkers don't help".  But the
results he used to prove that claim were weak at best, since he attacked
a realm where the password quality checker was installed just a few
weeks or months before.  If he had said, "password quality checkers only
marginally help immediately after their installation", that would have
been fairer.  But he didn't do that.  His thesis in his paper wasn't
backed up evidence that he claimed to support that claim, and it is that
intellectual dishonesty that ticked me off the most.

Arguably that unversity could have done more when they installed the
checker to handle the transition.  For example, they could have run a
password cracker themselves, and disabled the accounts of anyone with
weak passwords.  But there are other real world considerations that have
to be considered besides just security, and they may not have had the
political clout to just turn off accounts with weak passwords
(especially, when often it is inconvenient people like department heads
that are often the biggest offenders).  Over time, though, since a
university has a fairly quick turnover of users, the password quality
checker would have made a big difference in the security of their
systems.

Yes, password quality checkers are not a silver bullet.  But they aren't
the complete disaster which he claimed in that paper, either.  If you
consider that most of the password he cracked were completely trivial
passwords (including 1, 2, and 3 character passwords), it becomes pretty
obvious that a large number his cracked passwords would not have passed
the muster of even the most rudimentary password quality checker.  (For
example, at MIT the passwords must be at least six characters; it's not
just a simple dictionary test.)

   IMHO?  Get off it Ted.  There's nothing particularly H about your O.
   You just hate patents.  Yet still I'm glad that there's no "program
   committee" reviewing the Internet, so we can have these friendly
   discussions.  :-)

I dislike patents, because usually the patent holders try to extract
more value than they are worth, and they don't recognize how much
problems they cause for Open Source Software.  But in this case, it was
the intellectual dishonesty, and the overstatement of his case, which
bothered me the most, and which most reminded me more of a marketing
white paper than a peer-reviewed academic paper --- where you're
supposed to disclose inconvenient facts about your data set and how you
gathered it.

						- Ted

From owner-ietf-ssh@clinet.fi  Mon Aug 30 19:13:54 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 TAA17433;
	Mon, 30 Aug 1999 19:13:50 +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 TAA12210;
	Mon, 30 Aug 1999 19:13:50 +0300 (EEST)
Received: (from majordom@localhost)
	by lohi.clinet.fi (8.9.1/8.9.0) id TAA14899
	for ietf-ssh-outgoing; Mon, 30 Aug 1999 19:13:37 +0300 (EEST)
X-Authentication-Warning: lohi.clinet.fi: majordom set sender to owner-ietf-ssh@clinet.fi using -f
Received: from jupiter.esker.fr (jupiter.esker.fr [194.51.34.253])
	by lohi.clinet.fi (8.9.1/8.9.0) with ESMTP id TAA14883
	for <ietf-ssh@clinet.fi>; Mon, 30 Aug 1999 19:13:31 +0300 (EEST)
Received: from nicolasr.esker.fr (roumiantzeff.esker.fr [194.51.34.63]) by jupiter.esker.fr (/Esker 1.0) with SMTP id RAA04353 for <ietf-ssh@clinet.fi>; Mon, 30 Aug 1999 17:07:40 +0200
Message-ID: <000601bef301$9bf082a0$3f2233c2@nicolasr.esker.fr>
From: "Nicolas Roumiantzeff" <nicolasr@esker.fr>
To: <ietf-ssh@clinet.fi>
Subject: Re: Making host authentication more convenient
Date: Mon, 30 Aug 1999 18:06:23 +0200
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: 375
Lines: 14

>IMHO?  Get off it Ted.  There's nothing particularly H about your O.  You
>just hate patents.


Why are you guys fighting for?
Isn't "SRP is free for all use"?
See "Political Advantages" at http://srp.stanford.edu/srp/advantages.html

SRP seems very promissing to me!
What are the advantages of NOT implementing it evry where a password is
required?

Nicolas Roumiantzeff.

From owner-ietf-ssh@clinet.fi  Mon Aug 30 21:15:37 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 VAA21363;
	Mon, 30 Aug 1999 21:15:35 +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 VAA13705;
	Mon, 30 Aug 1999 21:15:35 +0300 (EEST)
Received: (from majordom@localhost)
	by lohi.clinet.fi (8.9.1/8.9.0) id VAA25439
	for ietf-ssh-outgoing; Mon, 30 Aug 1999 21:14:52 +0300 (EEST)
X-Authentication-Warning: lohi.clinet.fi: majordom set sender to owner-ietf-ssh@clinet.fi using -f
Received: from minbar.fac.cs.cmu.edu (MINBAR.FAC.CS.CMU.EDU [128.2.185.161])
	by lohi.clinet.fi (8.9.1/8.9.0) with SMTP id VAA25425
	for <ietf-ssh@clinet.fi>; Mon, 30 Aug 1999 21:14:45 +0300 (EEST)
Received: from AFSTEST-2.FAC.CS.CMU.EDU by minbar.fac.cs.cmu.edu id aa03841;
          30 Aug 99 14:12 EDT
Date: Mon, 30 Aug 1999 13:58:23 -0400
From: Jeffrey Hutzelman <jhutz+@cmu.edu>
To: Niels Mvller <nisse@lysator.liu.se>, jaltman@columbia.edu
cc: psst@net.lut.ac.uk, ietf-ssh@clinet.fi, map@stacken.kth.se,
        lha@stacken.kth.se, krbdev@MIT.EDU
Subject: Re: Making host authentication more convenient
Message-ID: <4013600168.936021503@AFSTEST-2.FAC.CS.CMU.EDU>
In-Reply-To: <nn671z7scp.fsf@sanna.lysator.liu.se>
Originator-Info: login-token=Mulberry:01B5Efb3H5lONT3J7yTBOQ0ZL2i5xJCqd9v4LiB/+b+AcEheA=;
 token_authority=postmaster@andrew.cmu.edu
X-Mailer: Mulberry (Win32) [1.4.4, s/n S-100002]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Sender: owner-ietf-ssh@clinet.fi
Precedence: bulk
Content-Length: 1359
Lines: 28

> Two final questions for those of you using kerberos: If you already
> have kerberos up and running on your site(s), why would you consider
> using ssh at all? If you want to combine them, would one of the
> following possibilities suit your needs?
> 
> * Use kerberos to create an encrypted connection between your
> machines. Run the ssh connection-protocol on top of that tunnel (i.e.
> do things like starting shells, forward X and tcp, etc, but don't do
> any of the ssh style authorization or encryption).

I imagine this would get used, if someone did it.  Right now, I use ssh
only when I want to forward X11 connections, or as an alternate path into a
machine when telnetd or inetd is not working (for various reasons, ssh and
telnet tend not to break at the same time).  On the other hand, the correct
solution to this problem would be to develop and deploy working, useful
Kerberos-based authentication for X11.

> * Use ssh, but add an authentication algorithm that lets you login
> using a kerberos ticket that you obtained earlier.

This is exactly what we do.  Kerberos V support ships with ssh, and patches
are available to add Kerberos IV support.

-- Jeffrey T. Hutzelman (N3NHS) <jhutz+@cmu.edu>
   Sr. Research Systems Programmer
   School of Computer Science - Research Computing Facility
   Carnegie Mellon University - Pittsburgh, PA

From owner-ietf-ssh@clinet.fi  Mon Aug 30 22:51:05 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 WAA20751;
	Mon, 30 Aug 1999 22:51:04 +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 WAA14797;
	Mon, 30 Aug 1999 22:51:04 +0300 (EEST)
Received: (from majordom@localhost)
	by lohi.clinet.fi (8.9.1/8.9.0) id WAA03552
	for ietf-ssh-outgoing; Mon, 30 Aug 1999 22:50:05 +0300 (EEST)
X-Authentication-Warning: lohi.clinet.fi: majordom set sender to owner-ietf-ssh@clinet.fi using -f
Received: from telemark.stanford.edu (telemark.Stanford.EDU [171.64.12.100])
	by lohi.clinet.fi (8.9.1/8.9.0) with ESMTP id WAA03534
	for <ietf-ssh@clinet.fi>; Mon, 30 Aug 1999 22:50:00 +0300 (EEST)
Received: from localhost by telemark.stanford.edu (8.10.0.PreAlpha1/8.10.0.PreAlpha1) with ESMTP id MAA08211;
	Mon, 30 Aug 1999 12:47:53 -0700 (PDT)
Date: Mon, 30 Aug 1999 12:47:53 -0700 (PDT)
From: Booker Bense <bbense@networking.stanford.edu>
To: David Jablon <dpj@IntegritySciences.com>
cc: "Theodore Y. Ts'o" <tytso@MIT.EDU>, Marc Horowitz <marc@MIT.EDU>,
        nisse@lysator.liu.se, jaltman@columbia.edu, psst@net.lut.ac.uk,
        ietf-ssh@clinet.fi, map@stacken.kth.se, lha@stacken.kth.se,
        krbdev@MIT.EDU
Subject: Re: Making host authentication more convenient
In-Reply-To: <3.0.5.32.19990830095312.00806ae0@world.std.com>
Message-ID: <Pine.GSO.4.10.9908301233240.7941-100000@telemark.stanford.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ietf-ssh@clinet.fi
Precedence: bulk
Content-Length: 3517
Lines: 83

On Mon, 30 Aug 1999, David Jablon wrote:

> At 07:02 PM 8/28/99 -0400, Theodore Y. Ts'o wrote:
> >   From: Marc Horowitz <marc@MIT.EDU>
> >   There are modifications to the kerberos protocol (EKE, SPEKE, and
> >   variants) which make offline brute-forcing impractical for a passive
> >   attacker. [...]
> >
> >And of course you can partionally protect against dictionary attacks by
> >simply adding a password quality checker to the kadmin daemon so that
> >lousy passwords can't be used in the first place.  
> 
> Not true.  Just by blocking the first million or so "lousy" passwords, you
> still
> don't block the next million
> not-quite-as-"lousy"-but-still-not-cryptographically-strong
> passwords, and so on.  And while you play this loser's game, you make it
> harder for many people to remember their passwords.

- There's no such thing as a "cryptographically" strong password. 
Cryptography is the science of using an existing secret.
Whether a secret is hard or easy to guess involves icky human 
factors. 

> 
> I see no good reason to endorse any protocol that unnecessarily permits
> cracking of  ANY passwords.
> 
> >And before someone points out the recent SRP paper, let me put in a
> >premptive response.  That paper neglects to mention that the university
> >the author attacked only recently put in a password quality checker, and
> >nearly all the passwords he grabbed were ones which predated the
> >password quality checker.  In fact, most of the captured passwords would
> >have been rejected by the passowrd quality checker if it had been in use
> >when the users' passwords were changed.  I talked to the the I/T
> >administrators at that university, and they were were livid about how
> >the results were presented, because they were clearly misrepresented.
> 
> This is ridiculous.  Tom presented results that were from a "real world"
> setting,
> as suggested by the title "A Real World Analysis of Kerberos Password
> Security".
> (www.Integritysciences.com/links.html#Wu99).  Your statement that "those
> passwords would not have been captured if they weren't used" is irrelevant.
> Some of them would have been cracked.  And noone can say how well the
> cracker would have performed against the changed passwords.
> 
> No, it was not an "ideal" world, with perfect password checkers, and
> perfect users.
> Then again, maybe Tom did focus too exclusively on how strong protocols
> solve the
> problem, and maybe he ignored the marginal value of password quality checkers.
> 
> But I also wonder if your unnamed I/T admins may have been "livid" in part
> because of the embarrassment of the situation, or because Kerberos was
> so dear to their hearts and yet was so easily cracked.
> 

- As one of the sysadmins involved, I can tell you that Mr. Wu's 
"paper" was no suprise to anybody. We were livid because of Mr. Wu's 
questionable ethics. 




> >IMHO, that paper was more a white paper whose main goal was marketing
> >author's patented technology; I was surprised the program committee
> >allowed it to be published.
> 
> IMHO?  Get off it Ted.  There's nothing particularly H about your O.  You
> just hate patents.
> Yet still I'm glad that there's no "program committee" reviewing the
> Internet, so we
> can have these friendly discussions.  :-)
> 
> -- David
> 
> ---------------------------------------------------
> David P. Jablon           dpj@IntegritySciences.com
> President                 +1 508 898 9024
> Integrity Sciences, Inc.  www.IntegritySciences.com
> 

From bbense@telemark.stanford.edu Mon Aug 30 22:37 MET 1999
Received: from telemark.stanford.edu (telemark.Stanford.EDU [171.64.12.100])
	by samantha.lysator.liu.se (8.9.3/8.9.3) with ESMTP id WAA29949
	for <nisse@lysator.liu.se>; Mon, 30 Aug 1999 22:37:24 +0200 (MET DST)
Received: from localhost by telemark.stanford.edu (8.10.0.PreAlpha1/8.10.0.PreAlpha1) with ESMTP id NAA08443;
	Mon, 30 Aug 1999 13:37:13 -0700 (PDT)
Date: Mon, 30 Aug 1999 13:37:13 -0700 (PDT)
From: Booker Bense <bbense@networking.stanford.edu>
To: David Jablon <dpj@IntegritySciences.com>
cc: "Theodore Y. Ts'o" <tytso@MIT.EDU>, Marc Horowitz <marc@MIT.EDU>,
        nisse@lysator.liu.se, jaltman@columbia.edu, psst@net.lut.ac.uk,
        ietf-ssh@clinet.fi, map@stacken.kth.se, lha@stacken.kth.se,
        krbdev@MIT.EDU
Subject: Re: Making host authentication more convenient
In-Reply-To: <Pine.GSO.4.10.9908301233240.7941-100000@telemark.stanford.edu>
Message-ID: <Pine.GSO.4.10.9908301331200.7941-100000@telemark.stanford.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Content-Length: 196
Xref: sanna.lysator.liu.se mail.psst:463 mail.ietf-ssh:128
Content-Length: 196
Lines: 8


- My previous message went out as a mistake. I meant to 
cancel it in it's incomplete form and it went out instead. 
Perhaps a freudian finger slip... Anyway, my apologies. 

- Booker C. Bense 

