Subject: Re: [kitten] new text for section 7.6

From: Nico Williams <[email-masked]>
Date: Thu, 1 Dec 2011 12:01:18 -0600

Sam, Shawn, and i met today for about 50 minutes and we've reached a
conclusion.  Below are my notes; actual I-D text to follow at some
point when I have time to write it up.

1) All name attributes -or, rather, name attribute namespaces- are in
fact locally critical for the mechanisms that must carry them.

2) We may want to (IMO should want to) define a namespace of
attributes that are entirely application-specific.  For example: local
process privileges.

3) When GSS_Set_name_attribute() is called on an MN the function MUST
fail if the MN's mechanism failes to understand the given name
attribute's semantics.

4) When GSS_Set_name_attribute() is called on a non-MN the function
MUST NOT fail on account of the name attribute not being known by some
mechanisms but MAY fail if the name attribute is not known by any
mechanisms.  A subsequent call to GSS_Acquire_cred() with a NAME that
has name attributes will result in a CREDENTIAL HANDLE for the subset
of desired_mechs which understand *all* of the name attributes that
were set.

Note that (4) implies that it's not easy to determine which mechanisms
don't support a given name attribute, but it makes the common case
where an application wants to negotiate mechanisms easy:
Import_name(), Set_name_attribute(), Acquire_cred(), Inquire_cred(),
negotiate mechanisms, then Init_sec_context().  (This applies to
SSHv2, for example, but also to SPNEGO.)

5) We will probably want a new function by which to ask which
mechanisms understand a given name attribute, and another function by
which to ask what name attribute prefixes a given mechanism supports.
We should define these two functions in a new I-D that also takes care
of inquiry of authenticated name attribute issuer name.

Nico
--

---

From: Leif Johansson <[email-masked]>
Date: Fri, 02 Dec 2011 22:44:20 +0100

On 12/01/2011 07:01 PM, Nico Williams wrote:
> Sam, Shawn, and i met today for about 50 minutes and we've reached
> a conclusion.  Below are my notes; actual I-D text to follow at
> some point when I have time to write it up.

OK I guess we'll have a consensus discussion when you send that then.

	Cheers Leif

> 
> 1) All name attributes -or, rather, name attribute namespaces- are
> in fact locally critical for the mechanisms that must carry them.
> 
> attributes that are entirely application-specific.  For example:
> local process privileges.
> 
> 3) When GSS_Set_name_attribute() is called on an MN the function
> MUST fail if the MN's mechanism failes to understand the given
> name attribute's semantics.
> 
> 4) When GSS_Set_name_attribute() is called on a non-MN the
> function MUST NOT fail on account of the name attribute not being
> known by some mechanisms but MAY fail if the name attribute is not
> known by any mechanisms.  A subsequent call to GSS_Acquire_cred()
> with a NAME that has name attributes will result in a CREDENTIAL
> HANDLE for the subset of desired_mechs which understand *all* of
> the name attributes that were set.
> 
> Note that (4) implies that it's not easy to determine which
> mechanisms don't support a given name attribute, but it makes the
> common case where an application wants to negotiate mechanisms
> easy: Import_name(), Set_name_attribute(), Acquire_cred(),
> Inquire_cred(), negotiate mechanisms, then Init_sec_context().
> (This applies to SSHv2, for example, but also to SPNEGO.)
> 
> mechanisms understand a given name attribute, and another function
> by which to ask what name attribute prefixes a given mechanism
> supports. We should define these two functions in a new I-D that
> also takes care of inquiry of authenticated name attribute issuer
> name.
> 
> Nico --

---

From: Nico Williams <[email-masked]>
Date: Fri, 2 Dec 2011 16:08:31 -0600

> OK I guess we'll have a consensus discussion when you send that then.

But you can give me a hint as to whether you disagree, no?  If not, why not?

---

From: Nico Williams <[email-masked]>
Date: Fri, 2 Dec 2011 21:48:27 -0600

Proposed text for section 7.6:

   When the given name object is an MN this function MUST fail if the
   mechanism for which the name is an MN does recognize the
   attribute name or the namespace it belomgs to.  This is because
   name attributes generally have some semantics that
   mechanisms must understand.

   On the other hand, when the given name is not an MN this
   function MUSTNOT fail -- instead credential acquisition with the
   resulting name MUST fail for mechanisms that don't
  understand any one or more name attributes set with this
function.  Applications may wish to use a non-MN, then acquire
   and use credentials with that name as the desired name.
   The acquired credentials will have elements only for the
   mechanisms that can carry the name attributes set on the name.

   In the future we may add an attribute namespace for
   attributes that only have application-specific semantics.
   But note that mechanisms will still need to know how to
   transport such attributes.  We may also wish to add functions
   by which to inquire whether a mechanism(s) understands a
   given attribute name or namespace, and to list which
   attributes or attribute namespaces a mechanism
   understands.

Note there's a reference to name attr as OID left in section 7.6.

Nico
--

---

From: Leif Johansson <[email-masked]>
Date: Sat, 03 Dec 2011 12:26:21 +0100

> When the given name object is an MN this function MUST fail if the

Say something specific about error return codes instead.

> mechanism for which the name is an MN does recognize the attribute
> name or the namespace it belomgs to.  This is because name
> attributes generally have some semantics that mechanisms must
> understand.

We don't use the term namespace anywhere else in the spec. Lets
not introduce new terminology here. Same goes for 'element' further
down.

> 
> On the other hand, when the given name is not an MN this function
> MUSTNOT fail -- instead credential acquisition with the resulting
> name MUST fail for mechanisms that don't understand any one or more
> name attributes set with this function.  Applications may wish to
> use a non-MN, then acquire and use credentials with that name as
> the desired name. The acquired credentials will have elements only
> for the mechanisms that can carry the name attributes set on the
> name.

I find that text extremely difficult to understand and I'd
like to get some feedback from implementors saying they grok
this (Luke that means you :-))

> 
> In the future we may add an attribute namespace for attributes that
> only have application-specific semantics. But note that mechanisms
> will still need to know how to transport such attributes.  We may
> also wish to add functions by which to inquire whether a
> mechanism(s) understands a given attribute name or namespace, and
> to list which attributes or attribute namespaces a mechanism 
> understands.

That sounds like something for the list and not for the
spec - at the very least is should be separated from the
rest of the text.

> Note there's a reference to name attr as OID left in section 7.6.

Yeah I fixed that already.

	Cheers Leif

---

From: "Jim Schaad" <[email-masked]>
Date: Sat, 3 Dec 2011 14:56:22 -0800

From: [email-masked] [mailto:[email-masked]] On Behalf Of Nico Williams
Sent: Friday, December 02, 2011 7:48 PM
To: Leif Johansson
Cc: [email-masked]
Subject: Re: [kitten] new text for section 7.6

I find the last sentence confusing.  Specifically It appears to contradict the MUST fail from the first sentence.  This is quite likely a shortage in my understanding.  However the following might be better:

The acquired credentials will only be fore mechanisms that can support the name attributes set.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Sun, 4 Dec 2011 01:25:10 -0600

> Say something specific about error return codes instead.

GSS_S_BAD_NAME_ATTR.

> not introduce new terminology here. Same goes for 'element' further

Indeed, but since we have attribute names it follows that we have
attribute namespaces.  The point is that if we expect mechanisms to
understand any semantics for one name attribute, surely we can expect
them to understand semantics of a set of name attributes related by a
common name attribute name prefix.

We don't strictly need to support "namespaces" as such.  Consider a
name attribute with application-specific semantics such that the only
thing the mechanism needs to know is how to transport the attribute.
But surely we'd want more than one such attribute.  But surely, too,
we don't want to have to modify mechanisms every time we add such an
application-specific attribute.  We could simply say that applications
get one such attribute and that the value encoding must encode
everything the application needs, but I suspect that having a
namespace of name attributes just for application-specific attributes
would be more convenient.

I'll write some text for the intro about this.

> this (Luke that means you :-))

If you call GSS_Import_name() with some name-type other than
GSS_C_NT_EXPORTED_NAME you get a non-MN.  If you then call
GSS_Set_name_attribute() then the mechglue doesn't yet know which
mechanism(s) you care about -- the mechglue could try all mechanisms,
but that could be a lot of work, and also complicates the application,
whereas deferring the validity check to credential acquisition time
works much better.

> spec - at the very least is should be separated from the

We've had forward-looking statements in GSS RFCs before... (channel
binding comes to mind, in RFC2743).

Nico
--

---

From: Sam Hartman <[email-masked]>
Date: Mon, 05 Dec 2011 09:49:19 -0500

