Subject: RE: Clarifications draft

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Wed, 31 Mar 2004 15:44:11 -0800

Nicolas Williams wrote:
> I think such a flag would be best implemented as authorization data,
as would the flag that MS > proposes.

For the anonymous flag, I do think it makes sense to implement it as AD,
but that is more out of personal preference than anything else.

For the delegated ticket flag, however, we can mark the ticket in the
mandatory flag field, and record the delegating server
identity/identities inside the AD-IF-RELEVANT container.

> > lzhu wrote: 
>> Can a server NOT on a host, or do we want to say the server is
running
               ^^^^^^^^^^^^^
> Can't parse this.

I meant: is the description "a server on a host" too general? In other
words, what is the difference between "a server on a host" and simply "a
server"?

> Jeffrey Altman wrote:
> why is item 2 a topic for discussion of Clarifications and not
Extensions?

Out of the two, one is a small editorial change, and we proposed the
other so that we can start to use the delegated ticket flag (if
assigned) right away.

Larry

-----Original Message-----
From: Nicolas Williams [mailto:[email-masked]] 
Sent: Wednesday, March 31, 2004 3:12 PM
To: Jeffrey Altman; Liqiang(Larry) Zhu; [email-masked]; JK
Jaganathan; Sam Hartman; [email-masked]
Subject: Re: Clarifications draft

On Wed, Mar 31, 2004 at 04:57:17PM -0600, Nicolas Williams wrote:
> I had a request for a new flag (I forget what it was, though I'm sure 
> I'll remember as soon as I send this) and Sam insisted that 
> authorization data would be better for that.

Predictably, I remember now.  I'd brought this up at the first interim
WG meeting at MIT.  I'd wanted a flag that the KDC could use to say
"treat the client principal as anonymous."  This is like splitting the
policy checked flag into two so we could express a policy like: "this
path is ok and you can use this ticket for session protection, but this
path is not quite so good so don't trust the client principal name."

The idea being that this would be useful in large internetworks that use
hierarchical cross-realm trust relations.

I think such a flag would be best implemented as authorization data, as
would the flag that MS proposes.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 31 Mar 2004 17:56:46 -0600

> but that is more out of personal preference than anything else.

This is silly.  You prefer my option be done as AD and I prefer your
option be done as AD.  What gives?  :)

> identity/identities inside the AD-IF-RELEVANT container.

"Mandatory flag field?"  What "mandatory flag field?"

There is no such thing, and though section 2 does not address the
application server side of ticket flag handling, it's pretty clear that
new ticket flags can't be expected to be critical.

Ergo you must use authorization data if you want this option to be
critical.

> >> Can a server NOT on a host, or do we want to say the server is

I think what is ultimately meant is that the server must have a hostname
associated with it.

> other so that we can start to use the delegated ticket flag (if

I didn't quite understand what change you requested wrt your first
issue.

As to the second, you need to clarify whether the proposed flags is
intended to be critical or not, and if it is then you cannot have it.

Nico
--

---

From: Jeffrey Altman <[email-masked]>
Date: Wed, 31 Mar 2004 22:24:33 -0500

>other so that we can start to use the delegated ticket flag (if
First of all, the first is hardly a small editorial change.
It may alter few words but it has signficant impact on the
use of the protocol and expections that application writers
have had of the protocol for more than a decade.  It is
absolutely inappropriate for Microsoft to propose such a
change after the I-D has passed both working group and
IETF Last Calls; and has been sitting in front of the IESG
for several months.

Secondly, adding new functionality to clarifications is
out of scope.  I realize you were not in all of the meetings
which got us to the separation between "clarifications" and
"extensions" but those words do describe very clearly what
these standards track documents were meant to achieve.  All
and I mean "all" of the extensions work was removed from the
rfc1510bis document to form "clarifications" in order for
the working group to reach consensus.  In fact it was to
a large extent Microsoft which forced us to do so.  Adding
new functionality is what the discussions on extensions are
all about.  I hope that Microsoft will be an active participant
in those discussions. 

Jeffrey Altman