Subject: Re: [kitten] We need a GSS_C_CHANNEL_BOUND_FLAG

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 12 Feb 2013 13:57:55 -0500

On Tue, 2013-02-12 at 06:40 +0100, Martin Rex wrote:
> Luke Howard wrote:
> >
> > Careful, said MS, you're stepping on my toes.
> > 
> > #define GSS_C_DCE_STYLE                 0x1000
> > #define GSS_C_IDENTIFY_FLAG             0x2000
> > #define GSS_C_EXTENDED_ERROR_FLAG       0x4000
> 
> 
> Correct.  The "standardized" flags fill up from the low values,
> whereas the vendor flags fill up form the high values.
> 
>   http://tools.ietf.org/html/rfc4121#section-4.1.1.1

Not quite.  RFC4121 reserves the 8 bits 0xff000 for "legacy" vendor
flags.  I don't recall exactly what we were thinking at the time, but
since there's no negotiation mechanism, the addition by vendors of _new_
flags in this range will almost certainly lead to bad results.

This is a 32-bit space, so we should be careful about allocating new
bits from among those that are currently reserved, and there really
isn't room for vendor-specific bits (other than the legacy ones) at all.
Nico suggests we need a registry, but I'm not convinced that's the case.
As written, RFC4121 does not contemplate that new flags will be
allocated by extensions; rather, they can be used only in new revisions
of the base spec.

It is also worth noting that while the existing mechanism represents
these flags on the wire using the same bits that are used in the C API,
there is no reason this must be the case.  We absolutely can create
flags in the API which do not correspond directly to bits on the wire,
and vice versa.

-- Jeff

---

From: Sam Hartman <[email-masked]>
Date: Tue, 12 Feb 2013 15:15:39 -0500

Nico needs a C API flag, not a wire flag, right?

---

From: Nico Williams <[email-masked]>
Date: Tue, 12 Feb 2013 14:29:35 -0600

On Tue, Feb 12, 2013 at 12:57 PM, Jeffrey Hutzelman <[email-masked]> wrote:

Allow me to respond to this out of order.

> flags in the API which do not correspond directly to bits on the wire,

This is true.  I don't think we have a rule about what the mechanism
should do with flags it doesn't know about (the mechglue and app
might, but in a plugin-style mechglue the mech might not).  I don't
need such a rule in this case because if the initiator app were to set
this flag as a req_flag, and were the mechglue to pass it dumbly to
the mech, and were the mech to pass it on the wire, no harm would
result.

> flags in this range will almost certainly lead to bad results.

Is there any evidence of "legacy" vendor flags, or that mechglues or
mechanisms do anything to filter out flags in this range?  If not then
I think we can re-purpose them.

> allocated by extensions; rather, they can be used only in new revisions

I want a registry to I can find the ones that are registered by means
other than looking at multiple implementations' header files / docs.
We may well want Standards Action to allocate them given their
scarcity, but the point for me is having a place where I can find them
all so I can allocate an as-yet unused one.

BTW, I could add an extended security context inquiry function instead
of using ret_flags.  For the Java API there'd be no real difference.
For the C API a flag is clearly easier to check.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Tue, 12 Feb 2013 14:45:39 -0600

> Nico needs a C API flag, not a wire flag, right?

In this case that distinction is irrelevant because setting this flag
in req_flags and having it automatically copied (locally and on the
wire) into ret_flags does no harm.

BTW, maybe we should have a range of flags that must be transported by
the mech regardless of the flags' semantics?  I think that'd be
overkill, but maybe I'm being unimaginative.

Nico
--

---

From: Sam Hartman <[email-masked]>
Date: Tue, 12 Feb 2013 15:55:21 -0500

>>>>> "Nico" == Nico Williams <[email-masked]> writes:

    >> Nico needs a C API flag, not a wire flag, right?

    Nico> In this case that distinction is irrelevant because setting
    Nico> this flag in req_flags and having it automatically copied
    Nico> (locally and on the wire) into ret_flags does no harm.

Help me out here.
I'm not seeing any reason to transport this flag over the wire nor have
it as an input in req_flags.

---

From: Nico Williams <[email-masked]>
Date: Tue, 12 Feb 2013 15:01:46 -0600

> it as an input in req_flags.

