Subject: [kitten] [Technical Errata Reported] RFC6680 (4337)

From: RFC Errata System <[email-masked]>
Date: Sat, 18 Apr 2015 14:52:22 -0700 (PDT)

The following errata report has been submitted for RFC6680,
"Generic Security Service Application Programming Interface (GSS-API) Naming Extensions".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=6680&eid=4337

--------------------------------------
Type: Technical
Reported by: Benjamin Kaduk <[email-masked]>

Section: 7.5

Original Text
-------------
   This function outputs the value(s) associated with a given GSS name
   object for a given name attribute.

Corrected Text
--------------
   This function outputs the value(s) associated with a given GSS name
   object for a given name attribute.  It is permitted to block pending
   network interactions when the attr input is not an attribute which
   would be included in the attrs output of a call to GSS_Inquire_name()
   on the same name input.

Notes
-----
RFC 6680 makes no mention of blocking or not blocking on network interaction, though RFC 2743 does.  This seems like the most reasonable interpretation of what is currently in RFC 6680.  Calls which are not explicitly permitted to block are assumed to be not permitted to block.

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC6680 (draft-ietf-kitten-gssapi-naming-exts-15)
--------------------------------------
Title               : Generic Security Service Application Programming Interface (GSS-API) Naming Extensions
Publication Date    : August 2012
Author(s)           : N. Williams, L. Johansson, S. Hartman, S. Josefsson
Category            : PROPOSED STANDARD
Source              : Common Authentication Technology Next Generation
Area                : Security
Stream              : IETF
Verifying Party     : IESG

---

From: Kathleen Moriarty <[email-masked]>
Date: Sat, 18 Apr 2015 18:49:34 -0400

Authors,

Please let us know what you think and if you agree with the errata, is the proposed text good.

We are trying to reduce work load a bit and have chairs/authors handling errata.  Stephen and I will update once we have received guidance.

Thanks,
Kathleen 

Sent from my iPhone

> On Apr 18, 2015, at 5:52 PM, RFC Errata System <[email-masked]> wrote:
>

---

From: Sam Hartman <[email-masked]>
Date: Sun, 19 Apr 2015 16:19:40 -0400

I really don't think we considered blocking when developing 6680.
I think this is something that if we're going to discuss we need a full
IETF consensus to say.

I think that the proposed text would be a good starting point, for this
API.
My concern is that other APIs in the document might block, and that I
think that a WG such as kitten should fully consider the issue rather
than using the erata process for this issue.

If Ben's aware of discussion in the kitten archives that show we
considered blocking and intended it to be the case that calls not
explicitly mentioned as blocking cannot block, then  I'd support
theerrata.
OTherwise, I'd prefer a new document address this concern.

I'll note that we cannot really say that a call never blocks.  An
implementation may have network swap or executable segments that are
demand page over a network filesystem.  An implementation may use
nsswitch resources that consult network databases, etc.
The best we can say is that it's reasonable to write applications
assuming certain APIs do not generally block.

---

From: Nico Williams <[email-masked]>
Date: Sun, 19 Apr 2015 18:08:48 -0500

> I think this is something that if we're going to discuss we need a full

I did think about it, though I don't recall specific on-the-list
discussions about it, I'm certain I discussed it with someone.  In
particular I had wanted to consider UID/GID/SID lookups.  My intention
was roughly as per-Ben's proposed text.

> than using the erata process for this issue.

I object neither to the erratum, nor to an update.  I think this erratum
is sufficient for now, and we can work on an update to specify blocking
behavior in more detail.

We could update the erratum to add a list of what should be
non-controversial non-blocking behaviors:

 - GSS_Inquire_name() (of course, otherwise Ben's text doesn't work)
 - GSS_Get_name_attribute() for attributes listed by GSS_Inquire_name()
 - GSS_Export_name_composite()
   (and any call to GSS_Import_name() to import an exported composite
   name token)

We might also want to say that specific attributes not listed by
GSS_Inquire_name() may yield blocking or non-blocking behavior in
GSS_Get/Set_name_attribute() according to the attributes'
specifications.

> assuming certain APIs do not generally block.

Yes.  Defining "non-blocking" and "blocking" is non-trivial.  What kinds
of I/O are slow (network) or fast (per-Unix: file I/O is fast)?  Does a
long-running CPU-bound computation count as blocking?

Nico
--

---

From: Sam Hartman <[email-masked]>
Date: Mon, 20 Apr 2015 09:37:37 -0400

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

    Nico> On Sun, Apr 19, 2015 at 04:19:40PM -0400, Sam Hartman wrote:
    >> I think this is something that if we're going to discuss we need
    >> a full IETF consensus to say.

    Nico> I did think about it, though I don't recall specific
    Nico> on-the-list discussions about it, I'm certain I discussed it
    Nico> with someone.  In particular I had wanted to consider
    Nico> UID/GID/SID lookups.  My intention was roughly as per-Ben's
    Nico> proposed text.

