Subject: Re: GSSAPI and SASL

From: Ken Raeburn <[email-masked]>
Date: 01 May 1998 15:28:10 -0400

Steve Hole <[email-masked]> writes:

> On a side note, operational experience with fallback between SASL mechanisms 
> has shown me that client fallback really should occur only with explicit 
> server permission.    In most cases, if you offer a GSSAPI level 
> authentication service, and authentication fails, you probably failed for
> a good reason and you really shouldn't try anything weaker.    You should fix
> configuration issue that prevents you from authenticating. 

I must be missing something.  I read this as implying that the first
SASL auth mechanism you try should be the only one, at least without
"explicit server permission".  E.g., if my krb5 tickets don't exist or
have expired, thus causing GSSAPI authentication to fail, are you
suggesting the client shouldn't even try using krb4 tickets?  Working
in an environment that mixes krb5 and krb4, I like having applications
fall back, myself.

If krb4 (for example) is considered too weak, why does your SASL
configuration ever allow it?

And what would constitute "explicit server permission"?

---

From: Chris Newman <[email-masked]>
Date: Fri, 01 May 1998 12:57:00 -0700 (PDT)

> And what would constitute "explicit server permission"?

The "TRANSITION-NEEDED" response code as documented in:
	draft-newman-sasl-plaintrans-04.txt

It has some serious security considerations, but it does allow a site to
gracefully deploy something more secure than plaintext passwords without
resetting the passwords for all users.  All in all a net gain for site
security.

Of course, that particular draft is dead for political reasons, but half
of it has moved to draft-newman-tls-imappop-04.txt, and I plan to
eventually do a draft on protocol authentication response codes (after
SMTP AUTH and POP3 extensions have moved through the standards pipeline). 

		- Chris

---

From: Steve Hole <[email-masked]>
Date: Mon, 4 May 1998 10:51:09 -0600

Message-ID: <[email-masked]>
Priority: NORMAL
X-Mailer: Simeon for Win32 Version 5.0 Preview Build (9)
MIME-Version: 1.0
Content-Type: Multipart/signed; BOUNDARY=Part9805041051.B; protocol="application/pgp-signature"; micalg=pgp-sha1

--Part9805041051.B
Content-Type: Text/PLAIN; CHARSET=US-ASCII

> in an environment that mixes krb5 and krb4, I like having applications

In this example, the krb5 SASL mechanism would not even be started because
your krb5 SASL driver (actually GSSAPI) would detect the fact that you 
do not have proper credentials and would not enter into a GSSAPI negotiation.
Therefore no fallback occurs to go to krb4 -- you would start with krb4.
If you have valid krb5 credentials and you fail to authenticate, then you 
failed to authenticate.   If a server only supports krb4 tickets then it
will advertise only the krb4 mechanism and once again, the client will never
attempt the krb5 mechanism.

Let me restate the point.    If your client believes that it has correct and
sufficient information to initiate a particular SASL mechanism, AND that
mechanism is supported by the server, AND you initiate the mechanism using
the appropriate protocol "AUTHENTICATE" command, then failure to authenticate
using that mechanism should be final unless:

1. the server explicitly allows you to "fallback" to another mechanism -- 
presumably less desirable.   And, by the way, it is reasonably easy to decide,
as a developer, which is stronger and which is weaker.   As a site
administrator, you will be informed by your vendor which is stronger and 
which is weaker so that you can establish clear security policies.

2. the "failed" mechanism allows the application to "try again" with the
same mechanism.   This is very useful for CRAM-MD5 and PLAIN where credentials
are user supplied and prone to typing errors.

> configuration ever allow it?

It's not weak at all.   Simeon does preferential listing of GSSAPI and krb4
at the same level.   It will try GSSAPI first simply because GSSAPI security
modules are likely to be OS or site provided and (probably) best expresses the
site security policy.   Operational experience shows that they are rarely 
jointly installed, and even when they are, they don't collide.   There are 
definitely better and worse implementations of GSSAPI however which can get
mixed up between the krb5 and krb4 thing -- but that is well before it gets
to the SASL support inside any application like Simeon.
 
> And what would constitute "explicit server permission"?

Chris answered this in his followup.   What he said.

Cheers.
---  
Steve Hole                           
The Esys Corporation
Mailto:[email-masked]  
Phone:403-424-4922

--Part9805041051.B
Content-Type: Application/pgp-signature

--Part9805041051.B--

---

From: Ken Raeburn <[email-masked]>
Date: 09 May 1998 16:32:02 -0400

> attempt the krb5 mechanism.

Ah, I see.  You're thinking of fallback in terms of the authentication
attempts sent to the server; I was thinking of what SASL mechanisms
the SASL library (if there is one) or application code invokes.  So I
would call the above a fallback (since GSSAPI was attempted and
failed, and it just happened to be a locally detected problem of a
particular kind), but you would not.  Sorry for the confusion.

I've got to go back to the GSSAPI spec to see for sure, but I assume
the error codes returned are sufficient to decide whether or not to
try another SASL mechanism (without getting server permission etc)?

> which is weaker so that you can establish clear security policies.

Since different sites, or even different machines at a site, may have
different admins and different vendors, there'll probably be some
disagreement as to which is better and which is worse, and the
decision will probably be more political than technical in some cases.
But the client and server should still be able to find one or more
mechanisms acceptable to both of them.

I still need to go look at the stuff Chris mentioned....

> It's not weak at all.

Your message said "[if GSSAPI fails, you] shouldn't try anything
weaker."  And you were talking about not falling back at all without
permission.  I guess I read in more to that combination that you
meant.  I don't consider krb4 to be especially weak either, though I'd
prefer triple-DES or something else better than plain DES, if I
weren't stuck in this mixed environment.

---

From: Ken Raeburn <[email-masked]>
Date: 01 May 1998 15:28:10 -0400

---

From: Chris Newman <[email-masked]>
Date: Fri, 01 May 1998 12:57:00 -0700 (PDT)

- Chris

---

From: Steve Hole <[email-masked]>
Date: Mon, 4 May 1998 10:51:09 -0600

--Part9805041051.B

 

Cheers.
---  
Steve Hole                           
The Esys Corporation

--Part9805041051.B

--Part9805041051.B--

---

From: Ken Raeburn <[email-masked]>
Date: 09 May 1998 16:32:02 -0400