Subject: [kitten] WGLC on draft-ietf-kitten-gssapi-naming-exts-11

From: Shawn Emery <[email-masked]>
Date: Thu, 26 May 2011 00:39:15 -0600

This message officially starts the 3rd kitten Working Group Last Call 
for the following document:

GSS-API Naming Extensions
http://tools.ietf.org/html/draft-ietf-kitten-gssapi-naming-exts-11

The Working Group Last Call for this document starts today on Thursday, 
May 26th and will end on Thursday, June 9th.

Please send any comments to the kitten mailing list or directly to the 
chairs. Feed-back from reviews that found no issues are also welcome.

Thank you,

Shawn Emery, kitten WG co-chair
--

---

From: Sam Hartman <[email-masked]>
Date: Fri, 27 May 2011 13:09:36 -0400

During the discussions that we held, the authors discovered an issue
that we had not previously discussed.

One possible resolution is to do nothing.

It's possible that you could set an attribute  on a name used to acquire
credentials or on an attribute used as target name in
gss_init_sec_context.

It's possible that such an attribute could have semantics that were
intended to change the behavior of acquire_cred or init_sec_context.  We
have no such attributes specified and at least currently I'm not aware
of plans to specify such attributes although I've at least had thought
experiments where doing something like this might have been the right
approach.

This draft is silent on what happens if such an attribute is set and for
whatever reason the effect of that attribute cannot be carried out.
The typical GSS-API philosophy is that applications need to check to see
if optional services are provided, so this may be the right approach.

I said I'd write up this situation and discuss whether we want to have
some text about this issue.

I think all the authors would be happy to wait until someone actually
proposes such an attribute before deciding to do something about this.
I suspect some people (Martin) may even argue that no such attributes
should exist.

--Sam

---

From: Luke Howard <[email-masked]>
Date: Fri, 27 May 2011 13:12:52 -0400

> experiments where doing something like this might have been the right

Right, I certainly implemented something like this for MIT.

-- Luke

---

From: Nico Williams <[email-masked]>
Date: Fri, 27 May 2011 14:03:15 -0500

> that we had not previously discussed.

I believe we did discuss it, years ago, when this work was first proposed.

> I suspect some people (Martin) may even argue that no such attributes

I would prefer that we cover this now.

Here's my proposal: add an 'int critical' argument to
GSS_Set_name_attribute() to indicate whether it is critical that the
mechanism understand the given attribute wherever the name is used as
an input, and allow the mechanism to ignore non-critical attributes
that it doesn't understand.

Nico
--

---

From: Luke Howard <[email-masked]>
Date: Fri, 27 May 2011 15:07:17 -0400

> that it doesn't understand.

Don't forget we (Heimdal and MIT) are shipping since some time now, not changing the ABI would be nice.

-- Luke

---

From: Nico Williams <[email-masked]>
Date: Fri, 27 May 2011 14:11:02 -0500

> Don't forget we (Heimdal and MIT) are shipping since some time now, not changing the ABI would be nice.

Ah, I had forgotten, yes.  What are the current semantics of these
implementations w.r.t. name attributes set via this function?  Is this
in use at all?  Would it be safe to say that these attributes are
always critical then?  That would be the best solution...

Nico
--

---

From: Luke Howard <[email-masked]>
Date: Fri, 27 May 2011 15:16:10 -0400

> always critical then?  That would be the best solution...

Well, we return GSS_S_UNAVAILABLE if the attribute is not recognised. I don't think there are any shipping plugins that define the semantics of particular attributes. In the Kerberos case, it's up to the plugin whether to make the attribute AD-If-Relevant, if that's what you meant by criticality.

-- Luke

---

From: Nico Williams <[email-masked]>
Date: Fri, 27 May 2011 14:24:03 -0500

> Well, we return GSS_S_UNAVAILABLE if the attribute is not recognised. I don't think there are any shipping plugins that define the semantics of particular attributes. In the Kerberos case, it's up…

That's not the only thing I meant by criticality.  Imagine an
attribute that corresponds to Kerberos realm, or, perhaps, transit
path: in this case criticality would refer to the mechanism ensuring
that the target is in the given realm or across the given transit
path.

Ah... I think it'd be quite fine if we said that these attributes are
non-critical, and that the caller has to inquire any resulting
credentials' or security contexts' target names to see what resulted.

Nico
--

---

