From owner-ietf-ssh@clinet.fi  Thu Feb  4 12:51: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 MAA18426;
	Thu, 4 Feb 1999 12:51:22 +0200 (EET)
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 MAA01362;
	Thu, 4 Feb 1999 12:51:22 +0200 (EET)
Received: (from majordom@localhost)
	by lohi.clinet.fi (8.9.1/8.9.0) id MAA19322
	for ietf-ssh-outgoing; Thu, 4 Feb 1999 12:46:50 +0200 (EET)
X-Authentication-Warning: lohi.clinet.fi: majordom set sender to owner-ietf-ssh@clinet.fi using -f
Received: from smtp4.server.ibm.com (smtp4.ny.us.ibm.com [198.133.22.43])
	by lohi.clinet.fi (8.9.1/8.9.0) with ESMTP id RAA06070
	for <ietf-ssh@clinet.fi>; Wed, 3 Feb 1999 17:46:21 +0200 (EET)
From: jaegert@us.ibm.com
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22])
	by smtp4.server.ibm.com (8.8.7/8.8.7) with ESMTP id KAA68968
	for <ietf-ssh@clinet.fi>; Wed, 3 Feb 1999 10:30:51 -0500
Received: from D51MTA03.pok.ibm.com (d51mta03.pok.ibm.com [9.117.200.31])
	by northrelay02.pok.ibm.com (8.8.7m1/NCO v1.8) with SMTP id KAA124756
	for <ietf-ssh@clinet.fi>; Wed, 3 Feb 1999 10:45:18 -0500
Received: by D51MTA03.pok.ibm.com(Lotus SMTP MTA Internal build v4.6.2  (651.2 6-10-1998))  id 8525670D.00568664 ; Wed, 3 Feb 1999 10:45:05 -0500
X-Lotus-FromDomain: IBMUS
Message-ID: <8525670D.00568270.0B@D51MTA03.pok.ibm.com>
Date: Wed, 3 Feb 1999 10:44:32 -0500
Subject: Call for Papers: Fourth ACM Workshop on Role-based Access Control
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: owner-ietf-ssh@clinet.fi
Precedence: bulk
Content-Length: 4633
Lines: 115

CALL FOR PAPERS
Fourth ACM WORKSHOP ON ROLE-BASED ACCESS CONTROL
Date: Oct. 28-29, 1999
Place: George Mason University
url: www.list.gmu.edu/rbac

Sponsored By: ACM Sigsac
Hosted By: George Mason University


The essence of Role-Based Access Control (RBAC) is that permissions
are assigned to roles rather than to individual users.  Users acquire
these permissions by virtue of being authorized to act in these roles.
The driving motivation for RBAC is to simplify security policy
administration while facilitating the definition of flexible,
customized policies.  Basic RBAC models have been successfully applied
since the mainframe era, but emerging systems, which have greater
numbers of users, roles, and systems, challenge the expressive power
of these traditional models.

Workshop Scope:

The ACM workshops on RBAC bring together researchers, developers, and
practitioners to discuss the application of RBAC to both traditional
and emerging systems and the development of new access control
paradigms for future applications.  The workshop invites participation from
the database, network, distributed systems, operating systems, security and
application communities.  Contributions reporting experiences with the
implementation and use of RBAC systems are strongly encouraged.
Attendance is limited to 40 participants to foster a workshop atmosphere.

Topics of interest include, but are not restricted to:

- Modeling and specification of RBAC systems
- Administration of RBAC systems
- RBAC in database security
- Specification and enforcement of security policy
- Delegation and inheritance of access rights in RBAC systems
- Task-based access control and RBAC in collaborative environments
- Application Areas e.g., health-care, WWW
- Support for RBAC in traditional access control systems
- RBAC and organizational control principles
- Experiences with RBAC-based systems; case studies
- Enabling technologies: Java, LDAP, intra-net environments
- Implementation, integration and scalability of RBAC
- End-user tools to support RBAC administration and engineering

Submissions:

Users, developers and researchers are invited to submit seven copies
of their papers (in English and limited to 6000 words) to the Program
Chair at the coordinates given below before the due date.  Submissions can
be either hard copy or electronic (postscript preferred). Papers must be
original and should not be under consideration for publication
elsewhere.  Copyrights for accepted papers must be transferable to ACM
(except for Government work).  Papers will be published by ACM in a
proceedings to be distributed at the workshop and mailed to all SIGSAC
members.  Outstanding papers will be considered for publication in ACM's
new Transactions on Information and Systems Security (TISSEC).

Proposals for panels and group discussions should be sent, preferably
by email, to the Panels Chair at dferraiolo@nist.gov.

Paper Submissions should be sent to:
Sylvia Osborn, Program Committee Chair,
Dept. of Computer Science,
The University of Western Ontario,
MC355,
London, Ontario, Canada, N6A 5B7
email: sylvia@csd.uwo.ca

SCHEDULE:
Papers and Panel Proposals Due: May 15, 1999
Notification of acceptance and advance program: June 30, 1999
Deadline for final version of papers: July 31, 1999
Workshop: October 28-29, 1999


CONFERENCE STEERING COMMITTEE:
Ed Coyne, Science Applications International Corporation
David Ferraiolo, National Institute of Standards and Technology
Trent Jaeger, IBM T.J. Watson Research Center
Sylvia Osborn, The University of Western Ontario
Ravi Sandhu, George Mason University
Charles Youman, Blue Cross Blue Shield

General Conference Chair: Charles Youman, Blue Cross Blue Shield
Local Arrangements: Srinivas Ganta, CygnaCom Solutions Inc.
Program Committee Chair: Sylvia Osborn, The University of Western Ontario
Panels Chair: David Ferraiolo, National Institute of Standards and
Technology
Proceedings Chair: Vijay Atluri, Rutgers University
Publicity Chair: Trent Jaeger, IBM T.J. Watson Research Center


PROGRAM COMMITTEE:

Vijay Atluri, Rutgers University
Dave Ferraiolo, National Institute of Standards and Technology
Luigi Giuri,  Fondazione Ugo Bordoni
Trent Jaeger, IBM T.J. Watson Research Center
Carl Landwehr, U.S. Naval Research Laboratory
Emil Lupu, Imperial College
Ravi Sandhu, George Mason University
Richard Simon
Roshan Thomas, TIS Labs at Network Associates
Dan Thomsen, Secure Computing Corp.
Dan Wallach, Rice University

REGISTRATION:
Information on registration and accommodations will be provided.
There will be a registration fee for all participants to cover meeting
costs.


From owner-ietf-ssh@clinet.fi  Fri Feb  5 11:52:46 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 LAA06422;
	Fri, 5 Feb 1999 11:52:46 +0200 (EET)
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 LAA11793;
	Fri, 5 Feb 1999 11:52:45 +0200 (EET)
Received: (from majordom@localhost)
	by lohi.clinet.fi (8.9.1/8.9.0) id LAA12485
	for ietf-ssh-outgoing; Fri, 5 Feb 1999 11:48:03 +0200 (EET)
X-Authentication-Warning: lohi.clinet.fi: majordom set sender to owner-ietf-ssh@clinet.fi using -f
Received: from nic.carlstedt.se (nic.carlstedt.se [193.12.107.10])
	by lohi.clinet.fi (8.9.1/8.9.0) with ESMTP id SAA26382;
	Thu, 4 Feb 1999 18:03:51 +0200 (EET)
Received: from giraf.carlstedt.se (root@giraf.carlstedt.se [172.16.1.10])
	by nic.carlstedt.se (8.9.1/8.9.1) with ESMTP id RAA23076;
	Thu, 4 Feb 1999 17:03:21 +0100 (MET)
Received: from carlstedt.se (maf@aston.carlstedt.se [172.16.1.90])
	by giraf.carlstedt.se (8.9.1/8.9.1) with ESMTP id RAA16539;
	Thu, 4 Feb 1999 17:03:17 +0100 (MET)
Message-Id: <199902041603.RAA16539@giraf.carlstedt.se>
Date: Thu, 4 Feb 1999 17:03:13 +0100 (MET)
From: Martin Forssen <maf@crt.se>
Subject: Generic challenge-repsonse aunetication in ssh2
To: ssh@clinet.fi, ietf-ssh@clinet.fi
MIME-Version: 1.0
Content-Type: MULTIPART/mixed; BOUNDARY="-2137996019-851401618-918144200=:24784"
Sender: owner-ietf-ssh@clinet.fi
Precedence: bulk
Content-Length: 8734
Lines: 270

---2137996019-851401618-918144200=:24784
Content-Type: TEXT/plain; charset=us-ascii

Attached below follows a proposal for a new authentication method for
SSH2. This new method implements general challenge-response
authentication.

Some background might be in order: the company where I work "Firedoor
Network Security AB" sells a security product (Firedoor) which uses ssh
rather heavily. We currently have installations which run ssh1 and use
securid token authentication and we want to keep those customers when
we upgrade to ssh2, we would also like to use some other authentication
methods.

But nobody has added securid authentication to ssh2. Therefore we
realized that we had to do it ourselves:-) This is the first result, a
draft for a new authentication method. I am including it here to get
some feedback. We are going to implement it if nobody raises any big
objections. The code will the be free for everybody to use. The idea is 
then to get SSH Communications OY and DataFellows to merge these
changes into their master versions. We would also like all other ssh2
projects to support it.

This protocol is written so that the client should not need to neither
know nor care about which challenge-response method the user really
uses. The most important issue is to get the generic support into the
clients since it is so much easier to modify a handful of servers that
hunderds of clients (the server must of course know the details of the
underlying authentication method).

I am not sure if the working group should release this as a draft or
what should be done with it. I am open to suggestions.

	/MaF
	

---2137996019-851401618-918144200=:24784
Content-Type: TEXT/plain; CHARSET=US-ASCII
Content-Description: draft-ietf-secsh-chrespauth-00







not yet an I-D                                                M. Forssen
draft-ietf-secsh-chrespauth-00.txt          Firedoor Network Security AB
                                                         4 February 1999


     Challenge-response authentication method for the SSH protocol


Abstract

   SSH is a protocol for secure remote login and other secure network
   services over an insecure network. This document describes a general
   purpose challenge-response authentication method for the SSH
   protocol.

Introduction

   The SSH authentication protocol is a general-purpose user
   authentication protocol. It is intended to be run over the SSH
   transport layer protocol [SSH-TRANS]. The protocol assumes that the
   underlying protocols provide integrity and confidentiality
   protection.

   This document describes a new challenge-response authentication
   method for the SSH authentication protocol. The method documented
   here is a general purpose challenge-response authentication method
   which can be used to support many different authentication methods,
   for example SecurID and RADIUS. The rationale for a general purpose
   protocol is that it is important to get support for this kind of
   protocol into all clients and that it is much easier to add
   specialized support for special authentication protocols in the
   servers.

   The method name for this authentication method is "challenge-
   response".

   This document should be read only after reading the SSH architecture
   document [SSH-ARCH] and the SSH authentication document [SSH-
   USERAUTH].  This document freely uses terminology and notation from
   both documents without reference or further explanation.

Challenge-response Authentication Method

   This method permits interaction between the server and the client
   during the authentication phase. The server may ask questions which
   the client should answer. The authentication begins with the client
   sending a SSH_MSG_USERAUTH_REQUEST message.




M. Forssen                                                      [Page 1]

not yet an I-D   SSH Challenge-response authentication   4 February 1999


     byte      SSH_MSG_USERAUTH_REQUEST
     string    user name
     string    service
     string    "challenge-response"
     boolean   FALSE
     string    method name
     string    response string (ISO-10646 UTF-8)

   The method name is an optional name of a specific challenge-response
   method, the client MAY leave this field empty. The server MAY ignore
   this value if it can infer from other data which challenge-response
   method is used. One way that can be inferred is when the server only
   supports one challenge-response method. The method name must be the same
   in all messages until the client receives a success or failure response.

   Note that the response string is encoded in ISO-10646 UTF-8. The response
   string contains the reply from the user to the last challenge received
   from the server. Since the client initiates the authentication session
   there is no challenge from the server when the first packet is sent. The
   response string may in this case be left empty or filled in with what the
   client thinks the server may want first.

   The server MUST respond with either SSH_MSG_USERAUTH_SUCCESS,
   SSH_MSG_USERAUTH_FAILURE or with a SSH_MSG_USERAUTH_CHALLENGE.
   The format of a SSH_MSG_USERAUTH_CHALLENGE is:

     byte      SSH_MSG_USERAUTH_CHALLENGE
     string    challenge (ISO-10646 UTF-8)
     string    language tag (as defined in RFC 1766)
     boolean   do not echo reply

   This reply contains a textual challenge which SHOULD be shown to the user
   and the user should be allowed to write a reply. If the "do not echo reply"
   field is TRUE then the client should treat the users input as sensitive and
   not echo any entered characters (as normally done when passwords are entered).
   The client should then reply to this packet with a new
   SSH_MSG_USERAUTH_REQUEST with the boolean value set to TRUE to indicate that
   this is an actual reply to a challenge.

   The following method-specific message numbers are used by the
   challenge-response authentication method.

     /* Challenge */
     #define SSH_MSG_USERAUTH_CHALLENGE             25


Security Considerations




M. Forssen                                                      [Page 2]

not yet an I-D   SSH Challenge-response authentication   4 February 1999


   The purpose of this protocol is to perform client user authentication.
   It assumed that this runs over a secure transport layer protocol, which
   has already authenticated the server machine, established an encrypted
   communications channel, and computed a unique session identifier for
   this session. The transport layer provides forward secrecy for password
   authentication and other methods that rely on secret data.

   The server may go into a "sleep" period after repeated unsuccessful
   authentications to make key search harder.

   If the transport layer does not provide encryption, authentication
   methods that rely on secret data SHOULD be disabled. If it does not
   provide MAC protection, requests to change authentication data (e.g.
   password change) SHOULD be disabled to avoid an attacker from modifying
   the ciphertext without being noticed, rendering the new authentication
   data unusable (denial of service).

   Several authentication methods with different security characteristics
   are allowed. It is up to the server's local policy to decide which
   methods (or combinations of methods) it is willing to accept for each
   user. Authentication is no stronger than the weakest combination
   allowed.

References

   [RFC-1766] Alvestrand, H., "Tags for the Identification of Languages",
   March 1995.

   [RFC-2044] Yergeau, F., "UTF-8, a Transformation Format of Unicode and
   ISO 10646", October 1996.

   [SSH-ARCH] Ylonen, T., Kivinen, T, and Saarinen, M., "SSH Protocol
   Architecture", Internet Draft, draft-secsh-architecture-00.txt

   [SSH-TRANS] Ylonen, T., Kivinen, T, and Saarinen, M., "SSH Transport
   Layer Protocol", Internet Draft, draft-secsh-transport-02.txt

   [SSH-USERAUTH] Ylonen, T., Kivinen, T, and Saarinen, M., "SSH
   Authentication Protocol", Internet Draft, draft-ietf-secsh-
   userauth-02.txt

   [SSH-CONNECT] Ylonen, T., Kivinen, T, and Saarinen, M., "SSH Connection
   Protocol", Internet Draft, draft-secsh-connect-02.txt

Author's Address

   Martin Forssen
   Firedoor Network Security AB



M. Forssen                                                      [Page 3]

not yet an I-D   SSH Challenge-response authentication   4 February 1999


   Stora Badhusgatan 18-20
   SE-411 21 Gothenburg
   SWEDEN

   E-mail: maf@firedoor.se














































M. Forssen                                                      [Page 4]


---2137996019-851401618-918144200=:24784--

From owner-ietf-ssh@clinet.fi  Fri Feb  5 19:20:24 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 TAA04369;
	Fri, 5 Feb 1999 19:20:23 +0200 (EET)
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 TAA14912;
	Fri, 5 Feb 1999 19:20:23 +0200 (EET)
Received: (from majordom@localhost)
	by lohi.clinet.fi (8.9.1/8.9.0) id TAA16763
	for ietf-ssh-outgoing; Fri, 5 Feb 1999 19:17:26 +0200 (EET)
X-Authentication-Warning: lohi.clinet.fi: majordom set sender to owner-ietf-ssh@clinet.fi using -f
Received: from ratbert.iconnet.net (ratbert.iconnet.net [209.3.247.87])
	by lohi.clinet.fi (8.9.1/8.9.0) with ESMTP id TAA16759;
	Fri, 5 Feb 1999 19:17:23 +0200 (EET)
Received: from iconnet.net (localhost [127.0.0.1])
	by ratbert.iconnet.net (8.9.2/8.9.1) with ESMTP id LAA09159;
	Fri, 5 Feb 1999 11:31:25 -0500 (EST)
Message-Id: <199902051631.LAA09159@ratbert.iconnet.net>
X-Mailer: exmh version 2.0.2 2/24/98
To: Martin Forssen <maf@crt.se>
Cc: ssh@clinet.fi, ietf-ssh@clinet.fi
Subject: Re: Generic challenge-repsonse aunetication in ssh2 
In-reply-to: Your message of "Thu, 04 Feb 1999 17:03:13 +0100."
             <199902041603.RAA16539@giraf.carlstedt.se> 
Date: Fri, 05 Feb 1999 11:31:25 -0500
From: Frank Cusack <fcusack@iconnet.net>
Sender: owner-ietf-ssh@clinet.fi
Precedence: bulk
Content-Length: 1612
Lines: 38

In message <199902041603.RAA16539@giraf.carlstedt.se>, 
Martin Forssen writes:
> ---2137996019-851401618-918144200=:24784
> Content-Type: TEXT/plain; charset=us-ascii
> 
> Attached below follows a proposal for a new authentication method for
> SSH2. This new method implements general challenge-response
> authentication.
> 

I think that a better method would be one that I proposed earlier. :)
I have implemented it for ssh1 already. I call it "password-plus".
[I haven't implemented it for ssh2 due to licensing restrictions.]

The "problem" with the "challenge-response" method is that the server
may not know ahead of time (ie, solely from the username) if a user
requires challenge-reponse or standard password auth. eg. when PAM
is used as the backend.

Of course, if the user only requires password auth, no harm, no foul;
the "challenge" is simply the password request and the response is
simply the password. But, personally, I'd rather that the name be
more indicative that this is a generalized authentication, and
/not neccessarily/ challenge-response.

Another problem is if multiple challenges are required.

Another useful generalization is to support multiple messages in
a single "challenge". As an example, if the backend (eg PAM) is requesting
a password change and wants to prompt the user twice for the new
password, both prompts would be in a single "challenge" message.
A GUI client could then display both prompts in a single window.

I have the original text of my proposal around here somewhere if anyone
is interested, however the last time I proposed it I got no responses.

~frank

From owner-ietf-ssh@clinet.fi  Fri Feb  5 20:20:50 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 UAA19062;
	Fri, 5 Feb 1999 20:20:50 +0200 (EET)
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 UAA15278;
	Fri, 5 Feb 1999 20:20:50 +0200 (EET)
Received: (from majordom@localhost)
	by lohi.clinet.fi (8.9.1/8.9.0) id UAA23423
	for ietf-ssh-outgoing; Fri, 5 Feb 1999 20:19:02 +0200 (EET)
X-Authentication-Warning: lohi.clinet.fi: majordom set sender to owner-ietf-ssh@clinet.fi using -f
Received: from neon.transmeta.com (neon-best.transmeta.com [206.184.214.10])
	by lohi.clinet.fi (8.9.1/8.9.0) with ESMTP id UAA22762;
	Fri, 5 Feb 1999 20:11:31 +0200 (EET)
Received: from deepthought.transmeta.com (mailhost.transmeta.com [10.1.1.15])
	by neon.transmeta.com (8.9.1/8.9.1) with ESMTP id KAA09390;
	Fri, 5 Feb 1999 10:10:09 -0800
Received: from transmeta.com (morgan@blighty.transmeta.com [10.1.27.37])
	by deepthought.transmeta.com (8.8.8+spamcan/8.8.5) with ESMTP id KAA10299;
	Fri, 5 Feb 1999 10:10:21 -0800 (PST)
Message-ID: <36BB340D.3486393D@transmeta.com>
Date: Fri, 05 Feb 1999 10:10:21 -0800
From: Andrew Morgan <morgan@transmeta.com>
Organization: Transmeta Corporation
X-Mailer: Mozilla 4.05 [en] (X11; U; Linux 2.1.126 i686)
MIME-Version: 1.0
To: Frank Cusack <fcusack@iconnet.net>
CC: Martin Forssen <maf@crt.se>, ssh@clinet.fi, ietf-ssh@clinet.fi
Subject: Re: Generic challenge-repsonse aunetication in ssh2
References: <199902051631.LAA09159@ratbert.iconnet.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-ssh@clinet.fi
Precedence: bulk
Content-Length: 2321
Lines: 57

If anyone is interested in integrating it into ssh2, there is an old
piece of prototype code for adding complete PAM support to ssh1 (client
and server) here:

ftp://ftp.kernel.org/pub/linux/libs/pam/pre/applications/ssh-PAM-patch.2.tar.gz

If enough people were to make the statement that they'd like to see this
type of thing supported by ssh2, and someone wants to offer me a little
help, I'd be willing to forward port this patch.

I happen to know that this patch is happily used by a number of people,
and I believe that more would want to use it, if it was part of the
official distribution.

Cheers

Andrew

Frank Cusack wrote:
> 
> In message <199902041603.RAA16539@giraf.carlstedt.se>,
> Martin Forssen writes:
> > ---2137996019-851401618-918144200=:24784
> > Content-Type: TEXT/plain; charset=us-ascii
> >
> > Attached below follows a proposal for a new authentication method for
> > SSH2. This new method implements general challenge-response
> > authentication.
> >
> 
> I think that a better method would be one that I proposed earlier. :)
> I have implemented it for ssh1 already. I call it "password-plus".
> [I haven't implemented it for ssh2 due to licensing restrictions.]
> 
> The "problem" with the "challenge-response" method is that the server
> may not know ahead of time (ie, solely from the username) if a user
> requires challenge-reponse or standard password auth. eg. when PAM
> is used as the backend.
> 
> Of course, if the user only requires password auth, no harm, no foul;
> the "challenge" is simply the password request and the response is
> simply the password. But, personally, I'd rather that the name be
> more indicative that this is a generalized authentication, and
> /not neccessarily/ challenge-response.
> 
> Another problem is if multiple challenges are required.
> 
> Another useful generalization is to support multiple messages in
> a single "challenge". As an example, if the backend (eg PAM) is requesting
> a password change and wants to prompt the user twice for the new
> password, both prompts would be in a single "challenge" message.
> A GUI client could then display both prompts in a single window.
> 
> I have the original text of my proposal around here somewhere if anyone
> is interested, however the last time I proposed it I got no responses.
> 
> ~frank
From owner-ietf-ssh@clinet.fi  Sun Feb  7 18:35:35 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 SAA23229;
	Sun, 7 Feb 1999 18:35:35 +0200 (EET)
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 SAA28344;
	Sun, 7 Feb 1999 18:35:34 +0200 (EET)
Received: (from majordom@localhost)
	by lohi.clinet.fi (8.9.1/8.9.0) id SAA02580
	for ietf-ssh-outgoing; Sun, 7 Feb 1999 18:32:39 +0200 (EET)
X-Authentication-Warning: lohi.clinet.fi: majordom set sender to owner-ietf-ssh@clinet.fi using -f
Received: from neon.transmeta.com (neon-best.transmeta.com [206.184.214.10])
	by lohi.clinet.fi (8.9.1/8.9.0) with ESMTP id SAA01478;
	Sun, 7 Feb 1999 18:17:05 +0200 (EET)
Received: from deepthought.transmeta.com (mailhost.transmeta.com [10.1.1.15])
	by neon.transmeta.com (8.9.1/8.9.1) with ESMTP id IAA30722;
	Sun, 7 Feb 1999 08:12:22 -0800
Received: from transmeta.com (morgan@blighty.transmeta.com [10.1.27.37])
	by deepthought.transmeta.com (8.8.8+spamcan/8.8.5) with ESMTP id IAA10213;
	Sun, 7 Feb 1999 08:15:38 -0800 (PST)
Message-ID: <36BDBC29.FD749827@transmeta.com>
Date: Sun, 07 Feb 1999 08:15:37 -0800
From: Andrew Morgan <morgan@transmeta.com>
Organization: Transmeta Corporation
X-Mailer: Mozilla 4.05 [en] (X11; U; Linux 2.2.1 i686)
MIME-Version: 1.0
To: Jean Chouanard <chouanard@parc.xerox.com>
CC: Frank Cusack <fcusack@iconnet.net>, Martin Forssen <maf@crt.se>,
        ssh@clinet.fi, ietf-ssh@clinet.fi
Subject: Re: Generic challenge-repsonse aunetication in ssh2
References: <4.1.19990206215750.00923240@mailback.parc.xerox.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-ssh@clinet.fi
Precedence: bulk
Content-Length: 4417
Lines: 116

Jean,

I'm not clear if I understand what you are proposing. Are you saying
this?:

 "Look at the PAM patch and you see that it does two things

    a. add some generic message exchange types to the client and the
server (echo'd prompt, invisible prompt, binary prompt (raw data
exchange) etc..)
    b. add an interface to PAM to the server to abstract the
authentication method which can drive the (a.) message exchanges.

  "We could add (a.) and make it the generic interface for doing
authentication exchanges under ssh2. PAM-support would then look like
'just another' authentication type which makes use of generic message
exchange mechanism."

This sounds like a noble goal. If it can be attained, I'd be really
happy to see/use it. 

[Why, given the choice, anyone would not actually want to use PAM I'd be
interested to discuss (off line).]

Cheers

Andrew