Well, I agree that we did think that things might block.
I am less clear that we thought about anything specific that wouldn't
block, and I'm concerned introducing this text implies there are things
that don't block.

---

From: Alejandro Perez Mendez <[email-masked]>
Date: Mon, 20 Apr 2015 16:55:45 +0200

> block, and I'm concerned introducing this text implies there are things

I agree with Sam's view. How can we assure that something doesn't block 
on a pending network interactions? Is a DNS query a pending network 
interaction? Or retrieving a DTD for XML validation? Or querying a SQL 
database using a connection to localhost. In principle, we could assume 
that any call to the "open/read/write" functions are potentially blocking.

 From my point of view, since the GSS is an API, one might assume the 
caller should not be aware of how each specific call is actually 
implemented. What's the purpose of knowing that something does not 
block? If the purpose is avoiding the caller to wait too much (or even 
forever) for a result, probably the best option would be to allow 
specifying some sort of timeout after which the caller will either 
receive a valid result, or obtain an ERROR (e.g. GSS_C_CALL_TIMEOUT).

Regards,
Alejandro

> _______________________________________________
> Kitten mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/kitten

---

From: Nico Williams <[email-masked]>
Date: Mon, 20 Apr 2015 10:53:15 -0500

> block, and I'm concerned introducing this text implies there are things

I always thought that attributes listed in GSS_Inquire_name() wouldn't
block: because they are would be "raw" things in Kerberos
authorization-data or similar.

Also, have you seen draft-williams-kitten-generic-naming-attributes-02 ?

That I-D uses your idea of attribute name prefixing to control a variety
of things.  It makes blocking/non-blocking attribute-specific for some
attribute prefixes.  In particular it adds a generic attribute prefix to
indicate the application's desire to not block.  I think this is the
right approach, and I think it was your idea.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Mon, 20 Apr 2015 10:54:09 -0500

On Mon, Apr 20, 2015 at 04:55:45PM +0200, Alejandro Perez Mendez wrote:
> I agree with Sam's view. How can we assure that something doesn't
> block on a pending network interactions? [...]

Please see draft-williams-kitten-generic-naming-attributes-02.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Mon, 20 Apr 2015 11:18:49 -0500

draft-williams-kitten-generic-naming-attributes-02 defines an attribute
prefix, GSS_C_ATTR_GENERIC_FAST, to denote "please be fast/non-blocking".

This works because if the mechanism/mechglue doesn't understand the
composed attribute, then it must fail.  And if it does understand it,
then it must fail if it can't satisfy the constraint.

This shows that we don't need to update RFC6680 so much as we need to
publish an RFC defining generic attributes and attribute prefixes like
this one.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Mon, 20 Apr 2015 11:23:56 -0500

> prefix, GSS_C_ATTR_GENERIC_FAST, to denote "please be fast/non-blocking".

We could also add an attribute prefix by which to request that the
mechanism implement a [POSIX thread] cancellation point around getting
an attribute, thus making it easier for callers to impose timeouts.

We could also have an attribute that imposes a particular timeout,
though that requires baking the timeout value into the attribute name,
and so that's a bit obnoxious.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Mon, 20 Apr 2015 11:26:21 -0500

I think Alejandro may need a batched get attributes function.  That
would decidedly be an update.

---

From: Sam Hartman <[email-masked]>
Date: Mon, 20 Apr 2015 12:34:53 -0400

>> I am less clear that we thought about anything specific that
    >> wouldn't block, and I'm concerned introducing this text implies
    >> there are things that don't block.

    Nico> I always thought that attributes listed in GSS_Inquire_name()
    Nico> wouldn't block: because they are would be "raw" things in
    Nico> Kerberos authorization-data or similar.

I agree that we should write applications assuming they will be fast.
That's very different from non-blocking for reasons including the ones I
already explained: network swap, demand paging over the net, database
lookups for things like nss etc that you'd expect to be fast but
sometimes aren't.

Basically, I don't think the IETF is in a position to say something is
non-blocking because there are many reasonable implementations where
that's simply impossible to implement.
We can talk about whether an application should be prepared for an API
to take a while.
I think that attributes listed in the return from inquire_name are
things an application can assume will be relatively fast compared to
ones not in inquire_name.

---

From: Nico Williams <[email-masked]>
Date: Mon, 20 Apr 2015 11:35:20 -0500

> would decidedly be an update.

Actually, it seems that Alejandro needs to be able to request name
attributes that should come in a security context token.  That's a
significant complication.  And it may be a great use for asynchronous
context tokens!

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Mon, 20 Apr 2015 11:42:26 -0500

> lookups for things like nss etc that you'd expect to be fast but

My take is this: if reading [what should be] a local configuration file
results in slow I/O, then all is lost when it comes to being
non-blocking.  The same applies to swapping.

