Subject: RE: SASL GSSAPI draft

From: Chris Newman <[email-masked]>
Date: Mon, 05 Jun 2000 21:51:30 -0700

--On Tuesday, May 30, 2000 9:52 -0400 "Linn, John" <[email-masked]> 
wrote:
> It's certainly true that an SPNEGO token won't be usefully processable by
> a target which doesn't support SPNEGO. If, however, a GSS implementation
> can support GSS_MECH_A and GSS_MECH_B negotiated under SPNEGO, and that
> GSS implementation is being used with SASL, it may not be too much
> incremental effort to make GSS_MECH_A and GSS_MECH_B also available for
> negotiation at the SASL level.  There's a security vs. interoperability
> tradeoff, since the SPNEGO negotiation is protected but the SASL
> negotiation isn't.  I'd suggest recommending, not discouraging, support
> for SPNEGO for use where available and appropriate, but also recommending
> configurable support to allow negotiation of individual GSS mechanisms at
> the SASL level.

Some problems with recommending SPNEGO in SASL:

There are standards-compliant email servers deployed which only support 
Kerberos 5 (GSSAPI SASL) and don't support SPNEGO.  Any email server which 
only advertises GSS-SPNEGO (not yet standardized) and not GSSAPI (standards 
track) for Kerberos 5 support is hostile both to the installed base of 
standards-compliant servers and to the deployment of Kerberos 5.  If admins 
encounter an interop problem when trying to upgrade security, the first 
thing they usually do is back out the security upgrade.  We don't want that 
to happen.

I suspect the protection provided by SPNEGO will be irrelevant to most 
SASL-based protocols in practice because they'll get integrity protection 
from either TLS or IPsec prior to the SASL negotiation if they want it at 
all.  So it just doesn't seem to be worth the extra round trip(s), IMHO.

> If an application client (and its associated SASL and/or SPNEGO client)
> supports policy-driven mechanism negotiation, the preferred set might (1)
> span both GSS and non-GSS SASL mechanisms or (2) might be GSS mechanisms
> only, with non-GSS SASL mechanisms to be invoked only as a fallback if
> none of the GSS mechanisms are available.  If (1), the client is most
> easily served by performing the negotiation (and exposing the individual
> GSS mechanisms) at the SASL level.  Given the prospect of (2), however,
> it'd be good to be able to negotiate among the available GSS mechanisms
> in an SPNEGO-protected manner.

I'm very uncomfortable with options in security protocols.  Every option 
can double the complexity of a security analysis of the software.  I 
suspect that any benefit gained by making SPNEGO an option will be 
outweighed by the cost of a security analysis of both codepaths and the 
interaction between various security polices and SPNEGO/SASL mechanism 
lists.

		- Chris

-++**==--++**==--++**==--++**==--++**==--++**==--++**==
This message was posted through the Stanford campus mailing list
server.  If you wish to unsubscribe from this mailing list, send the
message body of "unsubscribe ietf-cat-wg" to [email-masked]

---

From: [email-masked] (John Myers)
Date: Tue, 06 Jun 2000 16:21:15 -0700

"Linn, John" wrote:
> There's a security vs. interoperability tradeoff, since the
> SPNEGO negotiation is protected but the SASL negotiation isn't.

The design criterion I've used in preparing the draft is that one should
not trade away interoperability unless there exists a requirement in a
site's security policy which is incompatible with that interoperability.

> I'd suggest
> recommending, not discouraging, support for SPNEGO for use where available
> and appropriate, but also recommending configurable support to allow
> negotiation of individual GSS mechanisms at the SASL level.

The applicable requirement in the current draft is:

   In any case, there is no down-negotiation security
   consideration with using the strongest mechanism and set of options
   the implementation supports, so for interoperability that mechanism
   and set of options MUST be negotiable without using the "GSS-SPNEGO"
   mechanism.

> only, with non-GSS SASL mechanisms to be invoked only as a fallback if none
> of the GSS mechanisms are available.  If (1), the client is most easily
> served by performing the negotiation (and exposing the individual GSS
> mechanisms) at the SASL level.  Given the prospect of (2), however, it'd be
> good to be able to negotiate among the available GSS mechanisms in an
> SPNEGO-protected manner.

If your security policy allows the negotiation of a weak mechanism
outside of SPNEGO, then what benefit are you gaining from SPNEGO?  An
active attacker can make it appear that SPNEGO is not suppported by the
other side, removing all benefit of SPNEGO over SASL mechainsm
negotiation.

This is why I discourage rather than encourage SPNEGO underneath SASL. 
Unless you have a security policy of allowing certain mechanisms only
when their negotiation has been protected, the SPNEGO negotiation
protection doesn't buy you anything.  This particular security policy is
explicitly mentioned in the draft as a reason to violate the SHOULD NOT
directive against SPNEGO under SASL.

