Subject: [kitten] Consensus Calls for draft-ietf-kitten-gssapi-naming-exts-11

From: Shawn Emery <[email-masked]>
Date: Wed, 26 Oct 2011 12:06:25 -0600

This starts a consensus call for changes to 
draft-ietf-kitten-gssapi-naming-exts-11.  The call expires in two weeks 
(by 11/9/11).

1.1 Change the draft to clarify attributes that are not understood:

The proposed change is:

Add the following paragraph as the first paragraph of text (after the
specification text) in 7.6:

"An implementation SHOULD return GSS_S_UNAVAILABLE as indicated above
if the attribute and its semantic is not understood by implementation.
Allowing arbitrary attribute names to be set may alter the security
properties of the established context."

1.2 Change the draft to support a critical argument.  Text to be proposed.

1.3 Leave the draft as is.

1.4 Need more information.

2.1 Change the draft to remove attribute OID references:

Changing all occurrences of the term "attribute OID" to
"attribute name" This is a residue from an earlier version of this
draft when names were still OIDs. Arguably a minor nit.

2.2 Leave the draft as is.

2.3 Need more information.

Shawn.
--

---

From: Nico Williams <[email-masked]>
Date: Wed, 26 Oct 2011 16:04:14 -0500

> properties of the established context."

Can we have some guidance for when this function might be useful?

Possible use cases:

 - To request that the given attribute be present (how about absent?)
in the name to be authenticated by a credential to be acquired later
with the given NAME object as desired_name (the one on which the
attribute is being set).  Note that for this use case the caller may
want to know with certainty that credentials acquired with this NAME
will bear the given attribute (see below).

 - To modify a NAME object that will be passed to another part of the system.

We probably need to state that modifying a NAME does not modify any
credentials previously acquired with the same desired_name NAME object

I don't understand the sentence that starts with "The peer being an
authoritative...".

> 1.2 Change the draft to support a critical argument.  Text to be proposed.

I propose not adding a critical argument.  Instead I propose stating
that GSS_Acquire_cred() and friends can fail with either a new major
status code or with an appropriate minor status code by which to
indicate that a name attribute set with GSS_Set_name_attribute() could
not be honored.  OR, alternatively, I propose that attributes that
cannot be asserted for whatever reason be silently ignored: the
application can inquire the resulting credential to see that the
desired attributes will be asserted.

> draft when names were still OIDs. Arguably a minor nit.

I support this.

Nico
--

---

From: Luke Howard <[email-masked]>
Date: Thu, 27 Oct 2011 10:40:10 +1100

> desired attributes will be asserted.

+1 for not changing API signatures

-- Luke

---

From: Nico Williams <[email-masked]>
Date: Wed, 26 Oct 2011 18:47:12 -0500

> +1 for not changing API signatures

Agreed.  It's too late to change the function signatures.

Which of the two behaviors I propose do you prefer?  Both strike me as
obnoxious, but I prefer the second of the two I proposed on the theory
that most uses of GSS_Set_name_attribute() will be non-critical.  If
that theory is wrong then let's go with the first behavior.

Nico
--

---

From: Leif Johansson <[email-masked]>
Date: Thu, 27 Oct 2011 09:27:35 +0200

> that theory is wrong then let's go with the first behavior.

Nico - I'm not sure which alternative you indicated or if you wanted
to propose alternative text, can you clarify please?

	Cheers Leif

---

From: Nico Williams <[email-masked]>
Date: Thu, 27 Oct 2011 09:08:29 -0500

> to propose alternative text, can you clarify please?

In the text quoted by Luke above there's two proposed changes
separated by "OR".  I did not propose text because I didn't know which
of the two changes we'd want.  However, I've come to realize that only
the second alternative is workable, therefore I propose the following
addition to section 7.6 (say, at the end of it):

   GSS_Set_name_attribute() MAY succeed even though a credential acquired
   with the resulting NAME may not actually result in a peer seeing the given
   attribute.  If it is critical that the attribute be asserted in
subsequent security
   context establishments, then the caller must inquire the NAME for any
   CREDENTIAL HANDLE acquired with this NAME and then check that the
   requested attribute has indeed been set in the CREDENTIAL HANDLE's
   NAME.

Nico
--

---

From: Leif Johansson <[email-masked]>
Date: Thu, 27 Oct 2011 16:36:40 +0200

>    requested attribute has indeed been set in the CREDENTIAL HANDLE's

Silently ignoring attributes feels like a bad idea.

The current text basically already sais that setting unknown attributes
results in an error. My proposal (1.1) just clarifies that text and does
not change any API signatures.

You want to go from "return error" to "silently ignore". Help me
understand why that is better.

	Cheers Leif

---

From: "Cantor, Scott" <[email-masked]>
Date: Thu, 27 Oct 2011 14:42:04 +0000

>Silently ignoring attributes feels like a bad idea.

I think it makes sense in context. If you're setting attributes onto a
name that is to be used as input to credential acquisition, you're making
a request for something. The change is saying you can request anything,
but enforcement is up to you afterwards. That is much more likely to work
reliably.

That's a different use case from setting an attribute on an established
context. I don't know what "unknown" means in that context, since
whatever's doing the setting is probably trusted by the application.

-- Scott

---

From: Nico Williams <[email-masked]>
Date: Thu, 27 Oct 2011 10:18:32 -0500

> Silently ignoring attributes feels like a bad idea.

Yes, but how can the mechglue/mech know at this time that a credential
to be acquired with this name *later* will be able to assert the
requested attribute??

I don't think it can.  That's why I made the above proposal.

> not change any API signatures.

That works for unknown attributes, though what exactly is "unknown"
here?  Unknown to the world or to the mechglue or to the mech?

Also, presumably the input NAME has to be an MN, otherwise the only
way a mech gets a crack at this is either *later* (in which case we
must be able to silently ignore some attrs) or if the mechglue invokes
every mech (but then any mech that fails fails the whole thing).

It has to be as I proposed.  Alternatively we'd need a different API
that works on the name of a CREDENTIAL HANDLE.

> understand why that is better.

See above.

Nico
--

---

From: Leif Johansson <[email-masked]>
Date: Fri, 28 Oct 2011 09:34:21 +0200

> I don't think it can.  That's why I made the above proposal.

OK now I actually get it. I think your proposal makes sense...

	Cheers Leif