>>>>> "Leif" == Leif Johansson <[email-masked]> writes:

    >> When the given name object is an MN this function MUST fail if

    Leif> Say something specific about error return codes instead.

Also, what does it mean for it to recognize the namespace?  As I said,
coming up with text here is going to be tricky.  I agree with the intent
and will not block anything, but the first cut text you proposed is not
something I'd understand unless I was on the call with you.  I do agree
it captures the direction we wanted to go in.

---

From: Sam Hartman <[email-masked]>
Date: Mon, 05 Dec 2011 09:51:29 -0500

>>>>> "Nico" == Nico Williams <[email-masked]> writes:
    Nico>    On the other hand, when the given name is not an MN this
    Nico> function MUSTNOT fail -- instead credential acquisition with

MUSt NOT fail seems too strong.  If a mechglue wants to walk all its
mechanisms and see if any of them support the attribute that seems
reasonable.  I'd say MAY SUCCEED and could have my arm twisted into
SHOULD ssucceed.

---

From: Leif Johansson <[email-masked]>
Date: Mon, 05 Dec 2011 15:54:02 +0100

>> Say something specific about error return codes instead.

I seem to recall strong consensus not to change the API in a non-
backwards compatible way since there are deployed implementations
already.

>>> name attributes generally have some semantics that mechanisms
>>> must understand.
>> 
>> not introduce new terminology here. Same goes for 'element'
>> further down.
> 

not really but I take your point. I'm just saying that if we want to
introduce namespaces then lets do a proper job or figure out a way
to formulate the spec wo references to NS.

> understand any semantics for one name attribute, surely we can
> expect them to understand semantics of a set of name attributes
> related by a common name attribute name prefix.
> 
> We don't strictly need to support "namespaces" as such.  Consider
> a name attribute with application-specific semantics such that the
> only thing the mechanism needs to know is how to transport the
> attribute. But surely we'd want more than one such attribute.  But
> surely, too, we don't want to have to modify mechanisms every time
> we add such an application-specific attribute.  We could simply say
> that applications get one such attribute and that the value
> encoding must encode everything the application needs, but I
> suspect that having a namespace of name attributes just for
> application-specific attributes would be more convenient.
> 

... or write the spec wo references to NS

>>> function MUSTNOT fail -- instead credential acquisition with
>>> the resulting name MUST fail for mechanisms that don't
>>> and use credentials with that name as the desired name. The
>>> acquired credentials will have elements only for the mechanisms
>>> that can carry the name attributes set on the name.
>> 
>> I find that text extremely difficult to understand and I'd like
>> to get some feedback from implementors saying they grok this
>> (Luke that means you :-))
> 
> mechanism(s) you care about -- the mechglue could try all
> mechanisms, but that could be a lot of work, and also complicates
> the application, whereas deferring the validity check to credential
> acquisition time works much better.

OK so what does that look like as normative language?

> 
>>> 
>>> In the future we may add an attribute namespace for attributes
>>> that only have application-specific semantics. But note that
>>> mechanisms will still need to know how to transport such
>>> attributes.  We may also wish to add functions by which to
>>> inquire whether a mechanism(s) understands a given attribute
>>> name or namespace, and to list which attributes or attribute
>>> namespaces a mechanism understands.
>> 
>> That sounds like something for the list and not for the spec - at
>> the very least is should be separated from the rest of the text.
> 
> We've had forward-looking statements in GSS RFCs before...
> (channel binding comes to mind, in RFC2743).

absolutely - I'd just as soon not have it along with normative language.

	Cheers Leif

---

From: Leif Johansson <[email-masked]>
Date: Mon, 05 Dec 2011 15:55:18 +0100

On 12/05/2011 03:49 PM, Sam Hartman wrote:
> Also, what does it mean for it to recognize the namespace?  As I
> said, coming up with text here is going to be tricky.  I agree with
> the intent and will not block anything, but the first cut text you
> proposed is not something I'd understand unless I was on the call
> with you.  I do agree it captures the direction we wanted to go
> in.

Thats exactly how I'd put it.

---

From: Nico Williams <[email-masked]>
Date: Mon, 5 Dec 2011 10:32:18 -0600

> backwards compatible way since there are deployed implementations

Then there's nothing to say about specific major status codes.  Only
GSS_S_FAILURE will do.

