Subject: [Ietf-krb-wg] Negotiating "DCE style" -- a proposal and advice request

From: Nico Williams <[email-masked]>
Date: Tue, 7 Jun 2011 17:53:41 -0500

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

---

From: Nico Williams <[email-masked]>
Date: Tue, 7 Jun 2011 17:55:32 -0500

> named something like EncAPRepPartExt?

Note: for code simplicity reasons, I'd rather a field to the existing
SEQUENCE than add a new SEQUENCE.

Nico

---

From: Nico Williams <[email-masked]>
Date: Tue, 7 Jun 2011 21:10:00 -0500

> SEQUENCE than add a new SEQUENCE.

To give you an idea of how simple this is, see the attached patch (not
yet tested, written in the last 30 minutes).

Nico

---

From: "Stefan (metze) Metzmacher" <[email-masked]>
Date: Wed, 08 Jun 2011 06:19:49 +0200

>    E.g., GSS_C_EXTRA_TOKENS_OK?  GSS_C_NEGO_REPLAY_CACHE_AVOIDANCE?

anything is better which don't have DCE_STYLE in the name:-)

metze

---

From: "Stefan (metze) Metzmacher" <[email-masked]>
Date: Wed, 08 Jun 2011 06:25:32 +0200

> yet tested, written in the last 30 minutes).

+	    if (ctx->flags & GSS_C_DCE_STYLE_OK) {
+		ctx->flags |= GSS_C_DCE_STYLE;
+		ctx->auth_context->flags |=
+		    KRB5_AUTH_CONTEXT_EXTRA_AP_PDU_REQUIRED;
+	    }

Please don't imply GSS_C_DCE_STYLE.

metze

---

From: Nico Williams <[email-masked]>
Date: Wed, 8 Jun 2011 00:30:07 -0500

> Please don't imply GSS_C_DCE_STYLE.

Why not?

Nico

---

From: Nico Williams <[email-masked]>
Date: Wed, 8 Jun 2011 14:18:33 -0500

>> Please don't imply GSS_C_DCE_STYLE.

My guess is that you don't like the gratuitous differences between DCE
style and the standard mechanism.  I tend to agree, but as you can
see, it's rather easy to implement negotiation of three-legged
Kerberos if I re-use DCE style.  It's probably not that much harder to
just add the extra leg without implying DCE style, but all
implementations will need to implement DCE style anyways (all except
Samba??).

Anyways, do please explain why not imply DCE style.  Thanks,

Nico

---

From: "Stefan (metze) Metzmacher" <[email-masked]>
Date: Wed, 08 Jun 2011 19:54:21 +0200

>> Please don't imply GSS_C_DCE_STYLE.

Because the new feature should be completely unrelated to GSS_C_DCE_STYLE.

GSS_C_DCE_STYLE has more implications than just the 3 leg handshake.
E.g. it also changes the PDU layout!

I guess you don't want to force implementers of the new feature to also
implement the mircrosoft/DCERPC specific details.

I think it's fine if the application chooses to combine them, but the
library should
not enforce that.

metze

---

From: Nico Williams <[email-masked]>
Date: Wed, 8 Jun 2011 16:43:43 -0500

> Because the new feature should be completely unrelated to GSS_C_DCE_STYLE.

Sure it is.  Both allow the acceptor to avoid the use of an rcache.
One is negotiable, the other is not.

> E.g. it also changes the PDU layout!

Hmmm, the non-initial security context tokens are missing the OID
header in the DCE style case, and there's changes to the per-message
tokens.  The latter I can see objecting to.  Alright, almost sold;
I've to think about this.

> implement the mircrosoft/DCERPC specific details.

They have to anyways.

> I think it's fine if the application chooses to combine them, but the

IMO these two options must be mutually exclusive if the new one does
not imply the old one.

Nico

---

From: Nico Williams <[email-masked]>
Date: Wed, 8 Jun 2011 16:55:19 -0500

> IMO these two options must be mutually exclusive if the new one does

I take that back.

---

From: "Stefan (metze) Metzmacher" <[email-masked]>
Date: Thu, 09 Jun 2011 00:07:57 +0200

>> implement the mircrosoft/DCERPC specific details.

No, it's only used exclusive for DCERPC.

If someone wants to implement just LDAP, http, SMB, SMTP, IMAP or others
it's not needed (
and as far as I remember also not supported by windows).

> IMO these two options must be mutually exclusive if the new one does

Maybe for one specific session, but I haven't thought about more details.