From: Sam Hartman <[email-masked]>
Date: Fri, 27 May 2011 15:34:29 -0400

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

    Nico> I would prefer that we cover this now.

    Nico> Here's my proposal: add an 'int critical' argument to
    Nico> GSS_Set_name_attribute() to indicate whether it is critical
    Nico> that the mechanism understand the given attribute wherever the
    Nico> name is used as an input, and allow the mechanism to ignore
    Nico> non-critical attributes that it doesn't understand.

I'm against changing the function signature of anything specified by C
bindings in this document.  I'd support adding a new API in a future
document (set_critical_attribute) if we need it.

---

From: Sam Hartman <[email-masked]>
Date: Fri, 27 May 2011 15:39:41 -0400

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

    Nico> Ah... I think it'd be quite fine if we said that these
    Nico> attributes are non-critical, and that the caller has to
    Nico> inquire any resulting credentials' or security contexts'
    Nico> target names to see what resulted.

I'm also against this proposal because it is impractical. In particular,
in a mechanism like iakerb, when do you actually find out if the
attribute is being respected? What about a mechanism like Moonshot's
implementation of gss-eap that sometimes goes through Kerberos but
sometimes does not?

I think I'm with Simon and we should not go into this now.

In particular, I think it's unreasonable to ask the application to check
after every call to init_sec_context.  Even if you buy it's reasonable
to ask the application to check the resulting context, which I am
dubious about, it's not clear whether asking the application to check
after the first call is good enough and asking the application to check
at the end can be highly problematic.
  Solutions I can live with in the
future:

* gss_set_critical_name_attribute or whatever

* A mechanism attribute indicating a mechanism understands some
  well-defined set of attributes.

---

From: Luke Howard <[email-masked]>
Date: Fri, 27 May 2011 15:41:10 -0400

If you really want to add a flag and keep the ABI, we could make the complete argument a bit mask in the API bindings, but it's kind of ugly as we'd normally use OM_uint32 for that.

-- Luke

---

From: Nico Williams <[email-masked]>
Date: Fri, 27 May 2011 14:49:15 -0500

Going by what you say, Sam, I have the impression that nothing's
really using this function yet, so then why don't we say that all
attributes set with it are critical in that the mechanism must
understand them?

---

From: Nico Williams <[email-masked]>
Date: Fri, 27 May 2011 14:50:06 -0500

> If you really want to add a flag and keep the ABI, we could make the complete argument a bit mask in the API bindings, but it's kind of ugly as we'd normally use OM_uint32 for that.

Actually, that's not a bad idea.  I kinda like it.

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 27 May 2011 22:12:47 +0200

My preference is to defer any additions, unless we identify some reason
why it cannot be done later and that it has to be done in this document.

I'm not convinced it is sufficient to have a boolean critical flag.

For example, it may be that the local mechaninism understands an
attribute, and attempts to enforce it, but was not able to (due to the
server or something else).  The security context establishment could
fail in this case.  It may better to proceed and to let the application
query the security context for what happened.

Thus, I propose applications invoke GSS_Inquire_context to get
"targ_name" once the context is established (or even before it) and use
GSS_Get_name_attribute to extract some attributes, and that these
attributes and their value is what the application looks at.  It is just
a matter of defining some attributes that means whatever we want them to
mean, including "that other attribute was honored during this context
establishment".  If the application asserted one attribute, that
attribute could specify two other attributes that is returned after the
context is established, one would be present if the mechanism supported
the attribute, and another could be present if the mechanism supported
the attribute and it did something useful.

Would this work?

/Simon

---

From: Luke Howard <[email-masked]>
Date: Fri, 27 May 2011 16:19:06 -0400

> Actually, that's not a bad idea.  I kinda like it.

Hmm. Aesthetically, not so nice.

-- Luke

---

From: Nico Williams <[email-masked]>
Date: Fri, 27 May 2011 15:28:44 -0500

> why it cannot be done later and that it has to be done in this document.

I'd rather first see if we can resolve this now.  We have until WGLC
ends to do before we decide to punt.

> the attribute and it did something useful.

I proposed using inquiry functions to find out what happens because
there's precedent for it in the GSS-API (think of non-MN targ_name
values passed to GSS_Init_sec_context()).

Sam didn't like that approach, but I don't see what else we could do
regarding security context establishment.  For some mechanisms there
may not be any way to determine support for a given target name
attribute until the target thinks the context is fully established.

