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

From: The IESG <[email-masked]>
Date: Fri, 9 Jul 2010 08:14:13 -0700 (PDT)

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

IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=13136&rfc_flag=0

---

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
--

---

From: Leif Johansson <[email-masked]>
Date: Sun, 25 Jul 2010 16:53:34 +0200

>   document is inconsistent with the SAML base specification

Are you referring to the fact that there is nothing that corresponds
to the SAML Attribute element attribute @NameFormat?

>   data elements but does not actually provide a name for them.

True. The document only states how the authenticated flag must be set
for that type of data.

>   text and PKI folks will assume DER.

Actually the last paragraph of section 6.2.1 clearly (at least it was my
intention to be clear) states that unique loss-less representations as
string values MUST be used.

	Cheers Leif