Subject: [abfab] Review of draft-johannson-http-gss

From: Sam Hartman <[email-masked]>
Date: Wed, 01 Sep 2010 15:15:52 -0400

This is a review of an expired draft Leif wrote a while ago.

I'm writing the review because Moonshot's implementation would like to
consume some technology like this.

First, I would like to revisit the overall approach.  At this point,
Microsoft have started using channel binding in negotiate
authentication.  As best I can tell the major advantage of this draft is
the ability to handle multi-round-trip mechanisms without assuming the
same connection is used and to do fast reauth.  Both of those are really
important benefits.

There were some issues and limitations about how the server challenge
  could be expanded without breaking IE.
Do we remember what those are?

I wonder whether it would be easier to simply provide a mechanism to
  give a context identifier and then entirely reuse the RFC 4559
  headers?

How does a client know whether a server supports channel binding?
Perhaps the server could indicate this (insecurely) in the  initial
challenge.

For Kerberos we could always include CB even if the server claims not to
support it on the grounds that they can probably deal and will have to
deal in order to play nice with microsoft.

For non-Kerberos (particularly Moonshot) I'm not sure what to do.  One
approach would be to do something GS2-like: the client MUST include CB
and the server MUST check them.  There is a format that includes the
indication from the server of whether CB is accepted plus if it is the
actually CB data.  You'd either need MS's buy-in to do this all the time
for non-Kerberos or you'd need to use a different scheme name after all.

How does the client know that the server  checked the CB?
One possibility is to wrap something like "CB-VERIFIED" if the mechanism
supports that.
The GS2 approach is not quite good enough in two ways. First, it doesn't
help you for Kerberos. Secondly, if Microsoft does permit other GSS
mechs to be used with old-style negotiate, then 
you don't get channel binding confirmation if CB is disabled in IIS.
We can probably ignore the second issue.
We could fix the first issue by including gss_pseudo_random of a
constant string in a response header.
This is far more ugly that I'd like.
I wonder if we could get a conference call together to see if we could
come up with a non-ugly version of this.

If we do go with the GS2 approach, do we want to support clients that
cannot do CB?

If you're going to do CB, you might well want to generate a request that
will let you do GSS authentication before exposing the URI or request
body you want to expose.

Specific comments:

  3.2: How does gss-nt-hostbased-service deal with a trailing port?

Shouldn't the server include a unique identifier of the context even if
no session protection or cb? How do you do multi-round-trip without that?

You should probably mention that the unique identifier can be uite large
if it is going to be an exported context.

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 1 Sep 2010 15:21:28 -0500

>   give a context identifier and then entirely reuse the RFC 4559

Sounds worthwhile to me.  You could have a request header to request a
context identifier, a request header to refer to a given context by
context identifier, and a response header to indicate a server-assigned
context identifier.

> Perhaps the server could indicate this (insecurely) in the  initial

If you're using TLS and can stronly authenticate the server, then you
can live without channel binding.  Otherwise you must insist on channel
binding.

That's exactly what MSFT did, relying on the fact that the Kerberos V
GSS mechanism acceptor can ignore the initiator's channel bindings.

> deal in order to play nice with microsoft.

Right.

> for non-Kerberos or you'd need to use a different scheme name after all.

If MSFT doesn't implement the non-Kerberos mechanisms in question then
it doesn't matter now...

> How does the client know that the server checked the CB?

For a mechanism like SCRAM the acceptor must have used the same CB as
the initiator.  But since we have mechs for which that's not true (that
is, where the acceptor can ignore CB), I think it'd be nice to have a
per-msg token or PRF output by which the server can indicate, via an
HTTP response header, that it really did check CB.

> constant string in a response header.

Yes.

> This is far more ugly that I'd like.

:(

> come up with a non-ugly version of this.

I can think of other things, but none less ugly or easier to implement.

> If we do go with the GS2 approach, do we want to support clients that

I don't think so.

> will let you do GSS authentication before exposing the URI or request

I say: GET a well-known URL.

>   3.2: How does gss-nt-hostbased-service deal with a trailing port?

It... doesn't.  Why should it?

> no session protection or cb? How do you do multi-round-trip without that?

Yes.  Luck helps.

> if it is going to be an exported context.

Sure.  For Kerberos an exported context could consist of: the
initiator's Ticket (or the cleartext enc-part of it), the session keys,
context flags, sequence numbers and sequence number windows -- all
encrypted and authenticated.  Incidentally, you can't enforce out-of-
secquence (OOS) detection, or even replay detection, if you export/
import contexts on every request!  Unless the server keeps a replay
cache, but then why bother exporting contexts?  Replay caching is much
more onerous than keeping around sec contexts.  Not being able to detect
replays could be a big problem.

Nico
--