Subject: Re: Clarifications draft

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 01 Apr 2004 17:10:44 -0500

On Wednesday, March 31, 2004 19:45:07 -0600 Nicolas Williams 
<[email-masked]> wrote:

> On Wed, Mar 31, 2004 at 06:12:03PM -0600, Nicolas Williams wrote:
>> On Wed, Mar 31, 2004 at 04:06:44PM -0800, Liqiang(Larry) Zhu wrote:
>> > This new flag ("delegated") is not critical, and application servers
>> > may not process it.
>>
>> As long as it's not critical I don't see why it couldn't be added.
>>
>> Adding it in clarifications though, is another story -- I'll defer to
>> the WG chairs on that matter.
>
> To clarify my position: if you want this non-critical flag then you
> should specify it in a separate document -- there's no need to delay
> clarifications.  If you change your mind and decide that you want a
> critical flag then you must specify this feature through authorization
> data.
>
> I still welcome the opinion of the WG chairs, of course.

It is worth noting that ticket flags are not intended to serve as a general 
extension mechanism, and there is no mechanism for new flags to be 
allocated other than through a revision to the standard.

Such a revision is in progress, in the form of kerberos-extensions.
It would be appropriate for kerberos-extensions (or some document it 
incorporates by reference) to define a new ticket flag for this purpose, if 
it is the concensus of the working group that a flag is the right vehicle 
for this information (rather than an AD type, as Nico proposes).

The kerberos-clarifications has already undergone extensive review not only 
by this working group, but also by the Security AD's, the IESG, and the 
IETF as a whole.  It is literally hours away from being sent back to the 
IESG for final approval.  At this point, I consider the barrier for 
substantive protocol changes to be quite high, especially for extensions 
and enhancements, since there is a concensus to defer such work to 
kerberos-extensions.  While I understand that Microsoft wants to begin 
using this feature very soon, I don't think that alone is sufficient to 
clear this barrier.

It is clear to me that there is not yet concensus among the WG as to how 
this feature should be implemented.  However, of the two proposed methods 
under discussion, one (a new or modified AD type) can be done without any 
change to the base protocol, and the other (a ticket flag) can most likely 
be used with the clarifications protocol once the new flag has been 
allocated, even though the name and semantics of the flag are not in the 
clarifications spec.  Thus, I don't think it is necessary to hold up the 
progress of kerberos-clarifications in order to be able to use this feature 
as soon as it is well-defined.

Similar arguments apply to the hostname case issue.  The proposed change is 
not editorial; it is substantive.  The existing text addresses a real 
interoperability issue, which the CAT WG obviously felt was important 
enough to warrant a MUST.  I'm not saying this text is immutable, but 
making this change in kerberos-clarifications at this time would require a 
fairly strong concensus of the working group, which I have so far not seen.

-- Jeff

I expect kerberos-clarifications-06 to be submitted to the I-D repository 
within the next 24 hours or so, with only editorial changes needed to 
address comments raised by IESG members -- there are no substantive changes 
to the protocol.

-- Jeff

---

From: Sam Hartman <[email-masked]>
Date: Thu, 01 Apr 2004 15:51:23 -0500

>>>>> "Nicolas" == Nicolas Williams <[email-masked]> writes:

    Nicolas> On Wed, Mar 31, 2004 at 06:12:03PM -0600, Nicolas
    Nicolas> Williams wrote:
    >> On Wed, Mar 31, 2004 at 04:06:44PM -0800, Liqiang(Larry) Zhu
    >> wrote: > This new flag ("delegated") is not critical, and
    >> application servers may > not process it.
    >> 
    >> Adding it in clarifications though, is another story -- I'll
    >> defer to the WG chairs on that matter.

    Nicolas> To clarify my position: if you want this non-critical
    Nicolas> flag then you should specify it in a separate document --
    Nicolas> there's no need to delay clarifications.  If you change
    Nicolas> your mind and decide that you want a critical flag then
    Nicolas> you must specify this feature through authorization data.

I think that other document should be extensions.

If you want to start using the flag today, get working group consensus
on the flag, get Cliff to give you a flag number, and start using it
now ever though extensions is not finalized.

Why is the proxied flag inappropriate?  I know we discussed this on
the phone, but it seems like a question worth answering for the
group's benefit.