Subject: Re: Kerberos WG: draft-brezak-spnego-http-00.txt

From: Nicolas Williams <[email-masked]>
Date: Mon, 1 Oct 2001 10:49:26 -0400

Questions:

 - Can initiators start an HTTP exchange using GSS/SPNEGO for
   authentication, knowing, perhaps from a previous successful
   connection, that GSS/SPNEGO is required or preferred?

 - As Martin Rex asked, how are GSS tokens other than the first two
   exchanged?

 - Is there, could there be, or, even, should there be a way for the
   acceptor to indicate to the initiator what their GSS name(s) is
   (are)?

   I'm thinking that http/fqdn@REALM is too hardwired into this draft.

   What about web services running on ports other than 80?

   Why not support Kerberos names other than http/fqdn@REALM?

   E.g., http-8000/fqdn@REALM, or http/fqdn/8000@REALM, or
   funkyweb/fqdn@REALM?

   Can SPNEGO be used to support such naming? Or is SPNEGO incapable of
   "negotiating" the acceptor's GSS mechanism-specific name(s)?

Pardon my ignorance of SPNEGO.

Nico

On Tue, Sep 25, 2001 at 09:45:51AM -0400, Tim Bass wrote:
> FYI: Submitted Sept 24,  J. Brezak,  Microsoft:
> 
> http://www.ietf.org/internet-drafts/draft-brezak-spnego-http-00.txt
> 
> Comments by WG  appreciated.
> 
> Finest Regards, Tim
> 
> www.silkroad.com
> 
> 
--
-DISCLAIMER: an automatically appended disclaimer may follow. By posting-
-to a public e-mail mailing list I hereby grant permission to distribute-
-and copy this message.-

Visit our website at http://www.ubswarburg.com

This message contains confidential information and is intended only 
for the individual named.  If you are not the named addressee you 
should not disseminate, distribute or copy this e-mail.  Please 
notify the sender immediately by e-mail if you have received this 
e-mail by mistake and delete this e-mail from your system.

E-mail transmission cannot be guaranteed to be secure or error-free 
as information could be intercepted, corrupted, lost, destroyed, 
arrive late or incomplete, or contain viruses.  The sender therefore 
does not accept liability for any errors or omissions in the contents 
of this message which arise as a result of e-mail transmission.  If 
verification is required please request a hard-copy version.  This 
message is provided for informational purposes and should not be 
construed as a solicitation or offer to buy or sell any securities or 
related financial instruments.

---

From: Martin Rex <[email-masked]>
Date: Tue, 2 Oct 2001 21:03:18 +0200 (METDST)

>    connection, that GSS/SPNEGO is required or preferred?

Good question!

For basic-authentication, which uses a cleartext username/password,
all Web-Browsers perform automatic replay attacks for successive
requests so that an additional roundtrip for authentication is
only required on the first access.

GSS-API mechanisms on the other hand *MUST* implement a replay protection
on the authentication, so that a simple "cached replay" by the browser
*MUST* fail.  But when caching the knowledge that authentication
is required, inclusion of newly created initial context tokens with
every successive request would also save a roundtrip per request.

So it would really be good to know whether that works and if there
are gotchas!

>  - As Martin Rex asked, how are GSS tokens other than the first two

That is really the most interesting question.

It would be a total abuse of SPNEGO if an (arbitrary) number of
additional roundtrips would not be supported.

If actually only one roundtrip is supported, then just sending
the optimistic initial context token with no SPNEGO would have
just been just as good and so much simpler.

Actually -- every resonable implementation of SPNEGO should
allow direct context establishment with any of the available
underlying gssapi mechanisms -- so when the initiator sends
rfc-1964 Kerberos to an acceptor supporting rfc-1964 Kerberos
underneath SPNEGO, it should happily accept the security context
and skip the SPNEGO phase completely.  This would make supporting
this authentication type within other Web-Browsers much easier.
Does this work?

My original example with IAKERB may have been lame, since IAKERB
always requires multiple roundtrips (AFAIK at least on the initial
context establishment with a new target).

>    "negotiating" the acceptor's GSS mechanism-specific name(s)?

NOPE.

The major drawback about SPNEGO is that there is only a negotiation
of gssapi mechanisms, and it precludes a common namespace for the
mechanisms that are being negotiated.

Considering the fact that *NONE* of the 5 independent implementations of
SPKM1 that I've seen implement hostbased service names, there is no
wonder we don't see any other implementations of SPNEGO.

Even the traditional Microsoft SSPs that are being used with
Microsoft's SPNEGO don't have a common namespace, so normally
it is impossible to put them underneath SPNEGO.  Since Microsoft's
SSPI doesn't implement most of the name-related calls of gssapi
they didn't notice this SPNEGO incompatibility with their mechanisms.

It only works because NTLM doesn't actually support target
authentication, so that the target name simply gets ignored
when the result of the negotiation is NTLM.

> Pardon my ignorance of SPNEGO.

That's ok -- as long as you don't author protocol specs that use
(or even require) SPNEGO.

-Martin

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 2 Oct 2001 15:24:28 -0400

> every successive request would also save a roundtrip per request.

Whoa. The GSS Kerberos mech takes care of (or should take care of)
replays -- I expect the same of others. And I'm not talking about
replaying GSS tokens anyways, I'm talking about skipping the null
authentication http connect when the client knows that the server wants
GSS authentication, thus saving a round-trip.

> That is really the most interesting question.

I'd like the MS folk to answer it :)

> additional roundtrips would not be supported.

Indeed.

> just been just as good and so much simpler.

Who's to say that there will never be a mechanism that requires several
roundtrips (IAKERB seems to require 1 1/2 roundtrips...).

[...]

> mechanisms that are being negotiated.

Well, could this proposal be altered so that the http server can include
a possibly null list of exported GSS mech names it responds to? The
default list should be as the draft suggests.

I don't see how this draft can work well without assuming out-of-band
mechanisms for determining a server's GSS names. Since GSS is a general
security service I don't think that assumption can be silently made.

[...]

> (or even require) SPNEGO.

Heh.

Nico