> to formulate the spec wo references to NS.

Fair enough.  Since attribute names imply a namespace of attribute
names, we needn't really say anything about that which is implied.  It
seems prudent to anticipate the need for namespaces, but it isn't
strictly necessary, so I'll give on this.

> OK so what does that look like as normative language?

It means writing a paragraph or three elaborating on the text that you
found confusing.  One paragraph would cover the
GSS_Import_name-then-Acquire_credential() case and the other would
cover the GSS_Import_name-thenAdd_cred() case.

> absolutely - I'd just as soon not have it along with normative language.

Meaning you'd be happy to see it in some other section of the same I-D?

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Mon, 5 Dec 2011 10:43:03 -0600

> reasonable.  I'd say MAY SUCCEED and could have my arm twisted into

It seems easier to defer checking mechanism support in the non-MN case
given that the end result is the same (no credential handle) when none
of the available mechanisms understand the given attribute.  The
distinction between success and failure in this one case lies in
whether the application gets to know which specific attributes are not
understood across the board.  This raises the following question: is
it important for applications to be able to use the non-MN case and
determine which attributes are not understood?

If applications will generally all of a set of attributes set on a
name then they don't need to know which attributes are not understood
across the board.  On the other hand, if applications can have
fallback strategies then they do need to know.  Ah, that convinces me:
I want to not preclude that case.  So let's change that to MAY
succeed.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Mon, 5 Dec 2011 11:23:11 -0600

New proposal for section 7.6:

   When the given name object is an MN this function MUST fail (with
GSS_S_FAILURE) if the
   mechanism for which the name is an MN does recognize the attribute
   name or the namespace it belomgs to.  This is because name attributes
   generally have some semantics that mechanisms must understand.

   On the other hand, when the given name is not an MN this function
   MAY succeed even if none of the available mechanisms understand the
   given attribute, in which subsequent credential acquisition attempts
   (via GSS_Acquire_cred() or GSS_Add_cred()) with the resulting name
   MUST fail for mechanisms that don't understand any one or more name
   attributes set with this function.  Applications may wish to use
   a non-MN, then acquire a credential with that name as the desired
   name.  The acquired credentials will have elements only for the
   mechanisms that can carry the name attributes set on the name.

I think that paragraph should be clear now.  Is it?

I'll propose new text with forward-looking statements for an
informative section separately.

Nico
--

---

From: Sam Hartman <[email-masked]>
Date: Mon, 05 Dec 2011 13:29:51 -0500

Nico, I'm happy with your text if you make one substitution:
s:does recognize:does not recognize.

As currently written, mechanisms must reject attributes they understand.
I believe that to be a typo.

---

From: Nico Williams <[email-masked]>
Date: Mon, 5 Dec 2011 12:33:34 -0600

Yes, that's a typo.

---

From: Nico Williams <[email-masked]>
Date: Mon, 5 Dec 2011 13:20:44 -0600

I'd like to add a paragraph about criticality:

  Note that this means that all name attributes are locally critical:
  the mechanism(s) must understand them.  The reason for this is that
  name attributes must necessarily have some meaning that the mechanism
  must understand, even in the case of application-specific attributes
  (in which case the mechanism must know to transport the attribute
  to any peer).  However, there is no provision to ensure that peers
  understand any given name attribute.  Individual name attributes
  may be critical with respect to peers, and the specification of the
  attribute will have to indicate which of the mechanism's protocol or
  the application is expected to enforce criticality.

Nico
--

---

From: Leif Johansson <[email-masked]>
Date: Mon, 05 Dec 2011 20:33:59 +0100

On 12/05/2011 05:32 PM, Nico Williams wrote:
>> I seem to recall strong consensus not to change the API in a
>> non- backwards compatible way since there are deployed
>> implementations already.
> 
> Then there's nothing to say about specific major status codes.
> Only GSS_S_FAILURE will do.

ok but then I'm not an implementor... so I'm not sure how much
weight to give to what I say about this point.

> 
>>>> We don't use the term namespace anywhere else in the spec.
>>>> Lets not introduce new terminology here. Same goes for
>>>> 'element' further down.
>>> 
>>> Indeed, but since we have attribute names it follows that we
>>> have attribute namespaces.  The point is that if we expect
>>> mechanisms to
>> 
>> not really but I take your point. I'm just saying that if we want
>> to introduce namespaces then lets do a proper job or figure out a
>> way to formulate the spec wo references to NS.
> 
> names, we needn't really say anything about that which is implied.
> It seems prudent to anticipate the need for namespaces, but it
> isn't strictly necessary, so I'll give on this.
> 
>>> GSS_Set_name_attribute() then the mechglue doesn't yet know
>>> which mechanism(s) you care about -- the mechglue could try
>>> all mechanisms, but that could be a lot of work, and also
>>> complicates the application, whereas deferring the validity
>>> check to credential acquisition time works much better.
>> 
> It means writing a paragraph or three elaborating on the text that
> you found confusing.  One paragraph would cover the 

sounds good

> Meaning you'd be happy to see it in some other section of the same

Yep.

---

From: Leif Johansson <[email-masked]>
Date: Mon, 05 Dec 2011 20:35:16 +0100

On 12/05/2011 06:23 PM, Nico Williams wrote:
> GSS_S_FAILURE) if the mechanism for which the name is an MN does
> recognize the attribute name or the namespace it belomgs to.  This
> is because name attributes generally have some semantics that
> MAY succeed even if none of the available mechanisms understand
> the given attribute, in which subsequent credential acquisition
> attempts (via GSS_Acquire_cred() or GSS_Add_cred()) with the
> resulting name MUST fail for mechanisms that don't understand any
> one or more name attributes set with this function.  Applications
> may wish to use a non-MN, then acquire a credential with that name
> as the desired name.  The acquired credentials will have elements
> only for the mechanisms that can carry the name attributes set on
> the name.
> 

much better.

---

From: Leif Johansson <[email-masked]>
Date: Mon, 05 Dec 2011 20:36:17 +0100

On 12/05/2011 08:20 PM, Nico Williams wrote:
> Note that this means that all name attributes are locally
> critical: the mechanism(s) must understand them.  The reason for
> this is that name attributes must necessarily have some meaning
> that the mechanism must understand, even in the case of
> application-specific attributes (in which case the mechanism must
> know to transport the attribute to any peer).  However, there is no
> provision to ensure that peers understand any given name attribute.
> Individual name attributes may be critical with respect to peers,
> and the specification of the attribute will have to indicate which
> of the mechanism's protocol or the application is expected to
> enforce criticality.
> 
> Nico --

I think that make sens to include immediately after the new text you
just proposed.

---

From: Nico Williams <[email-masked]>
Date: Mon, 5 Dec 2011 13:40:12 -0600

> weight to give to what I say about this point.

I don't think it's a problem to add new major status codes
specializing GSS_S_FAILURE since GSS_S_FAILURE is so generic and we
can't really define any minor status codes here by which to specialize
it.  Without enough information the application can only assume that
something went wrong, and it might as well do that when receiving any
unknown major status codes.  This is a rule we probably want for the
API as a whole: whenever there are two or more error conditions for
which only GSS_S_FAILURE is specified we can later add a new major
status code to distinguish some of those error conditions.

Nico
--

---

From: Leif Johansson <[email-masked]>
Date: Mon, 05 Dec 2011 20:41:33 +0100

> New proposal for section 7.6:

Are we ok now? Just waiting for Nicos forward-looking text and then
I'll push out -12 unless anyone screams bloody murder in the next
few hrs..

	Cheers Leif

---

From: Nico Williams <[email-masked]>
Date: Mon, 5 Dec 2011 13:41:46 -0600

> I think that make sens to include immediately after the new text you

Yes.

---

From: Nico Williams <[email-masked]>
Date: Mon, 5 Dec 2011 13:47:34 -0600

> I'll push out -12 unless anyone screams bloody murder in the next

Sam indicated support, with a typo correction.  As for the
forward-looking text, just take that one paragraph and add it to the
end of the introduction:

   In the future we may add an attribute namespace for attributes that
   only have application-specific semantics.  But note that mechanisms
   will still need to know how to transport such attributes.  We may
   also wish to add functions by which to inquire whether a mechanism(s)
   understands a given attribute name or namespace, and to list which
   attributes or attribute namespaces a mechanism understands.  Finally,
   we're likely to add a function by which to determine the name of the
   issuer of a name attribute.

Also, w.r.t. local attribute naming... since URIs never separate the
scheme from the rest by two colons, why not reserve two colons for
future extensions or for local name attributes?

Nico
--

---

