Desired Enhancements to Generic Security Services Application Program Interface (GSS-API) Version 3 Naming
draft-ietf-kitten-gss-naming-05

PROTO Write-up

1.a) Have the chairs personally reviewed this version of the Internet
Draft (ID), and in particular, do they believe this ID is ready
to forward to the IESG for publication?

I have reviewed this document and believe it is ready for publication.

1.b) Has the document had adequate review from both key WG members
and key non-WG members? Do you have any concerns about the
depth or breadth of the reviews that have been performed?

The document has been given significant review and is ready for
publication.

1.c) Do you have concerns that the document needs more review from a
particular (broader) perspective (e.g., security, operational
complexity, someone familiar with AAA, etc.)?

I do not believe this draft requires additional review.


1.d) Do you have any specific concerns/issues with this document that
you believe the ADs and/or IESG should be aware of? For
example, perhaps you are uncomfortable with certain parts of the
document, or have concerns whether there really is a need for
it. In any event, if your issues have been discussed in the WG
and the WG has indicated it that it still wishes to advance the
document, detail those concerns in the write-up.

No.

1.e) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with
others being silent, or does the WG as a whole understand and
agree with it?

This document is primarily the product of a small number of individuals:
Sam Hartman and Nico Williams. It has received review from Bill
Sommerfeld, Jeffrey Hutzelman, and Martin Rex. Martin has frequently
disagreed with the directions that Sam and Nico are taking the working
group. Martin was very active in the CAT working group and is very
concerned about breaking backward compatibility. I believe that
Martin's concerns have been addressed as well as they need to be at this
stage. Martin's participation is a good door stop for the working group
to ensure that non-IETF GSSAPIv2 mechanisms will not be broken
unnecessarily.

The participants in this working group overlap those in the SASL and
Kerberos working groups. The name based authorization issues being
addressed in this draft are identical to the issues being address in
those working groups.

1.f) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in
separate email to the Responsible Area Director.

There is no threat of appeal.

1.g) Have the chairs verified that the document adheres to all of the
ID nits? (see http://www.ietf.org/ID-Checklist.html).

idnits 1.103 points out that there are some weird spacing issues where
two spaces are used instead of one and there is a lack of an IANA
Considerations section. Given that this draft will be significantly
edited during RFC publication and that as an informational draft that
describes direction for the working group I do not believe that the
lack of an IANA Considerations section should hold up publication.

1.h) Is the document split into normative and informative references?
Are there normative references to IDs, where the IDs are not
also ready for advancement or are otherwise in an unclear state?
(note here that the RFC editor will not publish an RFC with
normative references to IDs, it will delay publication until all
such IDs are also ready for publication as RFCs.)

Yes.

1.i) For Standards Track and BCP documents, the IESG approval
announcement includes a write-up section with the following
sections:


Technical Summary:

The Generic Security Services API (GSS-API) provides a naming
architecture that supports name-based authorization. GSS-API
authenticates two named parties to each other. Names can be stored
on access control lists to make authorization decisions. Advances in
security mechanisms and the way implementers wish to use GSS-API
require this model to be extended for the next version of GSS-API.
As people move within an organization or change their names, the name
authenticated by GSS-API may change. Using some sort of constant
identifier would make ACLs more stable. Some mechanisms such as
public-key mechanisms do not have a single name to be used across all
environments. Other mechanisms such as Kerberos may include group
membership or role information as part of authentication. This
document motivates extensions to GSS-API naming and describes the
extensions under discussion.

Working Group Summary:

The Kitten Working Group has achieved consensus that this document
describes the problem space associated with name-based authorization
in conjunction with the GSS-API.


Protocol Quality:

This is an informational draft describing the problem space and proposed
directions for an acceptable solution. It does not describe a specific
solution.