Kerberos Version 5 Generic Security Service Application Program Interface (GSS-API) Channel Binding Hash Agility
draft-ietf-krb-wg-gss-cb-hash-agility-10

[Ballot discuss]
I asked Ari Keränen to review this specification, and he had trouble understanding the description relating to the Exts field, and he also spotted an error in the IANA considerations text. Can some changes be accommodated to make Section 3 clearer and the IANA considerations corrected?

[Ballot comment]
Ari Keränen's review:


Is this the first document describing the format for the Exts field in
the GSS checksum? It seems so, but the document isn't too explicit about
that. I think the definition for the format of the Exts field would
deserve at least its own section in the document (i.e., split the format
of the field and and how it's used for hash agility into two different
sections). And perhaps could also mention in the abstract that the
format of the field is defined in this document (now it just says that
"extensions are defined" which seems a little understatement).


3.  Channel binding hash agility

    [...] All
    fields before "Exts" do not change from what is described in
    [RFC4121], they are listed for convenience. The 0x8003 GSS checksum
    MUST have the following structure:

This is a bit confusing (had to read it a few times and maybe I still
got it wrong). Could maybe rephrase this into something like:

    The 0x8003 GSS checksum MUST have the following structure (only the
"Exts" field is changed from what is described in [RFC4121], other
fields are listed only for convenience):

..if that's what was meant.


5.  IANA Considerations

      0x00000000 - 0x000003FF IETF Consensus

In RFC5226 this is "IETF Review" instead of "IETF Consensus".

Upon approval of this document, IANA will create a new top-level
registry and page called ""Kerberos V GSS-API Mechanism Parameters,"
separate from the existing Kerberos parameters registry.

On this page, IANA will create the following registry:

Registry Name: Kerberos V GSS-API mechanism extension types
Reference: [RFC-to-be]
Range Registration Procedure
----------------------- ----------------------
0x00000000 - 0x000003FF IETF Consensus
0x00000400 - 0xFFFFF3FF Specification Required

Type Number Type Name Description Reference
----------- --------- ------------ ---------
0x00000000 Channel Binding MIC Extension for the verifier of the
channel bindings [RFC-to-be]
0x00000001-0xFFFFF3FF Unassigned
0xFFFFF400-0xFFFFFFFF Private Use

We understand these to be the only actions for this document.

State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (Kerberos Version 5 GSS-API Channel Binding Hash Agility) to Proposed Standard


The IESG has received a request from the Kerberos WG (krb-wg) to consider
the following document:
- 'Kerberos Version 5 GSS-API Channel Binding Hash Agility'
  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
ietf@ietf.org mailing lists by 2011-11-07. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  Currently, channel bindings are implemented using a MD5 hash in the
  Kerberos Version 5 Generic Security Services Application Programming
  Interface (GSS-API) mechanism [RFC4121].  This document updates
  RFC4121 to allow channel bindings using algorithms negotiated based
  on Kerberos crypto framework as defined in RFC3961.  In addition,
  because this update makes use of the last extensible field in the
  Kerberos client-server exchange message, extensions are defined to
  allow future protocol extensions.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-krb-wg-gss-cb-hash-agility/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-krb-wg-gss-cb-hash-agility/


No IPR declarations have been submitted directly on this I-D.

Changes are expected over time. This version is dated September 17, 2008.

(1.a) Who is the Document Shepherd for this document? Has the
Document Shepherd personally reviewed this version of the
document and, in particular, does he or she believe this
version is ready for forwarding to the IESG for publication?

Sam Hartman
yes

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

review is fine

(1.c) Does the Document Shepherd have concerns that the document
needs more review from a particular or broader perspective,
e.g., security, operational complexity, someone familiar with
AAA, internationalization or XML?
no

(1.d) Does the Document Shepherd have any specific concerns or
issues with this document that the Responsible Area Director
and/or the IESG should be aware of? For example, perhaps he
or she is uncomfortable with certain parts of the document, or
has concerns whether there really is a need for it. In any
event, if the WG has discussed those issues and has indicated
that it still wishes to advance the document, detail those
concerns here. Has an IPR disclosure related to this document
been filed? If so, please include a reference to the
disclosure and summarize the WG discussion and conclusion on
this issue.

Somehow this document got stuck in waiting for chairs to produce proto-writeup since November 2008. So, the discussion is kind of dated.
However when polled the WG still did not have any issues . There are two implementations, so we should move forward.

While reviewing, I noticed that it was unclear where the IANA registry
would end up. I proposed a clarification to the WG list that would
create a new top-level IANA registry to be aligned with similar
sub-registries that are being created in ABFAB and KITTEN. I'm
waiting for WG comments but do not anticipate any difficulties. I
think that collecting AD review feedback now would be desirable but
I'd ask you to hold off on issuing the IETF last call until we resolve
where the IANA registry should go.


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

A number of people have contributed over the years. I think the final product has mostly been reviewed by the authors and the two implementations, but that seems sufficient for this document.

(1.f) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in
separate email messages to the Responsible Area Director. (It
should be in a separate email because this questionnaire is
entered into the ID Tracker.)
(1.g) Has the Document Shepherd personally verified that the
document satisfies all ID nits? (See the Internet-Drafts Checklist
and http://tools.ietf.org/tools/idnits/). Boilerplate checks are
not enough; this check needs to be thorough. Has the document
met all formal review criteria it needs to, such as the MIB
Doctor, media type and URI type reviews?

looks OK.

(1.h) Has the document split its references into normative and
informative? Are there normative references to documents that
are not ready for advancement or are otherwise in an unclear
state? If such normative references exist, what is the
strategy for their completion? Are there normative references
that are downward references, as described in [RFC3967]? If
so, list these downward references to support the Area
Director in the Last Call procedure for them [RFC3967].

looks good

(1.i) Has the Document Shepherd verified that the document IANA
consideration section exists and is consistent with the body
of the document? If the document specifies protocol
extensions, are reservations requested in appropriate IANA
registries? Are the IANA registries clearly identified? If
the document creates a new registry, does it define the
proposed initial contents of the registry and an allocation
procedure for future registrations? Does it suggest a
reasonable name for the new registry? See [RFC5226]. If the
document describes an Expert Review process has Shepherd
conferred with the Responsible Area Director so that the IESG
can appoint the needed Expert during the IESG Evaluation?

looks fine

(1.j) Has the Document Shepherd verified that sections of the
document that are written in a formal language, such as XML
code, BNF rules, MIB definitions, etc., validate correctly in
an automated checker?
no formal language

(1.k) The IESG approval announcement includes a Document
Announcement Write-Up. Please provide such a Document
Announcement Write-Up? Recent examples can be found in the
"Action" announcements for approved documents. The approval
announcement contains the following sections:
Technical Summary
This document provides a mechanism to achieve hash agility for Kerberos GSS-API channel binding verifiers.

Working Group Summary
The Kerberos working Group has consensus to advance this document as a proposed standard.

Document Quality

There are two implementations of this protocol.