Subject: What we want from ssh version 2

From: "Glenn Machin" <[email-masked]>
Date: Mon, 23 Oct 2000 09:34:35 -0600

Mike I did not know this discussion was taking place.  But included in
your list should
be.

  Kerberos V5 credential(ticket) and forwarded TGT (encrypted in ticket
session key)

SSH communications is working on the Kerberos V5 credentials and
password implementation now, and Sandia is beta testing it now. The
original code simply passed a TGT across as a user authentication
method.  I submitted some changes back to them which would pass a ticket
and the TGT encrypted in the session key.

Would you please include the above in addition to the list you have and
submit it to the appropriate folks?

Glenn Machin - Sandia Natl Labs

On Fri, 20 Oct 2000, Jeffrey Hutzelman wrote:
> What does the Kerberos community want from ssh?

The ability for a server to accept each of the following mechanisms (as
allowed by server policy):
	Kerberos 4 credentials
	Kerberos 5 credentials
	Kerberos 4 password
	Kerberos 5 password
	Non-kerberos, GSSAPI authentication (Globus, etc.)
	Non-kerberos, non-GSSAPI authentication (Unix passwords, etc.)

In particular, any use of GSSAPI by the protocol should not assume
Kerberos.  

I won't argue for the inclusion of Kerberos 4, but any protocol
identifiers used for Kerberos should not preclude clients and servers
from
using both Kerberos 4 and Kerberos 5.

A side-effect of server implementation needs is the desire to handle
Kerberos passwords via an interface like PAM that can't specify what
type
of password is being used.  For example, a server may not know whether
or
not its authentication libaries will accept Kerberos passwords, or just
Unix passwords.  Since SSHv1 treats a Kerberos password like any other
password, this is possible.  On the flip side, if your PAM configuration
accepts multiple types of passwords, you will generate lots of
authentication failures.  My best advice is to have the protocol know
that
it's a "Kerberos 5 password" versus a standard "password".  Server
implementations may or may not then use the same authentication routines
to handle both types.

The reuse of authentication negotiation schemes such as SASL or SPNEGO
would be desireable if they fit the problem.

Thanks to all of you who are working on this,
-- 
Mike Fisk, RADIANT Team, Network Engineering Group, Los Alamos National
Lab
See http://home.lanl.gov/mfisk/ for contact information