Jean Chouanard wrote:
> 
> Yes but... Cannot we do better ? :-)
> 
> Not all systems have PAM or (want to) use it, and we know that the main
> problem to add a new authentication scheme to the ssh protocol is to have
> to modify both the client and the server to implement this as a new
> authentication protocol.
> 
> So why don't we split this ssh-PAM-patch in two:
> 
> * Support for the generic authentication protocol as pre-defined
> authentication method between the client and the server (and perhaps
> enlarge this method to be able to handle any needs for authentication).
> * An optional module to add PAM support for the server side, using this
> generic authentication.
> 
> Thus, any new authentication methods can either be implemented through PAM
> (if PAM is used on the ssh server) or they can be coded as a server module
> using the generic authentication to communicate with the client.
> 
> Don't you think it will be more valuable?
> 
>         jean
> 
> At 10:10 AM 2/5/99 -0800, someone using Andrew Morgan's login wrote:
> >If anyone is interested in integrating it into ssh2, there is an old
> >piece of prototype code for adding complete PAM support to ssh1 (client
> >and server) here:
> >
> >ftp://ftp.kernel.org/pub/linux/libs/pam/pre/applications/ssh-PAM-patch.2.ta
> r.gz
> >
> >If enough people were to make the statement that they'd like to see this
> >type of thing supported by ssh2, and someone wants to offer me a little
> >help, I'd be willing to forward port this patch.
> >
> >I happen to know that this patch is happily used by a number of people,
> >and I believe that more would want to use it, if it was part of the
> >official distribution.
> >
> >Cheers
> >
> >Andrew
> >
> >Frank Cusack wrote:
> >>
> >> In message <199902041603.RAA16539@giraf.carlstedt.se>,
> >> Martin Forssen writes:
> >> > ---2137996019-851401618-918144200=:24784
> >> > Content-Type: TEXT/plain; charset=us-ascii
> >> >
> >> > Attached below follows a proposal for a new authentication method for
> >> > SSH2. This new method implements general challenge-response
> >> > authentication.
> >> >
> >>
> >> I think that a better method would be one that I proposed earlier. :)
> >> I have implemented it for ssh1 already. I call it "password-plus".
> >> [I haven't implemented it for ssh2 due to licensing restrictions.]
> >>
> >> The "problem" with the "challenge-response" method is that the server
> >> may not know ahead of time (ie, solely from the username) if a user
> >> requires challenge-reponse or standard password auth. eg. when PAM
> >> is used as the backend.
> >>
> >> Of course, if the user only requires password auth, no harm, no foul;
> >> the "challenge" is simply the password request and the response is
> >> simply the password. But, personally, I'd rather that the name be
> >> more indicative that this is a generalized authentication, and
> >> /not neccessarily/ challenge-response.
> >>
> >> Another problem is if multiple challenges are required.
> >>
> >> Another useful generalization is to support multiple messages in
> >> a single "challenge". As an example, if the backend (eg PAM) is requesting
> >> a password change and wants to prompt the user twice for the new
> >> password, both prompts would be in a single "challenge" message.
> >> A GUI client could then display both prompts in a single window.
> >>
> >> I have the original text of my proposal around here somewhere if anyone
> >> is interested, however the last time I proposed it I got no responses.
> >>
> >> ~frank
>    - jean -
From owner-ietf-ssh@clinet.fi  Mon Feb  8 00:23: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 AAA28426;
	Mon, 8 Feb 1999 00:23:13 +0200 (EET)
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 AAA29748;
	Mon, 8 Feb 1999 00:23:13 +0200 (EET)
Received: (from majordom@localhost)
	by lohi.clinet.fi (8.9.1/8.9.0) id AAA00894
	for ietf-ssh-outgoing; Mon, 8 Feb 1999 00:19:28 +0200 (EET)
X-Authentication-Warning: lohi.clinet.fi: majordom set sender to owner-ietf-ssh@clinet.fi using -f
Received: from GATE.INNOSOFT.COM (SYSTEM@GATE.INNOSOFT.COM [192.160.253.77])
	by lohi.clinet.fi (8.9.1/8.9.0) with ESMTP id AAA00888;
	Mon, 8 Feb 1999 00:19:26 +0200 (EET)
Received: from elvira.innosoft.com (ELVIRA.INNOSOFT.COM [192.160.253.135])
 by GATE.INNOSOFT.COM (PMDF V5.2-29 #10099)
 with ESMTP id <01J7GRA3VVU800026G@GATE.INNOSOFT.COM>; Sun,
 7 Feb 1999 14:18:27 PST
Received: from elwood.innosoft.com (ELWOOD.INNOSOFT.COM [192.160.253.235])
 by elvira.innosoft.com (PMDF V5.2-31 #13579)
 with SMTP id <0F6T00LGX1WZCM@elvira.innosoft.com>; Sun,
 07 Feb 1999 14:17:23 -0800 (PST)
Date: Sun, 07 Feb 1999 14:18:18 -0800 (PST)
From: Chris Newman <chris@INNOSOFT.COM>
Subject: Re: Generic challenge-repsonse aunetication in ssh2
In-reply-to: <199902041603.RAA16539@giraf.carlstedt.se>
Originator-info: login-id=chris; server=THOR.INNOSOFT.COM
To: Martin Forssen <maf@crt.se>
Cc: ssh@clinet.fi, ietf-ssh@clinet.fi
Message-id: <Pine.SOL.3.95.990207141457.17299I-100000@elwood.innosoft.com>
MIME-version: 1.0
Content-type: TEXT/PLAIN; charset=US-ASCII
Content-transfer-encoding: 7BIT
Sender: owner-ietf-ssh@clinet.fi
Precedence: bulk
Content-Length: 604
Lines: 16

On Thu, 4 Feb 1999, Martin Forssen wrote:
> Attached below follows a proposal for a new authentication method for
> SSH2. This new method implements general challenge-response
> authentication.

If you do a challenge response mechanism, make it compatible with HTTP
Digest and the DIGEST mechanism:

  <http://www.ietf.org/internet-drafts/draft-leach-digest-sasl-01.txt>

As was noted by others, ill-conceived security APIs like PAM actually make
network security harder so convergence on a single challenge-response
mechanism is important for multi-protocol code reuse and interoperability.

		- Chris

From owner-ietf-ssh@clinet.fi  Mon Feb  8 05:54: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 FAA29124;
	Mon, 8 Feb 1999 05:54:18 +0200 (EET)
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 FAA01881;
	Mon, 8 Feb 1999 05:54:18 +0200 (EET)
Received: (from majordom@localhost)
	by lohi.clinet.fi (8.9.1/8.9.0) id FAA19682
	for ietf-ssh-outgoing; Mon, 8 Feb 1999 05:51:32 +0200 (EET)
X-Authentication-Warning: lohi.clinet.fi: majordom set sender to owner-ietf-ssh@clinet.fi using -f
Received: from alpha.xerox.com (firewall-user@alpha.Xerox.COM [13.1.64.93])
	by lohi.clinet.fi (8.9.1/8.9.0) with SMTP id FAA19244;
	Mon, 8 Feb 1999 05:42:02 +0200 (EET)
Received: from thelma.parc.xerox.com ([13.1.100.28]) by alpha.xerox.com with SMTP id <51916(2)>; Sun, 7 Feb 1999 19:40:55 PST
Received: from gevrey.h2tp.com ([13.0.209.38]) by thelma.parc.xerox.com with SMTP id <102235>; Sun, 7 Feb 1999 19:40:50 PST
Message-Id: <4.1.19990207172817.00ac6690@mailback.parc.xerox.com>
X-Sender: chouanar@mailback.parc.xerox.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Sun, 7 Feb 1999 19:39:26 PST
To: Chris Newman <chris@INNOSOFT.COM>
From: Jean Chouanard <chouanard@parc.xerox.com>
Subject: Re: Generic challenge-repsonse authentication in ssh2
Cc: Martin Forssen <maf@crt.se>, ssh@clinet.fi, ietf-ssh@clinet.fi
In-Reply-To: <Pine.SOL.3.95.990207141457.17299I-100000@elwood.innosoft.c
 om>
References: <199902041603.RAA16539@giraf.carlstedt.se>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ietf-ssh@clinet.fi
Precedence: bulk
Content-Length: 1404
Lines: 39

Chris,

I might be wrong, but I don't see how an authentication mechanism which
will need more than *one* exchange between the server and the client to be
validate can be implemented through this scheme. 

Reading this document, I understand:
In "2.1.3 Step Three": The server receives and validates the
"digest-response". = the Authentication is either accepted or reject, and
the challenge is always closed.

For some authentication method one or more additional challenge/response
are needed before being able to judge the validity of the authentication.
A typical example for such multiple exchange need is SecurID in next token
mode where *two* challenge are needed.

Did I miss something?

	jean

At 02:18 PM 2/7/99 -0800, someone using Chris Newman's login wrote:
>On Thu, 4 Feb 1999, Martin Forssen wrote:
>> Attached below follows a proposal for a new authentication method for
>> SSH2. This new method implements general challenge-response
>> authentication.
>
>If you do a challenge response mechanism, make it compatible with HTTP
>Digest and the DIGEST mechanism:
>
>  <http://www.ietf.org/internet-drafts/draft-leach-digest-sasl-01.txt>
>
>As was noted by others, ill-conceived security APIs like PAM actually make
>network security harder so convergence on a single challenge-response
>mechanism is important for multi-protocol code reuse and interoperability.
>
>		- Chris
>

   - jean -
From owner-ietf-ssh@clinet.fi  Mon Feb  8 08:22:01 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 IAA28736;
	Mon, 8 Feb 1999 08:22:01 +0200 (EET)
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 IAA02598;
	Mon, 8 Feb 1999 08:22:01 +0200 (EET)
Received: (from majordom@localhost)
	by lohi.clinet.fi (8.9.1/8.9.0) id IAA27936
	for ietf-ssh-outgoing; Mon, 8 Feb 1999 08:19:07 +0200 (EET)
X-Authentication-Warning: lohi.clinet.fi: majordom set sender to owner-ietf-ssh@clinet.fi using -f
Received: from alpha.xerox.com (firewall-user@alpha.Xerox.COM [13.1.64.93])
	by lohi.clinet.fi (8.9.1/8.9.0) with SMTP id IAA27175;
	Mon, 8 Feb 1999 08:11:09 +0200 (EET)
Received: from thelma.parc.xerox.com ([13.1.100.28]) by alpha.xerox.com with SMTP id <52405(5)>; Sun, 7 Feb 1999 22:10:07 PST
Received: from gevrey.h2tp.com ([13.0.209.38]) by thelma.parc.xerox.com with SMTP id <102257>; Sun, 7 Feb 1999 22:10:05 PST
Message-Id: <4.1.19990207194220.00aa9d50@mailback.parc.xerox.com>
X-Sender: chouanar@mailback.parc.xerox.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Sun, 7 Feb 1999 22:09:40 PST
To: Andrew Morgan <morgan@transmeta.com>
From: Jean Chouanard <chouanard@parc.xerox.com>
Subject: Re: Generic challenge-repsonse aunetication in ssh2
Cc: Frank Cusack <fcusack@iconnet.net>, Martin Forssen <maf@crt.se>,
        ssh@clinet.fi, ietf-ssh@clinet.fi
In-Reply-To: <36BDBC29.FD749827@transmeta.com>
References: <4.1.19990206215750.00923240@mailback.parc.xerox.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ietf-ssh@clinet.fi
Precedence: bulk
Content-Length: 5855
Lines: 151

Andrew:

At 08:15 AM 2/7/99 -0800, someone using Andrew Morgan's login wrote:

>    a. add some generic message exchange types to the client and the
>server (echo'd prompt, invisible prompt, binary prompt (raw data
>exchange) etc..)

Yes and this has to be properly defined to be generic enough so that it
will stable in the future. Piece of cake! :-)

>    b. add an interface to PAM to the server to abstract the
>authentication method which can drive the (a.) message exchanges.

Yes.

>
>  "We could add (a.) and make it the generic interface for doing
>authentication exchanges under ssh2. PAM-support would then look like
>'just another' authentication type which makes use of generic message
>exchange mechanism."
>

Yes, but I would say : "We could add (a.) and make it the generic interface
for doing *NEW* authentication exchanges under ssh[2|1]."

It's important to keep all the existing authentication protocols without
any changes for compatibility reason.

Also, it is a nice option to have, as a fallback protocol, a predefined
authentication protocol, to be used if the client does not support the
*new* generic authentication. 

I explain: 
if I setup a server to use *only* the new generic authentication protocol,
and PAM as authentication mechanism, but if I want it still to accept *old*
clients which do not have this protocol built in, I may choose to enable a
pre-defined authentication protocol as a fallback(Let say the password
protocol for ex.)
I know that for such *old* clients, I won't be able to change their prompt,
or that more complex challenge won't be handled properly (multiple
challenge) but it should be *good enough* for most of the requests.
The authentication method is still the same (PAM in this case) but a
deprecated authentication protocol may be used to talk with old clients.

I have done that on the securID patch I've done to handle correctly the
different modes of securID and the fallback mechanism is really nice. 

	jean

>This sounds like a noble goal. If it can be attained, I'd be really
>happy to see/use it. 
>
>[Why, given the choice, anyone would not actually want to use PAM I'd be
>interested to discuss (off line).]
>
>Cheers
>
>Andrew
>
>
>
>
>Jean Chouanard wrote:
>> 
>> Yes but... Cannot we do better ? :-)
>> 
>> Not all systems have PAM or (want to) use it, and we know that the main
>> problem to add a new authentication scheme to the ssh protocol is to have
>> to modify both the client and the server to implement this as a new
>> authentication protocol.
>> 
>> So why don't we split this ssh-PAM-patch in two:
>> 
>> * Support for the generic authentication protocol as pre-defined
>> authentication method between the client and the server (and perhaps
>> enlarge this method to be able to handle any needs for authentication).
>> * An optional module to add PAM support for the server side, using this
>> generic authentication.
>> 
>> Thus, any new authentication methods can either be implemented through PAM
>> (if PAM is used on the ssh server) or they can be coded as a server module
>> using the generic authentication to communicate with the client.
>> 
>> Don't you think it will be more valuable?
>> 
>>         jean
>> 
>> At 10:10 AM 2/5/99 -0800, someone using Andrew Morgan's login wrote:
>> >If anyone is interested in integrating it into ssh2, there is an old
>> >piece of prototype code for adding complete PAM support to ssh1 (client
>> >and server) here:
>> >
>> >ftp://ftp.kernel.org/pub/linux/libs/pam/pre/applications/ssh-PAM-patch.2.ta
>> r.gz
>> >
>> >If enough people were to make the statement that they'd like to see this
>> >type of thing supported by ssh2, and someone wants to offer me a little
>> >help, I'd be willing to forward port this patch.
>> >
>> >I happen to know that this patch is happily used by a number of people,
>> >and I believe that more would want to use it, if it was part of the
>> >official distribution.
>> >
>> >Cheers
>> >
>> >Andrew
>> >
>> >Frank Cusack wrote:
>> >>
>> >> In message <199902041603.RAA16539@giraf.carlstedt.se>,
>> >> Martin Forssen writes:
>> >> > ---2137996019-851401618-918144200=:24784
>> >> > Content-Type: TEXT/plain; charset=us-ascii
>> >> >
>> >> > Attached below follows a proposal for a new authentication method for
>> >> > SSH2. This new method implements general challenge-response
>> >> > authentication.
>> >> >
>> >>
>> >> I think that a better method would be one that I proposed earlier. :)
>> >> I have implemented it for ssh1 already. I call it "password-plus".
>> >> [I haven't implemented it for ssh2 due to licensing restrictions.]
>> >>
>> >> The "problem" with the "challenge-response" method is that the server
>> >> may not know ahead of time (ie, solely from the username) if a user
>> >> requires challenge-reponse or standard password auth. eg. when PAM
>> >> is used as the backend.
>> >>
>> >> Of course, if the user only requires password auth, no harm, no foul;
>> >> the "challenge" is simply the password request and the response is
>> >> simply the password. But, personally, I'd rather that the name be
>> >> more indicative that this is a generalized authentication, and
>> >> /not neccessarily/ challenge-response.
>> >>
>> >> Another problem is if multiple challenges are required.
>> >>
>> >> Another useful generalization is to support multiple messages in
>> >> a single "challenge". As an example, if the backend (eg PAM) is
requesting
>> >> a password change and wants to prompt the user twice for the new
>> >> password, both prompts would be in a single "challenge" message.
>> >> A GUI client could then display both prompts in a single window.
>> >>
>> >> I have the original text of my proposal around here somewhere if anyone
>> >> is interested, however the last time I proposed it I got no responses.
>> >>
>> >> ~frank
>>    - jean -

   - jean -
From owner-ietf-ssh@clinet.fi  Mon Feb  8 13:01: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 NAA12763;
	Mon, 8 Feb 1999 13:01:14 +0200 (EET)
From: owner-ietf-ssh@clinet.fi
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 NAA06855;
	Mon, 8 Feb 1999 13:01:13 +0200 (EET)
Received: (from majordom@localhost)
	by lohi.clinet.fi (8.9.1/8.9.0) id MAA12328
	for ietf-ssh-outgoing; Mon, 8 Feb 1999 12:55:44 +0200 (EET)
Date: Mon, 8 Feb 1999 12:55:44 +0200 (EET)
Message-Id: <199902081055.MAA12328@lohi.clinet.fi>
X-Authentication-Warning: lohi.clinet.fi: majordom set sender to owner-ietf-ssh@clinet.fi using -f
In-Reply-To: <199902041603.RAA16539@giraf.carlstedt.se>; from Martin
Content-Length: 1979
Lines: 42

Forssen on Thu, Feb 04, 1999 at 05:03:13PM +0100
Sender: owner-ietf-ssh@clinet.fi
Precedence: bulk

On Thu, Feb 04, 1999 at 17:03:13 +0100, Martin Forssen wrote:
> This protocol is written so that the client should not need to neither
> know nor care about which challenge-response method the user really
> uses. The most important issue is to get the generic support into the
> clients since it is so much easier to modify a handful of servers that
> hunderds of clients (the server must of course know the details of the
> underlying authentication method).

>      Challenge-response authentication method for the SSH protocol

IMHO one of the things I dislike about authentication in a Un*x environment
is the lack of standardisation. Currently, there are some attempts to define
more or less generic authentication layers; most notably PAM
(http://www.us.kernel.org/pub/linux/libs/pam/) and PNIAM
(http://www.msu.ru/pniam/pniam.html). Have you considered those?

There are several PAM patches for ssh1 available; see
http://www.linuxhq.com/lnxlists/linux-security/lu_9810/msg00001.html With
PAM, the ssh daemon does not need to know the details of the underlying
authentication method; those are handled by the PAM library and the
pluggable authentication modules themselves. This allows one for instance to
change the authentication policy without requiring a recompilation of the
daemon.

I understand there's a difference between a protocol layer that allows for
generic authentication methods and an actual software authentication layer
on the server side, but I suspect that it would be wise to recommend
implementation of the server side authentication handling be done through a
software authentication layer like PAM.

Greetings,
Ray
-- 
UNFAIR  Term applied to advantages enjoyed by other people which we tried 
to cheat them out of and didn't manage. See also DISHONESTY, SNEAKY, 
UNDERHAND and JUST LUCKY I GUESS.     
- The Hipcrime Vocab by Chad C. Mulligan  

From owner-ietf-ssh@clinet.fi  Mon Feb  8 20:50: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 UAA04228;
	Mon, 8 Feb 1999 20:50:15 +0200 (EET)
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 UAA15043;
	Mon, 8 Feb 1999 20:50:15 +0200 (EET)
Received: (from majordom@localhost)
	by lohi.clinet.fi (8.9.1/8.9.0) id UAA25164
	for ietf-ssh-outgoing; Mon, 8 Feb 1999 20:48:25 +0200 (EET)
Received: from nic.carlstedt.se (nic.carlstedt.se [193.12.107.10])
	by lohi.clinet.fi (8.9.1/8.9.0) with ESMTP id UAA25155;
	Mon, 8 Feb 1999 20:48:22 +0200 (EET)
Received: from giraf.carlstedt.se (root@giraf.carlstedt.se [172.16.1.10])
	by nic.carlstedt.se (8.9.3/8.9.3) with ESMTP id TAA21311;
	Mon, 8 Feb 1999 19:47:13 +0100 (MET)
Received: from spitfire.carlstedt.se (maf@spitfire.carlstedt.se [172.16.1.70])
	by giraf.carlstedt.se (8.9.3/8.9.3) with ESMTP id TAA10701;
	Mon, 8 Feb 1999 19:47:12 +0100 (MET)
Received: from localhost (maf@localhost)
	by spitfire.carlstedt.se (8.9.1/8.9.1) with ESMTP id TAA17995;
	Mon, 8 Feb 1999 19:47:11 +0100 (MET)
X-Authentication-Warning: spitfire.carlstedt.se: maf owned process doing -bs
Date: Mon, 8 Feb 1999 19:47:11 +0100 (MET)
From: Martin Forssen <maf@firedoor.se>
X-Sender: maf@spitfire.carlstedt.se
To: Chris Newman <chris@INNOSOFT.COM>
cc: Martin Forssen <maf@firedoor.se>, ssh@clinet.fi, ietf-ssh@clinet.fi
Subject: Re: Generic challenge-repsonse aunetication in ssh2
In-Reply-To: <Pine.SOL.3.95.990207141457.17299I-100000@elwood.innosoft.com>
Message-ID: <Pine.GSO.4.04.9902081942490.17960-100000@spitfire.carlstedt.se>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ietf-ssh@clinet.fi
Precedence: bulk
Content-Length: 693
Lines: 18

On Sun, 7 Feb 1999, Chris Newman wrote:
> On Thu, 4 Feb 1999, Martin Forssen wrote:
> > Attached below follows a proposal for a new authentication method for
> > SSH2. This new method implements general challenge-response
> > authentication.
> 
> If you do a challenge response mechanism, make it compatible with HTTP
> Digest and the DIGEST mechanism:
> 
>   <http://www.ietf.org/internet-drafts/draft-leach-digest-sasl-01.txt>

I am not really sure that is a good idea since the conditions are quite
different. The draft mentioned above is quite concerned with protecting
the authentication data while on the wire whereas in ssh we already have a
secure channel when authenticating.

	/MaF

From owner-ietf-ssh@clinet.fi  Mon Feb  8 22:06:17 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 WAA02368;
	Mon, 8 Feb 1999 22:06:17 +0200 (EET)
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 WAA15626;
	Mon, 8 Feb 1999 22:06:16 +0200 (EET)
Received: (from majordom@localhost)
	by lohi.clinet.fi (8.9.1/8.9.0) id WAA03700
	for ietf-ssh-outgoing; Mon, 8 Feb 1999 22:04:59 +0200 (EET)
Received: from nic.carlstedt.se (nic.carlstedt.se [193.12.107.10])
	by lohi.clinet.fi (8.9.1/8.9.0) with ESMTP id WAA03695;
	Mon, 8 Feb 1999 22:04:56 +0200 (EET)
Received: from giraf.carlstedt.se (root@giraf.carlstedt.se [172.16.1.10])
	by nic.carlstedt.se (8.9.3/8.9.3) with ESMTP id VAA21757;
	Mon, 8 Feb 1999 21:03:30 +0100 (MET)
Received: from spitfire.carlstedt.se (maf@spitfire.carlstedt.se [172.16.1.70])
	by giraf.carlstedt.se (8.9.3/8.9.3) with ESMTP id VAA12108;
	Mon, 8 Feb 1999 21:03:29 +0100 (MET)
Received: from localhost (maf@localhost)
	by spitfire.carlstedt.se (8.9.1/8.9.1) with ESMTP id VAA18076;
	Mon, 8 Feb 1999 21:03:28 +0100 (MET)
X-Authentication-Warning: spitfire.carlstedt.se: maf owned process doing -bs
Date: Mon, 8 Feb 1999 21:03:28 +0100 (MET)
From: Martin Forssen <maf@firedoor.se>
X-Sender: maf@spitfire.carlstedt.se
To: Jean Chouanard <chouanard@parc.xerox.com>
cc: Andrew Morgan <morgan@transmeta.com>, Frank Cusack <fcusack@iconnet.net>,
        ssh@clinet.fi, ietf-ssh@clinet.fi
Subject: Re: Generic challenge-repsonse aunetication in ssh2
In-Reply-To: <4.1.19990207194220.00aa9d50@mailback.parc.xerox.com>
Message-ID: <Pine.GSO.4.04.9902081947260.17960-100000@spitfire.carlstedt.se>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ietf-ssh@clinet.fi
Precedence: bulk
Content-Length: 1777
Lines: 41

On Sun, 7 Feb 1999, Jean Chouanard wrote:
> At 08:15 AM 2/7/99 -0800, someone using Andrew Morgan's login wrote:
> >    a. add some generic message exchange types to the client and the
> >server (echo'd prompt, invisible prompt, binary prompt (raw data
> >exchange) etc..)
> Yes and this has to be properly defined to be generic enough so that it
> will stable in the future. Piece of cake! :-)

I must admit I am no expert on PAM, but from what I can see there are
two distinctive modes. One where it expects to talk to an user  and one
where it expects to talk to some program (via the PAM_BINARY... messages).

Implementing the first one is simple and only needs one simple
modification of my draft (addition of a message packet from server to
client witha bit to indicate error). Since the replies are expected to be
retreived from teh user the client does not need to know anything special.

The second one is tougher. The one thing I haven't found anything about in
the documents I have read is that how does the client know which module to
use? I might sit at a client with a smartcard reader, a retinal scanner
and a fingerprint reader. How do the client know which to use?

> It's important to keep all the existing authentication protocols without
> any changes for compatibility reason.

Yes Amen etc. This is imperative.

> Also, it is a nice option to have, as a fallback protocol, a predefined
> authentication protocol, to be used if the client does not support the
> *new* generic authentication. 

It is also a requirement of the ssh2 protocol (the publickkey
authentication is required).

> >[Why, given the choice, anyone would not actually want to use PAM I'd be
> >interested to discuss (off line).]

I guess that is a good topic for some beers:-)

	/MaF

From owner-ietf-ssh@clinet.fi  Mon Feb  8 23:15: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 XAA06280;
	Mon, 8 Feb 1999 23:15:02 +0200 (EET)
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 XAA16097;
	Mon, 8 Feb 1999 23:15:01 +0200 (EET)
Received: (from majordom@localhost)
	by lohi.clinet.fi (8.9.1/8.9.0) id XAA11084
	for ietf-ssh-outgoing; Mon, 8 Feb 1999 23:13:12 +0200 (EET)
X-Authentication-Warning: lohi.clinet.fi: majordom set sender to owner-ietf-ssh@clinet.fi using -f
Received: from ratbert.iconnet.net (ratbert.iconnet.net [209.3.247.87])
	by lohi.clinet.fi (8.9.1/8.9.0) with ESMTP id XAA11072;
	Mon, 8 Feb 1999 23:13:09 +0200 (EET)
Received: from iconnet.net (localhost [127.0.0.1])
	by ratbert.iconnet.net (8.9.2/8.9.1) with ESMTP id QAA18241;
	Mon, 8 Feb 1999 16:13:57 -0500 (EST)
Message-Id: <199902082113.QAA18241@ratbert.iconnet.net>
X-Mailer: exmh version 2.0.2 2/24/98
To: Martin Forssen <maf@firedoor.se>
Cc: Jean Chouanard <chouanard@parc.xerox.com>,
        Andrew Morgan <morgan@transmeta.com>, ssh@clinet.fi,
        ietf-ssh@clinet.fi
Subject: Re: Generic challenge-repsonse aunetication in ssh2 
In-reply-to: Your message of "Mon, 08 Feb 1999 21:03:28 +0100."
             <Pine.GSO.4.04.9902081947260.17960-100000@spitfire.carlstedt.se> 
Date: Mon, 08 Feb 1999 16:13:57 -0500
From: Frank Cusack <fcusack@iconnet.net>
Sender: owner-ietf-ssh@clinet.fi
Precedence: bulk
Content-Length: 1896
Lines: 40

In message <Pine.GSO.4.04.9902081947260.17960-100000@spitfire.carlstedt.se>, 
Martin Forssen writes:
> On Sun, 7 Feb 1999, Jean Chouanard wrote:
> > At 08:15 AM 2/7/99 -0800, someone using Andrew Morgan's login wrote:
> > >    a. add some generic message exchange types to the client and the
> > >server (echo'd prompt, invisible prompt, binary prompt (raw data
> > >exchange) etc..)
> > Yes and this has to be properly defined to be generic enough so that it
> > will stable in the future. Piece of cake! :-)
> 
> I must admit I am no expert on PAM, but from what I can see there are
> two distinctive modes. One where it expects to talk to an user  and one
> where it expects to talk to some program (via the PAM_BINARY... messages).
> 
> Implementing the first one is simple and only needs one simple
> modification of my draft (addition of a message packet from server to
> client witha bit to indicate error). Since the replies are expected to be
> retreived from teh user the client does not need to know anything special.
> 
> The second one is tougher. The one thing I haven't found anything about in
> the documents I have read is that how does the client know which module to
> use? I might sit at a client with a smartcard reader, a retinal scanner
> and a fingerprint reader. How do the client know which to use?

The client doesn't use any PAM modules. Presumably the prompt string
includes enough information so the user knows what auth device to use.
This gets kind of broken with PAM_BINARY, but I don't think it's
a good idea to implement that at this time anyway.

What the original message referred to (which you must have accidentally
elided :) ) was PAM support on the *server* side. In this case, it's
still transparent to the server, everything is done within the PAM
libraries.

I will post my proposal tomorrow (after I have time to dig it up and
clean it up).

~frank


From owner-ietf-ssh@clinet.fi  Tue Feb  9 20:02:55 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 UAA28496;
	Tue, 9 Feb 1999 20:02:54 +0200 (EET)
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 UAA25598;
	Tue, 9 Feb 1999 20:02:54 +0200 (EET)
Received: (from majordom@localhost)
	by lohi.clinet.fi (8.9.1/8.9.0) id TAA09623
	for ietf-ssh-outgoing; Tue, 9 Feb 1999 19:59:12 +0200 (EET)
X-Authentication-Warning: lohi.clinet.fi: majordom set sender to owner-ietf-ssh@clinet.fi using -f
Received: from GATE.INNOSOFT.COM (SYSTEM@GATE.INNOSOFT.COM [192.160.253.77])
	by lohi.clinet.fi (8.9.1/8.9.0) with ESMTP id TAA09615;
	Tue, 9 Feb 1999 19:59:09 +0200 (EET)
