Subject: Re: (Draft 3.0) Agenda for Kerberos Working Group

From: "Douglas E. Engert" <[email-masked]>
Date: Mon, 04 Dec 2000 09:58:30 -0600

Jeffrey Hutzelman wrote:
> 
> On Tue, 28 Nov 2000, Douglas E. Engert wrote:
> 
> > (Draft 3.0) Agenda for Kerberos WG (krb-wg)
> 
> Is it too late to get some time to talk about issues with Kerberos and
> SSH v2?  Particularly, I'd like to see some discussion on the key exchange
> methods described in draft-salowey-secsh-kerbkeyex-00.txt, and on how that
> mechanism might be extended to support arbitrary GSSAPI mechanisms.

I am reluctant to do this, since this document is not assigned to the 
krb-wg, and we have a lot to talk about already. 

I should also point out <draft-galb-secsh-gssapi-00.txt> 
SSH GSS-API Authentication Method which does support arbitrary GSSAPI
mechanisms with SSH. 

I would encourage the authors of these two drafts to get involved, 
if they have not already don so.
 
> 
> I suppose it's worthwhile to also try to get some time with the secsh
> folks...
> 
> -- Jeff

-- 

 Douglas E. Engert  <[email-masked]>
 Argonne National Laboratory
 9700 South Cass Avenue
 Argonne, Illinois  60439 
 (630) 252-5444

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 4 Dec 2000 11:49:24 -0500 (EST)

> krb-wg, and we have a lot to talk about already. 

OK; I can understand that.

> if they have not already don so.

Hm.  I was not aware of the existence of that draft.  I would like to talk
to its authors about mechanism negotiation -- it looks like what they are
doing will result in two levels of negotiation for GSSAPI mechanisms,
which can be problematic if implementations want to support a mixture of
GSSAPI and non-GSSAPI mechanisms with intermixed levels of preference.

A better approach is that used in draft-ietf-cat-sasl-gssapi-02.txt, which
defines a class of mechanisms such that a first-class SASL mechanism can
be derived for any GSSAPI mechanism, allowing all mechanisms to proceed
equally in the negoitation process without having to separately
standardize a SASL wrapper for each GSSAPI mechanism in advance.

In any event, the user auth method described in that draft doesn't really
overlap what we're trying to do with key exchange methods.  In fact, the
two are complementary; between them, they accomplish most of what we were
hoping for when I first started this thread in krb-wg.

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

---

From: Von Welch <[email-masked]>
Date: Mon, 4 Dec 2000 12:56:32 -0600

> GSSAPI and non-GSSAPI mechanisms with intermixed levels of preference.

If I understand you correctly, I think we can support this. A client
who is interested in mixing gssapi and non-gssapi mechanisms on their
preferred list can split the gssapi requests over multiple
SSH_MSG_USER_AUTH_REQUEST messages, in order of preference, where each
request has only a single mechanism OID (or some subset of supported
mechanisms OIDs) and there may be non-GSSAPI request interspersed.

We might want to add a way for the server to send messages distinguish
between "I don't support any of the requested gssapi mechanisms" and
"I don't support gssapi".

Von