Subject: [Ietf-krb-wg] 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
--
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

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

On Thu, Apr 28, 2011 at 1:48 PM, Stefan (metze) Metzmacher
<[email-masked]> wrote:
> 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...

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.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

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

Hi Nico,

metze

---

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

On Apr 28, 2011 11:28 PM, "Stefan (metze) Metzmacher" <[email-masked]>
wrote:
> 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).

Right. I want to use it for other protocols.  So a new flag and a AP-REP enc
part extension.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

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

On 29/04/2011, at 9:48 AM, Stefan (metze) Metzmacher wrote:

> Am 29.04.2011 07:03, schrieb Nico Williams:
> Why? It just adds complexity for no gain.

You can do away with the replay cache.

-- Luke

---

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

On Fri, 2011-04-29 at 04:10 -0400, Stefan (metze) Metzmacher wrote:
> Can you explain that?

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 06:28:36 +0200

Hi Nico,

metze

---

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

metze

---

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

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: "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

---

From: Sam Hartman <[email-masked]>
Date: Fri, 29 Apr 2011 11:52:25 -0400

Hi.
Please be aware that neither ap-rep extensions nor DCE style RPC are in
our current charter.

I think it would be problematic to add specifics.  However, if you
wanted to propose text to address the need for the Kerberos replay cache
and you got some folks to indicate support, we could potentially sneak
that in.  However we're late enough in the process you should start with
a specific text proposal.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Nico Williams <[email-masked]>
Date: Fri, 29 Apr 2011 11:01:42 -0500

> a specific text proposal.

Good point.

I think this is important.  I want us to do this.  Arguably, since
this may require a GSS req_flag, we could pursue this work in either
KITTEN or KRB-WG.  In any case, my proposed charter text:

  Today Kerberos requires a replay cache to be used in AP exchanges in
almost all cases.  Replay caches are quite complex to implement
correctly, particularly in clustered systems.  High-performance replay
caches are even more difficult to implement.  The WG will pursue
extensions to minimize the need for replay caching, optimize replay
caching, and/or elide the need for replay caching.

To the work items list I'd then add:

 o Make "DCE style" (3-legged AP exchange) negotiable.
 o Add extensions to make replay caching unnecessary for common
application protocols without having to resort to 3-legged AP
exchanges.

We might decide later to not complete the second of those work items,
if we conclude that any related API changes are too complex, say.

Nico

---

From: Greg Hudson <[email-masked]>
Date: Fri, 29 Apr 2011 12:12:03 -0400

On Fri, 2011-04-29 at 12:01 -0400, Nico Williams wrote:
> > that in.
[...]
> caching, and/or elide the need for replay caching.

I support this statement.  I'm not yet sure what I think is the best
approach to making replay caches unnecessary, but the options we've
discussed so far seem plausible.

---

From: Sam Hartman <[email-masked]>
Date: Fri, 29 Apr 2011 12:31:08 -0400

>>>>> "Greg" == Greg Hudson <[email-masked]> writes:

    Greg> On Fri, 2011-04-29 at 12:01 -0400, Nico Williams wrote:
    >> > wanted to propose text to address the need for the Kerberos
    >> replay cache > and you got some folks to indicate support, we
    >> could potentially sneak > that in.
    Greg> [...]
    >> Today Kerberos requires a replay cache to be used in AP exchanges
    >> in almost all cases.  Replay caches are quite complex to
    >> implement correctly, particularly in clustered systems.
    >> High-performance replay caches are even more difficult to
    >> implement.  The WG will pursue extensions to minimize the need
    >> for replay caching, optimize replay caching, and/or elide the
    >> need for replay caching.

    Greg> I support this statement.  I'm not yet sure what I think is
    Greg> the best approach to making replay caches unnecessary, but the
    Greg> options we've discussed so far seem plausible.

If there is sufficient support I could see adding a statement like this
to the work items.

Speaking as a chair, Nico's proposed text for the work items is to
proposal-specific and I don't see a way we could get a consensus on it
in time, nor is it the type of charter statement we would make.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Nico Williams <[email-masked]>
Date: Fri, 29 Apr 2011 11:35:01 -0500

> If there is sufficient support I could see adding a statement like this

So let's ask who's in favor.

> in time, nor is it the type of charter statement we would make.

Fair enough.  I'd firgured we'd need the work items to be somewhat
more granular than the first paragraph I wrote.  As long as we have
something in the charter that we could use to submit WG I-Ds on this.
If you think the first paragraph of what I wrote achieves that, then
I'm happy.  If not I can propose new text.

Nico

---

From: Sam Hartman <[email-masked]>
Date: Fri, 29 Apr 2011 12:57:29 -0400

I think that if there is sufficient suppo,support the chairs can take
your first paragraph and turn into work item text.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Nico Williams <[email-masked]>
Date: Fri, 29 Apr 2011 12:10:24 -0500

> your first paragraph and turn into work item text.

OK.  We have Greg's and my support.  We probably have yours as well,
chair hat off.

Anybody else?

Nico

---

From: Love Hörnquist Åstrand <[email-masked]>
Date: Fri, 29 Apr 2011 11:02:41 -0700

> application protocols without having to resort to 3-legged AP

I would like to see replay caches be to be un-necessary.

Love

---

From: Simo Sorce <[email-masked]>
Date: Fri, 29 Apr 2011 14:18:40 -0400

> I would like to see replay caches be to be un-necessary.

Me too, they are extremely painful.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York