---

From: David Margrave <[email-masked]>
Date: Thu, 08 Jun 2000 12:40:04 -0700

> directive against SPNEGO under SASL.

As long as major applications, like say LDAP or IMAP for example, are in love
with SASL (Honestly, do you blame them?  Good grief, look at the prototype for
gss_init_sec_context() some time!), don't you think it's worthwhile to at least
go to the effort to add a modicum of real security to it?  I mean, the only
SASL mech worth a darn security-wise at the moment is GSS-API.   I struggled
with this for a while, then realized that if both sides really want a secure
connection, then can simply decide they're only going to support one
SASL mech (GSS KRB5), and that SASL+GSS is simply GSS (real security) with a few
extra bytes of cruft (SASL) in front of the GSS token.   Everybody is happy,
everybody wins.

So I would think that an SPNEGO SASL mech would be a good thing, because
well-designed implementations of application protocols could be configured to
only support one SASL mech (SPNEGO), so that we get real negotiation of a
security protocol (SPNEGO) with a few extra bytes of cruft (SASL) wrapped around
it.

Its the cases where you'd say "I'll support SPNEGO and cleartext passwords as my
SASL mechs", and the man-in-the-middle says "Okay, lets do cleartext passwords"
that you would want to avoid by policy configuration.  I believe that the best
we can hope for is that SASL and SPNEGO(GSS) toolkits will play nice together so
that SASL (which isn't going away) will support SPNEGO as an available option in
the vast majority of implementations.

Dave

---

From: [email-masked] (John Myers)
Date: Sun, 11 Jun 2000 13:06:39 -0700

David Margrave wrote:
> with SASL [...] don't you think it's worthwhile to at least
> SASL mech worth a darn security-wise at the moment is GSS-API.

Personally, I think DIGEST-MD5 [RFC 2831] has an acceptable level of security.

One cannot simply "add security" by throwing in cryptographic protocols
wherever they are convenient.  One has to form a threat model, devise
security policies to address the modeled threats, and evaluate an
implementation of those policies as a whole against said threats.  To
claim that SPNEGO adds "a modicum of real security" to SASL, one must
show how the combination implements security policies to thwart which
classes of threats.

> I struggled

If both sides are configured to only support GSS KRB5, then what threat
does the addition of SPNEGO protect against?

> security protocol (SPNEGO) with a few extra bytes of cruft (SASL) wrapped around

Please address how a client supporting only Kerberos V5 underneath
SPNEGO underneath SASL would interoperate with a server supporting only
Kerberos V5 underneath SASL.

---

From: Ken Hornstein <[email-masked]>
Date: Mon, 12 Jun 2000 00:07:42 -0400

>Kerberos V5 underneath SASL.

You keep bringing up these mythical "only Kerberos V5 underneath
SPNEGO" implementations.  Even if you're doing SPNEGO, you still
have to parse V5 GSSAPI tokens; I can't really imagine a reason
why you would not be able to handle a V5 GSSAPI token exchange
without SPNEGO.  I don't think this is a legitimate reason for
recommending against the use of SPNEGO.

I am still undecided on this issue; maybe it is right to not recommend
the use of SPNEGO with SASL, but I don't think this is a valid reason.

--Ken

---

From: Lawrence Greenfield <[email-masked]>
Date: Mon, 12 Jun 2000 13:23:04 -0400 (EDT)

Date: Mon, 12 Jun 2000 00:07:42 -0400
   From: Ken Hornstein <[email-masked]>
[...]
   You keep bringing up these mythical "only Kerberos V5 underneath
   SPNEGO" implementations.  Even if you're doing SPNEGO, you still
   have to parse V5 GSSAPI tokens; I can't really imagine a reason
   why you would not be able to handle a V5 GSSAPI token exchange
   without SPNEGO.  I don't think this is a legitimate reason for
   recommending against the use of SPNEGO.

If a server advertises both GSSAPI (Krb5 without SPNEGO) in addition
to SPNEGO, no additional security is obtained via SPNEGO (the active
attacks that SPNEGO prevents are just circumvented by removing SPNEGO
from the capabilities line).

Thus, it only makes sense to support SPNEGO/Krb5 if it is going to be
used without advertising/allowing Krb5 without SPNEGO---which leads to
the interoperability problems.

Larry

---

From: Ken Hornstein <[email-masked]>
Date: Mon, 12 Jun 2000 17:37:16 -0400

>from the capabilities line).

