[kitten] Negotiating "DCE style" -- a proposal and advice request

[Nico Williams <[e-mail]>]

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