Subject: What do we want from sshv2?

From: Jeffrey Hutzelman <[email-masked]>
Date: Fri, 20 Oct 2000 18:33:51 -0400 (EDT)

At the Pittsburgh IETF meeting in August, Tatu Ylonen gave a presentation
in the secsh and krbwg working group sessions describing one proposal for
incorporating Kerberos support in SSH v2.  Those present at the krbwg
session found a number of problems with that proposal.

Most notably, it was basically assumed that hosts would continue to be
authenticated using only ssh's Diffie-Hellman key exchange and SHA1
signatures, and that users would always have a trusted copy of each host's
public key.  As a result, Kerberos mutual authentication was not used, and
one user authentication method described would hand the user's TGT to the
remote host before completing Kerberos authentication.

There was also the issue of using the user name field in password
authentication to pass a principal name, instead of the name of the local
user to authenticate as.  At a minimum, this makes life annoying for users
who expect to be able to log in using either a local password or a
Kerberos password.  It also assumes the existence on the server of a way
to map arbitrary Kerberos principal names to local accounts, which is
generally not possible.            

Due to the problems described above and various others, several of us have
come to believe that the proposal presented in August doesn't meet the needs
of sites that have adopted Kerberos as their primary authentication system.
So, Sam Hartman and I have been working on an alternate proposal that we
hope will meet those needs, without requiring changes to the ssh protocol.

To that end, we have developed a preliminary requirements document which
purports to describe what the Kerberos community wants and/or needs from
Kerberos support in sshv2.  Before proceeding further, we want to get
comments from the Kerberos community, to be sure we're on the right track.
Following is our current list of requirements...

What does the Kerberos community want from ssh?

 1. To use existing Kerberos infrastructure to authenticate ssh clients.

 2. To use existing Kerberos infrastructure to authenticate ssh servers to
    clients.  We already have one key-management mechanism in place, we
    should be able to leverage this for ssh host authentication instead of
    having to set up a parallel structure to manage ssh host public keys.

 3. To be able to forward krb5 credentials across an ssh connection, so
    that the single sign-on concept is extended across multiple hosts.

 4. Kerberos mutual authentication should be used.

 5. SSH key exchange must be tied to host authentication, or there is a
    possible man-in-the-middle attack.

 6. Credentials MUST NOT be forwarded until the identity of the server has
    been verified.  Otherwise, a rogue server can do malicious things on
    behalf of a user.

 7. Some separation of user authentication and host authentication is
    desirable, so that a connection may use different methods for each.

 8. Separation of credential delegation is desirable, so that users may
    delegate any arbitrary subset of their credentials, instead of only
    the exact set supported by the authentication mechanism currently
    in use.

 9. Perfect forward secrecy is desirable, but probably not essential.

10. The authorization name passed in the ssh protocol is associated with
    an account on the remote host which the client wishes to access.
    One proposal suggested passing a Kerberos principal name and then
    requiring the remote host to map this onto an account.  We think this
    is backwards; the correct behavior is to pass an account name as
    always, and let the remote host perform standard authorization checks
    to determine whether the credentials presented may be used to access
    the specified account.

11. Use of GSSAPI and support of arbitrary GSS mechanisms is desirable.

12. Minimizing the number of round trips required by GSSAPI in general
    and Kerberos in particular is desirable.

As always, any comments or discussion are welcome...

-- Jeffrey T. Hutzelman (N3NHS) <[email-masked]>
   Sr. Research Systems Programmer
   School of Computer Science - Research Computing Facility
   Carnegie Mellon University - Pittsburgh, PA

---

From: Mike Fisk <[email-masked]>
Date: Fri, 20 Oct 2000 23:49:16 +0000 (GMT)

> 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

---

From: Greg Troxel <[email-masked]>
Date: 20 Oct 2000 20:04:07 -0400

In general, I think your list is excellent.  (I'm in a mixed krb/ssh
environment, hoping to use more Kerberos, and not surprisingly this
addresses one of the big issues.)

There is one other issue, which probably deserves explicit mention,
even if in the negative.  One could send the Kerberos password to the
remote site for local login-like validation.  This is a) a bad idea
and b) not a protocol issue (remote side option only), but it might
help to be explicit about this, since I'd expect it to occur to those
who don't have the Kerberos religion.

Do you mean that if a ssh host key changes, but is authenticated by
Kerberos, there should be no ssh warning/failure?  This seems fine, and
I'm guessing that it's what you mean, but I suspect its not how the
ssh folks would read this.  Or do you mean doing away with ssh host
keys?  (In which case I disagree, since other authentication methods
will still be used.)

Each side needs to authenticate to the other, but this statement seems
stronger.

This protects the client.  It probably needs to be tied to client
authentication too.