You misread :)  I have no use for this flag to be sent over the wire
or used as a req_flag.  I only said that there's no need to forbid it
as it does no harm -- it's only silly to use it as a req_flag.

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 12 Feb 2013 16:08:47 -0500

On Tue, 2013-02-12 at 14:29 -0600, Nico Williams wrote:
> might, but in a plugin-style mechglue the mech might not).

The bits in the API and the bits on the wire are not the same thing, in
the same way that KDC options and ticket flags are not the same thing.
Yes, there are several cases where flags appear in both sets with
similar names and related meanings and possibly even the same value, but
that does not mean they are the same.

The bits on the wire are an artifact of the particular mechanism spec.
In the case of RFC4121, implementations certainly should not set
undefined flags on the wire; the spec is quite clear on this.

> Is there any evidence of "legacy" vendor flags

I assume we set them aside because we knew something was already using
them.  I don't really remember, but I bet there are archives of the
mailing list.

> other than looking at multiple implementations' header files / docs.

Ah, but there is no "registering", because there is no registry.  The
bits that are defined in the Kerberos GSS-API mechanism's flags on the
wire are those that are listed in the latest version of the Kerberos
GSS-API mechanism spec.  The only way to add new ones is to rev the
spec.

> all so I can allocate an as-yet unused one.

The only way to allocate an as-yet-unused one is to publish a new
version of the spec.  We could decide to change that, of course.

Note that this is all separate from adding flags to the abstract API, in
which they have only names, or to the C bindings, whose number space is
distinct 

-- Jeff

---

From: Nico Williams <[email-masked]>
Date: Tue, 12 Feb 2013 15:28:41 -0600

On Tue, Feb 12, 2013 at 3:08 PM, Jeffrey Hutzelman <[email-masked]> wrote:
> Yes, [...]

I am aware.  But the mech still gets flags, and it's entirely possible
that a mechglue and mech are out of sync and the mechglue passes in a
flag that the mech doesn't know, and it's entirely possible that a
mech implementation ends up doing something very naive with flags it
doesn't know.  I'm saying that I don't know of any hard and fast rule
about that and that we could use one.

> them.  I don't really remember, but I bet there are archives of the

I'm willing to say we can use them.  I'm also willing to say that we can't.

The main question is: are any such implementations around any longer?
Martin might know.

> [...]

Isn't that what I said, or at least didn't I strongly imply that I'm
aware that there's no registry?  :)

> version of the spec.  We could decide to change that, of course.

No implementors have ever allocated flags without Standard Actions?  I
don't think so.  Just the very first flag I checked just now
(GSS_C_EXTENDED_ERROR_FLAG) is not allocated in any RFC.

BTW, add flag numbering to the list of things we'd need to tighten up
if we ever want to have standard ABIs for the C bindings.  (And no,
this is not a cue to have a debate in this thread about whether
standard ABIs are desirable.  Start a new thread if you must have that
discussion :)

> which they have only names, or to the C bindings, whose number space is

Correct.

Nico
--

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 12 Feb 2013 16:40:54 -0500

> about that and that we could use one.

We _have_ one, from RFC4121 4.1.1.1:

   All other flag values not specified herein are reserved for future
   use.  Future revisions of this mechanism may use these reserved flags
   and may rely on implementations of this version to not use such flags
   in order to properly negotiate mechanism versions.  Undefined flag
   values MUST be cleared by the sender, and unknown flags MUST be
   ignored by the receiver.

While the values for the six existing flags are copied from RFC2744 and
the text even makes mention of that, it is quite clear from the above
that unspecified flags...

- Are reserved for future revisions _of this mechanism_
- MUST be zero
- MUST be ignored

> (GSS_C_EXTENDED_ERROR_FLAG) is not allocated in any RFC.

It's one of the legacy-vendor bits.  Using it was probably wrong, but
the vendor can at least reasonably expect that the standard is never
going to reuse that bit.

> if we ever want to have standard ABIs for the C bindings.

Hm?  The C bindings specify values for these flags.

-- Jeff

---

From: Nico Williams <[email-masked]>
Date: Tue, 12 Feb 2013 15:47:54 -0600

> We _have_ one, from RFC4121 4.1.1.1:

