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(_at_)lists(_dot_)anl(_dot_)gov
[mailto:ietf-krb-wg-bounces(_at_)lists(_dot_)anl(_dot_)gov] On Behalf Of Sam
Hartman
Sent: Thursday, March 20, 2008 10:20 AM
To: ietf(_at_)ietf(_dot_)org; ietf-krb-wg(_at_)anl(_dot_)gov
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(_at_)lists(_dot_)anl(_dot_)gov
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg
_______________________________________________
IETF mailing list
IETF(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf