Anonymity Support for Kerberos
RFC 6112

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

(Tim Polk) Yes

(Jari Arkko) No Objection

(Ron Bonica) No Objection

(Stewart Bryant) No Objection

(Gonzalo Camarillo) No Objection

(Ralph Droms) No Objection

Comment (2010-10-05)
No email
send info
Section 4.2:

   The TGS SHOULD NOT
   populate identity-based authorization data into an anonymous ticket
   in that such authorization data typically reveals the client's
   identity.

MUST?  Or, under what conditions can the TGS violate the SHOULD NOT?

Section 7:

   The padata-value field of the PA-PKINIT-KX type padata contains the
   DER [X680] [X690] encoding of the Abstract Syntax Notation One
   (ASN.1) type PA-PKINIT-KX.

Are [X680] and [X690] citations?  There are no matching references in the References section.

(Lars Eggert) No Objection

(Adrian Farrel) No Objection

Comment (2010-10-05)
No email
send info
idnits (http://tools.ietf.org/tools/idnits/) notes a few issues with
references that other ADs have noted, and one problem with format. It
would be good to sort these out.

---

I like the acknowledgement...

   Sam Hartman and Nicolas Williams were great champions of this work.

It is so often the case that document authors do not champion their
work :-)

(Russ Housley) No Objection

Comment (2010-10-06)
No email
send info
  Please consider the comments made by Elwyn Davies in the Gen-ART
  Review posted on 10 September 2010.  The review can be found here:

    http://www.softarmor.com/rai/temp-gen-art/
    draft-krb-wg-ananon-12-davies.txt

(Dan Romascanu) No Objection

(Peter Saint-Andre) No Objection

Comment (2010-10-05)
No email
send info
The Security Considerations note that "Because there are plaintext parts of the tickets that are exposed on the wire, such matching by a third party observer is relatively straightforward." Presumably the use of transport layer security would minimize the attack surface here, so at least an informative reference to draft-josefsson-kerberos5-starttls might be appropriate.

(Robert Sparks) No Objection

(Sean Turner) No Objection

Comment (2010-10-06)
No email
send info
1) Refer to RFC 5652 vice RFC 3852.

2) Sec 4.1.1: This is pretty nit-noid, but the certificates field is OPTIONAL in the ASN so it might be better to say absent as opposed to empty.  The signerInfos field isn't OPTIONAL so empty is correct.  It's up to you whether you should change this.