Subject: Re: [Ietf-krb-wg] Late Last Call comments: draft-ietf-krb-wg-anonymous

From: Larry Zhu <[email-masked]>
Date: Wed, 9 Apr 2008 12:52:37 -0700

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