From: Leif Johansson <[email-masked]>
Date: Mon, 05 Dec 2011 21:06:39 +0100

On 12/05/2011 08:47 PM, Nico Williams wrote:
>> Are we ok now? Just waiting for Nicos forward-looking text and
>> then I'll push out -12 unless anyone screams bloody murder in the
>> next few hrs..
> 
> forward-looking text, just take that one paragraph and add it to
> the end of the introduction:
> 
> attributes.  We may also wish to add functions by which to inquire
> whether a mechanism(s) understands a given attribute name or
> namespace, and to list which attributes or attribute namespaces a
> mechanism understands.  Finally, we're likely to add a function by
> which to determine the name of the issuer of a name attribute.

Call me picky but I'm not big on the 'we' thing in a specification. It
sounds like some cabal that owns the spec that that is only partly true.

> 
> Also, w.r.t. local attribute naming... since URIs never separate
> the scheme from the rest by two colons, why not reserve two colons
> for future extensions or for local name attributes?

Attribute names can be URIs so perhaps http://localhost/bla is enough?
Not sure if two colons is legal...

	Cheers Leif

---

From: "Jim Schaad" <[email-masked]>
Date: Mon, 5 Dec 2011 12:10:15 -0800

+1

Code should be written to allow for unexpected error codes to appear at a
later date and tread as GSS_S_FAILURE.

Jim

> -----Original Message-----
> Sent: Monday, December 05, 2011 11:40 AM
> To: Leif Johansson
> Cc: [email-masked]
> > ok but then I'm not an implementor... so I'm not sure how much weight
> > to give to what I say about this point.
> 
> I don't think it's a problem to add new major status codes specializing
> GSS_S_FAILURE since GSS_S_FAILURE is so generic and we can't really define
> any minor status codes here by which to specialize it.  Without enough
> information the application can only assume that something went wrong,
> and it might as well do that when receiving any unknown major status
codes.
> This is a rule we probably want for the API as a whole: whenever there are
> two or more error conditions for which only GSS_S_FAILURE is specified we
> can later add a new major status code to distinguish some of those error
> conditions.
> 
> Nico
> --
> _______________________________________________
> Kitten mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/kitten

---

From: Nico Williams <[email-masked]>
Date: Mon, 5 Dec 2011 14:13:23 -0600

> sounds like some cabal that owns the spec that that is only partly true.

We here is "the IETF".  I don't see anything wrong with that, but if
you want to feel free to change that text to the passive voice ("In
the future ... may be added").

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Mon, 5 Dec 2011 14:48:02 -0600

> later date and tread as GSS_S_FAILURE.

Do we have more support for this?

If so I'd propose GSS_S_BAD_NAME_ATTR.  And we might also need
GSS_S_BAD_NAME_ATTR_VAL (for when the semantics of the attribute
require that the mechanism understand the value and the value is
invalid).

Nico
--

---

From: Sam Hartman <[email-masked]>
Date: Mon, 05 Dec 2011 16:22:10 -0500

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

    Nico> Also, w.r.t. local attribute naming... since URIs never
    Nico> separate the scheme from the rest by two colons, why not
    Nico> reserve two colons for future extensions or for local name
    Nico> attributes?

I don't support this change.
There are so many better ways to do this when we do it.

---

From: Sam Hartman <[email-masked]>
Date: Mon, 05 Dec 2011 16:26:54 -0500

Nico> On Mon, Dec 5, 2011 at 2:10 PM, Jim Schaad <[email-masked]> wrote:
    >> +1
    >> 
    >> Code should be written to allow for unexpected error codes to
    >> appear at a later date and tread as GSS_S_FAILURE.

    Nico> Do we have more support for this?

I'd kind of prefer not to add a new error code at this point in the
spec's evolution.  However if it were two years ago I'd definitely
support adding the error codes.  Realistically no matter what we say
we'll get GSS_S_FAILURE for a while in the wild.

It's not a big deal to me if we do add the error codes.

---

From: Leif Johansson <[email-masked]>
Date: Mon, 05 Dec 2011 22:46:03 +0100

On 12/05/2011 09:13 PM, Nico Williams wrote:
>> Call me picky but I'm not big on the 'we' thing in a
>> specification. It sounds like some cabal that owns the spec that
>> that is only partly true.
> 
> We here is "the IETF".  I don't see anything wrong with that, but
> if you want to feel free to change that text to the passive voice
> ("In the future ... may be added").
> 
> Nico --

I was trying for "Future specifications may..." but I take your point
and will try for something reasonable...

	Cheers Leif

---

From: Nico Williams <[email-masked]>
Date: Mon, 5 Dec 2011 15:49:40 -0600

On Mon, Dec 5, 2011 at 3:26 PM, Sam Hartman <[email-masked]> wrote:
>    >> +1
>    >>
>    >> Code should be written to allow for unexpected error codes to
>    >> appear at a later date and tread as GSS_S_FAILURE.
>

I don't mind if applications get GSS_S_FAILURE for a while.  I would
rather we specify a new status code now, but it's not a big deal if we
don't.

> It's not a big deal to me if we do add the error codes.

So is that a yes or a no? :)