metze

---

From: Nico Williams <[email-masked]>
Date: Wed, 8 Jun 2011 17:14:28 -0500

> and as far as I remember also not supported by windows).

Mumble... As a GSS implementor I'd not know what the consumers are --
I'd want to implement this option.  OTOH, you've given me enough to
convince me, so that's that.

> Maybe for one specific session, but I haven't thought about more details.

They're not mutually exclusive after all, but it makes no sense to use
them both -- if you set both then the DCE_STYLE flag wins.

Nico

---

From: Nico Williams <[email-masked]>
Date: Thu, 9 Jun 2011 13:29:58 -0500

The most annoying problem so far is making sure that non-GSS kerberos
apps don't accept AP-REQs taken from a GSS exchange that's using this
three-legged exchange to avoind using the rcache.  Getting this right
requires a bit of refactoring.  And, of course, since there may be
multiple krb5 implementations using the same principal name, and not
all up to date, this feature has to be configurable, which too is
obnoxious.

Nico

---

From: Martin Rex <[email-masked]>
Date: Fri, 10 Jun 2011 00:46:37 +0200 (MEST)

Nico Williams wrote:
> 
> Stefan Metzmacher wrote:
> >
> > Nico Williams wrote:
> > >
> > > <[email-masked]> wrote:
> > > > I guess you don't want to force implementers of the new feature
> > > > to also implement the mircrosoft/DCERPC specific details.
> > >
> > > They have to anyways.

Are you sure?

Myself, I have never tried to use DCE at all or through GSS-API,
but the SSPI function CompleteAuthToken, that does not exist in GSS-API,
always made me wonder what weird things DCE did (or required from apps):

  http://msdn.microsoft.com/en-us/library/aa374764%28v=vs.85%29.aspx

> convince me, so that's that.

DCE seemed to have died around 1997/1998, from license strangulation.

Since the original implementation was basically GSS-API v1
(i.e. no interproces transfer of the security context),
is was never really an option for us.

-Martin

---

From: Luke Howard <[email-masked]>
Date: Thu, 9 Jun 2011 22:58:47 +0000

> DCE seemed to have died around 1997/1998, from license strangulation.

Whatever. D

---

From: Luke Howard <[email-masked]>
Date: Thu, 9 Jun 2011 23:00:48 +0000

>> DCE seemed to have died around 1997/1998, from license strangulation.

Um, whoops. DCE RPC still underpins Active Directory -- but the rest of DCE is dead, granted. But note that the authentication mechanism is quite different to what the OSF implementation did, which was not based on GSS. Windows uses GSS, with some quirks for Kerberos.

-- Luke

---

From: Martin Rex <[email-masked]>
Date: Fri, 10 Jun 2011 02:01:32 +0200 (MEST)

Luke Howard wrote:
> DCE RPC still underpins Active Directory -- but the rest of DCE is dead,
> granted. But note that the authentication mechanism is quite different
> to what the OSF implementation did, which was not based on GSS.
> Windows uses GSS, with some quirks for Kerberos.

It seems that Microsoft started developing Windows NT when DCE was
still assumed to have a bright future on Unix-based servers,
but Microsoft was just as much detered from the licensing conditions
as pretty much everyone else.
But Microsoft did implement some wire-level interop with DCE PDUs,
assuming that it might be beneficial to interop with Unix-based servers
(at a time when MS-DOS and early MS Windows was for pure end-user
machines).

>From what I heard, GSS-API was primarily developed by Digital Equipment
Coorporation (DEC) for the use in DCE, but some members of the DCE camp
frowned upon it because of the performance overhead compared to more
traditional APIs.  So DEC gave it to the IETF.  GSS-API v1 was later
retrofitted onto DCE as an alternative API (as of DCE v1.2, I believe).

-Martin

---

From: Luke Howard <[email-masked]>
Date: Fri, 10 Jun 2011 08:34:27 +0000

> as pretty much everyone else.

The protocols were licensed freely. By the time MS was ready to develop an enterprise directory, they realised (correctly) that CDS and GDS/X.500 were dead, and modern Kerberos and LDAP were not.

> (at a time when MS-DOS and early MS Windows was for pure end-user

I suspect it has as much to do with the people they hired as it does with interop.

> retrofitted onto DCE as an alternative API (as of DCE v1.2, I believe).

Sounds about right.

RPC came from Apollo NCS, FWIW. There's still some NCS-compatibility stuff in the OSF code (see dcerpc.org).

-- Luke