That's true, with the current draft.  But if GSSAPI simply means, "any
GSSAPI mechanism", then there's no reason a non-SPNEGO client can't
interoperate with a SPNEGO-aware server, without any loss of security
that I can tell (since there wouldn't be any negotiation in the
non-SPNEGO case).

I was under the impression that "the interoperability problem" was given
as a reason not to use SPNEGO; that's the only reason why I'm saying
I don't think it's a valid reason.

--Ken

---

From: [email-masked] (John Myers)
Date: Fri, 16 Jun 2000 14:58:25 -0700

My apologies, I accidentally left the ietf-cat-wg list off the recipient
list when I first sent this message:

Ken Hornstein wrote:
> SPNEGO" implementations.

Reportedly, the Microsoft Windows 2000 SSPI implementation only
advertises the availability of the SPNEGO GSSAPI mechanism.  A
straightforward implementation of SASL on Windows 2000 would be unlikely
to advertise or recognize GSSAPI SASL mechanisms other than the
"GSS-SPNEGO" mechanism that was registered by Microsoft.

> Even if you're doing SPNEGO, you still
> without SPNEGO.

Consider a SPNEGO client and a non-SPNEGO server.  The server will be
unable to parse the SPNEGO GSSAPI token that the client sends.

> that I can tell (since there wouldn't be any negotiation in the

If the "GSSAPI" SASL mechanism means "any GSSAPI mechanism," then a
client which supports more than one GSSAPI mechanism doesn't know which
one to send to the server.  If a client supports both Kerberos V5 and
SPKM-1 and sees the server advertising "GSSAPI", which one should it
send?  Surely you don't intend for an IMAP client to take two round
trips per GSSAPI mechanism in order to find out the server only supports
the last mechanism the client tried?

What do you mean there wouldn't be any negotiation in the non-SPNEGO
case?  There's always negotiation in SASL.  A man in the middle can
always make it look like either side doesn't support SPNEGO, so my "no
additional security is obtained" statement still applies.

> I don't think it's a valid reason.

I'm sorry, I don't understand.  What is the reason you're saying you
don't think "the interoperability problem" is a valid reason?

---

From: Ken Hornstein <[email-masked]>
Date: Fri, 16 Jun 2000 23:14:38 -0400

>"GSS-SPNEGO" mechanism that was registered by Microsoft.

Hm, back up here.

Are we talking about advertisement at the SASL or GSSAPI level?  I think
I'm a bit confused, because I thought SSPI was roughly equivalant to GSSAPI.

I will say that when I telnetted to the SMTP server on a coworkers
Windows 2000 box, one of the SASL mechanisms it advertised was "GSSAPI",
and I didn't see GSS-SPNEGO anywhere.  Maybe that will change in the
future.

Everything I have seen from Microsoft has led me to believe that
this server would accept a valid Kerberos 5 GSSAPI token (but I
haven't actually tested it yet), _and_ it would accept a SPNEGO
token.  I actually thought that this interoperability has been
tested by Microsoft, but I'd appreciate a correction.

>unable to parse the SPNEGO GSSAPI token that the client sends.

I agree, this is a problem; I don't think I ever disagreed with that.

>one to send to the server.

No disagreement here.  But ... it was my thinking that if you supported
more than one mechanism, you'd really have to do SPNEGO (or your proposed
draft).

>additional security is obtained" statement still applies.

My apologies; I should have been clearer.  I meant, "there wouldn't
be any _SPNEGO_ negotiation in the non-SPNEGO case" (e.g., a Kerberos 5
only GSSAPI implementation would only send a Kerberos 5 GSSAPI mechanism).
But you're right; you still don't gain any security, because you can
then simply remove GSSAPI from the supported mechanism line.  My apologies.

>don't think "the interoperability problem" is a valid reason?

It's been said a number of times that Kerberos 5-only GSSAPI
implementations won't interoperate with GSSAPI implementations that
support Kerberos 5 only under SPNEGO, and this is one of the reasons
a seperate GSS-SPNEGO SASL mechanism is needed.

It is my belief that there are no GSSAPI implementations that
support SPNEGO which do not support GSS Kerberos 5, and furthermore
there is no reason why you would ever _create_ such a GSSAPI
implementation (number one: you'd lose interoperability with Kerberos
5 GSSAPI implementations on non-SASL protocols such as FTP).  So
I don't think that any such interoperability problem exists.

(from another note)

>If a server supports Kerberos underneath SPNEGO but rejects Kerberos
>GSSAPI tokens not underneath SPNEGO, which requirement of RFC 2478 is
>that server violating?

None, as far as I can tell (that exists outside of the SPNEGO spec,
as far as I can tell).  But is there a reason why you would do such
a thing?

Please understand that I'm not raising an objection to your draft; I'm
just trying to understand the reasoning better.

--Ken