I meant a generic rule.  One that should be in RFC2743 or an RFC that
updates it.  It's true that RFC2743 does not imply that mechanisms
must transport flags.  But some do and those should get some guidance.
 Additionally we may need to have some rules for req/ret_flags
extensibility (though I don't think we need to have such rules in
order for this flag to be added).

(Part of the issue, of course, is that RFC2743 does not contemplate
pluggable mechglues in much detail, and we might not ever reach
consensus on whether to say much about mechglues in Standards-Track
RFCs.)

> Hm?  The C bindings specify values for these flags.

Yes, but if we have flags that have been added without
Standards-Actions... we need to make sure that implementors get the
same flag numbers.

Nico
--

---

From: Luke Howard <[email-masked]>
Date: Wed, 13 Feb 2013 09:03:35 +1100

> (GSS_C_EXTENDED_ERROR_FLAG) is not allocated in any RFC.

RFC 4757 7.1

--
Luke Howard / [email-masked]
www.padl.com / www.lukehoward.com

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 12 Feb 2013 17:12:03 -0500

> > (GSS_C_EXTENDED_ERROR_FLAG) is not allocated in any RFC.

Ah, right.  In fact, this is probably the "legacy" use that RFC4121 was
considering, given that it was widely deployed before 4121 was published
but not documented until well after.

---

From: Nico Williams <[email-masked]>
Date: Tue, 12 Feb 2013 16:16:43 -0600

> but not documented until well after.

Yup, that must be it.  I'll put out a -02 with a flag past the range
reserved in RFC4121 (and with Security and IANA Considerations
sections).

Nico
--

---

From: [email-masked] (Martin Rex)
Date: Wed, 13 Feb 2013 15:31:06 +0100 (CET)

Nico Williams wrote:
>
> Jeffrey Hutzelman <[email-masked]> wrote:
> 
> should do with flags it doesn't know about

The rule in both, base GSS-API and Kerberos GSS-API v2 mechanism is:

  - set all bits you do not know about to zero on send
  - ignore all bits you do not know about on receive

> I think we can re-purpose them.

I do remember from IETF CAT WG discussions that there were legacy/vendor
flags in mechanism implementations in 1995/6, and they were using from
the high value range.

It was discussed, because GSS-APIv2 assigned three new context flags
that did not exist in GSS-API v1:

   #define GSS_C_ANON_FLAG       64    /* (1<<6) */
   #define GSS_C_PROT_READY_FLAG 128   /* (1<<7) */
   #define GSS_C_TRANS_FLAG      256   /* (1<<8) */

and the idea was that future standardized flags would similarily
continue to be assigned from the low end of the bits.

While I did some superficial search on my CAT mailing list archives,
I haven't found any specific mails so far.  I do remember it was discussed.
It may have been within IETF WG meetings, and not be part of the
meeting minutes.

I had not previously noticed the "legacy" assignments of such low
bits as 2^12 (1<<12) in Microsoft Kerberos (rfc4121), and it's
awful and short-sighted that they poached in the low bit number range.

> For the C API a flag is clearly easier to check.

In order to reduce the likelyhood of clashes of vendor-pilfered
context attribute flags with standard-assigned ones in the (C-Bindings)
32-bit number range, an IANA registry seems appropriate.

-Martin

---

From: [email-masked] (Martin Rex)
Date: Wed, 13 Feb 2013 15:43:28 +0100 (CET)

Nico Williams wrote:
>
> Sam Hartman <[email-masked]> wrote:
> >

No, no, no.

As it says in rfc4121 Section 4.1.1.1:

With the exception of the generic token framing of the initial context
token, GSS-API itself specifies API semantics, not wire-level PDUs.

Context attributes (req_flags inputs and ret_flags outputs) can have
a meaning about strictly local API semantics (REPLAY,ANON,TRANS,PROT_READY),
or they can refer to a feature/characteristic that both communiation
peers have in common (DELEG,MUTUAL,SEQUENCE,CONF,INTEG).

A simplified variant of data REPLAY protection may use enforced sequencing
of data.

A gssapi mechanism must not pass along context attributes from the API
to the communication peer, for which it does not know the semantics,
and it must not pass along the context attributes for which the meaning
is limited to he local API (TRANS,PROT_READY,ANON and some variants of REPLAY).

-Martin