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

From: "Paul Leach" <[email-masked]>
Date: Fri, 5 Oct 2001 18:12:16 -0700

> -----Original Message-----
> From: Nicolas Williams [mailto:[email-masked]] 
> Sent: Monday, October 01, 2001 7:49 AM
> To: Tim Bass; [email-masked]
> Subject: Re: Kerberos WG: draft-brezak-spnego-http-00.txt
> 
> 
>  - 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)?

Remember, this draft describes what we _do_ right now as shipped, so
that people who want to interop with us can do so. Hence, for example,
IIS really does use the SPN of "http/fqdn" -- and a client who doesn't
construct, from the URL "http://host" an SPN of "http/host" won't suceed
in getting a ticket from the KDC.

Beyond that, I think your questsions are good ones. We are happy to
entertain suggestions for improvements to the spec if everyone wants to
put it on the standards track. (We have some in mind even if it doesn't
go standards track...)

And with particular respect to some of the other name ideas: the client
needs to be able to construct the SPN relying only on secure sources of
information. Since it is used to authenticate the server, in particular
it can not rely on anything the server tells it. Ditto, it can't rely on
anything from DNS. I think that means, for HTTP, that it has to
construct the SPN using solely the URL.

Paul

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 8 Oct 2001 10:06:30 -0400

> in getting a ticket from the KDC.

Ok, since you're pushing IAKERB, how does your spnego-http system work
with multi-round-trip GSS exchanges (IAKERB requires 1 1/2 round trips)?

> put it on the standards track. (We have some in mind even if it doesn't

Fair enough.

> construct the SPN using solely the URL.

This is silly. If the server tells the client that its name is 'foo'
and the client tries to authenticate to it by that name, and it turns
out that the server doesn't respond to 'foo' (e.g., someone spoofed its
initial answer) then authentication fails -- no harm done(*). OTOH, if
the server does respond to 'foo', then authentication succeeds - no
harm done.

(*) Of course, that's a DoS attack, but, this relies on the attacker
being able to spoof the server's address(es) and hijack its TCP
sessions, an unlikely capability that, in any case, leads to any number
of DoS attacks at the very least anyways (the attacker can DoS your web
server then, no matter what security you normally use for your client
sessions, whether it be SSL, TLS or GSS).

So I'd argue that having the server tell the client its name is not a
significant security problem.

Heck, you are currently relying on a mixture of plain insecure DNS, w/
secure updates and Kerberos w/ principal name canonicalization to give
you a fairly secure environment. So the initial HTTP exchange is
insecure, and telling the client to use name 'foo' instead of 'http' is
unreliable, but so is telling the client to use GSS/SPNEGO, until the
GSS context is established anyways. So you're relying on an initially
insecure TCP connection + GSS/SPEGO once the connection is made to give
you a fairly secure environment.

> Paul

Cheers,

Nico
--
-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: Mon, 8 Oct 2001 17:14:05 +0200 (METDST)

> with multi-round-trip GSS exchanges (IAKERB requires 1 1/2 round trips)?

Although John Brezak already answered "1 or 1.5 roundtrips", I expect this
to actually be exactly 1 roundtrip plus a dirty hack with an initial
non-SPNEGO compatible challenge during the "401 Unauthorized" exchange
for NTLM.

The worst conceivable answer would be:
"Yes, we require SPNEGO framing even for the initiator, but the
 handshake is limited to exactly one exchange of NegTokenInit and
 NegTokenTarg -- which violates the SPNEGO spec and meand that
 SPNEGO is *NOT* supported at all, but it's complexity is required."

SPNEGO (rfc2478) doesn't require that the initiator includes an
optimistic initial context token in the first NegTokenInit,
so *not* documenting their SPNEGO implementation and characteristics
might cause interoperability problems ...

> you a fairly secure environment.

For use with Kerberos 5 it is quite ok to require the "http@fqdn"
hostbased service name.  As Paul Leach points out, if one really
wants to perform mutual authentication you must not rely on any
insecure name transforms for the server name, and that includes
having the server announce its name in plain text.

The drawbacks that you notice is that this scheme wouldn't work
with any of the non-Kerberos based gssapi mechanisms since NONE
of them implements hostbased service names -- however this doesn't
seem to bother the majority of people -- I complained about
LIPKEY/NFSv4 reliance on support of hostbased service names and
nobody cared...

However this document is not a proposal but meant to describe an existing
implementation, to allow others to come up with independent interoperable
implementations -- therefore it is quite necessary to clearly document each
and every (design) flaw and restriction where it violates the specification
of the underlying standards!

As I've mentioned before, the "http/fqdn" hostbased service name
is actually incompatible with NT4 domain names -- however since
NTLM doesn't provide mutual authentication anyways, this problem
is simply ignored ...

-Martin

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 8 Oct 2001 11:35:19 -0400

> might cause interoperability problems ...

Agreed.

[...]

> having the server announce its name in plain text.

In krb5 environments people constantly rely on insecure name lookup
methods. It's precisely the mutual authentication bit that makes this
workable for, after context establishment BOTH, the initiator and the
acceptor know each other's name *securely*. Then both sides can decide
to proceed or abort based on each other's names. Not only that, but,
with krb5, the acceptor's name has to be that which the initiator
thinks it is, or else authentication fails.

Look, you could always say that, since TCP 32-bit ISNs hardly make for a
secure transport, GSS should not be used with TCP. GSS makes up for the
some of the lack of security in other protocols involved in getting
initators and acceptors talking.

> of the underlying standards!

Clearly, name announcements are not applicable where mutual
authentication is not possible.

Cheers,

Nico