Received: from elvira.innosoft.com (ELVIRA.INNOSOFT.COM [192.160.253.135])
 by GATE.INNOSOFT.COM (PMDF V5.2-29 #10099)
 with ESMTP id <01J7JARSOZ4K00096A@GATE.INNOSOFT.COM>; Tue,
 9 Feb 1999 09:57:56 PST
Received: from elwood.innosoft.com (ELWOOD.INNOSOFT.COM [192.160.253.235])
 by elvira.innosoft.com (PMDF V5.2-31 #13579)
 with SMTP id <0F6W00ANRF6PU0@elvira.innosoft.com>; Tue,
 09 Feb 1999 09:56:50 -0800 (PST)
Date: Tue, 09 Feb 1999 09:57:45 -0800 (PST)
From: Chris Newman <chris@INNOSOFT.COM>
Subject: Re: Generic challenge-repsonse aunetication in ssh2
In-reply-to: <Pine.GSO.4.04.9902081942490.17960-100000@spitfire.carlstedt.se>
Originator-info: login-id=chris; server=THOR.INNOSOFT.COM
To: Martin Forssen <maf@firedoor.se>
Cc: ssh@clinet.fi, ietf-ssh@clinet.fi
Message-id: <Pine.SOL.3.95.990209095339.3616A-100000@elwood.innosoft.com>
MIME-version: 1.0
Content-type: TEXT/PLAIN; charset=US-ASCII
Content-transfer-encoding: 7BIT
Sender: owner-ietf-ssh@clinet.fi
Precedence: bulk
Content-Length: 703
Lines: 16

On Mon, 8 Feb 1999, Martin Forssen wrote:
> I am not really sure that is a good idea since the conditions are quite
> different. The draft mentioned above is quite concerned with protecting
> the authentication data while on the wire whereas in ssh we already have a
> secure channel when authenticating.

Fair enough.  I didn't say it should be identical, but it'd be a lot
better if whatever mechanism is used in SSH can share the same format for
the predigested password verifiers on the server end.  FYI, there appears
to be a good chance that DIGEST-MD5 will have OS support in Windows 2000.
It's certainly nice to be able to use the OS password services rather than
rolling your own.

		- Chris


From owner-ietf-ssh@clinet.fi  Wed Feb 10 12:48:58 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 MAA04521;
	Wed, 10 Feb 1999 12:48:58 +0200 (EET)
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 MAA00755;
	Wed, 10 Feb 1999 12:48:58 +0200 (EET)
Received: (from majordom@localhost)
	by lohi.clinet.fi (8.9.1/8.9.0) id MAA02452
	for ietf-ssh-outgoing; Wed, 10 Feb 1999 12:45:39 +0200 (EET)
X-Authentication-Warning: lohi.clinet.fi: majordom set sender to owner-ietf-ssh@clinet.fi using -f
Received: from pompano.pcola.gulf.net (root@gulf.net [198.69.72.14])
	by lohi.clinet.fi (8.9.1/8.9.0) with ESMTP id BAA16447;
	Wed, 10 Feb 1999 01:21:22 +0200 (EET)
Received: from whgiii (minke42.pcola.gulf.net [205.160.71.57])
	by pompano.pcola.gulf.net (8.9.1a/8.9.1) with SMTP id RAA12242;
	Tue, 9 Feb 1999 17:18:59 -0600 (CST)
Received: from 100.100.100.1 by whgiii (IBM OS/2 SENDMAIL VERSION 2.03/2.0) id RAA016.05; Tue, 9 Feb 1999 17:32:10 -0500
Message-Id: <199902092232.RAA016.05@whgiii>
From: "William H. Geiger III" <whgiii@invweb.net>
Date: Tue, 09 Feb 1999 17:30:41 -0500
To: Chris Newman <chris@INNOSOFT.COM>
In-Reply-To: <Pine.SOL.3.95.990209095339.3616A-100000@elwood.innosoft.com>
Cc: Martin Forssen <maf@firedoor.se>, ssh@clinet.fi, ietf-ssh@clinet.fi
Subject: Re: Generic challenge-repsonse aunetication in ssh2
X-Mailer: MR/2 Internet Cruiser Edition for OS/2 v1.52 b52 
Sender: owner-ietf-ssh@clinet.fi
Precedence: bulk
Content-Length: 1776
Lines: 47

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

In <Pine.SOL.3.95.990209095339.3616A-100000@elwood.innosoft.com>, on
02/09/99 
   at 09:57 AM, Chris Newman <chris@INNOSOFT.COM> said:

>On Mon, 8 Feb 1999, Martin Forssen wrote:
>> I am not really sure that is a good idea since the conditions are quite
>> different. The draft mentioned above is quite concerned with protecting
>> the authentication data while on the wire whereas in ssh we already have a
>> secure channel when authenticating.

>Fair enough.  I didn't say it should be identical, but it'd be a lot
>better if whatever mechanism is used in SSH can share the same format for
>the predigested password verifiers on the server end.  FYI, there appears
>to be a good chance that DIGEST-MD5 will have OS support in Windows 2000.
>It's certainly nice to be able to use the OS password services rather
>than rolling your own.

Nothing personal but with M$'s track record when it comes to security the
last thing I would want to use it one of their OS's password services.

- -- 
- ---------------------------------------------------------------
William H. Geiger III  http://www.openpgp.net
Geiger Consulting    Cooking With Warp 4.0

Author of E-Secure - PGP Front End for MR/2 Ice
PGP & MR/2 the only way for secure e-mail.
OS/2 PGP 5.0 at: http://www.openpgp.net/pgp.html
Talk About PGP on IRC EFNet Channel: #pgp Nick: whgiii
- ---------------------------------------------------------------
 
Tag-O-Matic: He who laughs last uses OS/2.

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 5.0i OS/2 for non-commercial use
Comment: Registered_User_E-Secure_v1.1b1_ES000000
Charset: cp850

wj8DBQE2wKlYlHpjA6A1ypsRAhmhAKCbKRCos3EEon31lbcDo3N3SLGBtACbBLD7
WPQM0fUMdVj8RRm9vYxVh6U=
=C9gC
-----END PGP SIGNATURE-----


From owner-ietf-ssh@clinet.fi  Wed Feb 10 02:07:40 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 CAA29970;
	Wed, 10 Feb 1999 02:07:39 +0200 (EET)
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 CAA26907;
	Wed, 10 Feb 1999 02:07:39 +0200 (EET)
Received: (from majordom@localhost)
	by lohi.clinet.fi (8.9.1/8.9.0) id CAA20957
	for ietf-ssh-outgoing; Wed, 10 Feb 1999 02:06:18 +0200 (EET)
X-Authentication-Warning: lohi.clinet.fi: majordom set sender to owner-ietf-ssh@clinet.fi using -f
Received: from GATE.INNOSOFT.COM (SYSTEM@GATE.INNOSOFT.COM [192.160.253.77])
	by lohi.clinet.fi (8.9.1/8.9.0) with ESMTP id CAA20947;
	Wed, 10 Feb 1999 02:06:12 +0200 (EET)
Received: from elvira.innosoft.com (ELVIRA.INNOSOFT.COM [192.160.253.135])
 by GATE.INNOSOFT.COM (PMDF V5.2-29 #10099)
 with ESMTP id <01J7JNKRBM0U0009DE@GATE.INNOSOFT.COM>; Tue,
 9 Feb 1999 16:04:53 PST
Received: from elwood.innosoft.com (ELWOOD.INNOSOFT.COM [192.160.253.235])
 by elvira.innosoft.com (PMDF V5.2-31 #13579)
 with SMTP id <0F6W00M5VW6AEI@elvira.innosoft.com>; Tue,
 09 Feb 1999 16:03:46 -0800 (PST)
Date: Tue, 09 Feb 1999 16:04:42 -0800 (PST)
From: Chris Newman <chris@INNOSOFT.COM>
Subject: Re: Generic challenge-repsonse aunetication in ssh2
In-reply-to: <199902092232.RAA016.05@whgiii>
Originator-info: login-id=chris; server=THOR.INNOSOFT.COM
To: "William H. Geiger III" <whgiii@invweb.net>
Cc: Martin Forssen <maf@firedoor.se>, ssh@clinet.fi, ietf-ssh@clinet.fi
Message-id: <Pine.SOL.3.95.990209155939.3616S-100000@elwood.innosoft.com>
MIME-version: 1.0
Content-type: TEXT/PLAIN; charset=US-ASCII
Content-transfer-encoding: 7BIT
Sender: owner-ietf-ssh@clinet.fi
Precedence: bulk
Content-Length: 622
Lines: 16

On Tue, 9 Feb 1999, William H. Geiger III wrote:
> Nothing personal but with M$'s track record when it comes to security the
> last thing I would want to use it one of their OS's password services.

I sympathize.  But site administrators who have to manage users don't want
to have two password databases.  So if you actually want your software
used, it's important it can at least share the same backend database as
other software which authenticates users.

If you invent a challenge response mechanism with it's own custom backend
password verifier format, then you've just made life harder for everyone.

		- Chris



From owner-ietf-ssh@clinet.fi  Wed Feb 10 23:03:43 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 XAA15752;
	Wed, 10 Feb 1999 23:03:42 +0200 (EET)
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 XAA04563;
	Wed, 10 Feb 1999 23:03:42 +0200 (EET)
Received: (from majordom@localhost)
	by lohi.clinet.fi (8.9.1/8.9.0) id XAA26934
	for ietf-ssh-outgoing; Wed, 10 Feb 1999 23:00:45 +0200 (EET)
Received: from nic.carlstedt.se (nic.carlstedt.se [193.12.107.10])
	by lohi.clinet.fi (8.9.1/8.9.0) with ESMTP id XAA26925;
	Wed, 10 Feb 1999 23:00:42 +0200 (EET)
Received: from giraf.carlstedt.se (root@giraf.carlstedt.se [172.16.1.10])
	by nic.carlstedt.se (8.9.3/8.9.3) with ESMTP id VAA08111;
	Wed, 10 Feb 1999 21:59:09 +0100 (MET)
Received: from spitfire.carlstedt.se (maf@spitfire.carlstedt.se [172.16.1.70])
	by giraf.carlstedt.se (8.9.3/8.9.3) with ESMTP id VAA24608;
	Wed, 10 Feb 1999 21:59:08 +0100 (MET)
Received: from localhost (maf@localhost)
	by spitfire.carlstedt.se (8.9.1/8.9.1) with ESMTP id VAA16592;
	Wed, 10 Feb 1999 21:59:07 +0100 (MET)
X-Authentication-Warning: spitfire.carlstedt.se: maf owned process doing -bs
Date: Wed, 10 Feb 1999 21:59:07 +0100 (MET)
From: Martin Forssen <maf@firedoor.se>
X-Sender: maf@spitfire.carlstedt.se
To: Chris Newman <chris@INNOSOFT.COM>
cc: "William H. Geiger III" <whgiii@invweb.net>,
        Martin Forssen <maf@firedoor.se>, ssh@clinet.fi, ietf-ssh@clinet.fi
Subject: Re: Generic challenge-repsonse aunetication in ssh2
In-Reply-To: <Pine.SOL.3.95.990209155939.3616S-100000@elwood.innosoft.com>
Message-ID: <Pine.GSO.4.04.9902102151030.16590-100000@spitfire.carlstedt.se>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ietf-ssh@clinet.fi
Precedence: bulk
Content-Length: 1397
Lines: 28

On Tue, 9 Feb 1999, Chris Newman wrote:
> On Tue, 9 Feb 1999, William H. Geiger III wrote:
> > Nothing personal but with M$'s track record when it comes to security the
> > last thing I would want to use it one of their OS's password services.
> 
> I sympathize.  But site administrators who have to manage users don't want
> to have two password databases.  So if you actually want your software
> used, it's important it can at least share the same backend database as
> other software which authenticates users.
> 
> If you invent a challenge response mechanism with it's own custom backend
> password verifier format, then you've just made life harder for everyone.

In this case I am trying to design a protocol to handle challenge-response
authentication in ssh. I do not plan to design a new authentication
mechanism. 

let me restate: The important thing here is to design a protocol which is
generic enough so that one only has to modify the ssh server when adding
support for a new challenge-response system (only those systems where the
user is expected to type the response on the keyboard). No further
modification of the ssh clients should be necessary. I think my original
proposal augumented with a message packet (with an error bit) fits this
bill. Unfortunately I am currently in the midst of moving to a new house
so I will not have time to write a new draft this week.

	/MaF

From owner-ietf-ssh@clinet.fi  Thu Feb 11 14:16:11 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 OAA24486;
	Thu, 11 Feb 1999 14:16:09 +0200 (EET)
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 OAA12978;
	Thu, 11 Feb 1999 14:16:09 +0200 (EET)
Received: (from majordom@localhost)
	by lohi.clinet.fi (8.9.1/8.9.0) id OAA07780
	for ietf-ssh-outgoing; Thu, 11 Feb 1999 14:13:38 +0200 (EET)
X-Authentication-Warning: lohi.clinet.fi: majordom set sender to owner-ietf-ssh@clinet.fi using -f
Received: from sunthing.sjsinc.com (mail@sunthing.sjsinc.com [38.149.204.34])
	by lohi.clinet.fi (8.9.1/8.9.0) with ESMTP id FAA27390;
	Thu, 11 Feb 1999 05:24:58 +0200 (EET)
Received: (from sjs@localhost)
	by sunthing.sjsinc.com (Take-a-guess/Take-a-guess) id WAA04227;
	Wed, 10 Feb 1999 22:23:15 -0500 (EST)
Date: Wed, 10 Feb 1999 22:23:15 -0500 (EST)
From: Stefan Jon Silverman <sjs@sjsinc.com>
Message-Id: <199902110323.WAA04227@sunthing.sjsinc.com>
To: maf@firedoor.se
Subject: Re: Generic challenge-repsonse aunetication in ssh2
Cc: ssh@clinet.fi, ietf-ssh@clinet.fi, ken@proexam.org, whamlin@CONNETSYS.COM
Sender: owner-ietf-ssh@clinet.fi
Precedence: bulk
Content-Length: 3739
Lines: 72

Martin and fellow groupers:


> From: Martin Forssen <maf@firedoor.se>
> 
> In this case I am trying to design a protocol to handle challenge-response
> authentication in ssh. I do not plan to design a new authentication
> mechanism. 
> 
> let me restate: The important thing here is to design a protocol which is
> generic enough so that one only has to modify the ssh server when adding
> support for a new challenge-response system (only those systems where the
> user is expected to type the response on the keyboard). No further
> modification of the ssh clients should be necessary. I think my original
> proposal augumented with a message packet (with an error bit) fits this
> bill. Unfortunately I am currently in the midst of moving to a new house
> so I will not have time to write a new draft this week.
> 

	I agree wholeheartedly with what Martin is trying to accomplish.
Each time a new entry in the 1.2.x series came out, and now with 2.x I
have had to cobble in my custom mechanism to support the S/Key one-time
challange / response library. It would be much nicer to have a server
controlled dialogue where the type of challange and the user prompt
are sent by the server to the client and the client just knows how to
deal with it (i.e,. variable length prompt, variable length responses).
This would open up the ssh world to any kind of challange / response
dialogue that creative people want to put into the server source without
having to worry about the client. There should also be some more work
done on the protocol specs to deal with un-updated clients and rollover
to other authentication mechanisms.

	For the wish list, I would love to see the binary configuration
flags for authentication types modified to reflect some sort of
ordering of desired methods (perhaps even allowing several to be at the
same level). It would also be nice to introduce the concept of
"method=FORCE" to absolutely guarantee that if a site wanted to enforce
a particular authentication policy the server would have no choice
(this will also require some changes to both the server-side and client
specs to allow cascading methods; to combine it with the ordering,
perhaps:  "method=1,FORCE"). I have also cobbled in this code to
various releases. In general, I like to implement all of the
host-to-host methods and then in the user area use a login password
followed by a "forced" S/key exchange. Multi-tier may be a pain to
users, but I sleep better at night...

	And now back to the regularly scheduled debate on how to 
tunnel old-style primative dial-out protocols over a ssh tunnel
--> flame-bait to all of the virtual protectors of kermit and its
kin -- couldn't resist %^{0>

    Regards,

    b c++'ing u,

    %-) sjs

PS: I am my own employer, therefore: "all opinions are twice spoken for;"
    and they do, in fact, scare the hell out of said employer!!!

-------------------------------------------------------------------------------
Stefan Jon Silverman - President                     SJS Associates, N.A., Inc.
                                                                     Suite 15-B
Inter-/Intra-Net Architecture, Implementation & Security    698 West End Avenue
                                                             New York, NY 10025
E-mail:    sjs@sjsinc.com                                   Phone: 212 662 9450
Website:   http://www.sjsinc.com                            Fax:   212 662 9461
Text-Page: sjs-page@sjsinc.com                              Cell:  917 929 1668
-------------------------------------------------------------------------------
                  Weebles wobble, but they don't fall down!!!
-------------------------------------------------------------------------------

From owner-ietf-ssh@clinet.fi  Thu Feb 11 20:07:31 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 UAA03607;
	Thu, 11 Feb 1999 20:07:31 +0200 (EET)
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 UAA17330;
	Thu, 11 Feb 1999 20:07:31 +0200 (EET)
Received: (from majordom@localhost)
	by lohi.clinet.fi (8.9.1/8.9.0) id UAA00307
	for ietf-ssh-outgoing; Thu, 11 Feb 1999 20:04:38 +0200 (EET)
X-Authentication-Warning: lohi.clinet.fi: majordom set sender to owner-ietf-ssh@clinet.fi using -f
Received: from GATE.INNOSOFT.COM (SYSTEM@GATE.INNOSOFT.COM [192.160.253.77])
	by lohi.clinet.fi (8.9.1/8.9.0) with ESMTP id UAA00294;
	Thu, 11 Feb 1999 20:04:35 +0200 (EET)
Received: from elvira.innosoft.com (ELVIRA.INNOSOFT.COM [192.160.253.135])
 by GATE.INNOSOFT.COM (PMDF V5.2-29 #10099)
 with ESMTP id <01J7M3IWNYLC0009JW@GATE.INNOSOFT.COM>; Thu,
 11 Feb 1999 10:03:06 PST
Received: from elwood.innosoft.com (ELWOOD.INNOSOFT.COM [192.160.253.235])
 by elvira.innosoft.com (PMDF V5.2-31 #13579)
 with SMTP id <0F7000IFY4RAFA@elvira.innosoft.com>; Thu,
 11 Feb 1999 10:01:59 -0800 (PST)
Date: Thu, 11 Feb 1999 10:02:56 -0800 (PST)
From: Chris Newman <chris@INNOSOFT.COM>
Subject: Re: Generic challenge-repsonse aunetication in ssh2
In-reply-to: <Pine.GSO.4.04.9902102151030.16590-100000@spitfire.carlstedt.se>
Originator-info: login-id=chris; server=THOR.INNOSOFT.COM
To: Martin Forssen <maf@firedoor.se>
Cc: ssh@clinet.fi, IETF Secure Shell list <ietf-ssh@clinet.fi>
Message-id: <Pine.SOL.3.95.990211095750.1858C-100000@elwood.innosoft.com>
MIME-version: 1.0
Content-type: TEXT/PLAIN; charset=US-ASCII
Content-transfer-encoding: 7BIT
Sender: owner-ietf-ssh@clinet.fi
Precedence: bulk
Content-Length: 1193
Lines: 28

On Wed, 10 Feb 1999, Martin Forssen wrote:
> In this case I am trying to design a protocol to handle challenge-response
> authentication in ssh. I do not plan to design a new authentication
> mechanism. 
> 
> let me restate: The important thing here is to design a protocol which is
> generic enough so that one only has to modify the ssh server when adding
> support for a new challenge-response system (only those systems where the
> user is expected to type the response on the keyboard). No further
> modification of the ssh clients should be necessary. I think my original
> proposal augumented with a message packet (with an error bit) fits this
> bill. Unfortunately I am currently in the midst of moving to a new house
> so I will not have time to write a new draft this week.

So you're trying to do a mechanism to do generic prompts and responses?

If the server has several OTP/challenge-response mechanisms, how will it
know which one to use?

If the client has automated assistance (where it generates the response
given the challenge and password), how will it know which one to use?

If all you want is an OTP mechanism, why not just directly encapsulate RFC
2243?

		- Chris


From owner-ietf-ssh@clinet.fi  Thu Feb 11 21:22:48 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 VAA04028;
	Thu, 11 Feb 1999 21:22:47 +0200 (EET)
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 VAA17835;
	Thu, 11 Feb 1999 21:22:47 +0200 (EET)
Received: (from majordom@localhost)
	by lohi.clinet.fi (8.9.1/8.9.0) id VAA10165
	for ietf-ssh-outgoing; Thu, 11 Feb 1999 21:20:31 +0200 (EET)
X-Authentication-Warning: lohi.clinet.fi: majordom set sender to owner-ietf-ssh@clinet.fi using -f
Received: from ratbert.iconnet.net (ratbert.iconnet.net [209.3.247.87])
	by lohi.clinet.fi (8.9.1/8.9.0) with ESMTP id VAA10157;
	Thu, 11 Feb 1999 21:20:28 +0200 (EET)
Received: from iconnet.net (localhost [127.0.0.1])
	by ratbert.iconnet.net (8.9.2/8.9.1) with ESMTP id OAA27805;
	Thu, 11 Feb 1999 14:20:58 -0500 (EST)
Message-Id: <199902111920.OAA27805@ratbert.iconnet.net>
X-Mailer: exmh version 2.0.2 2/24/98
To: Chris Newman <chris@INNOSOFT.COM>
Cc: Martin Forssen <maf@firedoor.se>, ssh@clinet.fi,
        IETF Secure Shell list <ietf-ssh@clinet.fi>
Subject: Re: Generic challenge-repsonse aunetication in ssh2 
In-reply-to: Your message of "Thu, 11 Feb 1999 10:02:56 PST."
             <Pine.SOL.3.95.990211095750.1858C-100000@elwood.innosoft.com> 
Date: Thu, 11 Feb 1999 14:20:58 -0500
From: Frank Cusack <fcusack@iconnet.net>
Sender: owner-ietf-ssh@clinet.fi
Precedence: bulk
Content-Length: 1993
Lines: 47

In message <Pine.SOL.3.95.990211095750.1858C-100000@elwood.innosoft.com>, 
Chris Newman writes:
> On Wed, 10 Feb 1999, Martin Forssen wrote:
> > In this case I am trying to design a protocol to handle challenge-response
> > authentication in ssh. I do not plan to design a new authentication
> > mechanism. 
> > 
> > let me restate: The important thing here is to design a protocol which is
> > generic enough so that one only has to modify the ssh server when adding
> > support for a new challenge-response system (only those systems where the
> > user is expected to type the response on the keyboard). No further
> > modification of the ssh clients should be necessary. I think my original
> > proposal augumented with a message packet (with an error bit) fits this
> > bill. Unfortunately I am currently in the midst of moving to a new house
> > so I will not have time to write a new draft this week.
> 
> So you're trying to do a mechanism to do generic prompts and responses?
> 
> If the server has several OTP/challenge-response mechanisms, how will it
> know which one to use?

server-defined. eg, use PAM.

> 
> If the client has automated assistance (where it generates the response
> given the challenge and password), how will it know which one to use?

I don't think automated assistance is an issue in this case.
An automated challenge-response authentication already exists; RSA.

> 
> If all you want is an OTP mechanism, why not just directly encapsulate RFC
> 2243?

Well, it seems to me, (having skimmed it just now), that RFC 2243 requires
the client to have some knowledge of the OTP used (to specify the
encoding). It also seems closely tied to S/Key.

Part of the attempt here is to completely insulate the client from
needing any such knowledge. We don't want *an* OTP mechanism, we
want a *generic* mechanism for handling *generic* OTP's.

Also, assuming PAM would be used, the RFC requires a means to 
re-initialize the seed; PAM provides no such support.

~frank

From owner-ietf-ssh@clinet.fi  Thu Feb 11 23:56:46 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 XAA16921;
	Thu, 11 Feb 1999 23:56:45 +0200 (EET)
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 XAA18701;
	Thu, 11 Feb 1999 23:56:44 +0200 (EET)
Received: (from majordom@localhost)
	by lohi.clinet.fi (8.9.1/8.9.0) id XAA27253
	for ietf-ssh-outgoing; Thu, 11 Feb 1999 23:49:38 +0200 (EET)
X-Authentication-Warning: lohi.clinet.fi: majordom set sender to owner-ietf-ssh@clinet.fi using -f
Received: from ratbert.iconnet.net (ratbert.iconnet.net [209.3.247.87])
	by lohi.clinet.fi (8.9.1/8.9.0) with ESMTP id XAA27246;
	Thu, 11 Feb 1999 23:49:35 +0200 (EET)
Received: from iconnet.net (localhost [127.0.0.1])
	by ratbert.iconnet.net (8.9.2/8.9.1) with ESMTP id QAA28442;
	Thu, 11 Feb 1999 16:50:05 -0500 (EST)
Message-Id: <199902112150.QAA28442@ratbert.iconnet.net>
X-Mailer: exmh version 2.0.2 2/24/98
To: Stefan Jon Silverman <sjs@sjsinc.com>
Cc: maf@firedoor.se, ssh@clinet.fi, ietf-ssh@clinet.fi, ken@proexam.org,
        whamlin@CONNETSYS.COM
Subject: Re: Generic challenge-repsonse aunetication in ssh2 
In-reply-to: Your message of "Wed, 10 Feb 1999 22:23:15 EST."
             <199902110323.WAA04227@sunthing.sjsinc.com> 
Date: Thu, 11 Feb 1999 16:50:05 -0500
From: Frank Cusack <fcusack@iconnet.net>
Sender: owner-ietf-ssh@clinet.fi
Precedence: bulk
Content-Length: 962
Lines: 25

In message <199902110323.WAA04227@sunthing.sjsinc.com>, 
Stefan Jon Silverman writes:
> having to worry about the client. There should also be some more work
> done on the protocol specs to deal with un-updated clients and rollover
> to other authentication mechanisms.

I don't think anything needs to be said about un-updated clients:
they simply won't work. Rollover to other mechanisms is already
specified.

> 
> 	For the wish list, I would love to see the binary configuration
> flags for authentication types modified to reflect some sort of
> ordering of desired methods (perhaps even allowing several to be at the
> same level). It would also be nice to introduce the concept of

This could be accomplished easily through PAM; except for RSA auth,
and that may even be possible through PAM_BINARY (but I doubt it).

I really will work on posting my PWPLUS spec this weekend. :)
I'll also try to make ssh1 patches available to those in the US.

~frank


From owner-ietf-ssh@clinet.fi  Fri Feb 12 22:22:55 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 WAA20619;
	Fri, 12 Feb 1999 22:22:54 +0200 (EET)
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 WAA27058;
	Fri, 12 Feb 1999 22:22:54 +0200 (EET)
Received: (from majordom@localhost)
	by lohi.clinet.fi (8.9.1/8.9.0) id WAA08516
	for ietf-ssh-outgoing; Fri, 12 Feb 1999 22:20:55 +0200 (EET)
X-Authentication-Warning: lohi.clinet.fi: majordom set sender to owner-ietf-ssh@clinet.fi using -f
Received: from GATE.INNOSOFT.COM (SYSTEM@GATE.INNOSOFT.COM [192.160.253.77])
	by lohi.clinet.fi (8.9.1/8.9.0) with ESMTP id WAA08495;
	Fri, 12 Feb 1999 22:20:53 +0200 (EET)
Received: from elvira.innosoft.com (ELVIRA.INNOSOFT.COM [192.160.253.135])
 by GATE.INNOSOFT.COM (PMDF V5.2-29 #10099)
 with ESMTPS id <01J7NMKZM1DE000ABP@GATE.INNOSOFT.COM>; Fri,
 12 Feb 1999 12:19:16 PST
Received: from elwood.innosoft.com (ELWOOD.INNOSOFT.COM [192.160.253.235])
 by elvira.innosoft.com (PMDF V5.2-31 #13579)
 with SMTP id <0F7200M155Q4OO@elvira.innosoft.com>; Fri,
 12 Feb 1999 12:18:04 -0800 (PST)
Date: Fri, 12 Feb 1999 12:19:02 -0800 (PST)
From: Chris Newman <chris@INNOSOFT.COM>
Subject: Re: Generic challenge-repsonse aunetication in ssh2
In-reply-to: <Pine.GSO.4.04.9902102151030.16590-100000@spitfire.carlstedt.se>
Originator-info: login-id=chris; server=THOR.INNOSOFT.COM
To: Martin Forssen <maf@firedoor.se>
Cc: ssh@clinet.fi, IETF Secure Shell list <ietf-ssh@clinet.fi>
Message-id: <Pine.SOL.3.95.990212121156.4893J-100000@elwood.innosoft.com>
MIME-version: 1.0
Content-type: TEXT/PLAIN; charset=US-ASCII
Content-transfer-encoding: 7BIT
Sender: owner-ietf-ssh@clinet.fi
Precedence: bulk
Content-Length: 1266
Lines: 25

On Wed, 10 Feb 1999, Martin Forssen wrote:
> In this case I am trying to design a protocol to handle challenge-response
> authentication in ssh. I do not plan to design a new authentication
> mechanism. 
> 
> let me restate: The important thing here is to design a protocol which is
> generic enough so that one only has to modify the ssh server when adding
> support for a new challenge-response system (only those systems where the
> user is expected to type the response on the keyboard). No further
> modification of the ssh clients should be necessary. I think my original
> proposal augumented with a message packet (with an error bit) fits this
> bill. Unfortunately I am currently in the midst of moving to a new house
> so I will not have time to write a new draft this week.

I have no problem with this if you call it a generic user-interaction
mechanism.  The server generates prompts to be presented directly to the
user, and the user's typed response is sent back directly to the server.
Client processing is strictly forbidden for interoperability reasons.

Note that this is a very different beast from a challenge response
mechanism.  It can and likely will be used for plaintext passwords and
relies entirely on the SSH security layer.

		- Chris

From owner-ietf-ssh@clinet.fi  Thu Feb 18 04:18:09 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 EAA23077;
	Thu, 18 Feb 1999 04:18:09 +0200 (EET)
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 EAA15877;
	Thu, 18 Feb 1999 04:18:09 +0200 (EET)
Received: (from majordom@localhost)
	by lohi.clinet.fi (8.9.1/8.9.0) id EAA25649
	for ietf-ssh-outgoing; Thu, 18 Feb 1999 04:16:49 +0200 (EET)
X-Authentication-Warning: lohi.clinet.fi: majordom set sender to owner-ietf-ssh@clinet.fi using -f
Received: from mail.vandyke.com (vandyke.com [204.134.9.1])
	by lohi.clinet.fi (8.9.1/8.9.0) with ESMTP id EAA25645
	for <ietf-ssh@clinet.fi>; Thu, 18 Feb 1999 04:16:47 +0200 (EET)
Received: from sage ([192.168.0.5]) by mail.vandyke.com
          (Netscape Messaging Server 3.01)  with SMTP id 423
          for <ietf-ssh@clinet.fi>; Wed, 17 Feb 1999 19:19:04 -0700
Message-ID: <00db01be5ae4$6eb54790$0500a8c0@sage.vandyke.com>
From: "Joseph Galbraith" <galb@rt66.com>
To: <ietf-ssh@clinet.fi>
Subject: Fw: draft-ietf-secsh-connect-04.txt
Date: Wed, 17 Feb 1999 19:14:35 -0700
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: 240
Lines: 12

It looks to me like the secsh draft has expired (6 months
from 6 August 1998.)

Does any one have a guess for when a new version is
going to be out?  Or is there a new one available and
I just haven't found it?

Thanks,

Joseph Galbraith


From owner-ietf-ssh@clinet.fi  Thu Feb 18 04:33:36 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 EAA22987;
	Thu, 18 Feb 1999 04:33:35 +0200 (EET)
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 EAA15964;
	Thu, 18 Feb 1999 04:33:35 +0200 (EET)
Received: (from majordom@localhost)
	by lohi.clinet.fi (8.9.1/8.9.0) id EAA26699
	for ietf-ssh-outgoing; Thu, 18 Feb 1999 04:33:56 +0200 (EET)
X-Authentication-Warning: lohi.clinet.fi: majordom set sender to owner-ietf-ssh@clinet.fi using -f
Received: from jekyll.piermont.com (jekyll.piermont.com [206.1.51.15])
	by lohi.clinet.fi (8.9.1/8.9.0) with ESMTP id EAA26695
	for <ietf-ssh@clinet.fi>; Thu, 18 Feb 1999 04:33:54 +0200 (EET)
Received: by jekyll.piermont.com (Postfix, from userid 1000)
	id 66566171; Wed, 17 Feb 1999 21:31:37 -0500 (EST)
To: "Joseph Galbraith" <galb@rt66.com>
Cc: <ietf-ssh@clinet.fi>
Subject: Re: Fw: draft-ietf-secsh-connect-04.txt
References: <00db01be5ae4$6eb54790$0500a8c0@sage.vandyke.com>
Reply-To: perry@piermont.com
X-Reposting-Policy: redistribute only with permission
Mime-Version: 1.0 (generated by tm-edit 7.108)
Content-Type: text/plain; charset=US-ASCII
From: "Perry E. Metzger" <perry@piermont.com>
Date: 17 Feb 1999 21:31:36 -0500
In-Reply-To: "Joseph Galbraith"'s message of "Wed, 17 Feb 1999 19:14:35 -0700"
Message-ID: <87emnomohj.fsf@jekyll.piermont.com>
X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald"
Sender: owner-ietf-ssh@clinet.fi
Precedence: bulk
Content-Length: 361
Lines: 15


I'd say in a few days -- just before the draft deadline.

"Joseph Galbraith" <galb@rt66.com> writes:

> It looks to me like the secsh draft has expired (6 months
> from 6 August 1998.)
> 
> Does any one have a guess for when a new version is
> going to be out?  Or is there a new one available and
> I just haven't found it?
> 
> Thanks,
> 
> Joseph Galbraith
From owner-ietf-ssh@clinet.fi  Mon Feb 22 22:37:43 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 WAA10150;
	Mon, 22 Feb 1999 22:37:42 +0200 (EET)
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 WAA24153;
	Mon, 22 Feb 1999 22:37:41 +0200 (EET)
Received: (from majordom@localhost)
	by lohi.clinet.fi (8.9.1/8.9.0) id WAA20628
	for ietf-ssh-outgoing; Mon, 22 Feb 1999 22:35:33 +0200 (EET)
X-Authentication-Warning: lohi.clinet.fi: majordom set sender to owner-ietf-ssh@clinet.fi using -f
Received: from ratbert.iconnet.net (ratbert.iconnet.net [209.3.247.87])
	by lohi.clinet.fi (8.9.1/8.9.0) with ESMTP id WAA20620;
	Mon, 22 Feb 1999 22:35:25 +0200 (EET)
Received: from iconnet.net (localhost [127.0.0.1])
	by ratbert.iconnet.net (8.9.2/8.9.1) with ESMTP id PAA13064;
	Mon, 22 Feb 1999 15:34:44 -0500 (EST)
Message-Id: <199902222034.PAA13064@ratbert.iconnet.net>
X-Mailer: exmh version 2.0.2 2/24/98
To: ssh@clinet.fi, ietf-ssh@clinet.fi
Cc: psst@net.lut.ac.uk
Subject: Re: Generic challenge-repsonse aunetication in ssh2 
Date: Mon, 22 Feb 1999 15:34:44 -0500
From: Frank Cusack <fcusack@iconnet.net>
Sender: owner-ietf-ssh@clinet.fi
Precedence: bulk
Content-Length: 6832
Lines: 177

As I promised a long time ago, here is my counter proposal for
generic authentication in ssh. Comments are welcome...

Also, how do I go about submitting this as a draft under the
auspices of the ssh working group? Is it just a matter of
titling it "draft-ietf-secsh-xxx"? I'd prefer to put it
under the working group instead of just an independent draft.

[What is presented here is just the protocol workings, not the
complete text of the proposed draft, which contains an abstract
and other sections. I do still need to add a section that notes
this method is only appropriate for interactive authentications.]

I will post a URL to my ssh1 implementation of the below in a
few days.

~frank


Discussion

   Currently defined authentication methods for SSH are tightly coupled
   with the underlying authentication mechanism.  This makes it
   difficult to add new mechanisms for authentication as all clients
   must be updated to support the new mechanism.  With the generic
   method defined here, clients will not require code changes to support
   new authentication mechanisms, and if a separate authentication layer
   is used, such as [PAM], then the server may not need any code changes
   either.

   This presents a significant advantage to other methods, such as the
   "password" method, as new (presumably stronger) methods may be added
   "at will" and system security can be transparently enhanced.

Protocol Exchanges

   The authentication starts with the client sending the following
   packet (following the packet description conventions used in [SSH-
   USERAUTH]):

      byte    SSH_MSG_USERAUTH_REQUEST
      string  username
      string  service
      string  "password-plus"

   Note that when this message is sent to the server, the client has not
   yet prompted the user for a password, and so that information is NOT
   included with this initial message (unlike the "password" method).

   The server MUST reply with either a SSH_MSG_USERAUTH_SUCCESS,
   SSH_MSG_USERAUTH_FAILURE, or SSH_MSG_USERAUTH_INFO_REQUEST message.

   The server SHOULD NOT reply with the SSH_MSG_USERAUTH_FAILURE message
   if the failure is based on the username or service, instead it SHOULD
   send a SSH_MSG_USERAUTH_INFO_REQUEST message requesting a password,
   and then send the failure message.

   The format of the SSH_MSG_USERAUTH_INFO_REQUEST message is as
   follows:

      byte    SSH_MSG_USERAUTH_INFO_REQUEST
      boolean name present
      string  name (if name present is TRUE) (ISO-10646 UTF-8)
      boolean banner present
      string  banner (if banner present is TRUE) (ISO-10646 UTF-8)
      int     num prompts
      string  prompt[0] (ISO-10646 UTF-8)
      boolean echo[0]
      ...
      string  prompt[n] (ISO-10646 UTF-8)
      boolean echo[n]
      string  language tag (as defined in RFC 1766)

   The server SHOULD limit the length of the name and prompt fields to
   30 characters.

   Upon receiving the request message, the client should prompt the user
   as indicated.

   A CLI client SHOULD simply print the name and banner, followed by
   each prompt in turn, to obtain the requested authentication
   information.  The client is responsible for adding newlines to the
   name and banner.  A CLI client SHOULD NOT add any additional
   characters to the prompt such as ": "; the server is responsible for
   supplying all text to be shown to the user.

   A GUI client SHOULD present a dialog window, using the name (if
   supplied) as the title of the window, the banner (if supplied) as a
   text message inside the dialog, and the appropriate number of entry
   fields with the prompts as labels.  A GUI client MUST properly handle
   banners with embedded newlines.  A GUI client MUST also be able to
   display at least 30 characters for the name and prompts.  If the
   server presents names/prompts longer than 30 characters, the client
   MAY truncate these fields to the length it can display.

   For each prompt, the echo field indicates whether or not the user
   input should be echoed as characters are typed.  Clients MUST
   correctly echo/mask user input for each prompt independently of other
   prompts in the request message.  Clients must also accept empty
   responses from the user and pass them on as empty strings.

   After obtaining the requested information from a user, the client
   MUST respond with a SSH_MSG_USERAUTH_INFO_RESPONSE message:

      byte    SSH_MSG_USERAUTH_INFO_RESPONSE
      int     num responses
      string  response[0] (ISO-10646 UTF-8)
      ...
      string  response[n] (ISO-10646 UTF-8)

   Note that the responses are encoded in ISO-10646 UTF-8.  It is up to
   the server how it interprets the responses and validates them.
   However, if the client reads the responses in some other encoding
   (e.g., ISO 8859-1), it MUST convert the responses to ISO-10646 UTF-8
   before transmitting, and the server MUST convert the responses to the
   encoding used on that system that is needed to verify them.

   Upon receiving the response, the server MUST send a
   SSH_MSG_USERAUTH_FAILURE message if the number of responses is not
   the same as the number of prompts, or if validation of the responses
   fails.

   If validation of the responses is successful, and no further
   information is needed from the user, the server MUST respond with a
   SSH_MSG_USERAUTH_SUCCESS message.

   The server may also initiate another request/response cycle (as many
   times as needed) if more information is required from the user to
   authenticate him (e.g., if the user's password has expired).

Authentication Example

   Here is an example exchange between a client and server:

   C:      byte    SSH_MSG_USERAUTH_REQUEST
   C:      string  "foo"
   C:      string  "ssh-connection"
   C:      string  "password-plus"

   S:      byte    SSH_MSG_USERAUTH_INFO_REQUEST
   S:      boolean TRUE
   S:      string  "Password Authentication"
   S:      boolean TRUE
   S:      string  "Enter password for foo"
   S:      int     1
   S:      string  "Password: "
   S:      boolean FALSE
   S:      string  "en-US"

   [Client prompts user for password]

   C:      byte    SSH_MSG_USERAUTH_INFO_RESPONSE
   C:      int     1
   C:      string  "bar"

   S:      byte    SSH_MSG_USERAUTH_INFO_REQUEST
   S:      boolean TRUE
   S:      string  "Password Expired"
   S:      boolean TRUE
   S:      string  "Your password has expired."
   S:      int     2
   S:      string  "Enter new password: "
   S:      boolean FALSE
   S:      string  "Enter it again: "
   S:      boolean FALSE
   S:      string  "en-US"

   [Client prompts user for new password]

   C:      byte    SSH_MSG_USERAUTH_INFO_RESPONSE
   C:      int     2
   C:      string  "baz"
   C:      string  "baz"

   S:      byte    SSH_MSG_USERAUTH_SUCCESS


From owner-ietf-ssh@clinet.fi  Tue Feb 23 12:44:40 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 MAA01741;
	Tue, 23 Feb 1999 12:44:40 +0200 (EET)
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 MAA29117;
	Tue, 23 Feb 1999 12:44:40 +0200 (EET)
Received: (from majordom@localhost)
	by lohi.clinet.fi (8.9.1/8.9.0) id MAA09577
	for ietf-ssh-outgoing; Tue, 23 Feb 1999 12:45:03 +0200 (EET)
X-Authentication-Warning: lohi.clinet.fi: majordom set sender to owner-ietf-ssh@clinet.fi using -f
Received: from rover.cygnus.com (rover.cygnus.com [192.80.44.65])
	by lohi.clinet.fi (8.9.1/8.9.0) with ESMTP id XAA22783
	for <ietf-ssh@clinet.fi>; Mon, 22 Feb 1999 23:02:03 +0200 (EET)
Received: (from marc@localhost) by rover.cygnus.com (8.8.8/8.6.12) id PAA13248; Mon, 22 Feb 1999 15:58:22 -0500 (EST)
From: Marc Horowitz <marc@MIT.EDU>
To: ietf-ssh@clinet.fi
Subject: interpretation of channel subsystem name
Date: 22 Feb 1999 15:58:21 -0500
Message-ID: <t53btim40lu.fsf@rover.cygnus.com>
X-Mailer: Gnus v5.3/Emacs 19.34
Sender: owner-ietf-ssh@clinet.fi
Precedence: bulk
Content-Length: 990
Lines: 17

How exactly is the subsystem name (draft-ietf-secsh-connect-04.txt,
section 4.7) to be interpreted?  The simple implementation is that
there is a one-to-one correspondence between subsystem names and
backend mechanisms (this is what ssh2 from SSH Communications Security
does now).  Would it be reasonable for an implementation to understand
some structure in the subsystem name, in particular to understand
arguments?  For instance, one might desire a finger subsystem which
just sends back information about the users who are logged in.
However, it is useful to limit this information by giving arguments to
the subsystem.  A reasonably intelligent unix ssh server
implementation could interpret any subsystem name of the form
/^finger(\s+(.*))?$/, passing $2 to a backend finger program.  This
would appear to be compliant with the letter of the draft, but I'm not
sure about the spirit.  I'd like to hear what the group thinks, and
submit some clarifying text if people agree.

		Marc

From owner-ietf-ssh@clinet.fi  Tue Feb 23 12:47:39 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 MAA01580;
	Tue, 23 Feb 1999 12:47:38 +0200 (EET)
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 MAA29148;
	Tue, 23 Feb 1999 12:47:38 +0200 (EET)
Received: (from majordom@localhost)
	by lohi.clinet.fi (8.9.1/8.9.0) id MAA10121
	for ietf-ssh-outgoing; Tue, 23 Feb 1999 12:48:52 +0200 (EET)
X-Authentication-Warning: lohi.clinet.fi: majordom set sender to owner-ietf-ssh@clinet.fi using -f
Received: from ratbert.iconnet.net (ratbert.iconnet.net [209.3.247.87])
	by lohi.clinet.fi (8.9.1/8.9.0) with ESMTP id DAA15611;
	Tue, 23 Feb 1999 03:48:00 +0200 (EET)
Received: from iconnet.net (localhost [127.0.0.1])
	by ratbert.iconnet.net (8.9.2/8.9.1) with ESMTP id UAA13966;
	Mon, 22 Feb 1999 20:47:17 -0500 (EST)
Message-Id: <199902230147.UAA13966@ratbert.iconnet.net>
X-Mailer: exmh version 2.0.2 2/24/98
To: ssh@clinet.fi, ietf-ssh@clinet.fi
CC: psst@net.lut.ac.uk
Subject: Re: Generic challenge-repsonse aunetication in ssh2 
Date: Mon, 22 Feb 1999 20:47:17 -0500
From: Frank Cusack <fcusack@iconnet.net>
Sender: owner-ietf-ssh@clinet.fi
Precedence: bulk
Content-Length: 14908
Lines: 491

Here is an updated version of my proposal, fully formatted as an I-D.

Also, I've updated it to be even more generic, with support for
smartcards and biometrics (although how that support is to be done
is not specified in this version... looking for help there...)

I didn't run it through the "formfeed script" to avoid embedding
control characters in an email/posting.







Network Working Group                                          F. Cusack
INTERNET-DRAFT                                  Qwest Internet Solutions
draft-ietf-secsh-genericauth-00.txt                          22 Feb 1999
Expires in six months

            Generic Message Exchange Authentication For SSH

Status of this Memo

   This document is an Internet-Draft.  Internet-Drafts are working
   documents of the Internet Engineering Task Force (IETF), its areas,
   and its working groups.  Note that other groups may also distribute
   working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet- Drafts as reference
   material or to cite them other than as "work in progress."

   To view the entire list of current Internet-Drafts, please check the
   "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
   Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern
   Europe), ftp.nic.it (Southern Europe), munnari.oz.au (Pacific Rim),
   ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast).

Abstract

   SSH is a protocol for secure remote login and other secure network
   services over an insecure network.  This document describes a general
   purpose message exchange authentication method for the SSH protocol.
   The major goal of this method is to allow the SSH client to have
   little or no knowledge of the actual authentication mechanism used by
   the SSH server.


















Cusack                                                  FORMFEED[Page 1]





draft-ietf-secsh-genericauth-00.txt                          22 Feb 1999


1. Introduction

   The SSH authentication protocol is a general-purpose user
   authentication protocol. It is intended to be run over the SSH
   transport layer protocol [SSH-TRANS]. The protocol assumes that the
   underlying protocols provide integrity and confidentiality
   protection.

   This document describes a generic message exchange authentication
   method for the SSH authentication protocol.  The rationale for this
   generic method is to allow the server to arbitrarily select or change
   the underlying authentication method without having to update client
   code.

   The method name for this authentication method is "password-plus".

   This document should be read only after reading the SSH architecture
   document [SSH-ARCH] and the SSH authentication document [SSH-
   USERAUTH].  This document freely uses terminology and notation from
   both documents without reference or further explanation.

   This document also describes some of the client interaction with the
   user in obtaining the authentication information.  While this is
   somewhat out of the scope of a protocol specification, it is still
   described here since some aspects of the protocol are specifically
   designed based on user interface issues.

2. Discussion

   Currently defined authentication methods for SSH are tightly coupled
   with the underlying authentication mechanism.  This makes it
   difficult to add new mechanisms for authentication as all clients
   must be updated to support the new mechanism.  With the generic
   method defined here, clients will not require code changes to support
   new authentication mechanisms, and if a separate authentication layer
   is used, such as [PAM], then the server may not need any code changes
   either.

   This presents a significant advantage to other methods, such as the
   "password" method, as new (presumably stronger) methods may be added
   "at will" and system security can be transparently enhanced.

3. Protocol Exchanges

   The client initiates the authentication with a
   SSH_MSG_USERAUTH_REQUEST message.  The server then requests
   authentication information from the client with a
   SSH_MSG_USERAUTH_INFO_REQUEST message.  The client obtains the



Cusack                                                  FORMFEED[Page 2]





draft-ietf-secsh-genericauth-00.txt                          22 Feb 1999


   information from the user and then responds with a
   SSM_MSG_USERAUTH_INFO_RESPONSE message.

3.1 Initial Exchange

   The authentication starts with the client sending the following
   packet:

      byte    SSH_MSG_USERAUTH_REQUEST
      string  username
      string  service
      string  "password-plus"
      int     num-supported-input-types
      int     input-type[0]
      ...
      int     input-type[n]

   Note that when this message is sent to the server, the client has not
   yet prompted the user for a password, and so that information is NOT
   included with this initial message (unlike the "password" method).

   The input-types are from the list of types in section 5.

   The server MUST reply with either a SSH_MSG_USERAUTH_SUCCESS,
   SSH_MSG_USERAUTH_FAILURE, or SSH_MSG_USERAUTH_INFO_REQUEST message.

   The server SHOULD NOT reply with the SSH_MSG_USERAUTH_FAILURE message
   if the failure is based on the username or service; instead it SHOULD
   send a SSH_MSG_USERAUTH_INFO_REQUEST message requesting a password,
   and then send the failure message (after a suitable delay, as
   described below).  This is to prevent leaking of information that
   could potentially be used in an attack.

3.2 Information Requests / User Interface

   Requests are generated from the server using the
   SSH_MSG_USERAUTH_INFO_REQUEST message.

   Input types are specified in the request messages, and are limited to
   a single input type per request message.  The server MUST NOT send a
   request message with an input type that the client did not indicate
   support for in the initial exchange.

   The server may send as many requests as are necessary to authenticate
   the client; the client MUST be prepared to handle multiple exchanges,
   each with potentially different input types.

   The SSH_MSG_USERAUTH_INFO_REQUEST message is divided into a "common



Cusack                                                  FORMFEED[Page 3]





draft-ietf-secsh-genericauth-00.txt                          22 Feb 1999


   part" and an "input-type-specific part".  The "common part" is
   defined as follows:

      byte    SSH_MSG_USERAUTH_INFO_REQUEST
      int     input-type
      boolean name-present
      string  name (if name-present is TRUE) (ISO-10646 UTF-8)
      boolean banner-present
      string  banner (if banner-present is TRUE) (ISO-10646 UTF-8)
      rest of the packet is input-type-specific

   The server SHOULD limit the length of the name field to 30
   characters.  No restrictions are placed on the banner field.

3.2.1 SSH_USERAUTH_INPUT_KEYBOARD

   This input type is used when the user should type the response[s].
   This includes (e.g.) passwords and challenge-response authentications
   using handheld tokens.  All clients MUST support this input type.

   When this input type is specified, the remainder of the request
   message is defined as follows:

      int     num-prompts
      string  prompt[0] (ISO-10646 UTF-8)
      boolean echo[0]
      ...
      string  prompt[n] (ISO-10646 UTF-8)
      boolean echo[n]
      string  language tag (as defined in [RFC-1766])

   The server SHOULD limit the length of the prompt fields to 30
   characters.

   Upon receiving a request message of this type, the client SHOULD
   prompt the user as follows:

   For each prompt, the echo field indicates whether or not the user
   input should be echoed as characters are typed.  Clients MUST
   correctly echo/mask user input for each prompt independently of other
   prompts in the request message.  Clients MUST NOT add any additional
   characters to the prompt such as ": "; the server is reponsible for
   supplying all text to be displayed to the user.  Clients MUST also
   accept empty responses from the user and pass them on as empty
   strings.

   A CLI client SHOULD print the name and banner, adding newlines. Then
   for each prompt in turn, the client MUST display the prompt and read



Cusack                                                  FORMFEED[Page 4]





draft-ietf-secsh-genericauth-00.txt                          22 Feb 1999


   the user input.

   A GUI client SHOULD present a dialog window, using the name (if
   supplied) as the title of the window, the banner (if supplied) as a
   text message inside the dialog, and the appropriate number of entry
   fields with the prompts as labels.  A GUI client SHOULD NOT present
   each prompt in a separate window.  A GUI client MUST properly handle
   banners with embedded newlines.  A GUI client MUST also be able to
   display at least 30 characters for the name and prompts.  If the
   server presents names/prompts longer than 30 characters, the client
   MAY truncate these fields to the length it can display.

3.2.2 SSH_USERAUTH_INPUT_PCSC

   This input type is used when the user must authenticate via a
   smartcard.  The client will pass messages from/to the smartcard via
   the PC/SC interface.

   Protocol details will be provided in a later version of this
   specification.

3.2.3 SSH_USERAUTH_INPUT_BIO

   This input type is used when the user must authenticate via a
   biometric device.

   Protocol details will be provided in a later version of this
   specification.

3.3 Information Responses

   After obtaining the requested information from a user, the client
   MUST respond with a SSH_MSG_USERAUTH_INFO_RESPONSE message.

   The format of the response is input-type-specific.

3.3.1 SSH_USERAUTH_INPUT_KEYBOARD

   When the input type is SSH_USERAUTH_INPUT_KEYBOARD, the format of the
   SSH_MSG_USERAUTH_INFO_RESPONSE message is as follows:

      byte    SSH_MSG_USERAUTH_INFO_RESPONSE
      int     num responses
      string  response[0] (ISO-10646 UTF-8)
      ...
      string  response[n] (ISO-10646 UTF-8)

   Note that the responses are encoded in ISO-10646 UTF-8.  It is up to



Cusack                                                  FORMFEED[Page 5]





draft-ietf-secsh-genericauth-00.txt                          22 Feb 1999


   the server how it interprets the responses and validates them.
   However, if the client reads the responses in some other encoding
   (e.g., ISO 8859-1), it MUST convert the responses to ISO-10646 UTF-8
   before transmitting, and the server MUST convert the responses to the
   encoding used on that system that is needed to verify them.

   Upon receiving the response, the server MUST send a
   SSH_MSG_USERAUTH_FAILURE message if the number of responses is not
   the same as the number of prompts, or if validation of the responses
   fails.

   If validation of the responses is successful, and no further
   information is needed from the user, the server MUST respond with a
   SSH_MSG_USERAUTH_SUCCESS message.

3.3.2 SSH_USERAUTH_INPUT_PCSC

   Protocol details will be provided in a later version of this
   specification.

3.3.3 SSH_USERAUTH_INPUT_BIO

   Protocol details will be provided in a later version of this
   specification.

4. Authentication Example

   Here is an example exchange between a client and server:

   C:      byte    SSH_MSG_USERAUTH_REQUEST
   C:      string  "foo"
   C:      string  "ssh-connection"
   C:      string  "password-plus"
   C:      int     1
   C:      int     SSH_USERAUTH_INPUT_KEYBOARD

   S:      byte    SSH_MSG_USERAUTH_INFO_REQUEST
   S:      int     SSH_USERAUTH_INPUT_KEYBOARD
   S:      boolean TRUE
   S:      string  "Password Authentication"
   S:      boolean TRUE
   S:      string  "Enter password for foo"
   S:      int     1
   S:      string  "Password: "
   S:      boolean FALSE
   S:      string  "en-US"

   [Client prompts user for password]



Cusack                                                  FORMFEED[Page 6]





draft-ietf-secsh-genericauth-00.txt                          22 Feb 1999


   C:      byte    SSH_MSG_USERAUTH_INFO_RESPONSE
   C:      int     1
   C:      string  "bar"

   S:      byte    SSH_MSG_USERAUTH_INFO_REQUEST
   S:      int     SSH_USERAUTH_INPUT_KEYBOARD
   S:      boolean TRUE
   S:      string  "Password Expired"
   S:      boolean TRUE
   S:      string  "Your password has expired."
   S:      int     2
   S:      string  "Enter new password: "
   S:      boolean FALSE
   S:      string  "Enter it again: "
   S:      boolean FALSE
   S:      string  "en-US"

   [Client prompts user for new password]

   C:      byte    SSH_MSG_USERAUTH_INFO_RESPONSE
   C:      int     2
   C:      string  "baz"
   C:      string  "baz"

   S:      byte    SSH_MSG_USERAUTH_SUCCESS

5. Protocol constants

   The following method-specific constants are used with this
   authentication method:

   Message exchanges:

      SSH_MSG_USERAUTH_INFO_REQUEST           60
      SSH_MSG_USERAUTH_INFO_RESPONSE          61

   Input types:

      SSH_USERAUTH_INPUT_KEYBOARD             1
      SSH_USERAUTH_INPUT_PCSC                 2
      SSH_USERAUTH_INPUT_BIO                  3

      All negative values for input types are reserved for locally
      defined methods.  No method is specified for determining what
      "locality" a negative input type is valid in.


6. References



Cusack                                                  FORMFEED[Page 7]





draft-ietf-secsh-genericauth-00.txt                          22 Feb 1999


   [PAM] Samar, V., Schemers, R., "Unified Login With Pluggable
   Authentication Modules (PAM)", OSF RFC 86.0, October 1995

   [RFC-1766] Alvestrand, H., "Tags for the Identification of
   Languages", March 1995.

   [RFC-2044] Yergeau, F., "UTF-8, a Transformation Format of Unicode
   and ISO 10646", October 1996.

   [SSH-ARCH] Ylonen, T., Kivinen, T, and Saarinen, M., "SSH Protocol
   Architecture", Internet Draft, draft-secsh-architecture-00.txt

   [SSH-TRANS] Ylonen, T., Kivinen, T, and Saarinen, M., "SSH Transport
   Layer Protocol", Internet Draft, draft-secsh-transport-02.txt

   [SSH-USERAUTH] Ylonen, T., Kivinen, T, and Saarinen, M., "SSH
   Authentication Protocol", Internet Draft, draft-ietf-secsh-userauth-
   02.txt

   [SSH-CONNECT] Ylonen, T., Kivinen, T, and Saarinen, M., "SSH
   Connection Protocol", Internet Draft, draft-secsh-connect-02.txt

7. Author's Address

   Frank Cusack
   Qwest Internet Solutions
   1200 Harbor Blvd, 8th Fl.
   Weehawken, NJ 07087
   Email: fcusack@iconnet.net






















Cusack                                                  FORMFEED[Page 8]




From owner-ietf-ssh@clinet.fi  Wed Feb 24 12:38:32 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 MAA13004;
	Wed, 24 Feb 1999 12:38:32 +0200 (EET)
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 MAA13742;
	Wed, 24 Feb 1999 12:38:32 +0200 (EET)
Received: (from majordom@localhost)
	by lohi.clinet.fi (8.9.1/8.9.0) id MAA16050
	for ietf-ssh-outgoing; Wed, 24 Feb 1999 12:36:32 +0200 (EET)
X-Authentication-Warning: lohi.clinet.fi: majordom set sender to owner-ietf-ssh@clinet.fi using -f
Received: from hutcs.cs.hut.fi (kivinen@hutcs.cs.hut.fi [130.233.192.7])
	by lohi.clinet.fi (8.9.1/8.9.0) with ESMTP id NAA23050;
	Tue, 23 Feb 1999 13:57:10 +0200 (EET)
Received: (from kivinen@localhost) by hutcs.cs.hut.fi (8.8.8/8.8.8) id NAA27864; Tue, 23 Feb 1999 13:54:08 +0200 (EET)
Date: Tue, 23 Feb 1999 13:54:08 +0200 (EET)
Message-Id: <199902231154.NAA27864@hutcs.cs.hut.fi>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
From: Tero Kivinen <kivinen@iki.fi>
To: Frank Cusack <fcusack@iconnet.net>
Cc: ssh@clinet.fi, ietf-ssh@clinet.fi, psst@net.lut.ac.uk
Subject: Re: Generic challenge-repsonse aunetication in ssh2 
In-Reply-To: <199902230147.UAA13966@ratbert.iconnet.net>
References: <199902230147.UAA13966@ratbert.iconnet.net>
X-Mailer: VM 6.33 under Emacs 19.34.1
Organization: Helsinki University of Technology
X-Edit-Time: 21 min
X-Total-Time: 25 min
Sender: owner-ietf-ssh@clinet.fi
Precedence: bulk
Content-Length: 5766
Lines: 174

Few comments about the draft. 

Frank Cusack writes:
> 1. Introduction
...
>    The method name for this authentication method is "password-plus".

Is this really a password-plus? I really think the name should be
something else, like "keyboard-query-response". 

> 3.1 Initial Exchange
> 
>    The authentication starts with the client sending the following
>    packet:
> 
>       byte    SSH_MSG_USERAUTH_REQUEST
>       string  username
>       string  service
>       string  "password-plus"
>       int     num-supported-input-types
>       int     input-type[0]
>       ...
>       int     input-type[n]

I don't think we need another selector here for input-type. I think we
can just have more authnetication methods, like
"keyboard-query-response", "biometric-device" etc. There is no use to
complicate things by adding just one more way to select authentication
method, especially when they have very little common. So I would just
leave it like:

       byte    SSH_MSG_USERAUTH_REQUEST
       string  username
       string  service
       string  "keyboard-query-response"


> 3.2 Information Requests / User Interface
...
>    The SSH_MSG_USERAUTH_INFO_REQUEST message is divided into a "common
>    part" and an "input-type-specific part".  The "common part" is
>    defined as follows:

I think we can leave that input-type-specific part away, and say that
this is common part for authentication method named
"keyboard-query-response". 

>       byte    SSH_MSG_USERAUTH_INFO_REQUEST
>       int     input-type

This should be

	string	"keyboard-query-response"

i.e the authentication method to which this is info request. 

>       boolean name-present
>       string  name (if name-present is TRUE) (ISO-10646 UTF-8)
>       boolean banner-present
>       string  banner (if banner-present is TRUE) (ISO-10646 UTF-8)

Do we really need those boolean fields there? Why cannot we just say
that

        string  name (empty if not present) (ISO-10646 UTF-8)
        string  banner (empty if not present) (ISO-10646 UTF-8)

So that they will be empty strings (strings with length of 0), if we
do not want them. 

Then the rest of the packet is just like SSH_USERAUTH_INPUT_KEYBOARD:

>       int     num-prompts
>       string  prompt[0] (ISO-10646 UTF-8)
>       boolean echo[0]
>       ...
>       string  prompt[n] (ISO-10646 UTF-8)
>       boolean echo[n]
>       string  language tag (as defined in [RFC-1766])
...
> 3.2.2 SSH_USERAUTH_INPUT_PCSC
>    Protocol details will be provided in a later version of this
>    specification.
> 3.2.3 SSH_USERAUTH_INPUT_BIO
>    Protocol details will be provided in a later version of this
>    specification.

I dont really see any use for having this kind of sections here if
they really don't define anything. When someone describes how to use
them then they can write new draft with different authentication
method name, and define how to use them. I really dont see any point
to include them here.

For example most of the case the smartcard are using the normal public
key authentication (RSA). If there are some other kinds smartcards
that use some other authentication methods, then it is better to
separate them based on the authentication method (public key, one time
password) not based on the technology (smartcard). 

> 3.3.1 SSH_USERAUTH_INPUT_KEYBOARD
>    When the input type is SSH_USERAUTH_INPUT_KEYBOARD, the format of the
>    SSH_MSG_USERAUTH_INFO_RESPONSE message is as follows:
>       byte    SSH_MSG_USERAUTH_INFO_RESPONSE
>       int     num responses

I think this again should be the authentication method name, not
number:

	string	"keyboard-query-response"

>       string  response[0] (ISO-10646 UTF-8)
>       ...
>       string  response[n] (ISO-10646 UTF-8)
...
> 4. Authentication Example
> 
>    Here is an example exchange between a client and server:
> 
>    C:      byte    SSH_MSG_USERAUTH_REQUEST
>    C:      string  "foo"
>    C:      string  "ssh-connection"
>    C:      string  "password-plus"
>    C:      int     1
>    C:      int     SSH_USERAUTH_INPUT_KEYBOARD
> 
>    S:      byte    SSH_MSG_USERAUTH_INFO_REQUEST
>    S:      int     SSH_USERAUTH_INPUT_KEYBOARD
>    S:      boolean TRUE
>    S:      string  "Password Authentication"
>    S:      boolean TRUE
>    S:      string  "Enter password for foo"
>    S:      int     1
>    S:      string  "Password: "
>    S:      boolean FALSE
>    S:      string  "en-US"
> 
>    [Client prompts user for password]
> 
>    C:      byte    SSH_MSG_USERAUTH_INFO_RESPONSE
>    C:      int     1
>    C:      string  "bar"
> 
>    S:      byte    SSH_MSG_USERAUTH_INFO_REQUEST
>    S:      int     SSH_USERAUTH_INPUT_KEYBOARD
>    S:      boolean TRUE
>    S:      string  "Password Expired"
>    S:      boolean TRUE
>    S:      string  "Your password has expired."
>    S:      int     2
>    S:      string  "Enter new password: "
>    S:      boolean FALSE
>    S:      string  "Enter it again: "
>    S:      boolean FALSE
>    S:      string  "en-US"
> 
>    [Client prompts user for new password]
> 
>    C:      byte    SSH_MSG_USERAUTH_INFO_RESPONSE
>    C:      int     2
>    C:      string  "baz"
>    C:      string  "baz"
> 
>    S:      byte    SSH_MSG_USERAUTH_SUCCESS

I think this example is bad, because it can already be performed using
the basic userauth draft, it contains banners, it contains password
queries, it contains password change-request, and it even contains
advantage compared to this method, it can use users native language
when printing out most of the prompts.
-- 
kivinen@iki.fi                               Work : +358-9-4354 3218
SSH Communications Security                  http://www.ssh.fi/
SSH IPSEC Toolkit                            http://www.ssh.fi/ipsec/

From owner-ietf-ssh@clinet.fi  Tue Feb 23 14:09: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 OAA03562;
	Tue, 23 Feb 1999 14:09:14 +0200 (EET)
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 OAA00908;
	Tue, 23 Feb 1999 14:09:14 +0200 (EET)
Received: (from majordom@localhost)
	by lohi.clinet.fi (8.9.1/8.9.0) id OAA24939
	for ietf-ssh-outgoing; Tue, 23 Feb 1999 14:09:47 +0200 (EET)
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 OAA24924
	for <ietf-ssh@clinet.fi>; Tue, 23 Feb 1999 14:09:42 +0200 (EET)
Received: from sanna.lysator.liu.se (nisse@sanna.lysator.liu.se [130.236.254.206])
	by samantha.lysator.liu.se (8.8.7/8.8.7) with ESMTP id NAA01054;
	Tue, 23 Feb 1999 13:06:42 +0100 (MET)
Received: (from nisse@localhost)
	by sanna.lysator.liu.se (8.8.8/8.8.7) id NAA22785;
	Tue, 23 Feb 1999 13:06:36 +0100 (MET)
To: Marc Horowitz <marc@MIT.EDU>
Cc: ietf-ssh@clinet.fi
Subject: Re: interpretation of channel subsystem name
References: <t53btim40lu.fsf@rover.cygnus.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
From: nisse@lysator.liu.se (Niels =?ISO-8859-1?Q?M=F6ller?=)
Date: 23 Feb 1999 13:06:35 +0100
In-Reply-To: Marc Horowitz's message of "22 Feb 1999 15:58:21 -0500"
Message-ID: <nnww19729g.fsf@sanna.lysator.liu.se>
X-Mailer: Gnus v5.4.59/Emacs 19.34
Sender: owner-ietf-ssh@clinet.fi
Precedence: bulk
Content-Length: 787
Lines: 23

Marc Horowitz <marc@MIT.EDU> writes:

> Would it be reasonable for an implementation to understand
> some structure in the subsystem name, in particular to understand
> arguments?  For instance, one might desire a finger subsystem which
> just sends back information about the users who are logged in.
> However, it is useful to limit this information by giving arguments to
> the subsystem.

I think that it would be more reasonable to have optional arguments in
the subsystem-request message. I.e, to change the definition to

  byte		SSH_MSG_CHANNEL_REQUEST
  uint32	recipient channel
  string	"subsystem"
  boolean	 want reply
  string	subsystem name
  ... subsystem specific data follows.

I'd like to propose that this change is incorporated into the
specification.

/Niels Mller
From owner-ietf-ssh@clinet.fi  Tue Feb 23 18:04: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 SAA07678;
	Tue, 23 Feb 1999 18:04:20 +0200 (EET)
Received: from lohi.clinet.fi (root@lohi.clinet.fi [194.100.0.7])
	by ssh.fi (8.9.1/8.9.1/EPIPE-1.15) with ESMTP id SAA05042;
	Tue, 23 Feb 1999 18:04:20 +0200 (EET)
Received: (from majordom@localhost)
	by lohi.clinet.fi (8.9.1/8.9.0) id OAA03043
	for ietf-ssh-outgoing; Tue, 23 Feb 1999 14:55:10 +0200 (EET)
X-Authentication-Warning: lohi.clinet.fi: majordom set sender to owner-ietf-ssh@clinet.fi using -f
Received: from nic.carlstedt.se (nic.carlstedt.se [193.12.107.10])
	by lohi.clinet.fi (8.9.1/8.9.0) with ESMTP id OAA01915;
	Tue, 23 Feb 1999 14:47:55 +0200 (EET)
Received: from giraf.carlstedt.se (root@giraf.carlstedt.se [172.16.1.10])
	by nic.carlstedt.se (8.9.3/8.9.3) with ESMTP id NAA07963;
	Tue, 23 Feb 1999 13:43:51 +0100 (MET)
Received: from carlstedt.se (maf@aston.carlstedt.se [172.16.1.90])
	by giraf.carlstedt.se (8.9.3/8.9.3) with ESMTP id NAA16085;
	Tue, 23 Feb 1999 13:43:44 +0100 (MET)
Message-Id: <199902231243.NAA16085@giraf.carlstedt.se>
Date: Tue, 23 Feb 1999 13:43:41 +0100 (MET)
From: Martin Forssen <maf@crt.se>
Subject: Re: Generic challenge-repsonse aunetication in ssh2 
To: fcusack@iconnet.net
cc: ssh@clinet.fi, ietf-ssh@clinet.fi, psst@net.lut.ac.uk
In-Reply-To: <199902230147.UAA13966@ratbert.iconnet.net>
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Sender: owner-ietf-ssh@clinet.fi
Precedence: bulk
Content-Length: 3877
Lines: 100

On 22 Feb, Frank Cusack wrote:
> Here is an updated version of my proposal, fully formatted as an
> I-D.

This is looking good. I think it is more worthwhile to work on this
draft than on mine. But I do have some comments:-)

First the big issue. After some thinking I have reached the conclusion
(this is all IMHO of course) that we do not need to try to define some
generic protocol which can handle all smart-cards biometric devices
etc. Instead we need a way to let the client and the server load new
authentication methods dynamically. Therefore we should be able to
remove everything but the keyboard input type, and thus postponing many
potential problems (divide and conquer).

The basis for removing the non-keyboard types is that I think we should
separate those methods who need special code (drivers unique for that
method) on the client from those who do not (I do not count keyboard
interaction as defined here as special code). This document describes
the keyboard method.

Other methods who needs special code could take two approaches. One is
to document the protocol and write a draft about it. This is IMHO a
good idea. Or if one does not want to write a draft describing the
protocol one could use a private method name (one with an '@' in it).
We could even make a convention that one could register pam-modules as
module_name@pam.

The imporant thing is to define a common API (perhaps some modfied form
of PAM) which those methods cna use to connect to ssh.


And now over to the comments on the draft itself.

> 3.1 Initial Exchange
...
>    The authentication starts with the client sending the following
>    packet:
> 
>       byte    SSH_MSG_USERAUTH_REQUEST
>       string  username
>       string  service
>       string  "password-plus"
>       int     num-supported-input-types
>       int     input-type[0]
>       ...
>       int     input-type[n]

I would feel more comfortable if we used the same list format as the
sshauth draft does (ie a comma-separated string). I would like to
propose the following format instead:

	byte    SSH_MSG_USERAUTH_REQUEST
	string  username
	string	service
	string	"password-plus"
	string	methods

Where methods is a comma-separated strings of supported authentication
methods using the keyboard input type.

The rationale for having the methods field is that the user may have
multiple methods availbale (for example both SecurID and CryptoCard).
This list should be normally be provided by the user. The server should
also be able to ignore this field if it knows from some other context
which method(s) are avilable for the user.

> 3.2 Information Requests / User Interface
...
>    part" and an "input-type-specific part".  The "common part" is
>    defined as follows:
> 
>       byte    SSH_MSG_USERAUTH_INFO_REQUEST
>       int     input-type
>       boolean name-present
>       string  name (if name-present is TRUE) (ISO-10646 UTF-8)
>       boolean banner-present
>       string  banner (if banner-present is TRUE) (ISO-10646 UTF-8)
>       rest of the packet is input-type-specific

Why do we need the booleans? Should not just a zero-length string
suffice to inidcate that no value is given? I think the protocol would
look cleaner if one always had the same fields in a packet.

I also miss the language-tag for these fields. Perhaps it would be
enough for one language-tag for each packet (which would force the
name, banner and prompts to be in the same language).

> 5. Protocol constants
>       All negative values for input types are reserved for locally
>       defined methods.  No method is specified for determining what
>       "locality" a negative input type is valid in.

IMHO strings should be used to identify protocols. Then we can use the
same mechanism as the architecture draft (section 5) uses for
algorithms to denote local methods (appending @your.mail.domain).


	/MaF

From owner-ietf-ssh@clinet.fi  Wed Feb 24 12:38: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 MAA12154;
	Wed, 24 Feb 1999 12:38:29 +0200 (EET)
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 MAA13738;
	Wed, 24 Feb 1999 12:38:28 +0200 (EET)
Received: (from majordom@localhost)
	by lohi.clinet.fi (8.9.1/8.9.0) id MAA16249
	for ietf-ssh-outgoing; Wed, 24 Feb 1999 12:37:51 +0200 (EET)
X-Authentication-Warning: lohi.clinet.fi: majordom set sender to owner-ietf-ssh@clinet.fi using -f
Received: from neon.transmeta.com (neon-best.transmeta.com [206.184.214.10])
	by lohi.clinet.fi (8.9.1/8.9.0) with ESMTP id UAA15350;
	Tue, 23 Feb 1999 20:15:10 +0200 (EET)
Received: from deepthought.transmeta.com (mailhost.transmeta.com [10.1.1.15])
	by neon.transmeta.com (8.9.1/8.9.1) with ESMTP id KAA26172;
	Tue, 23 Feb 1999 10:10:14 -0800
Received: from transmeta.com (morgan@blighty.transmeta.com [10.1.27.37])
	by deepthought.transmeta.com (8.8.8+spamcan/8.8.5) with ESMTP id KAA12291;
	Tue, 23 Feb 1999 10:10:13 -0800 (PST)
Message-ID: <36D2EF05.9CFCE807@transmeta.com>
Date: Tue, 23 Feb 1999 10:10:13 -0800
From: Andrew Morgan <morgan@transmeta.com>
Organization: Transmeta Corporation
X-Mailer: Mozilla 4.05 [en] (X11; U; Linux 2.2.1 i686)
MIME-Version: 1.0
To: Martin Forssen <maf@crt.se>
CC: fcusack@iconnet.net, ssh@clinet.fi, ietf-ssh@clinet.fi, psst@net.lut.ac.uk
Subject: Re: Generic challenge-repsonse aunetication in ssh2
References: <199902231243.NAA16085@giraf.carlstedt.se>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-ssh@clinet.fi
Precedence: bulk
Content-Length: 3658
Lines: 88

Martin Forssen wrote:
> First the big issue. After some thinking I have reached the conclusion
> (this is all IMHO of course) that we do not need to try to define some
> generic protocol which can handle all smart-cards biometric devices
> etc. Instead we need a way to let the client and the server load new
> authentication methods dynamically. Therefore we should be able to
> remove everything but the keyboard input type, and thus postponing many
> potential problems (divide and conquer).

I'm in complete agreement with this. Adding generic tty based
authentication support and then forcing the server/client to only
support certain types of non-tty input would be a real shame.

> The imporant thing is to define a common API (perhaps some modfied form
> of PAM) which those methods cna use to connect to ssh.

The approach that we took when making our PAM extension to ssh-1.2
looked a lot like the stuff contained in this draft, so I'm confident
that the eventual form of the draft will be suitable for adding proper
PAM support to ssh.

The non-tty input methods we implemented were via a single 'BINARY'
message type.

Each binary message contained some indication of how the message was to
be used. The typical approach was for the server to send a binary
message ('binary-prompt') requesting that a given flavor of
authentication was initialized, the client would do this if it possessed
the corresponding PAM-agent and subsequent binary-prompts would be
directed to the agent for client side processing and the return of a
corresponding binray-prompt with the processed authentication
information. Not possessing the PAM-agent, the client would so state and
the server would be given the chance to offer some other method. This
approach could be configured from the PAM configuration file (by the
server's sys admin) and it was then possible to dynamically support all
flavors of authentication scheme in a way that the server's admin could
control/combine. (All without recompiling ssh again. :^)

If PAM module/PAM agent combinations had been written, you do things
like this:

  1. is the client host trusted to be locally maintained?
       Yes: goto 6

  2. can client do XXX authentication?
       Yes:
          they authenticated so grant access
          they did not authenticate correctly so permission denied

  3. can client do YYY authentication?
       Yes:
          they authenticated so goto 7
          they failed to authenticate so permission denied

  4. ask the user if they like s/key?
       Yes: try s/key via simple tty exchange)
          they authenticated so grant access
          they failed to authenticate so permission denied

  5. try OPIE (via simple tty exchange)
          they authenticated so grant access
          they failed to authenticate so permission denied

  6. do convenient authentication (something silly like identd)
       they authenticated so grant access
       they failed to authenticate so permission denied

  7. YYY needs to be backed up with the user doing ZZZ too, can the
client support it?
       YES:
          they authenticated so grant access
          they failed to authenticate so permission denied
       NO:
          the local admin will not trust YYY without ZZZ too: permission
denied.

I'd like to see this sort of authentication prompting supported by the
eventual form of this authentication draft.

The client/server telling all regarding supported methods on the first
exchange, does not gel well with PAM as it is currently implemented. In
this generic authentication environment, I'd be happy to learn why this
is an important requirement.

Cheers

Andrew

From owner-ietf-ssh@clinet.fi  Wed Feb 24 15:55:40 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 PAA01956;
	Wed, 24 Feb 1999 15:55:39 +0200 (EET)
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 PAA15492;
	Wed, 24 Feb 1999 15:55:39 +0200 (EET)
Received: (from majordom@localhost)
	by lohi.clinet.fi (8.9.1/8.9.0) id PAA17248
	for ietf-ssh-outgoing; Wed, 24 Feb 1999 15:55:33 +0200 (EET)
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 PAA17236;
	Wed, 24 Feb 1999 15:55:31 +0200 (EET)
Received: from sanna.lysator.liu.se (nisse@sanna.lysator.liu.se [130.236.254.206])
	by samantha.lysator.liu.se (8.8.7/8.8.7) with ESMTP id OAA17052;
	Wed, 24 Feb 1999 14:52:17 +0100 (MET)
Received: (from nisse@localhost)
	by sanna.lysator.liu.se (8.8.8/8.8.7) id OAA25931;
	Wed, 24 Feb 1999 14:52:11 +0100 (MET)
To: Tero Kivinen <kivinen@iki.fi>
Cc: Frank Cusack <fcusack@iconnet.net>, ssh@clinet.fi, ietf-ssh@clinet.fi,
        psst@net.lut.ac.uk
Subject: Re: Generic challenge-repsonse aunetication in ssh2
References: <199902230147.UAA13966@ratbert.iconnet.net> <199902231154.NAA27864@hutcs.cs.hut.fi>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
From: nisse@lysator.liu.se (Niels =?ISO-8859-1?Q?M=F6ller?=)
Date: 24 Feb 1999 14:52:09 +0100
In-Reply-To: Tero Kivinen's message of "Tue, 23 Feb 1999 13:54:08 +0200 (EET)"
Message-ID: <nniucr7vue.fsf@sanna.lysator.liu.se>
X-Mailer: Gnus v5.4.59/Emacs 19.34
Sender: owner-ietf-ssh@clinet.fi
Precedence: bulk
Content-Length: 4667
Lines: 97

Tero Kivinen <kivinen@iki.fi> writes:

> Few comments about the draft. 

[ details skipped ]

> I think this example is bad, because it can already be performed using
> the basic userauth draft, it contains banners, it contains password
> queries, it contains password change-request, and it even contains
> advantage compared to this method, it can use users native language
> when printing out most of the prompts.

I think I agree with all of your points. However, I suspect that you
don't understand which problem the proposal tries to solve (I'm not
entirely sure I understand it either).

The existing ssh userauth mechanisms lets the client side "drive" the
authentication process; the user decides, for instance, whether to
attempt login using a password or using some smartcard.

On the other side, we have sysadmins that want to be able to
configure, at the server side, exactly how the authentication process
should proceed, for instance using PAM (Pluggable Authentiction
Modules, available at least on Linux and Solaris).

PAM, in its current incarnations, is not well suited for ssh2 style
user authentication. For instance it is more or less impossible for a
PAM-aware ssh server to find out the correct list of methods for the
"authentications that can continue" field of the USERAUTH_FAILURE
message.

The point of the proposal, as I understand it, is to create a more
PAM-friendly mechanism, where the server tells the client what it has
to do at each step. I.e., the authentication process is driven by
the PAM-framework, which speaks more or less directly with the client
side. And where the level of abstraction in these message is similar
to PAM's.

One other valid point is supporting a text-based challenge response
authentication protocol, for instance for the hardware tokens where
the user types a PIN-code and a server challenge, to produce a
response that should be presented to the server for authentication.
But that particular application can be supported with a simpler
authentication method, something like the "keyboard-query-response"
you are describing.

Of course, it is possible that I have missed some important problem
that the "generic challenge response" authentication method solves. If
so, please correct me.

For reference, I include my notes about ssh2 and PAM below (also
available in the lsh distribution,
ftp://ftp.lysator.liu.se/pub/security/lsh). Since I wrote this,
possible work-arounds for some of the problems have been pointed out
to me. 

/Niels

----8<----

I spent a day reading the PAM documentation. My conclusion was that
PAM is not at all suited for handling ssh user authentication. There
are three main problems, the first two of which would be show-stoppers
for any SSH server, while the last is a problem that affects servers
like lshd which doesn't fork() for each connection.

(i) The design of PAM is to hide all details about the actual
authentication methods used, and that the application should never
know anything about that. However, ssh user authentication is about
particular authentication methods. When the client asks which
authentication methods can be used, the server should be able to tell
it, for example, whether or not password authentication is acceptable.
When the client tries the password authentication method, no other
method should be invoked. But PAM won't let the server know or control
such details. This problem excludes using PAM for anything but simple
password authentication.

(ii) PAM wants to talk directly to the user, to ask for passwords,
request password changes, etc. These messages are not abstracted *at*
*all*, PAM gives the application a string and some display hints, and
expects a string back as the users response. This mode of operation
doesn't fit with the ssh user-authentication protocol. 

If PAM would tell the ssh server that it wanted the user to chose a
new password, for instance, the server could the appropriate message,
SSH_SSH_MSG_USERAUTH_PASSWD_CHANGEREQ, to the client, and pass any
response back to PAM. But PAM refuses to tell the application what it
really wants the user to do, and therefore there's no way the server
can map PAM's messages to the appropriate SSH packets. This problem
excludes using PAM for password authentication.

(iii) The PAM conversation function expects the server to ask the user
some question, block until a response is received, and then return the
result to PAM. That is very unfriendly to a server using a select()
loop to manage many simultaneous tasks. This problem by itself does
not exclude using PAM for a traditional accept(); fork()-style server,
but it is completely unacceptable for lshd.
From owner-ietf-ssh@clinet.fi  Thu Feb 25 13:38: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 NAA27737;
	Thu, 25 Feb 1999 13:38:00 +0200 (EET)
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 NAA25142;
	Thu, 25 Feb 1999 13:37:59 +0200 (EET)
Received: (from majordom@localhost)
	by lohi.clinet.fi (8.9.1/8.9.0) id NAA27852
	for ietf-ssh-outgoing; Thu, 25 Feb 1999 13:33:04 +0200 (EET)
X-Authentication-Warning: lohi.clinet.fi: majordom set sender to owner-ietf-ssh@clinet.fi using -f
Received: from hutcs.cs.hut.fi (kivinen@hutcs.cs.hut.fi [130.233.192.7])
	by lohi.clinet.fi (8.9.1/8.9.0) with ESMTP id WAA03912;
	Wed, 24 Feb 1999 22:26:00 +0200 (EET)
Received: (from kivinen@localhost) by hutcs.cs.hut.fi (8.8.8/8.8.8) id WAA22040; Wed, 24 Feb 1999 22:22:43 +0200 (EET)
Date: Wed, 24 Feb 1999 22:22:43 +0200 (EET)
Message-Id: <199902242022.WAA22040@hutcs.cs.hut.fi>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
From: Tero Kivinen <kivinen@iki.fi>
To: nisse@lysator.liu.se (Niels Mller)
Cc: Frank Cusack <fcusack@iconnet.net>, ssh@clinet.fi, ietf-ssh@clinet.fi,
        psst@net.lut.ac.uk
Subject: Re: Generic challenge-repsonse aunetication in ssh2
In-Reply-To: <nniucr7vue.fsf@sanna.lysator.liu.se>
References: <199902230147.UAA13966@ratbert.iconnet.net>
	<199902231154.NAA27864@hutcs.cs.hut.fi>
	<nniucr7vue.fsf@sanna.lysator.liu.se>
X-Mailer: VM 6.33 under Emacs 19.34.1
Organization: Helsinki University of Technology
X-Edit-Time: 12 min
X-Total-Time: 16 min
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by lohi.clinet.fi id WAA03914
Sender: owner-ietf-ssh@clinet.fi
Precedence: bulk
Content-Length: 2749
Lines: 57

Niels Mller writes:
> The existing ssh userauth mechanisms lets the client side "drive" the
> authentication process; the user decides, for instance, whether to
> attempt login using a password or using some smartcard.

No. The current userauth mechanisms allows either side "drive" the
authentication. If the server wants to drive the authentication it
only offers one authentication method at time to the clinet, and
client has to do that or fail. If the server wants to allow client to
drive the it can just give the full list. 

> PAM, in its current incarnations, is not well suited for ssh2 style
> user authentication. For instance it is more or less impossible for a
> PAM-aware ssh server to find out the correct list of methods for the
> "authentications that can continue" field of the USERAUTH_FAILURE
> message.

If it is text-base keyboard-query-response then it willmost likely to
be password. The following conversation is quite possible in the ssh2
protocol:

C: SSH_MSG_USERAUTH_REQUEST, "kivinen", "service", "none"
S: SSH_MSG_USERAUTH_BANNER, "Enter normal password for kivinen", en_EN
S: SSH_MSG_USERAUTH_FAILURE, "password", FALSE
C: SSH_MSG_USERAUTH_REQUEST, "kivinen", "service", "password", FALSE, "foobar"
S: SSH_MSG_USERAUTH_BANNER, "Enter one time password 23 for kivinen", en_EN
S: SSH_MSG_USERAUTH_FAILURE, "password", TRUE
C: SSH_MSG_USERAUTH_REQUEST, "kivinen", "service", "password", FALSE, "01201"
S: SSH_MSG_USERAUTH_SUCCESS

Only thing here missing is the ability to ask password that are
allowed to be echoed to screen. Also using banner to send text
messages is not really the intendend use for it...

> The point of the proposal, as I understand it, is to create a more
> PAM-friendly mechanism, where the server tells the client what it has
> to do at each step. I.e., the authentication process is driven by
> the PAM-framework, which speaks more or less directly with the client
> side. And where the level of abstraction in these message is similar
> to PAM's.

I don't really know anything about the PAM, so I cannot say if it can
be implemented using userauth or not. 

> (ii) PAM wants to talk directly to the user, to ask for passwords,
> request password changes, etc. These messages are not abstracted *at*
> *all*, PAM gives the application a string and some display hints, and
> expects a string back as the users response. This mode of operation
> doesn't fit with the ssh user-authentication protocol. 

This can be kludged around using the BANNER and "password"
authentication method. 
-- 
kivinen@iki.fi                               Work : +358-9-4354 3218
SSH Communications Security                  http://www.ssh.fi/
SSH IPSEC Toolkit                            http://www.ssh.fi/ipsec/

From owner-ietf-ssh@clinet.fi  Thu Feb 25 13:38: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 NAA08169;
	Thu, 25 Feb 1999 13:38:01 +0200 (EET)
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 NAA25145;
	Thu, 25 Feb 1999 13:38:00 +0200 (EET)
Received: (from majordom@localhost)
	by lohi.clinet.fi (8.9.1/8.9.0) id NAA27939
	for ietf-ssh-outgoing; Thu, 25 Feb 1999 13:33:25 +0200 (EET)
X-Authentication-Warning: lohi.clinet.fi: majordom set sender to owner-ietf-ssh@clinet.fi using -f
Received: from hutcs.cs.hut.fi (kivinen@hutcs.cs.hut.fi [130.233.192.7])
	by lohi.clinet.fi (8.9.1/8.9.0) with ESMTP id WAA04539;
	Wed, 24 Feb 1999 22:33:41 +0200 (EET)
Received: (from kivinen@localhost) by hutcs.cs.hut.fi (8.8.8/8.8.8) id WAA22146; Wed, 24 Feb 1999 22:30:18 +0200 (EET)
Date: Wed, 24 Feb 1999 22:30:18 +0200 (EET)
Message-Id: <199902242030.WAA22146@hutcs.cs.hut.fi>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
From: Tero Kivinen <kivinen@iki.fi>
To: Andrew Morgan <morgan@transmeta.com>
Cc: Martin Forssen <maf@crt.se>, fcusack@iconnet.net, ssh@clinet.fi,
        ietf-ssh@clinet.fi, psst@net.lut.ac.uk
Subject: Re: Generic challenge-repsonse aunetication in ssh2
In-Reply-To: <36D2EF05.9CFCE807@transmeta.com>
References: <199902231243.NAA16085@giraf.carlstedt.se>
	<36D2EF05.9CFCE807@transmeta.com>
X-Mailer: VM 6.33 under Emacs 19.34.1
Organization: Helsinki University of Technology
X-Edit-Time: 5 min
X-Total-Time: 5 min
Sender: owner-ietf-ssh@clinet.fi
Precedence: bulk
Content-Length: 2303
Lines: 45

Andrew Morgan writes:
> The non-tty input methods we implemented were via a single 'BINARY'
> message type.

What authentication methods there are that use those BINARY messages?
I am not talking about what might be, I am talking about what
currently exists? 

> Each binary message contained some indication of how the message was to
> be used. The typical approach was for the server to send a binary
> message ('binary-prompt') requesting that a given flavor of
> authentication was initialized, the client would do this if it possessed
> the corresponding PAM-agent and subsequent binary-prompts would be
> directed to the agent for client side processing and the return of a
> corresponding binray-prompt with the processed authentication
> information. Not possessing the PAM-agent, the client would so state and
> the server would be given the chance to offer some other method. This
> approach could be configured from the PAM configuration file (by the
> server's sys admin) and it was then possible to dynamically support all
> flavors of authentication scheme in a way that the server's admin could
> control/combine. (All without recompiling ssh again. :^)

So this seems to be same thing that the ssh-agent does?

> I'd like to see this sort of authentication prompting supported by the
> eventual form of this authentication draft.
> 
> The client/server telling all regarding supported methods on the first
> exchange, does not gel well with PAM as it is currently implemented. In
> this generic authentication environment, I'd be happy to learn why this
> is an important requirement.

No, the server never gives out list of supported methods, it gives out
list of possible continuations of the authentication exchange. That
list may change over the authentication process. It might for example
fist only offer hostbased authentication and after that has been
successfully performed, it will say that ok, that was partial success,
now the user still must do either rsa or password authentication. The
list is sent out in each SSH_MSG_USERAUTH_FAILURE message and it may
change. 
-- 
kivinen@iki.fi                               Work : +358-9-4354 3218
SSH Communications Security                  http://www.ssh.fi/
SSH IPSEC Toolkit                            http://www.ssh.fi/ipsec/

From owner-ietf-ssh@clinet.fi  Thu Feb 25 13:38:03 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 NAA26715;
	Thu, 25 Feb 1999 13:38:03 +0200 (EET)
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 NAA25155;
	Thu, 25 Feb 1999 13:38:03 +0200 (EET)
Received: (from majordom@localhost)
	by lohi.clinet.fi (8.9.1/8.9.0) id NAA28313
	for ietf-ssh-outgoing; Thu, 25 Feb 1999 13:35:14 +0200 (EET)
X-Authentication-Warning: lohi.clinet.fi: majordom set sender to owner-ietf-ssh@clinet.fi using -f
Received: from delcluster2.vsnl.net.in (delcluster2.vsnl.net.in [202.54.96.2])
	by lohi.clinet.fi (8.9.1/8.9.0) with ESMTP id JAA11255
	for <ietf-ssh@clinet.fi>; Thu, 25 Feb 1999 09:47:35 +0200 (EET)
Received: from mailserver ([202.54.106.216])
	by delcluster2.vsnl.net.in (8.9.2/8.9.2) with SMTP id NAA26264
	for <ietf-ssh@clinet.fi>; Thu, 25 Feb 1999 13:14:25 -0500 (GMT)
Received: by mailserver with XtraMail-SMTP/POP3-Server (v1.10 58210006074) for <ietf-ssh@clinet.fi> at Thu, 25 Feb 99  13:08:02 +0570
Received: from proxy2.ba.best.com (root@proxy2.ba.best.com [206.184.139.13])
	by fpage1.ba.best.com (8.9.2/8.9.2/best.sh) with ESMTP id TAA19274
	for <ravibaid+XRCPT.61616c6f6b4042495351554152452e434f4d@fpage1.ba.best.com>; Wed, 24 Feb 1999 19:32:44 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by proxy2.ba.best.com (8.9.3/8.9.2/best.in) with ESMTP id TAA19783;
	Wed, 24 Feb 1999 19:29:11 -0800 (PST)
Received: by ietf.org (8.9.1a/8.9.1a) id WAA15397
	for ietf-123-outbound.02@ietf.org; Wed, 24 Feb 1999 22:25:14 -0500 (EST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28481;
	Wed, 24 Feb 1999 18:15:52 -0500 (EST)
Message-Id: <199902242315.SAA28481@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: ietf-ssh@clinet.fi
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-secsh-userauth-05.txt
Date: Wed, 24 Feb 1999 18:15:51 -0500
X-Rcpt-To: aalok@bisquare.com
X-UIDL: 06219606b8896834ec551d3b302abcd4
Sender: owner-ietf-ssh@clinet.fi
Precedence: bulk
Content-Length: 2767
Lines: 86

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Secure Shell Working Group of the IETF.

	Title		: SSH Authentication Protocol
	Author(s)	: T. Ylonen, T. Kivinen, M. Saarinen,
                          T. Rinne, S. Lehtinen
	Filename	: draft-ietf-secsh-userauth-05.txt
	Pages		: 11
	Date		: 22-Feb-99
	
SSH is a protocol for secure remote login and other secure network ser-
vices over an insecure network. This document describes the SSH authen-
tication protocol framework and public key, password, and host-based
client authentication methods.  Additional authentication methods are
deferred to separate documents.  The SSH authentication protocol runs on
top the SSH transport layer protocol and provides a single authenticated
tunnel for the SSH connection protocol.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-secsh-userauth-05.txt

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

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


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

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-secsh-userauth-05.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<19990224175509.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-secsh-userauth-05.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-secsh-userauth-05.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<19990224175509.I-D@ietf.org>

--OtherAccess--

--NextPart--




From owner-ietf-ssh@clinet.fi  Thu Feb 25 13:41:47 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 NAA27766;
	Thu, 25 Feb 1999 13:41:47 +0200 (EET)
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 NAA25227;
	Thu, 25 Feb 1999 13:41:47 +0200 (EET)
Received: (from majordom@localhost)
	by lohi.clinet.fi (8.9.1/8.9.0) id NAA28978
	for ietf-ssh-outgoing; Thu, 25 Feb 1999 13:39:25 +0200 (EET)
X-Authentication-Warning: lohi.clinet.fi: majordom set sender to owner-ietf-ssh@clinet.fi using -f
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by lohi.clinet.fi (8.9.1/8.9.0) with ESMTP id BAA22618
	for <ietf-ssh@clinet.fi>; Thu, 25 Feb 1999 01:21:00 +0200 (EET)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28579;
	Wed, 24 Feb 1999 18:17:17 -0500 (EST)
Message-Id: <199902242317.SAA28579@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: ietf-ssh@clinet.fi
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-secsh-transport-05.txt
Date: Wed, 24 Feb 1999 18:17:17 -0500
Sender: owner-ietf-ssh@clinet.fi
Precedence: bulk
Content-Length: 3021
Lines: 88

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Secure Shell Working Group of the IETF.

	Title		: SSH Transport Layer Protocol
	Author(s)	: T. Ylonen, T. Kivinen, M. Saarinen,  
                          T. Rinne, S. Lehtinen
	Filename	: draft-ietf-secsh-transport-05.txt
	Pages		: 21
	Date		: 22-Feb-99
	
SSH is a protocol for secure remote login and other secure network ser-
vices over an insecure network.  This document describes the SSH trans-
port layer protocol which typically runs on top of TCP/IP. The protocol
can be used as a basis for a number of secure network services. It pro-
vides strong encryption, server authentication, and integrity protec-
tion. It may also provide compression.  Key exchange method, public key
algorithm, symmetric encryption algorithm, message authentication algo-
rithm, and hash algorithm are all negotiated.  This document also
describes the Diffie-Hellman key exchange method and the minimal set of
algorithms that are needed to implement the SSH transport layer proto-
col.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-secsh-transport-05.txt

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

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


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

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-secsh-transport-05.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<19990224175650.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-secsh-transport-05.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-secsh-transport-05.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<19990224175650.I-D@ietf.org>

--OtherAccess--

--NextPart--


From owner-ietf-ssh@clinet.fi  Thu Feb 25 13:42:11 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 NAA27888;
	Thu, 25 Feb 1999 13:42:11 +0200 (EET)
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 NAA25235;
	Thu, 25 Feb 1999 13:42:10 +0200 (EET)
Received: (from majordom@localhost)
	by lohi.clinet.fi (8.9.1/8.9.0) id NAA29042
	for ietf-ssh-outgoing; Thu, 25 Feb 1999 13:39:50 +0200 (EET)
X-Authentication-Warning: lohi.clinet.fi: majordom set sender to owner-ietf-ssh@clinet.fi using -f
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by lohi.clinet.fi (8.9.1/8.9.0) with ESMTP id BAA22735
	for <ietf-ssh@clinet.fi>; Thu, 25 Feb 1999 01:22:16 +0200 (EET)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28636;
	Wed, 24 Feb 1999 18:18:34 -0500 (EST)
Message-Id: <199902242318.SAA28636@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: ietf-ssh@clinet.fi
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-secsh-connect-05.txt
Date: Wed, 24 Feb 1999 18:18:34 -0500
Sender: owner-ietf-ssh@clinet.fi
Precedence: bulk
Content-Length: 2772
Lines: 84

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Secure Shell Working Group of the IETF.

	Title		: SSH Connection Protocol
	Author(s)	: T. Ylonen, T. Kivinen, M. Saarinen, 
                          T. Rinne, S. Lehtinen
	Filename	: draft-ietf-secsh-connect-05.txt
	Pages		: 17
	Date		: 22-Feb-99
	
SSH is a protocol for secure remote login and other secure network ser-
vices over an insecure network. This document describes the SSH connec-
tion protocol. It provides interactive login sessions, remote execution
of commands, forwarded TCP/IP connections, and forwarded X11 connec-
tions. All of these channels are multiplexed into a single encrypted
tunnel.  The SSH Connection Protocol has been designed to run on top of
the SSH transport layer and user authentication protocols.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-secsh-connect-05.txt

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

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


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

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-secsh-connect-05.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<19990224175809.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-secsh-connect-05.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-secsh-connect-05.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<19990224175809.I-D@ietf.org>

--OtherAccess--

--NextPart--


From owner-ietf-ssh@clinet.fi  Thu Feb 25 13:42:42 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 NAA27906;
	Thu, 25 Feb 1999 13:42:42 +0200 (EET)
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 NAA25249;
	Thu, 25 Feb 1999 13:42:41 +0200 (EET)
Received: (from majordom@localhost)
	by lohi.clinet.fi (8.9.1/8.9.0) id NAA29165
	for ietf-ssh-outgoing; Thu, 25 Feb 1999 13:40:20 +0200 (EET)
X-Authentication-Warning: lohi.clinet.fi: majordom set sender to owner-ietf-ssh@clinet.fi using -f
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by lohi.clinet.fi (8.9.1/8.9.0) with ESMTP id BAA23041
	for <ietf-ssh@clinet.fi>; Thu, 25 Feb 1999 01:27:09 +0200 (EET)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28880;
	Wed, 24 Feb 1999 18:23:28 -0500 (EST)
Message-Id: <199902242323.SAA28880@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: ietf-ssh@clinet.fi
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-secsh-connect-05.txt
Date: Wed, 24 Feb 1999 18:23:27 -0500
Sender: owner-ietf-ssh@clinet.fi
Precedence: bulk
Content-Length: 2772
Lines: 84

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Secure Shell Working Group of the IETF.

	Title		: SSH Connection Protocol
	Author(s)	: T. Ylonen, T. Kivinen, M. Saarinen, 
                          T. Rinne, S. Lehtinen
	Filename	: draft-ietf-secsh-connect-05.txt
	Pages		: 17
	Date		: 22-Feb-99
	
SSH is a protocol for secure remote login and other secure network ser-
vices over an insecure network. This document describes the SSH connec-
tion protocol. It provides interactive login sessions, remote execution
of commands, forwarded TCP/IP connections, and forwarded X11 connec-
tions. All of these channels are multiplexed into a single encrypted
tunnel.  The SSH Connection Protocol has been designed to run on top of
the SSH transport layer and user authentication protocols.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-secsh-connect-05.txt

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

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


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

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-secsh-connect-05.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<19990224175809.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-secsh-connect-05.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-secsh-connect-05.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<19990224175809.I-D@ietf.org>

--OtherAccess--

--NextPart--


From owner-ietf-ssh@clinet.fi  Thu Feb 25 01:28:25 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 BAA15368;
	Thu, 25 Feb 1999 01:28:25 +0200 (EET)
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 BAA18573;
	Thu, 25 Feb 1999 01:28:25 +0200 (EET)
Received: (from majordom@localhost)
	by lohi.clinet.fi (8.9.1/8.9.0) id BAA23145
	for ietf-ssh-outgoing; Thu, 25 Feb 1999 01:28:09 +0200 (EET)
X-Authentication-Warning: lohi.clinet.fi: majordom set sender to owner-ietf-ssh@clinet.fi using -f
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by lohi.clinet.fi (8.9.1/8.9.0) with ESMTP id BAA23138
	for <ietf-ssh@clinet.fi>; Thu, 25 Feb 1999 01:28:06 +0200 (EET)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28959;
	Wed, 24 Feb 1999 18:24:25 -0500 (EST)
Message-Id: <199902242324.SAA28959@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: ietf-ssh@clinet.fi
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-secsh-architecture-03.txt
Date: Wed, 24 Feb 1999 18:24:24 -0500
Sender: owner-ietf-ssh@clinet.fi
Precedence: bulk
Content-Length: 3002
Lines: 86

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Secure Shell Working Group of the IETF.

	Title		: SSH Protocol Architecture
	Author(s)	: T. Ylonen, T. Kivinen, M. Saarinen, T. Rinne, S. Lehtinen
	Filename	: draft-ietf-secsh-architecture-03.txt
	Pages		: 11
	Date		: 22-Feb-99
	
SSH is a protocol for secure remote login and other secure network ser-
vices over an insecure network. This document describes the architecture
of the SSH protocol, and the notation and terminology used in SSH proto-
col documents. It also discusses the SSH algorithm naming system that
allows local extensions.  The SSH protocol consists of three major com-
ponents: Transport layer protocol provides server authentication, confi-
dentiality, and integrity with perfect forward secrecy. User authentica-
tion protocol authenticates the client to the server. Connection proto-
col multiplexes the encrypted tunnel into several logical channels.
Details of these protocols are described in separate documents.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-secsh-architecture-03.txt

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

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


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

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-secsh-architecture-03.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<19990224180404.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-secsh-architecture-03.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-secsh-architecture-03.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<19990224180404.I-D@ietf.org>

--OtherAccess--

--NextPart--


From owner-ietf-ssh@clinet.fi  Thu Feb 25 13:38: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 NAA27814;
	Thu, 25 Feb 1999 13:38:01 +0200 (EET)
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 NAA25144;
	Thu, 25 Feb 1999 13:38:00 +0200 (EET)
Received: (from majordom@localhost)
	by lohi.clinet.fi (8.9.1/8.9.0) id NAA28190
	for ietf-ssh-outgoing; Thu, 25 Feb 1999 13:34:46 +0200 (EET)
X-Authentication-Warning: lohi.clinet.fi: majordom set sender to owner-ietf-ssh@clinet.fi using -f
Received: from ratbert.iconnet.net (ratbert.iconnet.net [209.3.247.87])
	by lohi.clinet.fi (8.9.1/8.9.0) with ESMTP id CAA01922;
	Thu, 25 Feb 1999 02:44:59 +0200 (EET)
Received: from iconnet.net (localhost [127.0.0.1])
	by ratbert.iconnet.net (8.9.2/8.9.1) with ESMTP id TAA20240;
	Wed, 24 Feb 1999 19:44:02 -0500 (EST)
Message-Id: <199902250044.TAA20240@ratbert.iconnet.net>
X-Mailer: exmh version 2.0.2 2/24/98
To: ssh@clinet.fi, ietf-ssh@clinet.fi
Cc: psst@net.lut.ac.uk
Subject: Re: Generic challenge-repsonse aunetication in ssh2
Mime-Version: 1.0
Content-Type: multipart/mixed ;
	boundary="==_Exmh_-2918312890"
Date: Wed, 24 Feb 1999 19:44:02 -0500
From: Frank Cusack <fcusack@iconnet.net>
Sender: owner-ietf-ssh@clinet.fi
Precedence: bulk
Content-Length: 19205
Lines: 573

This is a multipart MIME message.

--==_Exmh_-2918312890
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

Sorry for the length.

Here is another version of the draft. Please comment before Friday
so I can submit a reasonably non-controversial version :)
before the conference deadline.

I'd like to address a few of the comments:

In message <199902231154.NAA27864@hutcs.cs.hut.fi>, =

Tero Kivinen writes:

> For example most of the case the smartcard are using the normal public
> key authentication (RSA). If there are some other kinds smartcards
> that use some other authentication methods, then it is better to
> separate them based on the authentication method (public key, one time
> password) not based on the technology (smartcard). =

> =


I disagree. [Arguably] RSA authentication using a smartcard is much
more secure then RSA using a private key stored on disk. The current
definitions do not allow for specifying that RSA must be done via
a smartcard.

I'm not saying that authentications /should/ be classified according
to technology, only that there definitely should to be a way to
"mandate" that an authentication uses a certain technology.
That said, I don't know how to FORCE a user to use a smartcard
vs. a disk-based key -- a "non-compliant" client implementation
could ignore any flag from the server saying "use x technology".

Without such a way to FORCE such compliance, a technology flag
is moot. If a publickey auth relies on intrinsic server knowledge
of the public key, it may be administratively possible to force
compliance (and a technology flag may not be /required/), but
if publickey auth is verified via a certificate, then it may
be difficult to force technology compliance.

> > 4. Authentication Example
> > =

> >    Here is an example exchange between a client and server:
> > =

> >    C:      byte    SSH_MSG_USERAUTH_REQUEST
> >    C:      string  "foo"
=2E..
> >    S:      byte    SSH_MSG_USERAUTH_SUCCESS
> =

> I think this example is bad, because it can already be performed using
> the basic userauth draft, it contains banners, it contains password
> queries, it contains password change-request,

I think this example is good, for the same reason -- it can already
be performed using the userauth draft. This shows how to accomplish
the same thing using this method. It shows the strength of the
generic info request -- no need for another type of message
(PASSWD_CHANGEREQ). I think how to do a challenge response
authentication becomes obvious from this example (which was my
other choice for an example). My third choice was an
administrative no-login situation, where the last info-request
contained zero num-prompts, and then a failure message.

> and it even contains
> advantage compared to this method, it can use users native language
> when printing out most of the prompts.

I don't follow you. This example can use the user's native language.

In message <199902231243.NAA16085@giraf.carlstedt.se>, =

Martin Forssen writes:
> =

> First the big issue. After some thinking I have reached the conclusion
> (this is all IMHO of course) that we do not need to try to define some
> generic protocol which can handle all smart-cards biometric devices

Yeah, I added that in as an afterthought. I agree it was poorly thought
out.

> I would feel more comfortable if we used the same list format as the
> sshauth draft does (ie a comma-separated string). I would like to
> propose the following format instead:
> =

> 	byte    SSH_MSG_USERAUTH_REQUEST
> 	string  username
> 	string	service
> 	string	"password-plus"
> 	string	methods
> =

> Where methods is a comma-separated strings of supported authentication
> methods using the keyboard input type.
> =

> The rationale for having the methods field is that the user may have
> multiple methods availbale (for example both SecurID and CryptoCard).
> This list should be normally be provided by the user. The server should=

> also be able to ignore this field if it knows from some other context
> which method(s) are avilable for the user.

This requires client knowledge of the auth device; and a new client
would be required for each auth device. One of the goals was to
not require new client code to support new authentications that
/could/ be handled by existing methods.

Now I agree that there might be a place for the client to tell the
server which authentication devices are available, but in the end
it is up to the server to decide which device to accept. So this
could be wrapped up in the PAM service module (it could check for
a list of users it knows have a securid card, which is how I believe
the securid hack to ssh1 works, and continue on to cryptocard for
users that don't have the securid).

So as long as the input happens with the keyboard, I think specifying
the actual device is better left in the server code. Maybe you
can provide an example where the server does need to know what devices
are available?

=3D=3D=3D=3D=3D=3D=3D
As many noticed, this draft really is meant for PAM, which is indeed
a generic keyboard-interactive authentication. I added the non-keyboard
types to attempt to deal with PAM_BINARY, but I do agree that it is
too limiting to add that into this draft. Also, PAM_BINARY is really
a kludge to make PAM do things that the original design didn't
account for.

~frank


--==_Exmh_-2918312890
Content-Type: text/plain ; name="pwplus.txt"
Content-Description: pwplus.txt
Content-Disposition: attachment; filename="pwplus.txt"
Content-Transfer-Encoding: quoted-printable







Network Working Group                                          F. Cusack
INTERNET-DRAFT                                  Qwest Internet Solutions
draft-ietf-secsh-auth-kbdinteract-00.txt                     24 Feb 1999
Expires in six months

            Generic Message Exchange Authentication For SSH

Status of this Memo

   This document is an Internet-Draft.  Internet-Drafts are working
   documents of the Internet Engineering Task Force (IETF), its areas,
   and its working groups.  Note that other groups may also distribute
   working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   To view the entire list of current Internet-Drafts, please check the
   "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
   Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern
   Europe), ftp.nic.it (Southern Europe), munnari.oz.au (Pacific Rim),
   ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast).

Abstract

   SSH is a protocol for secure remote login and other secure network
   services over an insecure network.  This document describes a general
   purpose authentication method for the SSH protocol, suitable for
   interactive authentications where the authentication data should be
   entered via a keyboard.  The major goal of this method is to allow
   the SSH client to have little or no knowledge of the underlying
   authentication mechanism(s) used by the SSH server.

















Cusack                                                  FORMFEED[Page 1]





draft-ietf-secsh-auth-kbdinteract-00.txt                     24 Feb 1999


1. Introduction

   The SSH authentication protocol is a general-purpose user
   authentication protocol. It is intended to be run over the SSH
   transport layer protocol [SSH-TRANS]. The protocol assumes that the
   underlying protocols provide integrity and confidentiality
   protection.

   This document describes a general purpose authentication method for
   the SSH protocol, suitable for interactive authentications where the
   authentication data should be entered via a keyboard.  The major goal
   of this method is to allow the SSH client to have little or no
   knowledge of the underlying authentication mechanism(s) used by the
   SSH server.  This will allow the server to arbitrarily select or
   change the underlying authentication mechanism(s) without having to
   update client code.

   The method name for this authentication method is "keyboard-
   interactive".

   This document should be read only after reading the SSH architecture
   document [SSH-ARCH] and the SSH authentication document [SSH-
   USERAUTH].  This document freely uses terminology and notation from
   both documents without reference or further explanation.

   This document also describes some of the client interaction with the
   user in obtaining the authentication information.  While this is
   somewhat out of the scope of a protocol specification, it is still
   described here since some aspects of the protocol are specifically
   designed based on user interface issues, and omitting this
   information may lead to incompatible or awkward implementations.

2. Rationale

   Currently defined authentication methods for SSH are tightly coupled
   with the underlying authentication mechanism.  This makes it
   difficult to add new mechanisms for authentication as all clients
   must be updated to support the new mechanism.  With the generic
   method defined here, clients will not require code changes to support
   new authentication mechanisms, and if a separate authentication layer
   is used, such as [PAM], then the server may not need any code changes
   either.

   This presents a significant advantage to other methods, such as the
   "password" method (defined in [SSH-USERAUTH]), as new (presumably
   stronger) methods may be added "at will" and system security can be
   transparently enhanced.




Cusack                                                  FORMFEED[Page 2]





draft-ietf-secsh-auth-kbdinteract-00.txt                     24 Feb 1999


   Challenge-response and One Time Password mechanisms are also easily
   supported with this authentication method.

3. Protocol Exchanges

   The client initiates the authentication with a
   SSH_MSG_USERAUTH_REQUEST message.  The server then requests
   authentication information from the client with a
   SSH_MSG_USERAUTH_INFO_REQUEST message.  The client obtains the
   information from the user and then responds with a
   SSM_MSG_USERAUTH_INFO_RESPONSE message.

3.1 Initial Exchange

   The authentication starts with the client sending the following
   packet:

      byte    SSH_MSG_USERAUTH_REQUEST
      string  username
      string  service
      string  "keyboard-interactive"

   Note that when this message is sent to the server, the client has not
   yet prompted the user for a password, and so that information is NOT
   included with this initial message (unlike the "password" method).

   The server MUST reply with either a SSH_MSG_USERAUTH_SUCCESS,
   SSH_MSG_USERAUTH_FAILURE, or SSH_MSG_USERAUTH_INFO_REQUEST message.

   The server SHOULD NOT reply with the SSH_MSG_USERAUTH_FAILURE message
   if the failure is based on the username or service; instead it SHOULD
   send a SSH_MSG_USERAUTH_INFO_REQUEST message requesting a password,
   and then send the failure message (after a suitable delay, as
   described below).  This is to help limit certain types of attacks.

3.2 Information Requests

   Requests are generated from the server using the
   SSH_MSG_USERAUTH_INFO_REQUEST message.

   The server may send as many requests as are necessary to authenticate
   the client; the client MUST be prepared to handle multiple exchanges.

   The SSH_MSG_USERAUTH_INFO_REQUEST message is defined as follows:







Cusack                                                  FORMFEED[Page 3]





draft-ietf-secsh-auth-kbdinteract-00.txt                     24 Feb 1999


      byte    SSH_MSG_USERAUTH_INFO_REQUEST
      string  name (ISO-10646 UTF-8)
      string  instruction (ISO-10646 UTF-8)
      int     num-prompts
      string  prompt[1] (ISO-10646 UTF-8)
      boolean echo[1]
      ...
      string  prompt[num-prompts] (ISO-10646 UTF-8)
      boolean echo[num-prompts]
      string  language tag (as defined in [RFC-1766])

   The server SHOULD limit the length of the name and prompt fields to
   30 characters.  No restrictions are placed on the instruction field.

   The name and instruction fields MAY be empty strings, the client MUST
   be prepared to handle this correctly.

   The num-prompts field may be `0', in which case there will be no
   prompt/echo fields in the message, but the client MUST still display
   the name and instruction fields (as described below).

3.3 User Interface

   Upon receiving a request message, the client SHOULD prompt the user
   as follows:

   For each prompt, the corresponding echo field indicates whether or
   not the user input should be echoed as characters are typed.  Clients
   MUST correctly echo/mask user input for each prompt independently of
   other prompts in the request message.  Clients MUST NOT add any
   additional characters to the prompt such as ": "; the server is
   reponsible for supplying all text to be displayed to the user.
   Clients MUST also accept empty responses from the user and pass them
   on as empty strings.

   A CLI client SHOULD print the name and instruction (if supplied),
   adding newlines. Then for each prompt in turn, the client MUST
   display the prompt and read the user input.

   A GUI client SHOULD present a dialog window, using the name (if
   supplied) as the title of the window, the instruction (if supplied)
   as a text message inside the dialog, and the appropriate number of
   entry fields with the prompts as labels.  A GUI client SHOULD NOT
   present each prompt in a separate window.  A GUI client MUST properly
   handle an instruction with embedded newlines.  A GUI client MUST also
   be able to display at least 30 characters for the name and prompts.
   If the server presents names/prompts longer than 30 characters, the
   client MAY truncate these fields to the length it can display.  If



Cusack                                                  FORMFEED[Page 4]





draft-ietf-secsh-auth-kbdinteract-00.txt                     24 Feb 1999


   the client does truncate any fields, there SHOULD be an obvious
   indication that such truncation has occured.

3.4 Information Responses

   After obtaining the requested information from the user, the client
   MUST respond with a SSH_MSG_USERAUTH_INFO_RESPONSE message.

   The format of the SSH_MSG_USERAUTH_INFO_RESPONSE message is as
   follows:

      byte    SSH_MSG_USERAUTH_INFO_RESPONSE
      int     num-responses
      string  response[1] (ISO-10646 UTF-8)
      ...
      string  response[num-responses] (ISO-10646 UTF-8)

   Note that the responses are encoded in ISO-10646 UTF-8.  It is up to
   the server how it interprets the responses and validates them.
   However, if the client reads the responses in some other encoding
   (e.g., ISO 8859-1), it MUST convert the responses to ISO-10646 UTF-8
   before transmitting, and the server MUST convert the responses to the
   encoding used on that system that is needed to verify them.

   In the case that the server sends a `0' num-prompts field in the
   request message, the client MUST send a response message with a `0'
   num-responses field.

   After receiving the response, the server MUST send either a
   SSH_MSG_USERAUTH_SUCCESS, SSH_MSG_USERAUTH_FAILURE, or another
   SSH_MSG_USERAUTH_INFO_REQUEST message.

   If the server fails to authenticate the user (through the underlying
   authentication mechanism(s)), it SHOULD NOT send another request
   message(s) in an attempt to obtain new authentication data, instead
   it SHOULD send a failure message.  The only time the server should
   send multiple request messages is if additional authentication data
   is needed (i.e., because there are multiple underlying authentication
   mechanisms that must be used to authenticate the user).

   If the num-responses field does not match the num-prompts field in
   the request message, the server MUST send a failure message.

   If the server responds with a failure message, it SHOULD delay a
   minimum of 2 seconds before sending the failure message, to limit
   certain types of attacks.

4. Authentication Example



Cusack                                                  FORMFEED[Page 5]





draft-ietf-secsh-auth-kbdinteract-00.txt                     24 Feb 1999


   Here is an example exchange between a client and server:

      C:      byte    SSH_MSG_USERAUTH_REQUEST
      C:      string  "foo"
      C:      string  "ssh-connection"
      C:      string  "keyboard-interactive"

      S:      byte    SSH_MSG_USERAUTH_INFO_REQUEST
      S:      string  "Password Authentication"
      S:      string  "Enter password for foo"
      S:      int     1
      S:      string  "Password: "
      S:      boolean FALSE
      S:      string  "en-US"

      [Client prompts user for password]

      C:      byte    SSH_MSG_USERAUTH_INFO_RESPONSE
      C:      int     1
      C:      string  "bar"

      S:      byte    SSH_MSG_USERAUTH_INFO_REQUEST
      S:      string  "Password Expired"
      S:      string  "Your password has expired."
      S:      int     2
      S:      string  "Enter new password: "
      S:      boolean FALSE
      S:      string  "Enter it again: "
      S:      boolean FALSE
      S:      string  "en-US"

      [Client prompts user for new password]

      C:      byte    SSH_MSG_USERAUTH_INFO_RESPONSE
      C:      int     2
      C:      string  "baz"
      C:      string  "baz"

      S:      byte    SSH_MSG_USERAUTH_SUCCESS

5. Protocol constants

   The following method-specific constants are used with this
   authentication method:

   SSH_MSG_USERAUTH_INFO_REQUEST           60
   SSH_MSG_USERAUTH_INFO_RESPONSE          61




Cusack                                                  FORMFEED[Page 6]





draft-ietf-secsh-auth-kbdinteract-00.txt                     24 Feb 1999


6. References

   [PAM] Samar, V., Schemers, R., "Unified Login With Pluggable
   Authentication Modules (PAM)", OSF RFC 86.0, October 1995

   [RFC-1766] Alvestrand, H., "Tags for the Identification of
   Languages", March 1995.

   [RFC-2044] Yergeau, F., "UTF-8, a Transformation Format of Unicode
   and ISO 10646", October 1996.

   [SSH-ARCH] Ylonen, T., Kivinen, T, and Saarinen, M., "SSH Protocol
   Architecture", Internet Draft, draft-ietf-secsh-architecture-00.txt

   [SSH-CONNECT] Ylonen, T., Kivinen, T, and Saarinen, M., "SSH
   Connection Protocol", Internet Draft, draft-ietf-secsh-connect-02.txt

   [SSH-TRANS] Ylonen, T., Kivinen, T, and Saarinen, M., "SSH Transport
   Layer Protocol", Internet Draft, draft-ietf-secsh-transport-02.txt

   [SSH-USERAUTH] Ylonen, T., Kivinen, T, and Saarinen, M., "SSH
   Authentication Protocol", Internet Draft, draft-ietf-secsh-userauth-
   02.txt

7. Author's Address

   Frank Cusack
   Qwest Internet Solutions
   1200 Harbor Blvd, 8th Fl.
   Weehawken, NJ 07087
   Email: fcusack@iconnet.net




















Cusack                                                  FORMFEED[Page 7]




--==_Exmh_-2918312890--


From owner-ietf-ssh@clinet.fi  Thu Feb 25 03:05:08 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 DAA19375;
	Thu, 25 Feb 1999 03:05:08 +0200 (EET)
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 DAA19160;
	Thu, 25 Feb 1999 03:05:08 +0200 (EET)
Received: (from majordom@localhost)
	by lohi.clinet.fi (8.9.1/8.9.0) id DAA03368
	for ietf-ssh-outgoing; Thu, 25 Feb 1999 03:06:14 +0200 (EET)
X-Authentication-Warning: lohi.clinet.fi: majordom set sender to owner-ietf-ssh@clinet.fi using -f
Received: from ratbert.iconnet.net (ratbert.iconnet.net [209.3.247.87])
	by lohi.clinet.fi (8.9.1/8.9.0) with ESMTP id DAA03360;
	Thu, 25 Feb 1999 03:06:12 +0200 (EET)
Received: from iconnet.net (localhost [127.0.0.1])
	by ratbert.iconnet.net (8.9.2/8.9.1) with ESMTP id UAA20319;
	Wed, 24 Feb 1999 20:05:15 -0500 (EST)
Message-Id: <199902250105.UAA20319@ratbert.iconnet.net>
X-Mailer: exmh version 2.0.2 2/24/98
To: ssh@clinet.fi, ietf-ssh@clinet.fi
Cc: psst@net.lut.ac.uk
Subject: Re: Generic challenge-repsonse aunetication in ssh2 
In-reply-to: Your message of "Wed, 24 Feb 1999 19:44:02 EST."
             <199902250044.TAA20240@ratbert.iconnet.net> 
Date: Wed, 24 Feb 1999 20:05:15 -0500
From: Frank Cusack <fcusack@iconnet.net>
Sender: owner-ietf-ssh@clinet.fi
Precedence: bulk
Content-Length: 1003
Lines: 24

In message <199902250044.TAA20240@ratbert.iconnet.net>, 
Frank Cusack writes:
> 
> I'm not saying that authentications /should/ be classified according
> to technology, only that there definitely should to be a way to
> "mandate" that an authentication uses a certain technology.
> That said, I don't know how to FORCE a user to use a smartcard
> vs. a disk-based key -- a "non-compliant" client implementation
> could ignore any flag from the server saying "use x technology".
> 
> Without such a way to FORCE such compliance, a technology flag
> is moot. If a publickey auth relies on intrinsic server knowledge
> of the public key, it may be administratively possible to force
> compliance (and a technology flag may not be /required/), but

but would be useful to tell a compliant client which device to use,
disk or smartcard, since multiple devices may (will) be available.

> if publickey auth is verified via a certificate, then it may
> be difficult to force technology compliance.
> 

~frank

From owner-ietf-ssh@clinet.fi  Thu Feb 25 08:45:00 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 IAA20944;
	Thu, 25 Feb 1999 08:45:00 +0200 (EET)
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 IAA22741;
	Thu, 25 Feb 1999 08:44:59 +0200 (EET)
Received: (from majordom@localhost)
	by lohi.clinet.fi (8.9.1/8.9.0) id IAA01511
	for ietf-ssh-outgoing; Thu, 25 Feb 1999 08:44:48 +0200 (EET)
Received: from nic.carlstedt.se (nic.carlstedt.se [193.12.107.10])
	by lohi.clinet.fi (8.9.1/8.9.0) with ESMTP id IAA01504;
	Thu, 25 Feb 1999 08:44:45 +0200 (EET)
Received: from giraf.carlstedt.se (root@giraf.carlstedt.se [172.16.1.10])
	by nic.carlstedt.se (8.9.3/8.9.3) with ESMTP id HAA21310;
	Thu, 25 Feb 1999 07:41:31 +0100 (MET)
Received: from spitfire.carlstedt.se (maf@spitfire.carlstedt.se [172.16.1.70])
	by giraf.carlstedt.se (8.9.3/8.9.3) with ESMTP id HAA26682;
	Thu, 25 Feb 1999 07:41:29 +0100 (MET)
Received: from localhost (maf@localhost)
	by spitfire.carlstedt.se (8.9.1/8.9.1) with ESMTP id HAA27954;
	Thu, 25 Feb 1999 07:41:28 +0100 (MET)
X-Authentication-Warning: spitfire.carlstedt.se: maf owned process doing -bs
Date: Thu, 25 Feb 1999 07:41:27 +0100 (MET)
From: Martin Forssen <maf@firedoor.se>
X-Sender: maf@spitfire.carlstedt.se
To: Frank Cusack <fcusack@iconnet.net>
cc: ssh@clinet.fi, ietf-ssh@clinet.fi, psst@net.lut.ac.uk
Subject: Re: Generic challenge-repsonse aunetication in ssh2
In-Reply-To: <199902250044.TAA20240@ratbert.iconnet.net>
Message-ID: <Pine.GSO.4.10.9902250718100.27862-100000@spitfire.carlstedt.se>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ietf-ssh@clinet.fi
Precedence: bulk
Content-Length: 2723
Lines: 64

On Wed, 24 Feb 1999, Frank Cusack wrote:
> Here is another version of the draft. Please comment before Friday
> so I can submit a reasonably non-controversial version :)
> before the conference deadline.

That is a noble goal:-)

The main problem here is that we are trying to merge two different
philosofies (sp?) for doing user authentication.

> In message <199902231243.NAA16085@giraf.carlstedt.se>, 
> Martin Forssen writes:
> > I would feel more comfortable if we used the same list format as the
> > sshauth draft does (ie a comma-separated string). I would like to
> > propose the following format instead:
> > 
> > 	byte    SSH_MSG_USERAUTH_REQUEST
> > 	string  username
> > 	string	service
> > 	string	"password-plus"
> > 	string	methods
> > 
> > Where methods is a comma-separated strings of supported authentication
> > methods using the keyboard input type.
> > 
> > The rationale for having the methods field is that the user may have
> > multiple methods availbale (for example both SecurID and CryptoCard).
> > This list should be normally be provided by the user. The server should
> > also be able to ignore this field if it knows from some other context
> > which method(s) are avilable for the user.
> 
> This requires client knowledge of the auth device; and a new client
> would be required for each auth device. One of the goals was to
> not require new client code to support new authentications that
> /could/ be handled by existing methods.

No, read my text again. I meant the list of methods to be supplied by the
user. For example by setting some option to a list of devices he/she has.
The list is also only advisory to the server. I fully agree with the goal
of not having to update the client to support new methods (as long as they
are text-based) and my proposal was carefully though out to allow just
that.

> So as long as the input happens with the keyboard, I think specifying
> the actual device is better left in the server code. Maybe you
> can provide an example where the server does need to know what devices
> are available?

Well the user might have both but left one of them at the office? But the
point is that my change gives the server the choice of either letting the
client specify method or to just override the client. A PAM-driven server
might just ignore this field.

Therefore I think my proposal is more flexible since it allows for
different server implementations to do it differently. It allows for both 
philosofies to be implemented in the server.


Apart from this I have no major issues with your draft. I have a couple of
small comments which will appear in a later message (after I reach the
office despite all the bussdrivers being on strike:-().

	/MaF

From owner-ietf-ssh@clinet.fi  Thu Feb 25 13:45:25 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 NAA26729;
	Thu, 25 Feb 1999 13:45:25 +0200 (EET)
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 NAA25344;
	Thu, 25 Feb 1999 13:45:24 +0200 (EET)
Received: (from majordom@localhost)
	by lohi.clinet.fi (8.9.1/8.9.0) id NAA29732
	for ietf-ssh-outgoing; Thu, 25 Feb 1999 13:43:04 +0200 (EET)
X-Authentication-Warning: lohi.clinet.fi: majordom set sender to owner-ietf-ssh@clinet.fi using -f
Received: from hutcs.cs.hut.fi (kivinen@hutcs.cs.hut.fi [130.233.192.7])
	by lohi.clinet.fi (8.9.1/8.9.0) with ESMTP id JAA10562;
	Thu, 25 Feb 1999 09:43:29 +0200 (EET)
Received: (from kivinen@localhost) by hutcs.cs.hut.fi (8.8.8/8.8.8) id JAA00690; Thu, 25 Feb 1999 09:40:13 +0200 (EET)
Date: Thu, 25 Feb 1999 09:40:13 +0200 (EET)
Message-Id: <199902250740.JAA00690@hutcs.cs.hut.fi>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
From: Tero Kivinen <kivinen@iki.fi>
To: Frank Cusack <fcusack@iconnet.net>
Cc: ssh@clinet.fi, ietf-ssh@clinet.fi, psst@net.lut.ac.uk
Subject: Re: Generic challenge-repsonse aunetication in ssh2
In-Reply-To: <199902250044.TAA20240@ratbert.iconnet.net>
References: <199902250044.TAA20240@ratbert.iconnet.net>
X-Mailer: VM 6.33 under Emacs 19.34.1
Organization: Helsinki University of Technology
X-Edit-Time: 13 min
X-Total-Time: 12 min
Sender: owner-ietf-ssh@clinet.fi
Precedence: bulk
Content-Length: 2265
Lines: 45

Frank Cusack writes:
> I disagree. [Arguably] RSA authentication using a smartcard is much
> more secure then RSA using a private key stored on disk. The current
> definitions do not allow for specifying that RSA must be done via
> a smartcard.

Yes it can. If the adminstrator only allows putting public keys of
such keys that are on the smartcard to authorized_keys files, then he
can limit that only rsa authentication can only use smartcard.

BTW. There is no real difference compared to the RSA private key on
the disk and in smartcard. The authentication is same, only thing that
differs is how easy it is to stole the private key. Note that when you
are using smartcards the pin/passphrase is propably much much more
easier than what you use for the key that is on the disk, so getting
the pin by looking over persons shoulder is much easier. 

> I'm not saying that authentications /should/ be classified according
> to technology, only that there definitely should to be a way to
> "mandate" that an authentication uses a certain technology.
> That said, I don't know how to FORCE a user to use a smartcard
> vs. a disk-based key -- a "non-compliant" client implementation
> could ignore any flag from the server saying "use x technology".

There is no way you can do that anyways. The user can write his own
client that can fake to do a smartcard authentication when it is doing
normal disk based private key authentication. I dont see any use for
that kind of false security. 

> > and it even contains
> > advantage compared to this method, it can use users native language
> > when printing out most of the prompts.
> I don't follow you. This example can use the user's native language.

How? The server doesn't know how to speak Finnish. My client does know
that. If we use the built-in messages without embedded strings then
the client can print out dialogs in Finnish, but if the server sends
me a message saying that "Change your password", my client doesn't
know what the server is asking, and cannot translate it to "Vaihda
salasanasi". 
-- 
kivinen@iki.fi                               Work : +358-9-4354 3218
SSH Communications Security                  http://www.ssh.fi/
SSH IPSEC Toolkit                            http://www.ssh.fi/ipsec/

From owner-ietf-ssh@clinet.fi  Thu Feb 25 10:23:12 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 KAA21074;
	Thu, 25 Feb 1999 10:23:12 +0200 (EET)
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 KAA23400;
	Thu, 25 Feb 1999 10:23:11 +0200 (EET)
Received: (from majordom@localhost)
	by lohi.clinet.fi (8.9.1/8.9.0) id KAA21362
	for ietf-ssh-outgoing; Thu, 25 Feb 1999 10:21:38 +0200 (EET)
Received: from monet.math.chalmers.se (monet.math.chalmers.se [129.16.167.74])
	by lohi.clinet.fi (8.9.1/8.9.0) with ESMTP id KAA20276;
	Thu, 25 Feb 1999 10:15:16 +0200 (EET)
Received: from morisot.math.chalmers.se (morisot.math.chalmers.se [129.16.167.91])
	by monet.math.chalmers.se (8.8.5/8.8.5) with ESMTP id JAA06517;
	Thu, 25 Feb 1999 09:12:01 +0100 (MET)
Received: from localhost (pin@localhost)
	by morisot.math.chalmers.se (8.8.5/8.8.5) with SMTP id JAA12917;
	Thu, 25 Feb 1999 09:12:00 +0100 (MET)
X-Authentication-Warning: morisot.math.chalmers.se: pin owned process doing -bs
Date: Thu, 25 Feb 1999 09:11:59 +0100 (MET)
From: Ivan Popov <pin@math.chalmers.se>
To: Frank Cusack <fcusack@iconnet.net>
cc: ssh@clinet.fi, ietf-ssh@clinet.fi, psst@net.lut.ac.uk
Subject: Re: Generic challenge-repsonse aunetication in ssh2
In-Reply-To: <199902250044.TAA20240@ratbert.iconnet.net>
Message-ID: <Pine.GSO.4.02A.9902250822310.12003-100000@morisot.math.chalmers.se>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ietf-ssh@clinet.fi
Precedence: bulk
Content-Length: 2524
Lines: 56

Well, I regard the draft as only a half-step forward as this
functionality might be embraced by more generic authentication method,
providing for interaction between server and client authentication
*modules*. Interactive authentication being just one - or several - of the
unlimited set of modules.

The lack of stable pam specification for client side does not prevent us
from implementing "built-in" modules.

[Ssh in fact went this way - but without providing for modular
extendability. The result was separate "ssh*config" files to administer,
providing partially for the same functionality as pam.conf]

On Wed, 24 Feb 1999, Frank Cusack wrote:

> > multiple methods availbale (for example both SecurID and CryptoCard).
> > This list should be normally be provided by the user. The server should
> > also be able to ignore this field if it knows from some other context
> > which method(s) are avilable for the user.
> 
> This requires client knowledge of the auth device; and a new client
> would be required for each auth device. One of the goals was to
> not require new client code to support new authentications that
> /could/ be handled by existing methods.

>From my point of view the main reason for defining the new
authentication type is a possibility to plug-in authentication modules on
both servers and clients. PAM (needing extention, of course) provides por
pluggability and ssh provides for communication.

As I'd like to see it (in the ideal world), *all* authentication methods,
including all sorts of public key authentication, should reside out of ssh
code, ssh being responsible for the rest (encrypted connection and traffic
forwarding).

> As many noticed, this draft really is meant for PAM, which is indeed
> a generic keyboard-interactive authentication. I added the non-keyboard
> types to attempt to deal with PAM_BINARY, but I do agree that it is
> too limiting to add that into this draft. Also, PAM_BINARY is really
> a kludge to make PAM do things that the original design didn't
> account for.

I think Andrew Morgan talked about client-side PAM module specification
that is not yet finished. Isn't it the time to discuss it in more
details?

Looks like both ssh and pam specifications are missing important parts to
be able to adequately support wide range of connectivity/authentication
needs. They should become aware of each others concepts. The sooner the
better.

Regards,
--
Ivan Popov <pin@math.chalmers.se>
Systemman, Driftavdelningen, Matematiska institutionen, Chalmers TH

From owner-ietf-ssh@clinet.fi  Thu Feb 25 10:40:13 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 KAA12366;
	Thu, 25 Feb 1999 10:40:13 +0200 (EET)
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 KAA23503;
	Thu, 25 Feb 1999 10:40:13 +0200 (EET)
Received: (from majordom@localhost)
	by lohi.clinet.fi (8.9.1/8.9.0) id KAA24892
	for ietf-ssh-outgoing; Thu, 25 Feb 1999 10:38:40 +0200 (EET)
Received: from monet.math.chalmers.se (monet.math.chalmers.se [129.16.167.74])
	by lohi.clinet.fi (8.9.1/8.9.0) with ESMTP id KAA23616;
	Thu, 25 Feb 1999 10:32:19 +0200 (EET)
Received: from morisot.math.chalmers.se (morisot.math.chalmers.se [129.16.167.91])
	by monet.math.chalmers.se (8.8.5/8.8.5) with ESMTP id JAA09797;
	Thu, 25 Feb 1999 09:29:04 +0100 (MET)
Received: from localhost (pin@localhost)
	by morisot.math.chalmers.se (8.8.5/8.8.5) with SMTP id JAA13143;
	Thu, 25 Feb 1999 09:29:03 +0100 (MET)
X-Authentication-Warning: morisot.math.chalmers.se: pin owned process doing -bs
Date: Thu, 25 Feb 1999 09:29:02 +0100 (MET)
From: Ivan Popov <pin@math.chalmers.se>
To: Tero Kivinen <kivinen@iki.fi>
cc: Frank Cusack <fcusack@iconnet.net>, ssh@clinet.fi, ietf-ssh@clinet.fi,
        psst@net.lut.ac.uk
Subject: Re: Generic challenge-repsonse aunetication in ssh2
In-Reply-To: <199902250740.JAA00690@hutcs.cs.hut.fi>
Message-ID: <Pine.GSO.4.02A.9902250913520.12003-100000@morisot.math.chalmers.se>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ietf-ssh@clinet.fi
Precedence: bulk
Content-Length: 768
Lines: 19

On Thu, 25 Feb 1999, Tero Kivinen wrote:

> How? The server doesn't know how to speak Finnish. My client does know
> that. If we use the built-in messages without embedded strings then
> the client can print out dialogs in Finnish, but if the server sends
> me a message saying that "Change your password", my client doesn't
> know what the server is asking, and cannot translate it to "Vaihda
> salasanasi". 

Following that reasoning there will be no separate "interactive" protocol.
All messages have to be binary and be predefined in the protocol.
Is would be a bit hard to modify or extend - you must go through protocol
redefinition procedure...

Regards,
--
Ivan Popov <pin@math.chalmers.se>
Systemman, Driftavdelningen, Matematiska institutionen, Chalmers TH

From owner-ietf-ssh@clinet.fi  Thu Feb 25 11:32: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 LAA25175;
	Thu, 25 Feb 1999 11:32:38 +0200 (EET)
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 LAA24180;
	Thu, 25 Feb 1999 11:32:38 +0200 (EET)
Received: (from majordom@localhost)
	by lohi.clinet.fi (8.9.1/8.9.0) id LAA05649
	for ietf-ssh-outgoing; Thu, 25 Feb 1999 11:30:50 +0200 (EET)
X-Authentication-Warning: lohi.clinet.fi: majordom set sender to owner-ietf-ssh@clinet.fi using -f
Received: from mail1.oz.is (mail1.oz.is [193.4.211.180])
	by lohi.clinet.fi (8.9.1/8.9.0) with ESMTP id LAA05630
	for <ietf-ssh@clinet.fi>; Thu, 25 Feb 1999 11:30:45 +0200 (EET)
Received: from undo.com (scarecrow.oz.is [193.4.211.95])
	by mail1.oz.is (8.8.7/8.8.7) with ESMTP id JAA08693
	for <ietf-ssh@clinet.fi>; Thu, 25 Feb 1999 09:31:20 GMT
Message-ID: <36D517A1.6783EDC0@undo.com>
Date: Thu, 25 Feb 1999 09:28:01 +0000
From: Sigurdur Asgeirsson <siggi@undo.com>
X-Mailer: Mozilla 4.5 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: ietf-ssh@clinet.fi
Subject: Re: I-D ACTION:draft-ietf-secsh-architecture-03.txt
References: <199902242324.SAA28959@ietf.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-ssh@clinet.fi
Precedence: bulk
Content-Length: 4023
Lines: 86

Internet-Drafts@ietf.org wrote:
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Secure Shell Working Group of the IETF.
> 
>         Title           : SSH Protocol Architecture
>         Author(s)       : T. Ylonen, T. Kivinen, M. Saarinen, T. Rinne, S. Lehtinen
>         Filename        : draft-ietf-secsh-architecture-03.txt
>         Pages           : 11
>         Date            : 22-Feb-99
> 
> SSH is a protocol for secure remote login and other secure network ser-
> vices over an insecure network. This document describes the architecture
> of the SSH protocol, and the notation and terminology used in SSH proto-
[snip]

  After a cursory look at the new transport spec, it seems that of the
three changes I've suggested, the two that are meant to clarify/correct
the spec have been entirely disregarded for no apparent reason, while
the third (dss signature format) has been changed in the opposite
direction from what I suggested.
  This does cast some doubt on how effective it is to make comments on
the SSH spec in this venue and whether the authors actually pay any heed
to suggestions from the list.
  Never the less, here is a resubmission of the first two comments, and
a new comment on the DSS signature format:

---
  1. Section 5, "Key Exchange" contains the following text:

"Each side MAY guess which algorithm the other side is using,
and MAY send an initial key exchange packet according to the algorithm
if appropriate for the preferred method.  If all algorithms were guessed
right, the optimistically sent packet MUST be handled as the first key
exchange packet.  However, if the guess was wrong, and a packet was
optimistically sent by one or both parties, such packets MUST be ignored
(even if the error in the guess would not affect the contents of the
initial packet(s)), and the appropriate side MUST send the correct
initial packet."

  The bit that goes "If all algorithms were guessed right" is what I
have trouble with. It seem to me that only the key exchange algorithm
and the server host key algorithm affect the key exchange, and the ssh
reference implementation indeed makes and verifies a guess based on
those two only. It is my suggestion that the paragraph above be modified
to this:

"Each side MAY guess which key exchange algorithm and server key
algorithm the other side is using, and MAY send an initial key exchange
packet according to the guessed algorithms if appropriate.  If both
algorithms were guessed right, the optimistically sent packet MUST be
handled as the first key exchange packet.  However, if the guess was
wrong, and a packet was optimistically sent by one or both parties, such
packets MUST be ignored (even if the error in the guess would not affect
the contents of the initial packet(s)), and the appropriate side MUST
send the correct initial packet."

---
  2. Section 5.2, "Output from Key Exchange" contains the following
text:

"The key exchange produces two values: a shared secret K, and an
exchange hash H."

  Section 6, "Diffie-Hellman Key Exchange" then goes to great lengths to
specify excactly how the exchange hash "H" is computed, but fails to
specify the format of "K", which is used in key derivation.
  I suggest that section 6 specify that the binary format of K, the
shared secret, be mpint (as in the ssh reference implementation).

---
  3. Section 4.6, "Public Key Algorithms" contains this text:

The resulting signature is encoded as:

  uint32    length
  string    "ssh-dss"
  string    dss_signature_blob

The problem with this is that there is apparently no formal standard for
the binary format of a DSA signature, and the "string
dss_signature_blob" is therefore not an unambiguous description. There
exists a de-facto (BOB?) format which is what is in fact used in the ssh
reference implementation. This format should IMO be documented in the
draft, or the draft contain a reference to another document which
details the format of the signature.
From owner-ietf-ssh@clinet.fi  Thu Feb 25 12:25:17 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 MAA26189;
	Thu, 25 Feb 1999 12:25:17 +0200 (EET)
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 MAA24658;
	Thu, 25 Feb 1999 12:25:17 +0200 (EET)
Received: (from majordom@localhost)
	by lohi.clinet.fi (8.9.1/8.9.0) id MAA15473
	for ietf-ssh-outgoing; Thu, 25 Feb 1999 12:23:48 +0200 (EET)
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 MAA15461;
	Thu, 25 Feb 1999 12:23:44 +0200 (EET)
Received: from sanna.lysator.liu.se (nisse@sanna.lysator.liu.se [130.236.254.206])
	by samantha.lysator.liu.se (8.8.7/8.8.7) with ESMTP id LAA12143;
	Thu, 25 Feb 1999 11:20:29 +0100 (MET)
Received: (from nisse@localhost)
	by sanna.lysator.liu.se (8.8.8/8.8.7) id LAA29908;
	Thu, 25 Feb 1999 11:20:19 +0100 (MET)
To: Frank Cusack <fcusack@iconnet.net>
Cc: ssh@clinet.fi, ietf-ssh@clinet.fi, psst@net.lut.ac.uk
Subject: Re: Generic challenge-repsonse aunetication in ssh2
References: <199902250044.TAA20240@ratbert.iconnet.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
From: nisse@lysator.liu.se (Niels =?ISO-8859-1?Q?M=F6ller?=)
Date: 25 Feb 1999 11:20:18 +0100
In-Reply-To: Frank Cusack's message of "Wed, 24 Feb 1999 19:44:02 -0500"
Message-ID: <nng17u7pjx.fsf@sanna.lysator.liu.se>
X-Mailer: Gnus v5.4.59/Emacs 19.34
Sender: owner-ietf-ssh@clinet.fi
Precedence: bulk
Content-Length: 3390
Lines: 76

Frank Cusack <fcusack@iconnet.net> writes:

> Tero Kivinen writes:
> 
> > For example most of the case the smartcard are using the normal public
> > key authentication (RSA). If there are some other kinds smartcards
> > that use some other authentication methods, then it is better to
> > separate them based on the authentication method (public key, one time
> > password) not based on the technology (smartcard). 
> > 
> 
> I disagree. [Arguably] RSA authentication using a smartcard is much
> more secure then RSA using a private key stored on disk. The current
> definitions do not allow for specifying that RSA must be done via
> a smartcard.
> 
> I'm not saying that authentications /should/ be classified according
> to technology, only that there definitely should to be a way to
> "mandate" that an authentication uses a certain technology.
> That said, I don't know how to FORCE a user to use a smartcard
> vs. a disk-based key -- a "non-compliant" client implementation
> could ignore any flag from the server saying "use x technology".

You can't base any security on the assumption that clients will be
"compliant".

If you want to mandate use of a physical smartcard, the way to go is
to make sure that the private key is known to the smartcard, but *not*
to the user. I.e., you need a tamperproof smartcard. (Whether or not
tamper-proof devices exists in reality, I don't know).

> Martin Forssen writes:
>
> > I would feel more comfortable if we used the same list format as the
> > sshauth draft does (ie a comma-separated string). I would like to
> > propose the following format instead:
> > 
> > 	byte    SSH_MSG_USERAUTH_REQUEST
> > 	string  username
> > 	string	service
> > 	string	"password-plus"
> > 	string	methods
> > 
> > Where methods is a comma-separated strings of supported authentication
> > methods using the keyboard input type.
> > 
> > The rationale for having the methods field is that the user may have
> > multiple methods availbale (for example both SecurID and CryptoCard).
> > This list should be normally be provided by the user. The server should
> > also be able to ignore this field if it knows from some other context
> > which method(s) are avilable for the user.
> 
> This requires client knowledge of the auth device; and a new client
> would be required for each auth device. One of the goals was to
> not require new client code to support new authentications that
> /could/ be handled by existing methods.

As far as I can tell, having the client list available device types
does *not* require the client to know anything (or be recompiled,
whatever) just because you obtain a new type of device. All that's
needed is a line "Keybord-interactive-devices foo,bar" in the user's
.ssh/config file. 

> As many noticed, this draft really is meant for PAM, which is indeed
> a generic keyboard-interactive authentication. I added the non-keyboard
> types to attempt to deal with PAM_BINARY, but I do agree that it is
> too limiting to add that into this draft. Also, PAM_BINARY is really
> a kludge to make PAM do things that the original design didn't
> account for.

As I read the PAM spec, one of the primary design goals of PAM is to
support sophisticated authentication methods (for instance smartcards
using public key cryptography). But I have too little experience with PAM
to say whether it has failed meet this goal or not.

/Niels
From owner-ietf-ssh@clinet.fi  Thu Feb 25 17:03:00 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 RAA31977;
	Thu, 25 Feb 1999 17:03:00 +0200 (EET)
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 RAA28048;
	Thu, 25 Feb 1999 17:02:59 +0200 (EET)
Received: (from majordom@localhost)
	by lohi.clinet.fi (8.9.1/8.9.0) id RAA03593
	for ietf-ssh-outgoing; Thu, 25 Feb 1999 17:02:56 +0200 (EET)
X-Authentication-Warning: lohi.clinet.fi: majordom set sender to owner-ietf-ssh@clinet.fi using -f
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by lohi.clinet.fi (8.9.1/8.9.0) with SMTP id RAA03576;
	Thu, 25 Feb 1999 17:02:52 +0200 (EET)
Received: from sunmail1.Sun.COM ([129.145.1.2]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id GAA10473; Thu, 25 Feb 1999 06:58:00 -0800
Received: from jurassic.eng.sun.com by sunmail1.Sun.COM (SMI-8.6/SMI-4.1)
	id GAA14890; Thu, 25 Feb 1999 06:57:58 -0800
Received: from teal (awe171-147.AWE.Sun.COM [192.29.171.147])
	by jurassic.eng.sun.com (8.9.3+Sun/8.9.3) with SMTP id GAA00855;
	Thu, 25 Feb 1999 06:57:52 -0800 (PST)
Date: Thu, 25 Feb 1999 06:58:24 -0800 (PST)
From: Mike Eisler <mre@Eng.Sun.COM>
Reply-To: Mike Eisler <mre@Eng.Sun.COM>
Subject: Re: Generic challenge-repsonse aunetication in ssh2
To: Tero Kivinen <kivinen@iki.fi>
Cc: =?iso-8859-1?Q?Niels_M=F6ller?= <nisse@lysator.liu.se>,
        Frank Cusack <fcusack@iconnet.net>, ssh@clinet.fi, ietf-ssh@clinet.fi,
        psst@net.lut.ac.uk
In-Reply-To: "Your message with ID" <199902242022.WAA22040@hutcs.cs.hut.fi>
Message-ID: <Roam.SIMC.2.0.6.919954704.1141.mre@eng.sun.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-ietf-ssh@clinet.fi
Precedence: bulk
Content-Length: 1930
Lines: 39


> I don't really know anything about the PAM, so I cannot say if it can
> be implemented using userauth or not. 
> 
> > (ii) PAM wants to talk directly to the user, to ask for passwords,
> > request password changes, etc. These messages are not abstracted *at*
> > *all*, PAM gives the application a string and some display hints, and
> > expects a string back as the users response. This mode of operation
> > doesn't fit with the ssh user-authentication protocol. 

My model for PAM is that user logs into his desktop, and PAM acquires all the
credentials necessary to seamlessly access other services.

For example I have a kerberized pam module that does the equivalent of kinit
for me, and stores the kerberos creds in a temporary file.

When using kerberized telnet, the client client side of telnet doesn't care
about PAM. On the server side, the telnet daemon does care about PAM, to the
extent that if kerberos authentication is being used, the pam module is
configured to be quiet. If the kerberos authentication is not used, then
telnet will both through the stack of pam modules, which includes the kerberos
module. So the user runs through the same set of PAM queries that he did when
he logged into his desktop.

I agree with those who say that attempting to structure PAM within a protocol
makes no sense. Instead, the protocol should be able to provide an
uninterpreted byte stream to the entity invoking the SSH client so that when
the SSH server runs through the PAM stack, PAM itself drives the user's
actions.

Keep in mind that PAM modules can pretty much do anything ... ask for the ids
and passwords of multiple people, interact with a local smart card, do
challengeg/response withor without a token card, act as an access control
feature ("if it's a full moon on Saturday, and its joe logging in, tell him
no"), a logging feature, etc. I'm skeptical that this general a feature
can be structuted.

	-mre

From owner-ietf-ssh@clinet.fi  Thu Feb 25 17:41: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 RAA32205;
	Thu, 25 Feb 1999 17:41:29 +0200 (EET)
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 RAA28321;
	Thu, 25 Feb 1999 17:41:28 +0200 (EET)
Received: (from majordom@localhost)
	by lohi.clinet.fi (8.9.1/8.9.0) id RAA09332
	for ietf-ssh-outgoing; Thu, 25 Feb 1999 17:42:44 +0200 (EET)
X-Authentication-Warning: lohi.clinet.fi: majordom set sender to owner-ietf-ssh@clinet.fi using -f
Received: from nic.carlstedt.se (nic.carlstedt.se [193.12.107.10])
	by lohi.clinet.fi (8.9.1/8.9.0) with ESMTP id RAA08393;
	Thu, 25 Feb 1999 17:35:27 +0200 (EET)
Received: from giraf.carlstedt.se (root@giraf.carlstedt.se [172.16.1.10])
	by nic.carlstedt.se (8.9.3/8.9.3) with ESMTP id QAA24158;
	Thu, 25 Feb 1999 16:30:29 +0100 (MET)
Received: from carlstedt.se (maf@aston.carlstedt.se [172.16.1.90])
	by giraf.carlstedt.se (8.9.3/8.9.3) with ESMTP id QAA19004;
	Thu, 25 Feb 1999 16:30:22 +0100 (MET)
Message-Id: <199902251530.QAA19004@giraf.carlstedt.se>
Date: Thu, 25 Feb 1999 16:30:19 +0100 (MET)
From: Martin Forssen <maf@crt.se>
Subject: Re: Generic challenge-repsonse aunetication in ssh2
To: fcusack@iconnet.net
cc: ssh@clinet.fi, ietf-ssh@clinet.fi, psst@net.lut.ac.uk
In-Reply-To: <199902250044.TAA20240@ratbert.iconnet.net>
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Sender: owner-ietf-ssh@clinet.fi
Precedence: bulk
Content-Length: 6414
Lines: 143

Here comes my comments on the draft.

> 3.1 Initial Exchange
...
>    The server SHOULD NOT reply with the SSH_MSG_USERAUTH_FAILURE message
>    if the failure is based on the username or service; instead it SHOULD
>    send a SSH_MSG_USERAUTH_INFO_REQUEST message requesting a password,
>    and then send the failure message (after a suitable delay, as
>    described below).  This is to help limit certain types of attacks.

But that can be revealing as well. I suggest the following wording
instead:

    The server SHOULD NOT reply with the SSH_MSG_USERAUTH_FAILURE message
    if the failure is based on the username or service; instead it SHOULD
    send a SSH_MSG_USERAUTH_INFO_REQUEST message which looks just like the
    one which would have been sent in cases where authentication should
    proceed, and then send the failure message (after a suitable delay, as
    described below). The goal is to make it impossible to find valid
    usernames by just comparing the results when authenticating as
    different users.

> 3.2 Information Requests
...
>       byte    SSH_MSG_USERAUTH_INFO_REQUEST
>       string  name (ISO-10646 UTF-8)
>       string  instruction (ISO-10646 UTF-8)
>       int     num-prompts
>       string  prompt[1] (ISO-10646 UTF-8)
>       boolean echo[1]
>       ...
>       string  prompt[num-prompts] (ISO-10646 UTF-8)
>       boolean echo[num-prompts]
>       string  language tag (as defined in [RFC-1766])

I think it would be sligthly cleaner to move the language-tag to before
the prompts (possible it should be placed before name). IMHO it is cleaner
to have the "static" portions of a message first and the dynamic last.

> 3.3 User Interface
...
>    A CLI client SHOULD print the name and instruction (if supplied),
>    adding newlines. Then for each prompt in turn, the client MUST
>    display the prompt and read the user input.
> 
>    A GUI client SHOULD present a dialog window, using the name (if
>    supplied) as the title of the window, the instruction (if supplied)
>    as a text message inside the dialog, and the appropriate number of
>    entry fields with the prompts as labels.  A GUI client SHOULD NOT
>    present each prompt in a separate window.  A GUI client MUST properly
>    handle an instruction with embedded newlines.  A GUI client MUST also
>    be able to display at least 30 characters for the name and prompts.
>    If the server presents names/prompts longer than 30 characters, the
>    client MAY truncate these fields to the length it can display.  If

Nowhere does the draft explain the terms CLI and GUI. Also a lot of the
restrictions placed on GUI-clients should also be applied to CLI-clients.
I would propose the following wording:

    A text-based client SHOULD print the name and instruction (if
    supplied), adding newlines. Then for each prompt in turn, the
    client MUST display the prompt and read the user input.

    A graphical user interface (GUI) client SHOULD present a dialog
    window, using the name (if non-empty) as the title of the window,
    the instruction (if non-empty) as a text message inside the dialog,
    and the appropriate number of entry fields with the prompts as
    labels. A GUI client SHOULD NOT present each prompt in a separate
    window.

    All clients MUST properly handle an instruction with embedded
    newlines. They MUST also be able to display at least 30 characters
    for the name and prompts. If the server presents names/prompts
    longer than 30 characters, the client MAY truncate these fields to
    the length it can display. If the client does truncate any fields,
    there SHOULD be an obvious indication that such truncation has
    occured.

> 3.4 Information Responses
...
> 
>    After obtaining the requested information from the user, the client
>    MUST respond with a SSH_MSG_USERAUTH_INFO_RESPONSE message.
> 
>    The format of the SSH_MSG_USERAUTH_INFO_RESPONSE message is as
>    follows:
> 
>       byte    SSH_MSG_USERAUTH_INFO_RESPONSE
>       int     num-responses
>       string  response[1] (ISO-10646 UTF-8)
>       ...
>       string  response[num-responses] (ISO-10646 UTF-8)
> 
>    Note that the responses are encoded in ISO-10646 UTF-8.  It is up to
>    the server how it interprets the responses and validates them.
>    However, if the client reads the responses in some other encoding
>    (e.g., ISO 8859-1), it MUST convert the responses to ISO-10646 UTF-8
>    before transmitting, and the server MUST convert the responses to the
>    encoding used on that system that is needed to verify them.
> 
>    In the case that the server sends a `0' num-prompts field in the
>    request message, the client MUST send a response message with a `0'
>    num-responses field.
> 
>    After receiving the response, the server MUST send either a
>    SSH_MSG_USERAUTH_SUCCESS, SSH_MSG_USERAUTH_FAILURE, or another
>    SSH_MSG_USERAUTH_INFO_REQUEST message.
> 
>    If the server fails to authenticate the user (through the underlying
>    authentication mechanism(s)), it SHOULD NOT send another request
>    message(s) in an attempt to obtain new authentication data, instead
>    it SHOULD send a failure message.  The only time the server should
>    send multiple request messages is if additional authentication data
>    is needed (i.e., because there are multiple underlying authentication
>    mechanisms that must be used to authenticate the user).
> 
>    If the num-responses field does not match the num-prompts field in
>    the request message, the server MUST send a failure message.

I think this last paragraph should move up a bit and be placed after the
"Note that the responses..." paragraph.

> 6. References
...
>    [SSH-ARCH] Ylonen, T., Kivinen, T, and Saarinen, M., "SSH Protocol
>    Architecture", Internet Draft, draft-ietf-secsh-architecture-00.txt
> 
>    [SSH-CONNECT] Ylonen, T., Kivinen, T, and Saarinen, M., "SSH
>    Connection Protocol", Internet Draft, draft-ietf-secsh-connect-02.txt
> 
>    [SSH-TRANS] Ylonen, T., Kivinen, T, and Saarinen, M., "SSH Transport
>    Layer Protocol", Internet Draft, draft-ietf-secsh-transport-02.txt
> 
>    [SSH-USERAUTH] Ylonen, T., Kivinen, T, and Saarinen, M., "SSH
>    Authentication Protocol", Internet Draft, draft-ietf-secsh-userauth-
>    02.txt

Perhaps we should update these references to be aginst the current versions
of the drafts:-)

	/MaF


From owner-ietf-ssh@clinet.fi  Thu Feb 25 18:34: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 SAA00443;
	Thu, 25 Feb 1999 18:34:55 +0200 (EET)
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 SAA28762;
	Thu, 25 Feb 1999 18:34:55 +0200 (EET)
Received: (from majordom@localhost)
	by lohi.clinet.fi (8.9.1/8.9.0) id SAA16142
	for ietf-ssh-outgoing; Thu, 25 Feb 1999 18:35:32 +0200 (EET)
X-Authentication-Warning: lohi.clinet.fi: majordom set sender to owner-ietf-ssh@clinet.fi using -f
Received: from ratbert.iconnet.net (ratbert.iconnet.net [209.3.247.87])
	by lohi.clinet.fi (8.9.1/8.9.0) with ESMTP id SAA15040;
	Thu, 25 Feb 1999 18:24:39 +0200 (EET)
Received: from iconnet.net (localhost [127.0.0.1])
	by ratbert.iconnet.net (8.9.2/8.9.1) with ESMTP id LAA22517;
	Thu, 25 Feb 1999 11:23:34 -0500 (EST)
Message-Id: <199902251623.LAA22517@ratbert.iconnet.net>
X-Mailer: exmh version 2.0.2 2/24/98
To: Tero Kivinen <kivinen@iki.fi>
Cc: ietf-ssh@clinet.fi, ssh@clinet.fi
Subject: Re: Generic challenge-repsonse aunetication in ssh2 
In-reply-to: Your message of "Thu, 25 Feb 1999 09:40:13 +0200."
             <199902250740.JAA00690@hutcs.cs.hut.fi> 
Date: Thu, 25 Feb 1999 11:23:34 -0500
From: Frank Cusack <fcusack@iconnet.net>
Sender: owner-ietf-ssh@clinet.fi
Precedence: bulk
Content-Length: 3217
Lines: 75

In message <199902250740.JAA00690@hutcs.cs.hut.fi>, 
Tero Kivinen writes:

> 
> BTW. There is no real difference compared to the RSA private key on
> the disk and in smartcard. The authentication is same, only thing that

Yes.

> differs is how easy it is to stole the private key. Note that when you
> are using smartcards the pin/passphrase is propably much much more
> easier than what you use for the key that is on the disk, so getting
> the pin by looking over persons shoulder is much easier. 

Ok, yes, /in general/ a pin may be easier to acquire than a
passphrase for a disk-based private key. But if you steal the pin
you also need to have the smartcard, which presumably is more
difficult (and definitely more noticeable). That's the entire
point of smartcard authentication isn't it? 2-factor vs. 1-factor.

> 
> > I'm not saying that authentications /should/ be classified according
> > to technology, only that there definitely should to be a way to
> > "mandate" that an authentication uses a certain technology.
> > That said, I don't know how to FORCE a user to use a smartcard
> > vs. a disk-based key -- a "non-compliant" client implementation
> > could ignore any flag from the server saying "use x technology".
> 
> There is no way you can do that anyways. The user can write his own
> client that can fake to do a smartcard authentication when it is doing
> normal disk based private key authentication. I dont see any use for
> that kind of false security. 

Right, that's my point, a client can ignore a technology-specific flag.

But I would like to see if there is a way to force such a technology
specific flag (in the protocol, not administrativly), I do believe it is
useful (it IS useful). I think it's a worthwhile addition even if
the flag is only advisory, it quickly tells [a compliant] client how to
obtain a signature (or whatever the authentication data may be).

Anyway, let's kill this part of the discussion; it's off-topic for
this thread.

> 
> > > and it even contains
> > > advantage compared to this method, it can use users native language
> > > when printing out most of the prompts.
> > I don't follow you. This example can use the user's native language.
> 
> How? The server doesn't know how to speak Finnish. My client does know
> that. If we use the built-in messages without embedded strings then
> the client can print out dialogs in Finnish, but if the server sends
> me a message saying that "Change your password", my client doesn't
> know what the server is asking, and cannot translate it to "Vaihda
> salasanasi". 

Ahh.. I thought you were referring to the language tags. Yes, you
are correct, specific messages can easily be translated when they
are "message codes" (PASSWD_CHANGEREQ) but the language tag also
provides some of that if the client is smart enough.

But specific message codes are not flexible.
Perhaps a good addition would be a language tag sent by the client
in the initial exchange to specify a preferred language for
subsequent exchanges?

I'm not sure that the proper place is in the auth protocol though,
perhaps in the transport spec (which is the first place a client
might receive language specific messages, I think).


~frank


From owner-psst@net.lut.ac.uk Fri Feb 26 09:11 MET 1999
Received: from gizmo.lut.ac.uk (gizmo.lut.ac.uk [158.125.96.46])
	by samantha.lysator.liu.se (8.8.7/8.8.7) with ESMTP id JAA09821;
	Fri, 26 Feb 1999 09:11:18 +0100 (MET)
Received: from majordom by gizmo.lut.ac.uk with local (Exim 2.12 #2)
	id 10GIDg-0007kN-00
	for psst-outgoing@gizmo.lut.ac.uk; Fri, 26 Feb 1999 08:02:00 +0000
Received: from [206.184.214.10] (helo=neon.transmeta.com)
	by gizmo.lut.ac.uk with esmtp (Exim 2.12 #2)
	id 10GIDc-0007kI-00
	for psst@net.lut.ac.uk; Fri, 26 Feb 1999 08:01:56 +0000
Received: from deepthought.transmeta.com (mailhost.transmeta.com [10.1.1.15])
	by neon.transmeta.com (8.9.1/8.9.1) with ESMTP id AAA08754;
	Fri, 26 Feb 1999 00:01:23 -0800
Received: from transmeta.com (morgan@morgan-home.transmeta.com [10.8.21.6])
	by deepthought.transmeta.com (8.8.8+spamcan/8.8.5) with ESMTP id AAA17261;
	Fri, 26 Feb 1999 00:01:22 -0800 (PST)
Message-ID: <36D656F8.11652FC8@transmeta.com>
Date: Fri, 26 Feb 1999 00:10:32 -0800
From: Andrew Morgan <morgan@transmeta.com>
Organization: Transmeta Corporation
X-Mailer: Mozilla 4.05 [en] (X11; U; Linux 2.1.123 i586)
MIME-Version: 1.0
To: Tero Kivinen <kivinen@iki.fi>
CC: ssh@clinet.fi, ietf-ssh@clinet.fi, psst@net.lut.ac.uk
Subject: Re: Generic challenge-repsonse aunetication in ssh2
References: <199902231243.NAA16085@giraf.carlstedt.se>
		<36D2EF05.9CFCE807@transmeta.com> <199902242030.WAA22146@hutcs.cs.hut.fi>
Content-Transfer-Encoding: 7bit
Content-MD5: lpV/9zpu1ipl+FwCuU0OqA==
Content-MD5-Origin: gizmo.lut.ac.uk
Sender: owner-psst@net.lut.ac.uk
Precedence: bulk
Content-MD5: 0fkqS3adaQ3qp3qck9JyYQ==
Content-MD5-Origin: gizmo.lut.ac.uk
Content-Type: text/plain; charset=us-ascii
X-Content-Length: 2068
Xref: sanna.lysator.liu.se mail.psst:303 mail.ietf-ssh:54
Content-Length: 2068
Lines: 47

Tero Kivinen wrote:
> 
> Andrew Morgan writes:
> > The non-tty input methods we implemented were via a single 'BINARY'
> > message type.
> 
> What authentication methods there are that use those BINARY messages?
> I am not talking about what might be, I am talking about what
> currently exists?

We have a publicly available simple shared secret authentication that is
basically a proof of concept thing (its in the Linux PAM sources). I
have also prototyped code that will do RSA. If you discount 'what might
be', however, then you really are missing the point of PAM.

> So this seems to be same thing that the ssh-agent does?

It has some similarities. The agent as we have defined it is really a
client side PAM module. Its the complement to a PAM module that is
plugged into the server. Because of the way we've constructed things,
this agent can be a simple perl (or even Java) program, or (for machine
to machine private authentication where the client need/should not know
the details) an execute only binary.

This PAM-agent is only for authentication, and is of course designed for
use by other client/servers besides SSH.. It could be used with (a
slightly modified) telnet or some other client/server. To paraphrase
Mike Eisler, the point is that a server application needs to lend its
transport layer to PAM for the duration of the authentication process.
SSH stands out as desirable because it provides an encrypted transport
layer, but with BINARY message types there is nothing to prevent the
PAM-module/agent combo from encrypting their own authentication
exchange.

PAM aims to provide generic and pluggable support to applications for
locally provided/configured authentication methods -- but nothing more.
Perhaps I am mistaken, but I understood that ssh-agents are also used
for tunneling different transport protocols (X, ppp...) over an SSH
connection? PAM is well out of the picture for this sort of thing (and
with the ssh-1.2.* patch we wrote well over a year ago), does not
interfere with this useful SSH-specific feature.

Cheers

Andrew

From owner-ietf-ssh@clinet.fi  Mon Mar  1 12:40: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 MAA10008;
	Mon, 1 Mar 1999 12:40:06 +0200 (EET)
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 MAA24964;
	Mon, 1 Mar 1999 12:40:06 +0200 (EET)
Received: (from majordom@localhost)
	by lohi.clinet.fi (8.9.1/8.9.0) id MAA23029
	for ietf-ssh-outgoing; Mon, 1 Mar 1999 12:40:14 +0200 (EET)
X-Authentication-Warning: lohi.clinet.fi: majordom set sender to owner-ietf-ssh@clinet.fi using -f
Received: from ssh.fi (ssh.fi [194.100.44.97])
	by lohi.clinet.fi (8.9.1/8.9.0) with ESMTP id NAA12330
	for <ietf-ssh@clinet.fi>; Fri, 26 Feb 1999 13:06:23 +0200 (EET)
Received: from torni.ssh.fi (torni.ssh.fi [192.168.2.43])
	by ssh.fi (8.9.1/8.9.1/EPIPE-1.15) with ESMTP id NAA05760
	for <ietf-ssh@clinet.fi>; Fri, 26 Feb 1999 13:03:03 +0200 (EET)
Received: from torni.ssh.fi (torni.ssh.fi [192.168.2.43])
	by torni.ssh.fi (8.9.1/8.9.1/EPIPE-1.13) with ESMTP id NAA05945
	for <ietf-ssh@clinet.fi>; Fri, 26 Feb 1999 13:03:02 +0200 (EET)
Date: Fri, 26 Feb 1999 13:03:02 +0200 (EET)
From: Ssh Mailing List Administrator <sshlist@ssh.fi>
To: ietf-ssh@clinet.fi
Subject: BOUNCE ietf-ssh@clinet.fi:     taboo body match "/\bpicture/i" at
 line 39   (fwd)
Message-ID: <Pine.OSF.4.05.9902261302410.4290-100000@torni.ssh.fi>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ietf-ssh@clinet.fi
Precedence: bulk
Content-Length: 3249
Lines: 71

approve: KokaKola
Received: from neon.transmeta.com (neon-best.transmeta.com [206.184.214.10])
	by lohi.clinet.fi (8.9.1/8.9.0) with ESMTP id KAA16052;
	Fri, 26 Feb 1999 10:05:47 +0200 (EET)
Received: from deepthought.transmeta.com (mailhost.transmeta.com [10.1.1.15])
	by neon.transmeta.com (8.9.1/8.9.1) with ESMTP id AAA08754;
	Fri, 26 Feb 1999 00:01:23 -0800
Received: from transmeta.com (morgan@morgan-home.transmeta.com [10.8.21.6])
	by deepthought.transmeta.com (8.8.8+spamcan/8.8.5) with ESMTP id AAA17261;
	Fri, 26 Feb 1999 00:01:22 -0800 (PST)
Sender: morgan@transmeta.com
Message-ID: <36D656F8.11652FC8@transmeta.com>
Date: Fri, 26 Feb 1999 00:10:32 -0800
From: Andrew Morgan <morgan@transmeta.com>
Organization: Transmeta Corporation
X-Mailer: Mozilla 4.05 [en] (X11; U; Linux 2.1.123 i586)
MIME-Version: 1.0
To: Tero Kivinen <kivinen@iki.fi>
CC: ssh@clinet.fi, ietf-ssh@clinet.fi, psst@net.lut.ac.uk
Subject: Re: Generic challenge-repsonse aunetication in ssh2
References: <199902231243.NAA16085@giraf.carlstedt.se>
		<36D2EF05.9CFCE807@transmeta.com> <199902242030.WAA22146@hutcs.cs.hut.fi>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Tero Kivinen wrote:
> 
> Andrew Morgan writes:
> > The non-tty input methods we implemented were via a single 'BINARY'
> > message type.
> 
> What authentication methods there are that use those BINARY messages?
> I am not talking about what might be, I am talking about what
> currently exists?

We have a publicly available simple shared secret authentication that is
basically a proof of concept thing (its in the Linux PAM sources). I
have also prototyped code that will do RSA. If you discount 'what might
be', however, then you really are missing the point of PAM.

> So this seems to be same thing that the ssh-agent does?

It has some similarities. The agent as we have defined it is really a
client side PAM module. Its the complement to a PAM module that is
plugged into the server. Because of the way we've constructed things,
this agent can be a simple perl (or even Java) program, or (for machine
to machine private authentication where the client need/should not know
the details) an execute only binary.

This PAM-agent is only for authentication, and is of course designed for
use by other client/servers besides SSH.. It could be used with (a
slightly modified) telnet or some other client/server. To paraphrase
Mike Eisler, the point is that a server application needs to lend its
transport layer to PAM for the duration of the authentication process.
SSH stands out as desirable because it provides an encrypted transport
layer, but with BINARY message types there is nothing to prevent the
PAM-module/agent combo from encrypting their own authentication
exchange.

PAM aims to provide generic and pluggable support to applications for
locally provided/configured authentication methods -- but nothing more.
Perhaps I am mistaken, but I understood that ssh-agents are also used
for tunneling different transport protocols (X, ppp...) over an SSH
connection? PAM is well out of the picture for this sort of thing (and
with the ssh-1.2.* patch we wrote well over a year ago), does not
interfere with this useful SSH-specific feature.

Cheers

Andrew

From owner-ietf-ssh@clinet.fi  Sun Feb 28 18:43:28 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 SAA26687;
	Sun, 28 Feb 1999 18:43:27 +0200 (EET)
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 SAA17940;
	Sun, 28 Feb 1999 18:43:27 +0200 (EET)
Received: (from majordom@localhost)
	by lohi.clinet.fi (8.9.1/8.9.0) id SAA15095
	for ietf-ssh-outgoing; Sun, 28 Feb 1999 18:42:15 +0200 (EET)
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 SAA15091;
	Sun, 28 Feb 1999 18:42:12 +0200 (EET)
Received: from sanna.lysator.liu.se (nisse@sanna.lysator.liu.se [130.236.254.206])
	by samantha.lysator.liu.se (8.8.7/8.8.7) with ESMTP id RAA15220;
	Sun, 28 Feb 1999 17:38:27 +0100 (MET)
Received: (from nisse@localhost)
	by sanna.lysator.liu.se (8.8.8/8.8.7) id RAA08945;
	Sun, 28 Feb 1999 17:38:22 +0100 (MET)
To: "J.H.M. Dassen" <jdassen@wi.leidenuniv.nl>
Cc: psst@net.lut.ac.uk, ssh@clinet.fi, ietf-ssh@clinet.fi
Subject: Re: Ssh bugreport & ssh2 signature support
References: <Pine.LNX.3.96.990202221131.6262A-100000@balabit.hu> <19990227121713.A27544@ultra5.wi.leidenuniv.nl>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
From: nisse@lysator.liu.se (Niels =?ISO-8859-1?Q?M=F6ller?=)
Date: 28 Feb 1999 17:38:21 +0100
In-Reply-To: "J.H.M. Dassen"'s message of "Sat, 27 Feb 1999 12:17:14 +0100"
Message-ID: <nn678m7abm.fsf@sanna.lysator.liu.se>
X-Mailer: Gnus v5.4.59/Emacs 19.34
Sender: owner-ietf-ssh@clinet.fi
Precedence: bulk
Content-Length: 1711
Lines: 52

"J.H.M. Dassen" <jdassen@wi.leidenuniv.nl> writes:

> On Tue, Feb 02, 1999 at 22:14:36 +0100, Balazs Scheidler wrote:
> > In the meantime I think I will write support for ssh2-style signatures and
> > make it a configure-time option.
> 
> The updated IETF secsh drafts have changes in the transport layer. It would
> be interesting to know if the draft now prescribes SSH2's behaviour.

The new definition is

  uint32    length
  string    "ssh-dss"
  string    dss_signature_blob

This is incompatible with *both* the old draft and the current ssh2
behaviour. Furthermore, the format of "dss_signature_blob" is not
described at all in the new draft, at least I have not been able to
find it anywhere. *sigh*

Any ideas about how to interpret it? My guess is that we have 20
octets representing r and 20 octets representing s. But that is just a
guess, nothing more.

I would be most grateful if someone could enligten me as to what the
new signature format (i.e. the signature blod) really is. And of
course, I'm also curious about why the format in the previous draft
(which was simple, unambigously described, and easy to implement) was
abandoned.

For reference, the old format was

  uint32    length
  string    "ssh-dss"
  mpint     r
  mpint     s

The format used by current ssh2 versions, as far as I know, is
something like

  uint32    length
  string    r
  string    s

where the strings are expected to always have length 20 (160 bits),
and where the strings are interpreted as non-negative numbers. (i.e.
the strings may have leading zero octets, if that is necessary to make
them 20 octets long, and the most significant bit can be 1 without
implying a negative sign).

Regards,
/Niels Mller
