The Kerberos V5 ("GSSAPI") Simple Authentication and Security Layer (SASL) Mechanism
draft-ietf-sasl-gssapi-08

IANA Evaluation Comments:

Upon approval of this document, the IANA will make the following changes
in the "SIMPLE AUTHENTICATION AND SECURITY LAYER (SASL) MECHANISMS"
registry located at
http://www.iana.org/assignments/sasl-mechanisms

Old:
MECHANISMS USAGE REFERENCE OWNER
---------- ----- --------- -----
GSSAPI COMMON [RFC2222] IESG


New:
MECHANISMS USAGE REFERENCE OWNER
---------- ----- --------- -----
GSSAPI COMMON [RFC-sasl-gssapi] IESG

We understand the above to be the only IANA Actions for this document.

[Ballot comment]
Section 1., paragraph 1:
>    The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY"
>    in this document are to be interpreted as defined in "Key words for
>    use in RFCs to Indicate Requirement Levels" [KEYWORDS].

  Nit: is not the required boilerplate.

[Ballot comment]
As this document replaces section 7.2 of RFC 2222, and together with RFC 4422, obsoletes RFC 2222 in its entirety, the header of the document should mention 'Obsoletes RFC 2222' when approved.

[Ballot comment]
As yhis document replaces section 7.2 of RFC 2222, the definition of the "GSSAPI" SASL mechanism, the header of the document should mention 'Updates RFC 2222' when approved.

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? Which chair is the WG
Chair Shepherd for this document?

Yes and yes. Kurt.

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?

Key members of the WG did review this draft.

The depth and breadth of the WG review to met the minimal level
necessary for progression, and hence have some concerns in this
area. Additional review, especially from the GSS-API and Kerberos
communities, is desirable. Recommend the draft be submitted to
the Security Directorate for review and that review be assigned to
individuals who are detailed understanding of GSS-API and Kerberos.

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, internationalization,
XML, etc.)?

In addition to the reviews recommended in 1.b, a gen-art review is
recommended.

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?

The WG consensus behind this document represents a strong concurrence
of a minority of WG. The majority of this WG runs away and hides
when they hear the terms GSS-API and Kerberos. Approximate half of
the reviewers would not claim to be GSS-API and/or Kerberos experts
(including myself), but were able to provide useful review. As
noted above, the degree of consensus for progression on the
standards track.

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. (It should be
separate email because this questionnaire will be entered into
the tracker).

No.

1.g) Have the chairs verified that the document checks out against
all the ID nits? (see http://www.ietf.org/ID-Checklist.html).
Boilerplate checks are not enough; this check needs to be
thorough.

Yes.

1.h) Has the document split its references into normative and
informative? Are there normative references to IDs, where the
IDs are not also ready for advancement or are otherwise in an
unclear state? The RFC Editor will not publish an RFC with
normative references to IDs (will delay the publication until
all such IDs are also ready for RFC publicatioin). If the
normative references are behind, what is the strategy for their
completion? On a related matter, are there normative references
that are downward references, as described in BCP 97, RFC 3967
RFC 3967 [RFC3967]? Listing these supports the Area Director in
the Last Call downref procedure specified in RFC 3967.

Yes, No, N/A, No.


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

Technical Summary

This document provides a revised technical specification for the
the Simple Authentication and Security Layer (SASL) "GSSAPI" mechanism.
It uses the Generic Security Service Application Program Interface
(GSS-API) Kerberos V5 mechanism for authentication and data
security services.

This document replaces section 7.2 of RFC 2222, the previous
"GSSAPI" technical specification.


Working Group Summary

This document is a work item of the SASL working group. The working
group came to consensus on this document. There were comments
received during WG Last Call, and these have been addressed in this
revision.


Protocol Quality

The document was reviewed for the IESG by Sam Hartman.