Nico
--

---

From: Luke Howard <[email-masked]>
Date: Tue, 6 Dec 2011 09:16:12 +1100

Existing implementations return GSS_S_UNAVAILABLE if the attribute is absent, from memory this is consistent with the draft. Apologies if you were talking about something else (e.g. bad attribute syntax).

-- Luke

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

---

From: Nico Williams <[email-masked]>
Date: Mon, 5 Dec 2011 16:21:43 -0600

> Existing implementations return GSS_S_UNAVAILABLE if the attribute is absent, from memory this is consistent with the draft. Apologies if you were talking about something else (e.g. bad attribute s…

Oh, I completely missed that.  Emily Litella moment for me..  (i.e.,
"never mind").

---

From: Leif Johansson <[email-masked]>
Date: Tue, 06 Dec 2011 09:23:47 +0100

On 12/05/2011 11:16 PM, Luke Howard wrote:
> Existing implementations return GSS_S_UNAVAILABLE if the attribute
> is absent, from memory this is consistent with the draft. Apologies
> if you were talking about something else (e.g. bad attribute
> syntax).
> 
Yes that is what we're talking about and I think Nico wants
to change that to something else.

---

From: Leif Johansson <[email-masked]>
Date: Tue, 06 Dec 2011 15:07:31 +0100

On 12/05/2011 11:21 PM, Nico Williams wrote:
>> Existing implementations return GSS_S_UNAVAILABLE if the
>> attribute is absent, from memory this is consistent with the
>> draft. Apologies if you were talking about something else (e.g.
>> bad attribute syntax).
> 
> Oh, I completely missed that.  Emily Litella moment for me..
> (i.e., "never mind").

Yeah but this is how the discussion got started. The text you now
said "never mind" about is the very text you wanted to change!

	Cheers Leif

---

From: Martin Rex <[email-masked]>
Date: Tue, 6 Dec 2011 18:10:17 +0100 (MET)

Nico Williams wrote:
> it.

Huh?

A GSS-API mechanism that returns GSS_S_FAILURE *without* and accompanying
minor_status that translates into something that the end user can
understand would be thoroughly broken.

   http://tools.ietf.org/html/rfc2744#page-14

   The GSS major status code GSS_S_FAILURE is used to indicate that the
   underlying mechanism detected an error for which no specific GSS
*> status code is defined.  The mechanism-specific status code will
*> provide more details about the error.                      ^^^^^^

>
> Without enough information the application can only assume that
> unknown major status codes.

In theory, portable applications can distinguish major status codes
in order to use a programmatic remedy.  i.e. an expired GSS-API
security context could be worked around by establishing a new
security context.  But in general, programmatic recovery from any
GSS-API errors is quite difficult.  With GSS_S_FAILURE and
mechanism-specific (and most of the time implementation-specific)
error codes, programmatic recovery is limited to non-portable
apps when used with specific implementations.

>
> This is a rule we probably want for the

That sounds like a very bad idea.  Because if there are error codes
where distinguishing them at the mechanism level helps the user,
some apps might code to recognize GSS_S_FAILURE in combination
with the minor_status value.  If you later define new major
status codes and change the gssapi mechanism, you're going to
break those apps in the installed base that work on recognizing
the minor_status value.

-Martin

---

From: Leif Johansson <[email-masked]>
Date: Fri, 16 Dec 2011 23:58:52 +0100

> ("In the future ... may be added").

Yeah If I can think of a way to give it some polish I will and if not
I'll just use your text. In either case I'll drop a new version shortly.

	Cheers Leif