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

Yes

(Stephen Farrell)

No Objection

(Adrian Farrel)
(Dan Romascanu)
(Gonzalo Camarillo)
(Pete Resnick)
(Peter Saint-Andre)
(Robert Sparks)
(Ron Bonica)
(Stewart Bryant)
(Wesley Eddy)

Note: This ballot was opened for revision 10 and is now closed.

Stephen Farrell Former IESG member
Yes
Yes () Unknown

                            
Adrian Farrel Former IESG member
No Objection
No Objection () Unknown

                            
Dan Romascanu Former IESG member
No Objection
No Objection () Unknown

                            
Gonzalo Camarillo Former IESG member
No Objection
No Objection () Unknown

                            
Jari Arkko Former IESG member
(was Discuss) No Objection
No Objection (2011-12-01) Unknown
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".
Pete Resnick Former IESG member
No Objection
No Objection () Unknown

                            
Peter Saint-Andre Former IESG member
No Objection
No Objection () Unknown

                            
Robert Sparks Former IESG member
No Objection
No Objection () Unknown

                            
Ron Bonica Former IESG member
No Objection
No Objection () Unknown

                            
Russ Housley Former IESG member
No Objection
No Objection (2011-11-29) Unknown
  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
Sean Turner Former IESG member
No Objection
No Objection (2011-11-28) Unknown
An informative reference to RFC 6151 might be good in the 1st
sentence of the introduction.
Stewart Bryant Former IESG member
No Objection
No Objection () Unknown

                            
Wesley Eddy Former IESG member
No Objection
No Objection () Unknown