Subject: [kitten] "Negotiating "DCE style"" - accept as a WG item

From: Alexey Melnikov <[email-masked]>
Date: Sun, 19 Jun 2011 15:43:31 +0100

It is not very clear to chairs from the discussion whether there is no 
interest in this work item as a WG item, whether there is silent support 
for doing it, or silent dislike for it.

So I would appreciate hearing some explicit +1/-1. Feel free to send 
them directly to me and not to the mailing list.

Best Regards,
Alexey, as a Kitten co-chair.

Subject: [kitten] Negotiating "DCE style" -- a proposal and advice request
From: Nico Williams <[email-masked]>
To: [email-masked], [email-masked]
Date: Tue, 7 Jun 2011 17:53:41 -0500
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>

I've a proposal to make, but I need advice.

The proposal is:

 - add a new GSS req_flag: GSS_C_DCE_STYLE_OK (possibly with a nicer
name; suggestions?);

 - [optional] add a authz-data element to use in Authenticator to
serve the same purpose as GSS_C_DCE_STYLE_OK, for non-GSS apps;

 - add a field or more to EncAPRepPart;  acceptors/servers would only
use the EncAPRepPart extension when the GSS_C_DCE_STYLE_OK (or
authz-data element) is present in the initiator/client's AP-REQ's
Authenticator.

I need advice on the following:

a) What better flag name might there be instead of GSS_C_DCE_STYLE_OK?

   E.g., GSS_C_EXTRA_TOKENS_OK?  GSS_C_NEGO_REPLAY_CACHE_AVOIDANCE?
GSS_C_NO_RCACHE_OK?

b) What to add to EncAPRepPart?  And should we add a new SEQUENCE
named something like EncAPRepPartExt?

   I was thinking of adding authorization data to EncAPRepPart, like so:

EncAPRepPart ::= [APPLICATION 27]     SEQUENCE {
        ctime[0]                KerberosTime,
        cusec[1]                krb5int32,
        subkey[2]               EncryptionKey OPTIONAL,
        seq-number[3]           krb5uint32 OPTIONAL,
        authorization-data[4]   AuthorizationData OPTIONAL,
        ...
}

   And there would also be a new authorization-data type by which the
server would indicate that it understood the GSS_C_DCE_STYLE_OK flag
and awaits one more token from the initiator.

   Is this OK?  Would folks prefer a typed hole for anything *other*
than authorization data here?  My opinion is that we already overload
authorization-data, and we're going to do much more of it in the
future, plus we are likely to want to have a way for the acceptor to
send some authorization data to the initiator, plus symmetry is good
when we can have it.

Nico
--
_______________________________________________
Kitten mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/kitten

---

From: Nico Williams <[email-masked]>
Date: Mon, 20 Jun 2011 14:34:35 -0500

On Sun, Jun 19, 2011 at 9:43 AM, Alexey Melnikov
<[email-masked]> wrote:
> interest in this work item as a WG item, whether there is silent support for
> doing it, or silent dislike for it.
>
> So I would appreciate hearing some explicit +1/-1. Feel free to send them
> directly to me and not to the mailing list.

There has been plenty of discussion.  No one has spoken in opposition
to this (one person spoke in opposition to one particular design, but
not in opposition to the feature as such).

That's not enough, I realize.  I would like to see some +1s.  If not,
that's OK, I'll just pursue the individual submission track -- but I
think this needs to be reviewed here.

Nico
--

---

From: Greg Hudson <[email-masked]>
Date: Mon, 20 Jun 2011 16:42:40 -0400

> not in opposition to the feature as such).

I'm definitely interested in ways to make replay caches unnecessary with
Kerberos.  There are a lot of design issues which make it hard for me to
confidently comment on whether Nico's approach is the right one (or if
there even is a viable approach).  That plus being generally busy is why
I've been quiet in the most recent round of discussion.

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 20 Jun 2011 21:48:51 +0100

Hi Greg,

>I've been quiet in the most recent round of discussion.
The WG doesn't have to implement Nico's proposal as is. The WG just 
needs to decide if it is willing to do the work.
So I will count you as "+1".

---

From: Nico Williams <[email-masked]>
Date: Mon, 20 Jun 2011 15:49:22 -0500

> I've been quiet in the most recent round of discussion.

There's no way to avoid a replay cache or out-of-band communications
in a one-round-trip mechanism.

Anyways, I'd be happy with making this work item broader to cover more
possible designs if you like.

---

From: "Henry B. Hotz" <[email-masked]>
Date: Mon, 20 Jun 2011 18:27:05 -0700

+1 for the problem in general.  Have not read and therefore cannot comment on Nico's specific proposal.

On Jun 19, 2011, at 7:43 AM, Alexey Melnikov wrote:

> It is not very clear to chairs from the discussion whether there is no interest in this work item as a WG item, whether there is silent support for doing it, or silent dislike for it.
> 
> So I would appreciate hearing some explicit +1/-1. Feel free to send them directly to me and not to the mailing list.

------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
[email-masked], or [email-masked]