Skip to main content

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

Revision differences

Document history

Date Rev. By Action
2012-08-22
10 (System) post-migration administrative database adjustment to the No Objection position for Jari Arkko
2012-01-12
10 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2012-01-12
10 (System) IANA Action state changed to Waiting on RFC Editor from Waiting on Authors
2012-01-09
10 (System) IANA Action state changed to Waiting on Authors from In Progress
2012-01-06
10 (System) IANA Action state changed to In Progress
2012-01-06
10 Cindy Morgan State changed to RFC Ed Queue from Approved-announcement sent.
2012-01-06
10 Amy Vezza IESG state changed to Approved-announcement sent
2012-01-06
10 Amy Vezza IESG has approved the document
2012-01-06
10 Amy Vezza Closed "Approve" ballot
2012-01-06
10 Amy Vezza Approval announcement text regenerated
2012-01-06
10 Stephen Farrell Ballot writeup text changed
2012-01-06
10 (System) New version available: draft-ietf-krb-wg-gss-cb-hash-agility-10.txt
2011-12-15
09 (System) New version available: draft-ietf-krb-wg-gss-cb-hash-agility-09.txt
2011-12-04
10 Samuel Weiler Request for Last Call review by SECDIR Completed. Reviewer: Kathleen Moriarty.
2011-12-01
10 Cindy Morgan Removed from agenda for telechat
2011-12-01
10 Cindy Morgan State changed to Approved-announcement to be sent::Point Raised - writeup needed from IESG Evaluation.
2011-12-01
10 Jari Arkko [Ballot Position Update] Position for Jari Arkko has been changed to No Objection from Discuss
2011-12-01
10 Stephen Farrell Ballot writeup text changed
2011-12-01
10 Dan Romascanu [Ballot Position Update] New position, No Objection, has been recorded
2011-12-01
10 Gonzalo Camarillo [Ballot Position Update] New position, No Objection, has been recorded
2011-12-01
10 Jari Arkko
[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 …
[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?
2011-12-01
10 Jari Arkko [Ballot Position Update] New position, Discuss, has been recorded
2011-12-01
10 Jari Arkko
[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 …
[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".
2011-12-01
10 Adrian Farrel [Ballot Position Update] New position, No Objection, has been recorded
2011-11-30
10 Pete Resnick [Ballot Position Update] New position, No Objection, has been recorded
2011-11-29
10 Ron Bonica [Ballot Position Update] New position, No Objection, has been recorded
2011-11-29
10 Russ Housley [Ballot comment]
Please consider the editorial comments in the Gen-ART Review from
  Francis Dupont on 5-Nov-2011.  See the comments here:

  http://www.ietf.org/mail-archive/web/gen-art/current/msg06908.html
2011-11-29
10 Russ Housley [Ballot Position Update] New position, No Objection, has been recorded
2011-11-29
10 Robert Sparks [Ballot Position Update] New position, No Objection, has been recorded
2011-11-29
10 Stewart Bryant [Ballot Position Update] New position, No Objection, has been recorded
2011-11-28
10 Peter Saint-Andre [Ballot Position Update] New position, No Objection, has been recorded
2011-11-28
10 Sean Turner [Ballot comment]
An informative reference to RFC 6151 might be good in the 1st
sentence of the introduction.
2011-11-28
10 Sean Turner [Ballot Position Update] New position, No Objection, has been recorded
2011-11-27
10 Wesley Eddy [Ballot Position Update] New position, No Objection, has been recorded
2011-11-16
10 Stephen Farrell State changed to IESG Evaluation from Waiting for AD Go-Ahead.
2011-11-16
10 Stephen Farrell Setting stream while adding document to the tracker
2011-11-16
10 Stephen Farrell Stream changed to IETF from IETF
2011-11-16
10 Stephen Farrell Placed on agenda for telechat - 2011-12-01
2011-11-15
10 Francis Dupont Request for Last Call review by GENART Completed. Reviewer: Francis Dupont.
2011-11-15
10 Stephen Farrell Removed from agenda for telechat
2011-11-12
10 Amanda Baber
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 …
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.
2011-11-07
10 Stephen Farrell Placed on agenda for telechat - 2011-12-01
2011-11-07
10 Stephen Farrell [Ballot Position Update] New position, Yes, has been recorded for Stephen Farrell
2011-11-07
10 Stephen Farrell Ballot has been issued
2011-11-07
10 Stephen Farrell Created "Approve" ballot
2011-11-07
10 Stephen Farrell Ballot writeup text changed
2011-11-07
10 (System) State changed to Waiting for AD Go-Ahead from In Last Call.
2011-11-01
10 Jean Mahoney Request for Last Call review by GENART is assigned to Francis Dupont
2011-11-01
10 Jean Mahoney Request for Last Call review by GENART is assigned to Francis Dupont
2011-10-28
10 Samuel Weiler Request for Last Call review by SECDIR is assigned to Kathleen Moriarty
2011-10-28
10 Samuel Weiler Request for Last Call review by SECDIR is assigned to Kathleen Moriarty
2011-10-24
10 Amy Vezza Last call sent
2011-10-24
10 Amy Vezza
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: …
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.


2011-10-24
10 Amy Vezza Last Call text changed
2011-10-23
10 Stephen Farrell Last Call was requested
2011-10-23
10 Stephen Farrell State changed to Last Call Requested from AD Evaluation::AD Followup.
2011-10-23
10 (System) Ballot writeup text was added
2011-10-23
10 (System) Last call text was added
2011-10-23
10 (System) Ballot approval text was added
2011-10-18
10 (System) Sub state has been changed to AD Follow up from New Id Needed
2011-10-18
08 (System) New version available: draft-ietf-krb-wg-gss-cb-hash-agility-08.txt
2011-08-12
10 Stephen Farrell State changed to AD Evaluation::Revised ID Needed from Publication Requested.
2011-07-27
10 Cindy Morgan
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 …
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.
2011-07-27
10 Cindy Morgan Draft added in state Publication Requested
2011-07-27
10 Cindy Morgan [Note]: 'Sam Hartman (hartmans-ietf@mit.edu) is the document shepherd.' added
2011-05-13
07 (System) New version available: draft-ietf-krb-wg-gss-cb-hash-agility-07.txt
2010-12-24
06 (System) New version available: draft-ietf-krb-wg-gss-cb-hash-agility-06.txt
2009-05-07
10 (System) Document has expired
2008-11-03
05 (System) New version available: draft-ietf-krb-wg-gss-cb-hash-agility-05.txt
2008-07-14
04 (System) New version available: draft-ietf-krb-wg-gss-cb-hash-agility-04.txt
2007-11-10
03 (System) New version available: draft-ietf-krb-wg-gss-cb-hash-agility-03.txt
2007-10-11
02 (System) New version available: draft-ietf-krb-wg-gss-cb-hash-agility-02.txt
2007-03-08
01 (System) New version available: draft-ietf-krb-wg-gss-cb-hash-agility-01.txt
2006-11-28
00 (System) New version available: draft-ietf-krb-wg-gss-cb-hash-agility-00.txt