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

From: Simon Josefsson <[email-masked]>
Date: Wed, 02 Mar 2011 11:39:58 +0100

I believe this document needs more work on the API descriptions and it
is not ready for publication.  I started a review with details below,
but stopped when I had found too many problems.

Section 7.1:

   o  name NAME,

Should be INTERNAL NAME?

   o  display_name STRING

Should be OCTET STRING?  Further, it should specify memory allocation
considerations like RFC 2743 does.  I suggest:

   o  display_name OCTET STRING, -- caller must release
   -- with GSS_Release_buffer()

Section 7.1.1 is just a sketch, compare with how RFC 2744 is written.
Also, the C function name should be lower-cased.

Section 7.2:

   o  name NAME

Should be INTERNAL NAME again?

Memory de-allocation considerations should be added for the NM_MECH and
ATTRS variables, compare how RFC 2743 is written.

   This function outputs the set (represented as a NULL terminated array
   of gss_buffer_t) of attributes of a name.

I don't see how this works -- gss_buffer_t is a C-language specific
construct and the size of the types involved may differ depending on
architecture.  You want to use a language independent format here.

   The gss_buffer_set_t type and associated API is defined in [GFD.024]

This is a normative reference, so it would help if there were a URL to
the stable document in the reference section.  Right now I don't know
how to find the latest version of the document.  I believe it is
important to review that document in the IETF.  The use of C language
constructs at the abstract GSS-API level seems confusing to me, and I
wonder if it is fully baked.

Section 7.2.1:

     int                           name_is_MN,

You can't return values in C with a prameter like that, add a '*'.

The section needs more text, compare RFC 2744.

/Simon

---

From: Sam Hartman <[email-masked]>
Date: Wed, 02 Mar 2011 17:05:36 -0500

>>>>> "Simon" == Simon Josefsson <[email-masked]> writes:

    Simon> I believe this document needs more work on the API
    Simon> descriptions and it is not ready for publication.  I started
    Simon> a review with details below, but stopped when I had found too
    Simon> many problems.

Simon,  thanks for your feedback.
I spoke to Nico and we believe that you've made a good case for
reviewing section 7 of the draft prior to publication.
I'll see if we can get you a copy of the buffer set proposal.
If there is a good URI to include, I certainly would be happy to do
that.

Can I get you to take a look at http://www.ggf.org/documents/GFD.24.pdf
and see if that's the right API?
I believe it is.

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 04 Mar 2011 15:45:43 +0100

> and see if that's the right API?

Thanks for the link.  That document says the latest version of it is
available from

https://forge.gridforum.org/projects/gsi-wg

but if following that link and navigating to the documents I find
draft-ggf-gss-extensions-12 linked from

https://forge.gridforum.org/sf/docman/do/listDocuments/projects.gsi-wg/docman.root

but that version looks somewhat different to the document above.

Two concerns:

1) draft-ietf-kitten-gssapi-naming-exts is referencing the C-specific
gss_buffer_set_t (I assume, it actually says gss_buffer_t but that looks
like a typo) in the abstract GSS-API function definition.  That looks
like a layer violation to me, similar to a problem clarified in 5554.

2) What parts of GFD.024 are intended to be normative?  It is a
normative reference from our document.  The PDF is marked as
experimental and it dates from 2004.  It hasn't gone through any IETF
review.  I would prefer it the normative and relevant parts of it could
be extracted and submitted and published through the IETF, so we have a
stable reference.  It looks like the document could use some
improvements as well -- for example, there is security considerations
that applies to the buffer set API.  Of course, the GGF needs to agree
to re-licensing the document.

/Simon