So, if I ask for "fast" behavior, I should get "fast" behavior given the
constraints of the running environment.  E.g., bare metal with close-by
local storage all cached in memory anyways, vs. VM guests with
all-remote "local" storage.  Using standard, portable APIs, the
implementation can't tell if reading a "local" configuration file, or a
memory allocation of some non-trivial size, will be slow, but it also
doesn't have to.

> that's simply impossible to implement.

We don't have to be too exact.

> We can talk about whether an application should be prepared for an API

That's what my I-D does.

> ones not in inquire_name.

Yes, but consider an attribute prefix that demands "relatively fast"
service.  A mechanism must fail if it doesn't understand that prefix.
And if it does understand it, then it must fail if it can't satisfy the
requested constraint.

Nico
--

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 20 Apr 2015 13:44:07 -0400 (EDT)

> OTherwise, I'd prefer a new document address this concern.

This is somewhat overcome by events, but when submitting this erratum, I
considered only the recent (past month) discussions on kitten.  I did not
investigate discussions back from when the document was still being
developed.

-Ben

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 20 Apr 2015 14:03:16 -0400 (EDT)

> is sufficient for now, and we can work on an update to specify blocking

It sounds like the main objection to the current proposed erratum text is
in the COMMENT, "Calls which are not explicitly permitted to block are
assumed to be not permitted to block."  Though the new text which
explicitly calls out the attrs output of GSS_Inquire_name() does still
have some implicit implications that some calls do not block, as well.

I am not tied to the comment text; we could remove it and still have an
erratum which stands on its own.  It is a bit harder to excise the
implicit implication from the new text.

> long-running CPU-bound computation count as blocking?

These both are getting to seem like fairly substantial changes which do
not seem appropriate for an erratum, to me.  It's also unclear that the WG
has sufficient energy to do a full 6680bis right now.

I will also note that we can choose to mark the current (small) 6680
erratum as Verified or Hold for Document Update, if we want to accept it;
the latter may be more appropriate given Sam's concerns.

-Ben

---

From: Sam Hartman <[email-masked]>
Date: Mon, 20 Apr 2015 14:07:36 -0400

>>>>> "Benjamin" == Benjamin Kaduk <[email-masked]> writes:

    Benjamin> It sounds like the main objection to the current proposed
    Benjamin> erratum text is in the COMMENT, "Calls which are not
    Benjamin> explicitly permitted to block are assumed to be not
    Benjamin> permitted to block."  Though the new text which explicitly
    Benjamin> calls out the attrs output of GSS_Inquire_name() does
    Benjamin> still have some implicit implications that some calls do
    Benjamin> not block, as well.

    Benjamin> I am not tied to the comment text; we could remove it and
    Benjamin> still have an erratum which stands on its own.  It is a
    Benjamin> bit harder to excise the implicit implication from the new
    Benjamin> text.

Yeah, the comment is what caused me to have a concern.
I think adding a note that this call can block would be helpful.

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 20 Apr 2015 19:36:16 -0400 (EDT)

> lookups for things like nss etc that you'd expect to be fast but

I do not disagree.

I used the term "block" in the erratum submission because that is the
terminology used in RFC 2743, and the erratum should be consistent with
the current base spec.

> We can talk about whether an application should be prepared for an API

That's probably a better set of language to use, yes.  We should keep it
in mind when we pick up a 6680bis or 2743bis.

-Ben

---

From: Kathleen Moriarty <[email-masked]>
Date: Mon, 20 Apr 2015 20:19:10 -0400

As Sam said, we can put a note in it and can edit the text of the proposed errata.  Tell us what this changes are and either Stephen or I will update and mark the errata.

Thanks,
Kathleen 

Sent from my iPhone

> On Apr 20, 2015, at 7:36 PM, Benjamin Kaduk <[email-masked]> wrote:
>

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 22 Apr 2015 13:50:31 -0400 (EDT)

[Removing the ADs from the cc list until discussion is complete]

> I think adding a note that this call can block would be helpful.

Okay, I propose then that we modify the comment text in the reported
erratum, and mark it as "hold for document update" (not "verified").  Does
this proposal seem agreeable to everyone as a path forward?  Other
document updates could then proceed via the normal paths.

OLD COMMENT:

RFC 6680 makes no mention of blocking or not blocking on network
interaction, though RFC 2743 does. This seems like the most reasonable
interpretation of what is currently in RFC 6680. Calls which are not
explicitly permitted to block are assumed to be not permitted to block.

NEW COMMENT:

RFC 6680 makes no mention of blocking or not blocking on network
interaction, though RFC 2743 does. This seems like the most reasonable
interpretation of what is currently in RFC 6680.

-Ben

---

From: Sam Hartman <[email-masked]>
Date: Wed, 22 Apr 2015 13:59:28 -0400

I'm fine with the new comment, but I'd recommend marking approved.
We can still do the update

---

From: Nico Williams <[email-masked]>
Date: Wed, 22 Apr 2015 13:19:22 -0500

> We can still do the update

+1