We could make name attributes critical relative to credential acquisition.

It'd be odd, but OK with me, to make name attributes critical only for
credential acquisition but not security context target.

Nico
--

---

From: Sam Hartman <[email-masked]>
Date: Sat, 28 May 2011 11:06:30 -0400

Nico> On Fri, May 27, 2011 at 3:12 PM, Simon Josefsson <[email-masked]> wrote:
    >> My preference is to defer any additions, unless we identify some
    >> reason why it cannot be done later and that it has to be done in
    >> this document.

    Nico> I'd rather first see if we can resolve this now.  We have
    Nico> until WGLC ends to do before we decide to punt.

There's no way I'll be happy with a solution now.  I've convinced myself
the problem is a bit tricky. I've convinced myself that:

* A critical flag is difficult to specify and may be insufficient. I can
  think of multiple things it could mean

* Ignoring the issue and having the initiator look at the resulting
  context is undesirable and for things like restrictions on a ticket
  possibly actively harmful

* I can't see any reason to decide this now.

I also don't have a lot of time to think about this.
So, I have a strong preference for doing nothing unless it can be shown
that doing nothing is harmful.

---

From: Nico Williams <[email-masked]>
Date: Sat, 28 May 2011 10:49:17 -0500

>  possibly actively harmful

All the more reason to get criticality right right now.  Or at least
know that we're not painting ourselves into any corners.

For example, I think we should remove the set-attribute function if we
choose to not resolve its semantics now, as implementors will be
forced to pick some semantics for it, which will then cause us trouble
down the line.  Worse, since implementors already ship that and will
want to continue doing so, we kinda need to clarify its semantics now.

> * I can't see any reason to decide this now.

See above

> I also don't have a lot of time to think about this.

There's no need to hurry though, is there?  If we're not readyto pass
WGLC, we can wait until a more opportune time.

> that doing nothing is harmful.

Well, if different implementors implement different semantics for this
function, that will cause some harm -- not a lot, perhaps not enough
for us to bother nailing this down, but I think we should try.

Nico
--

---

From: Simon Josefsson <[email-masked]>
Date: Sun, 29 May 2011 09:06:08 +0200

> want to continue doing so, we kinda need to clarify its semantics now.

I'm not following this -- why are implementations forced to resolve this
semantics now?  Why can't the semantics wrt credential acquisition be
attribute specific?

/Simon

---

From: Nico Williams <[email-masked]>
Date: Sun, 29 May 2011 02:19:43 -0500

On Sun, May 29, 2011 at 2:06 AM, Simon Josefsson <[email-masked]> wrote:
> semantics now?  [...]

This is our chance to make sure that different implementations don't
provide different, incompatible semantics.  I happen to think that
that's important.

>           [...]  Why can't the semantics wrt credential acquisition be
> attribute specific?

The issue is that the set-attribute function's semantics need to be clear.

As for whether the semantics should be attribute-specific, well, if
there's any way in which an attribute's being set on a name prior to
credential acquisition or prior to using the name as a target name,
could be meaningful...  What else could that meaning be if not that
the resulting authenticated principal's name will bear that attribute?
 Consider an attribute for naming a trust path (think of a Kerberos
transited path, or a PKI certificate validation path): surely we'll
want a name attribute to indicate trust path, and surely setting the
trust path attribute on a name should actually result in that trust
path being required.  Maybe it's because it's late, but I can't think
of any attributes that one wouldn't want to work this way.

So we only have to decide criticality.  Sam makes a very good case for
criticality being the default.  Privately Sam asked if it'd make a
difference if an attribute was set on an MN versus a non-MN -- I think
that would be an interesting way to distinguish between critical and
non-critical.

Nico
--

---

From: Simon Josefsson <[email-masked]>
Date: Sun, 29 May 2011 20:47:26 +0200

> provide different, incompatible semantics.  I happen to think that

I agree -- but if each attribute provides guidance, surely implementers
of those attributes will behave the same?  Is your worry that we don't
provide enough guidance to people specifying attributes?

> of any attributes that one wouldn't want to work this way.

I can think of plenty of attributes that would not demand that the
target name has the same attribute.  For example, the attribute named
"http://josefsson.org/ foobar" that I define now to mean absolutely
nothing.  If an application set that attribute on a name, and establish
a security context to that target name, the target name would not
necessarily have that attribute asserted.

/Simon