I hold that all remote terminal-type sessions should have PFS, since
users are in practice likely to type passwords over them.  (I'm
compulsive about this in part because I typed passwords over eklogin
at MIT in the late 80s/early 90s for years before I grokked PFS, at
which point I realized that the confidentiality protection I thought I
was getting wasn't nearly as strong as I thought.)

Right now, I believe that one can assume that all SSH connections have
PFS.  Having a Kerberos ssh mechanism that lacks PFS would have not
only the obvious disadvantage, but it would likely result in people
believing they have PFS when they don't.  Plus, from a "plays well
with others" point of view, I think the requirements list will sit
well with the ssh crowd except for the suggestions of possibly giving
up PFS.

This may be heresy here, but IMHO a major weakness of Kerberos as a
_key exchange_ mechanism is lack of PFS.  This is of course not
relevant to the primary role of authentication, except that one
typically wants confidentiality protection for the authenticated
conversation.

Thus, I'd like to see "not breaking ssh's PFS" as a requirement.

	Greg Troxel

---

From: "E. Larry Lidz" <[email-masked]>
Date: Mon, 23 Oct 2000 10:55:34 -0500

>session found a number of problems with that proposal.

I've got one thing that I'd like to see in sshv2's Kerberos
implementation: a method of rejecting Kerberos passwords typed over the
network. 

I'd like to be able to have it accept either Unix passwords over the
network or tickets, but not Kerberos passwords. Of course, ideally this
sort of thing is configurable in ssh's configuration file.

-Larry

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 23 Oct 2000 15:30:55 -0400

> sort of thing is configurable in ssh's configuration file.

This feature should be tunable by site-policies, and not just required
by the protocol specification, though it may be useful to have a
protocol specification for tagging password prompts and passwords so as
to make it possible to prompt for/send type tagged passwords and thus
make it possible to negotiate password types... I'll leave this to
others as I don't care much for such features; PAM provides sufficient
control.

If an implementation of SSH uses PAM then site administrators can decide
to allow/dis-allow the use of Kerberos passwords in SSH rather easily by
listing/not listing pam_krb5 in the PAM configuration for SSH. One could
even specify, via the PAM config, that the use of Kerberos passwords
over secure SSH connections is ok but not to initialize a local
credentials cache...

> -Larry

Nico
--

---

From: Ken Raeburn <[email-masked]>
Date: 26 Oct 2000 19:13:30 -0400

>     that the single sign-on concept is extended across multiple hosts.

I'd like to have this item explicitly permit forwarding of credentials
long after connection establishment, so that if I have a long-running
ssh session I don't have to type my Kerberos password over the wire to
the other end.

>     the exact set supported by the authentication mechanism currently

Another possibility related to this is to have the server side request
specific credentials from the client.  (Assume for the moment that we
may have an IPC-based credentials cache interface, so that random
Kerberos programs may end up talking to the ssh server.)  The server
side could send TGS_REQ-like messages to the client, and the client
side would either acquire and forward the requested tickets, or send a
"request denied" message, perhaps after checking a list of "approved"
services, or prompting the user.

> 11. Use of GSSAPI and support of arbitrary GSS mechanisms is desirable.

If this use of GSSAPI is only to authenticate the session, yes.  My
understanding is that when GSSAPI credentials expire, GSSAPI routines
are allowed to return errors.  That wouldn't do for a long-lived
session.  (Or would it?  Would this be a desirable result in some
situation?)

Ken

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 30 Oct 2000 14:10:02 -0500 (EST)

> services, or prompting the user.

I would very much like to see something like this.  It seems possible to
extend ssh's agent protocol to handle Kerberos or other credentials, and
(without rereading the drafts) it also seems possible to add some
mechanism for explicit user-triggered forwarding.

Unfortunately, getting this right is hard.  I suspect it will take a
while, and I think it should be done separately instead of as part of the
same document that describes the new key-exchange and user-auth methods.
In the meantime, perhaps we can get by with the credential forwarding that
GSSAPI and Kerberos provide at authentication time.

> session.  (Or would it?  Would this be a desirable result in some

In my proposal, GSSAPI would be used in exactly the same way as Kerberos
is used in the first section of Joe's draft, and in the current Kerberos
user-auth proposals -- to authenticate the session and key exchange.  So,
having credentials expire would not be a problem.

-- Jeff

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 30 Oct 2000 15:45:14 -0500

> GSSAPI and Kerberos provide at authentication time.

Ideally I imagine a Kerberos ticket extension which can be used to brand
a proxied service ticket as a pseduo-TGT. The extension would include
information on how to contact the pseudo-TGS. Pseudo-TGTs would be used
to authenticate to the pseudo-TGS, a service that would run on a user's
initial login host.

A neat benefit of such a mechanism would be to give users the ability to
audit remote services' use of forwarded credentials, and even the
ability to review (approve/veto) pseudo-TGS requests.

Using a ticket extension instead of an SSH specification would allow the
use of this feature with other protocols. Only client-side libraries
would need to be changed to implement this pseudo-TGT concept.

Nico
--