Subject: Re: Last Call: draft-ietf-kitten-gssapi-naming-exts (GSS-API Naming Extensions) to Proposed Standard

From: Simon Josefsson <[email-masked]>
Date: Fri, 09 Jul 2010 22:53:25 +0200

The IESG <[email-masked]> writes:

> The IESG has received a request from the Kitten (GSS-API Next Generation) 
> WG (kitten) to consider the following document:
>
> - 'GSS-API Naming Extensions '
>    <draft-ietf-kitten-gssapi-naming-exts-08.txt> as a Proposed Standard
>
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action.  Please send substantive comments to the
> [email-masked] mailing lists by 2010-07-23. Exceptionally, 
> comments may be sent to [email-masked] instead. In either case, please 
> retain the beginning of the Subject line to allow automated sorting.
>
> The file can be obtained via
> http://www.ietf.org/internet-drafts/draft-ietf-kitten-gssapi-naming-exts-08.txt

Here are my comments:

1) Section 3 says:

   An attribute is 'authenticated' iff there is a secure association

I suggest expanding iff for clarity.

2) Section 7 defines several new APIs, but I cannot find discussion about
who is responsible for de-allocating the output buffers: the caller or
the GSS-API implementation.

For example, in section 7.1 the 'display_name' parameter is defined as:

   o  display_name STRING

First, it should probably be OCTET STRING, not STRING, at least I cannot
find any type called only STRING in RFC 2743.

Secondly, also compare how RFC 2743 clarifies who is responsible for
memory de-allocation like this:

   o  interprocess_token OCTET STRING  -- caller must release
   -- with GSS_Release_buffer()

Something similar is needed.

3) The C-binding sections are not complete, they need to describe
semantics for the function and its parameters.  Compare how RFC 2744
defines each function and discusses each parameter.  For the
interprocess_token above, there is this text:

   interprocess_token   buffer, opaque, modify
                        token to be transferred to target process.
                        Storage associated with this token must be
                        freed by the application after use with a
                        call to gss_release_buffer().

I expect similar text for each C function and its parameters.

4) The mapping of PKIX subjectAltNames to values is fuzzily described in
   section 6.2:

   PKIX certificate subjectAltNames MUST be mapped as *authenticated*
   GSS-API name attributes.  The values SHOULD be the values of the
   subjectAltName represented as OCTET STRINGs if the type of the
   subjectAltName supports a unique loss-less representation as string
   values.  Specifically dnsName, ipAddress, uniformResourceLocator and
   emailAddress MUST be returned using the corresponding string
   representation of those data types.

   6.2.2.  Other PKIX Certificate Extensions and Attributes

   Any X.509 certificate extension not covered above SHOULD be
   represented as GSS-API name attributes with the OID of the X.509
   extension and with OCTET STRING values containing the encoded value
   of the extension.

Is "supports a unique loss-less representation" intended to _only_ mean
dnsName+ipAddress+uniformResourceLocator+emailAddress or are other types
also intended to be covered if they, decided by each implementer, can be
uniquely and loss-lessly converted?  For good interop, I believe the
document should clarify for each supported type exactly how translation
should work, and not leave this aspect implementation defined.

For example, the ipAddress extension holds binary data (of arbitrary
length, for IPv4+IPv6), and there are several data formats permitted
(127.0.0.1, 127.1, 127::1, etc).  It should specify a unique data
format.

Further, the text above is not clear how the commonly used XMPP
subjectAltName extension is translated because that uses an
SubjectAltName otherName type.

Again, these problems would be solved if the document contains an
explicit list of SAN types that are supported and describe exactly how
they are converted to string values.

/Simon

---

From: Sam Hartman <[email-masked]>
Date: Mon, 12 Jul 2010 17:23:16 -0400

Recently I've tried to use draft-ietf-kitten-gssapi-naming-exts in the
design of a GSS-API mechanism.
I think this is a good start but is not quite done yet.

draft-hartman-gss-eap-naming-00 discusses a couple of problems with
naming extensions:

* The format of attribute names proposed in this specification is
  incompatible with several of the things you'd like to name, in my case
  including SAML attributes.
* The description of how to name SAML attributes currently in the
  document is inconsistent with the SAML base specification
* The approach of naming things like SAML attributes entirely with a
* The approach of letting a mechanism create authenticated attributes
  with an arbitrary URI  makes the application's life really hard

While not mentioned in my existing draft, I've noticed a number of other
problems:

* The document claims to name Kerberos entities such as authorization
  data elements but does not actually provide a name for them.
* The document does not discuss the encoding of subjectAlternativeName
  elements. I suspect application authors will assume human-readable
  text and PKI folks will assume DER.

In addition, there is no way to get the identity of the issuer of a name
attribute.

I've discussed these concerns with one of the authors, Nico Williams. I
have also requested time to present my concerns at the kitten meeting at
IETF 78.

I'm happy to help resolve these concerns up to and including becoming an
author of the document and writing significant text.

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 22 Jul 2010 18:14:47 -0500

> I think this is a good start but is not quite done yet.

I agree.  I'm not sure whether it's best to proceed to publication then
later publish another RFC, or if it'd be best to cancel the IETF LC and
improve this I-D.

>   with an arbitrary URI  makes the application's life really hard

One or more of your bullet points is incomplete, Sam.

> In addition, there is no way to get the identity of the issuer of a name

This is a big deal, IMO.

> have also requested time to present my concerns at the kitten meeting at

We should definitely discuss this next week.

> author of the document and writing significant text.

I think that's a good idea, however I'll let my co-author comment on
this as well, given that he's the primary author now :)

Nico
--