Subject: GSSAPI and SASL

From: Marc Horowitz <[email-masked]>
Date: Wed, 29 Apr 1998 21:10:33 EDT

I've recently become aware of a possible change to SASL which I think
would be a serious mistake.  I'm going to base my arguments on rfc2222
(since I don't see a more recent draft), and on the archives I
downloaded from imc.org.

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

>> 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.

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

>> > (2) Have separate GSS-KERB5, GSS-RSA-blah, etc. mechanisms
>> > which are specific interoperable profiles of GSSAPI 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.

I think it would be a tremendous mistake to separate out the GSSAPI
mechanisms this way.  One of the ideas behind the GSSAPI is that
applications which use it do not need to have any understanding of the
underlying security mechanism which is being used.  The SPNEGO
mechanism allows peers to negotiate a common mechanism without
requiring that this process be exposed to the caller.  At least wrt
authentication, there is no reason for any specific knowledge to be
exposed.

John Meyers makes a good point later:

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

>> 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.

Looking at the IMAP and SASL specifications, there's no single
mandatory required authentication mechanism, so there's no guarantee
of interoperability, there, either.  (Where are {S,}CRAM-MD5 defined,
anyway?)  However, this problem can be solved.

IMAP could require that a particular SASL mech be implemented, and it
could also require certain behavior of the GSSAPI mech if it exists.
Given the unlikelyhood of a server which supports multiple mechanisms
but not SPNEGO, IMAP (and other protocols) could require this: request
SPNEGO, and if the acceptor doesn't recognize the mechanism, then fall
back to a "real" mechanism.  It is reasonable to expect SPNEGO will
get deployed widely, so this won't be necessary except for new clients
talking to older servers, which will also get upgraded relatively
quickly, one would think.

In any case, a client should be prepared to fall back, because
regardless of how cleverly the server constructs the list of
mechanisms it supports, the actual process can still fail.  Another
mechanism might succeed, and it would be nice if the client tried it.

This does require a bit of extra work now, but in the long run, it
will be worth it.  People may want krb5 now, but in a year, they'll be
asking for SPKI, or whatever, and it would be nice to have a clean
migration path.

I also think that putting GSSAPI in a separate document would be a
good idea.  Otherwise, it cannot progress to Draft Standard, since
GSSAPI isn't there yet, and this gives us some time to come to
consensus on the GSSAPI issues.

From: Mark Crispin <[email-masked]>
Date: Mon, 2 Feb 1998 12:06:30 -0800 (PST)

>> GSSAPI is not like c-client, which carefully keeps the application at
>> a distance from its drivers.  GSSAPI only takes you so far, then you
>> start having to have knowledge about the actual authentication
>> infrastructure.
>> 
>> Think in terms of a world where most people do not build their own
>> binaries.
>> 
>> Both my client and (especially!) server code have K5 knowledge.  The
>> client code may function with something other than K5, although you
>> would definitely have to rebuild and the error handling won't be right
>> without source code changes.  The server code will definitely not
>> function without source code changes.

This is simply not true.  SAP has a server/client infrastructure which
is *completely* independent of the particulars of the underlying
mechanism.  In fact, they don't plan on shipping the GSSAPI mechanism
at all, for export reasons.  All they require is a proper mechanism in
a shared lib (unix) or DLL (windows).  SASL can do this, too, you just
need to decide you want to.  If you have questions (which is entirely
understandable, given the state of the documentation), please ask for
help; you'll get it.

		Marc

---

From: Chris Newman <[email-masked]>
Date: Wed, 29 Apr 1998 18:35:35 -0700 (PDT)

On Wed, 29 Apr 1998, Marc Horowitz wrote:
> of interoperability, there, either.

The mandatory-to-implement mechanism for IMAP is the plaintext LOGIN
command.  I suspect this will have to change before IMAP can move to draft
status.  SASL is silent on mandatory-to-implement mechanisms.  But each
SASL mechanism has to interoperate, and the GSSAPI one doesn't as written.

> (Where are {S,}CRAM-MD5 defined,

CRAM-MD5 is RFC 2195.  SCRAM-MD5 is draft-newman-auth-scram-03.txt.

> could also require certain behavior of the GSSAPI mech if it exists.

The former will likely be necessary (as the LOGIN command is now
insufficient by IETF rules), the latter would be a layering violation.
The SASL library I've written is shared by our POP and IMAP servers and
will be shared by the SMTP server as well.

> quickly, one would think.

If an IMAP client tries the GSSAPI mechanism and it fails, then it will
fall back to another SASL mechanism or plaintext LOGIN.  If you want to
change the definition of the GSSAPI mechanism itself so it includes such
a fallback, that'd be fine, but it'd be a change.

> mechanism might succeed, and it would be nice if the client tried it.

Yes.  But the SASL GSSAPI mechanism is defined in such a way that there is
no fallback at that layer.  There is only fallback to other SASL
mechanisms.

> consensus on the GSSAPI issues.

I concur.

		- Chris

---

From: Marc Horowitz <[email-masked]>
Date: 29 Apr 1998 21:53:04 -0400

>> SASL mechanism has to interoperate, and the GSSAPI one doesn't as written.

I didn't see this in rfc20260.  What section is this?  In any case,
you're right, the IESG will likely require that this be changed.

>> CRAM-MD5 is RFC 2195.  SCRAM-MD5 is draft-newman-auth-scram-03.txt.

I guess that's what I get for just downloading *sasl* :-)

>> will be shared by the SMTP server as well.

I don't believe the latter is a layering violation.  All it really
does is restrict what parameters you specify to the SASL layer.  

>> a fallback, that'd be fine, but it'd be a change.

This sounds like an API issue, not a protocol issue.  A simpler
example is the CRAM-MD5 mechanism.  If it fails, you would probably
want the client to try again, since people are notoriously bad at
typing passwords.  GSSAPI can behave the same way, except that it can
quietly switch mechanisms.  Even if this isn't required behavior, it's
still intelligent behavior.

>> no fallback at that layer.  There is only fallback to other SASL

Is this specific to the GSSAPI mechanism, or does it reply to all SASL
mechanisms?  I don't see where it's specified that a client can't try
the same mechanism again if it has some reason to believe it might
succeed this time.

		Marc

---

From: Chris Newman <[email-masked]>
Date: Wed, 29 Apr 1998 19:42:25 -0700 (PDT)

On Wed, 29 Apr 1998, Marc Horowitz wrote:
> >> command.

Section 6.2.2 combined with the fact everything in RFC 2060 is
mandatory-to-implement unless it explicitly states otherwise.

> I guess that's what I get for just downloading *sasl* :-)

The GSSAPI spec doesn't include the SPKM or K5 mechanisms.  :-)

> does is restrict what parameters you specify to the SASL layer.  

I guess we disagree.  I think mechanisms should be independent of the
protocol which calls them (with the possible exception of the GSSAPI/SASL 
service name and the meaning of the authorization identity).

> This sounds like an API issue, not a protocol issue.  ...
> GSSAPI can behave the same way, except that it can

You're right, I looked at the SASL API I'm working on and noticed I
already have an error code (SASL_TRYAGAIN) suitable for this condition. 
So there is a cumbersome way to implement SASL+GSSAPI that interoperates,
but it's not required and failure to do so results in interoperability
problems.

		- Chris

---

From: Marc Horowitz <[email-masked]>
Date: 30 Apr 1998 03:17:48 -0400

>> but it's not required and failure to do so results in interoperability

Well, I think that the (separate :-) SASL+GSSAPI document could
specify this, and then we'd have interoperability.

		Marc

---

From: Steve Hole <[email-masked]>
Date: Thu, 30 Apr 1998 12:11:41 -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=Part9804301211.D; protocol="application/pgp-signature"; micalg=pgp-sha1

--Part9804301211.D
Content-Type: Text/PLAIN; CHARSET=US-ASCII

> still intelligent behavior.

I agree.   I have explicitly added a SASL_Continue state code to my API that
allows the SASL consumer to try that mechanism again.   You really must be 
able to do this for CRAM-MD5, PLAIN, and I believe, GSSAPI.   All of my 
implementations of the above do this.
 
> the same mechanism again if it has some reason to believe it might

The behaviour is purely implementation defined -- there is no definition at 
all in SASL on trying again.    You really must be able to try certain 
mechanisms again, the policy of which is defined by the mechanism itself.

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. 

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

--Part9804301211.D
Content-Type: Application/pgp-signature

--Part9804301211.D--

---

From: "Jack De Winter" <[email-masked]>
Date: Thu, 30 Apr 1998 15:21:32 -0400

>configuration issue that prevents you from authenticating. 

While I agree with most of this thread so far, I would disagree in part
with the above statement.  I would agree that if you try and authenticate,
and fail, you should try again.  However, seeing as it is very hard to
determine empircally "if something is weaker", I would problably add the
caveat that once an authentication mechanism is used to attempt
authentication,
it might be a good idea to only allow that authentication from that point in.

regards,
Jack
-------------------------------------------------
Jack De Winter - Wildbear Consulting, Inc.
(519) 884-4498		http://www.wildbear.on.ca/jacks/

---

From: Chris Newman <[email-masked]>
Date: Wed, 29 Apr 1998 18:35:35 -0700 (PDT)

I concur.

		- Chris

---

From: Marc Horowitz <[email-masked]>
Date: 29 Apr 1998 21:53:04 -0400

Marc

---

From: Chris Newman <[email-masked]>
Date: Wed, 29 Apr 1998 19:42:25 -0700 (PDT)

- Chris

---

From: Marc Horowitz <[email-masked]>
Date: 30 Apr 1998 03:17:48 -0400

Marc

---

From: Steve Hole <[email-masked]>
Date: Thu, 30 Apr 1998 12:11:41 -0600

--Part9804301211.D

 

Cheers.
---  
Steve Hole                           
The Esys Corporation

--Part9804301211.D

--Part9804301211.D--

---

From: "Jack De Winter" <[email-masked]>
Date: Thu, 30 Apr 1998 15:21:32 -0400

regards,
Jack

Date: Thu, 30 Apr 1998 15:21:32 -0400
To: Steve Hole <[email-masked]>, IETF SASL Discussion List <[email-masked]>
From: "Jack De Winter" <[email-masked]>
Subject: Re: GSSAPI and SASL
Sender: [email-masked]

regards,
Jack

From: Steve Hole <[email-masked]>
Date: Thu, 30 Apr 1998 12:11:41 -0600
To: IETF SASL Discussion List <[email-masked]>
Subject: Re: GSSAPI and SASL
Sender: [email-masked]

--Part9804301211.D

 

Cheers.
---  
Steve Hole                           
The Esys Corporation

--Part9804301211.D

--Part9804301211.D--

To: Chris Newman <[email-masked]>
Cc: [email-masked]
Subject: Re: GSSAPI and SASL
From: Marc Horowitz <[email-masked]>
Date: 30 Apr 1998 03:17:48 -0400
Lines: 17
Sender: [email-masked]

		Marc

Date: Wed, 29 Apr 1998 19:42:25 -0700 (PDT)
From: Chris Newman <[email-masked]>
Subject: Re: GSSAPI and SASL
To: Marc Horowitz <[email-masked]>
Cc: [email-masked]
Originator-Info: login-id=chris; server=THOR.INNOSOFT.COM
Sender: [email-masked]

		- Chris

To: Chris Newman <[email-masked]>
Cc: [email-masked]
Subject: Re: GSSAPI and SASL
From: Marc Horowitz <[email-masked]>
Date: 29 Apr 1998 21:53:04 -0400
Lines: 63
Sender: [email-masked]

		Marc

Date: Wed, 29 Apr 1998 18:35:35 -0700 (PDT)
From: Chris Newman <[email-masked]>
Subject: Re: GSSAPI and SASL
To: Marc Horowitz <[email-masked]>
Cc: [email-masked]
Originator-Info: login-id=chris; server=THOR.INNOSOFT.COM
Sender: [email-masked]

I concur.

		- Chris

To: [email-masked]
Subject: GSSAPI and SASL
Date: Wed, 29 Apr 1998 21:10:33 EDT
From: Marc Horowitz <[email-masked]>
Sender: [email-masked]

		Marc