Subject: [kitten] Negotiating DCE style

From: Nico Williams <[email-masked]>
Date: Thu, 28 Apr 2011 11:39:37 -0500

I see two ways to negotiate DCE style (3-legged AP exchange):

a) the KDC knows whether the service supports it and announces it to
the client via a ticket option (which, incidentally, gets recorded in
ccaches, which is very nice);

b) the initiator sets a flag in the authenticator (either as a GSS
flag or as an authz-data element, since we can't use auth-options,
since that's not authenticated) and if the acceptor understands it
then it will respond with a new form of AP-REP (mainly in that there
would be new fields in the enc part), and if not, well, then the mech
does the standard one round-trip thing.

I'm quite partial to (b), actually.  I don't really like the idea that
the KDC has to know about specific features supported by a principal.

Nico
--

---

From: "Stefan (metze) Metzmacher" <[email-masked]>
Date: Thu, 28 Apr 2011 20:48:15 +0200

Hi Nico,

> the KDC has to know about specific features supported by a principal.

Why are you thinking about that? It's (b) with a GSS flag (GSS_C_DCE_STYLE)

See http://www.ietf.org/rfc/rfc4757.txt.

I think there's no reason to redesign this, as it wouldn't be needed at
all...

metze

---

From: Nico Williams <[email-masked]>
Date: Thu, 28 Apr 2011 13:53:07 -0500

> I think there's no reason to redesign this, as it wouldn't be needed at

RFC4757 does not describe something that's negotiable.  If the
acceptor doesn't support this flag then things should fail if the
initiator tries to use it.

---

From: "Stefan (metze) Metzmacher" <[email-masked]>
Date: Fri, 29 Apr 2011 06:28:36 +0200

Hi Nico,

> initiator tries to use it.

The acceptor has to support it if implementing DCERPC authtype 16
or offer krb5 via spnego (authtype 9). And it should be used only for
DCERPC (and only because existing clients and servers use it).

metze

---

From: Nico Williams <[email-masked]>
Date: Fri, 29 Apr 2011 00:03:26 -0500

> DCERPC (and only because existing clients and servers use it).

Right. I want to use it for other protocols.  So a new flag and a AP-REP enc
part extension.

---

From: "Stefan (metze) Metzmacher" <[email-masked]>
Date: Fri, 29 Apr 2011 09:48:20 +0200

> Right. I want to use it for other protocols.  So a new flag and a AP-REP enc

Why? It just adds complexity for no gain.

metze

---

From: Luke Howard <[email-masked]>
Date: Fri, 29 Apr 2011 10:02:18 +0200

> Why? It just adds complexity for no gain.

You can do away with the replay cache.

-- Luke

---

From: "Stefan (metze) Metzmacher" <[email-masked]>
Date: Fri, 29 Apr 2011 10:10:24 +0200

> You can do away with the replay cache.

Can you explain that?

In anyway I think the GSS_C_DCE_STYLE flag should not be used,
as it also has impact on the PDU encoding.

If you need to 3 legs, please add a completely new feature
and don't mix it with existing stuff.

metze

---

From: Greg Hudson <[email-masked]>
Date: Fri, 29 Apr 2011 10:06:43 -0400

> > You can do away with the replay cache.

The first client->server leg of the exchange establishes the client
identity, but could be replayed.  The second leg establishes the server
identity and creates a fresh acceptor subkey (at least for modern
enctypes and implementations).  The third leg proves that the client was
able to decode the acceptor subkey and use it.

If the client is going to send a wrapped message or use channel
bindings, the third leg is sort of unnecessary, depending on the app.
But the app would still see a complete gss_accept_sec_context() after
the second leg, before the client has proved that it's not just a
replay, and in some circumstances the mere ability to fake a successful
authentication is a problem.

---

From: "Stefan (metze) Metzmacher" <[email-masked]>
Date: Fri, 29 Apr 2011 16:10:44 +0200

> authentication is a problem.

Ok, got it.

metze

---

From: Luke Howard <[email-masked]>
Date: Fri, 29 Apr 2011 16:43:04 +0200

> able to decode the acceptor subkey and use it.

Just to add to this, my understanding is that the acceptor subkey is always used for GSS_C_DCE_STYLE, regardless of enctype.

-- Luke