Subject: re: Call for volunteers: Moving SASL to draft status (fwd)

From: Chris Newman <[email-masked]>
Date: Thu, 15 Jan 1998 17:11:48 -0800 (PST)

On the IMAP list Thu, 15 Jan 1998, Mark Crispin wrote:
> I am debugging a GSSAPI SASL mechanism in c-client now.  It will probably be
> in Pine 4.00.  Kerberos 5 is important to us.  So, I have a problem with
> GSSAPI not being in the base specification.

I'd actually like to keep GSSAPI in the base spec, but I don't see that
happening.  The GSSAPI specs themselves are so huge and complex that I
doubt they'll move past proposed anytime in the near future.  Holding SASL
(and by reference IMAP/ACAP/LDAPv3) at proposed status waiting for GSSAPI
to move to draft status is just not reasonable, IMHO. 

Would it be OK with you if we got the draft standard version of SASL and a
recycle at proposed of the GSSAPI mechanism in consecutive RFCs?  That
would allow us to fix any bugs in the GSSAPI mechanism.

> The main problem with the GSSAPI mechanism is that it is inadequately
> specified.  I don't want to say too much yet, since I'm not sure that my
> understanding is 100% correct.

I believe the problem is the basic GSSAPI assumption that the client and
server have the same mechanism "active."  This assumption fails in
practice and thus breaks interoperability.  I can see two ways to fix
this: (1) wait for SNEGO to go proposed and make that part of the GSSAPI
mechanism. (2) Have separate GSS-KERB5, GSS-RSA-blah, etc. mechanisms
which are specific interoperable profiles of GSSAPI mechanisms.

Does this match your understanding?

		- Chris

---

From: Mark Crispin <[email-masked]>
Date: Thu, 15 Jan 1998 17:15:01 -0800 (PST)

Chris -

> (2) Have separate GSS-KERB5, GSS-RSA-blah, etc. mechanisms

It would be quite acceptable -- and probably extremely desirable -- to do
this.  I am assuming two things: it allows Kerberos 5 to remain part of the
base SASL specification, and it blesses implementations that implement GSSAPI
only for Kerberos 5.

If you decide to do this, please do so immediately, because I plan to release
an imap-4.1 toolkit with GSSAPI to the world imminently.

---

From: Simon Spero <[email-masked]>
Date: Fri, 16 Jan 1998 09:58:08 -0500 (EST)

I've actually heard requests for a raw K5 profile cloned as much as
possible from the K4 one.
BTW, I've done a K4 IMAP-> Cyrus in C; authentication only though for
legal reasons I'm supposed to do one in java but that may not be done
before the IETF.

Simon

Now available - The Freddy Hayek Kayak            | "Pass me another elf
Paddle Your Own Canoe! Be Rowed To Surfdom!       | Sergeant- this one's
>From The Taco Institute for Dyslexic Libertarians | split"
  Moments ago I had everything. Now, there's a cow in my nose - La Salla

---

From: Chris Newman <[email-masked]>
Date: Fri, 16 Jan 1998 10:21:39 -0800 (PST)

[recipient list trimmed]

> possible from the K4 one.

Since we already have a defined way to do K5 in SASL, it would require a
*strong* justification to create a new one.  If you can convince Jeff
Schiller that it's a good idea to remove GSSAPI from the K5 picture, then
I'll go along.

> legal reasons I'm supposed to do one in java but that may not be done

So you did an independent implementation of the SASL KERBEROS_V4
mechanism in an IMAP client and are willing to interoperability test?
(using the Cyrus lib for SASL in the a client wouldn't be independent).

Well it'd be nice to do testing in the IETF terminal room, we may have to
do some over the net later.

		- Chris

---

From: John Gardiner Myers <[email-masked]>
Date: Mon, 26 Jan 1998 11:32:27 -0800

Steve Hole wrote:
>
> Hang on a minute.   The issue is that a client and server GSSAPI will
> not interoperate if they implement different underlying mechanisms.  If
> so then: (1) this will probably not happen often in practise because
> the authentication infrastructure an organization uses is usually controlled
> by the organization and 

I'm not sure this is entirely true.  Organizations may control their
infrastructure, but they don't necessarily control what is included in
the deployed software.

> (2) if it does happen, then authentication fails for a
> valid reason.

Let's take an example: the client supports both Kerberos v5 under GSSAPI
and Kerberos v5 under SNEGO under GSSAPI.  The server is older and
supports Kerberos v5 under GSSAPI, but doesn't support SNEGO.

If the organization has a Kerberos V5 infrastructure set up, the client
can still send either Kerberos v5 under GSSAPI or Kerberos v5 under
SNEGO under GSSAPI.  If it sends the latter, authentication fails, but
this is not due to any policy reason.

The client can always fall back, but this was true before we put in
server advertisement of SASL mechanisms anyway.  We've simply gotten rid
of the benefit of having servers advertise available mechanisms.

---

From: Chris Newman <[email-masked]>
Date: Thu, 15 Jan 1998 17:11:48 -0800 (PST)

- Chris

---

From: Mark Crispin <[email-masked]>
Date: Thu, 15 Jan 1998 17:15:01 -0800 (PST)

Chris -

---

From: Simon Spero <[email-masked]>
Date: Fri, 16 Jan 1998 09:58:08 -0500 (EST)

Simon

---

From: Chris Newman <[email-masked]>
Date: Fri, 16 Jan 1998 10:21:39 -0800 (PST)

[recipient list trimmed]

		- Chris

---

From: John Gardiner Myers <[email-masked]>
Date: Mon, 26 Jan 1998 11:32:27 -0800