Sam wrote: > As it turns out, a client cannot check ticket flags: it doesn't actually know the key needed to decrypt the ticket. > Perhaps you mean that the client should check the KDC flags. The KDC duplicates the tickets flag in the EncKDCRepPart and the client can check that. I would propose the following changes to clarify this point. 356,359c365,368 < by checking the presence of the anonymous ticket flag. This is < because KDCs ignore unknown KDC options. A KDC that does not < understand the anonymous KDC option will not return an error, but < will instead return a normal ticket. --- > by checking the presence of the anonymous ticket flag in the flags > field of the EncKDCRepPart. This is because KDCs ignore unknown KDC > options. A KDC that does not understand the anonymous KDC option > will not return an error, but will instead return a normal ticket. > First, if I call gss_display_name on an anonymous principal in an acceptor, what do I expect to get back? Would section 2.1.1 of RFC1964 be sufficient for this purpose? > Second, if I provide the anonymous name to a KDC in an AS-REP with the > anonymous option set, but don't provide padata, should I expect a > preauth_required error from the KDC listing pkinit? Yes, I would like to propose the following new sentence into section 4 to make this clear. 262a266,269 > The KDC conforming to this specification MUST indicate the support of > anonymous PKINIT as described above in this section according to > Section 3.4 of [RFC4556]. > Let me know if you do not believe these changes are editorial and if any of all your concerns is not sufficiently addressed. Thanks, --larry -----Original Message----- From: ietf-krb-wg-bounces@xxxxxxxxxxxxx [mailto:ietf-krb-wg-bounces@xxxxxxxxxxxxx] On Behalf Of Sam Hartman Sent: Thursday, March 20, 2008 10:20 AM To: ietf@xxxxxxxx; ietf-krb-wg@xxxxxxx Subject: [Ietf-krb-wg] Late Last Call comments: draft-ietf-krb-wg-anonymous With one minor concern, I do believe this draft is ready for publication as a proposed standard. However I think this draft is fairly rough as proposed standards go; I expect that we will end up needing a new revision of this spec at some future point that refines some of the details based on implementation experience. That's what our process is all about, so I am not bothered. The following requirement is impossible to implement: > If a client requires anonymous communication then the client MUST > check to make sure that the ticket in the reply is actually anonymous > by checking the presence of the anonymous ticket flag. This is As it turns out, a client cannot check ticket flags: it doesn't actually know the key needed to decrypt the ticket. Perhaps you mean that the client should check the KDC flags. Additionally, there are a few areas in which the spec is unclear. These could be fixed now or fixed in a future revision of the spec. First, if I call gss_display_name on an anonymous principal in an acceptor, what do I expect to get back? Second, if I provide the anonymous name to a KDC in an AS-REP with the anonymous option set, but don't provide padata, should I expect a preauth_required error from the KDC listing pkinit? _______________________________________________ ietf-krb-wg mailing list ietf-krb-wg@xxxxxxxxxxxxx https://lists.anl.gov/mailman/listinfo/ietf-krb-wg _______________________________________________ IETF mailing list IETF@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf