Subject: RE: Do we have any consensus on the 8003 checksum--text follows this line--

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Mon, 8 Sep 2003 10:24:10 -0700

Nicolas Williams wrote:

>> Note:  I oppose extending Kerberos V types for the mechanism, but if
we
>>       commit to carry such extensions forward to the Kerberos V
>>       extensions work, I could be convinced to go along.

It might be that the name of the field is not appealing.  How about
calling it "extensions" to disconnect it from the Kerberos V GSSAPI
mechanism?

   EncAPRepPart    ::= [APPLICATION 27] SEQUENCE {
            ctime           [0] KerberosTime,
            cusec           [1] Microseconds,
            subkey          [2] EncryptionKey OPTIONAL,
            seq-number      [3] UInt32 OPTIONAL
            extensions      [4] TYPED-DATA OPTIONAL  -- typed hole added

    }

But my real point here is that doing this does not differ much from the
way we insert the GSS checksum 8003 into the authenticator (namely would
your arguments against this apply as well to the use of the GSS checksum
8003?)

Thx. Larry

-----Original Message-----
From: Nicolas Williams [mailto:[email-masked]] 
Sent: Monday, September 08, 2003 9:59 AM
To: Liqiang(Larry) Zhu
Cc: Jeffrey Hutzelman; Sam Hartman; [email-masked]
Subject: Re: Do we have any consensus on the 8003 checksum--text follows
this line--

On Mon, Sep 08, 2003 at 09:55:49AM -0700, Liqiang(Larry) Zhu wrote:
> I include a summary for the offline discussion with Nicolas.

Note:  I oppose extending Kerberos V types for the mechanism, but if we
       commit to carry such extensions forward to the Kerberos V
       extensions work, I could be convinced to go along.

> In this case it is slightly different:  we introduced new formats for
> per-message and context-deletion tokens, none of those is
> backward-compatible, but we can get away with that and we already
> crossed the line here.  

We did not extend any Kerberos V types for the per-msg tokens.  I did,
at one time, propose that we extend KRB-SAFE as we would in extensions,
but I thought then (and now) that it's a lot easier to safely extend
KRB-SAFE in a way that we'd still like when we got to extensions than it
would be to extend AP-REP.

> With that, I would not object assigning a new tag for the resulting
> AP_REP message.
> 
> Yet another question is whether this new message definition should go
to
> the Kerberos clarifications or this draft.

No, clarifications is not about extending Kerberos V.  That's what the
extensions work that we'll be doing at the interim meeting is for.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 8 Sep 2003 10:30:05 -0700

> calling it "extensions" to disconnect it from the Kerberos V GSSAPI

No Larry, it's not that the field name is unappealing.  I've explained
my position.

I don't want to have each application define its own Kerberos extensions
except through the use of typed holes (adding a typed hole is not the
same sort of extension as using an existing hole).

> your arguments against this apply as well to the use of the GSS checksum

Sure, except that checksum 0x8003 is water under the bridge.  We're
supposed to learn from mistakes of the past so we can avoid repeating
them.

Now, I am tempted to design the new context tokens with proper use of
the checksum field of the authenticator.  If we make the context token
design generic enough we can build on it later to get user2user and even
1 1/2 round-trip AP exchanges (to allow us to get rid of the replay
cache safely).  IMO we can do this w/o extending Kerberos V types.

We could also wait for extensions to arrive; but I thought we'd already
reached consensus on that.

Cheers,

Nico
--

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 08 Sep 2003 17:30:14 -0400

> same sort of extension as using an existing hole).

Precisely.  Adding a typed hole is pretty much like adding any other field. 
Note that while kerberos-extensions will likely leave extension markers at 
the end of most of its messages, allowing for the addition of fields in 
later versions of the protocol, the use of this mechanism will be strictly 
limited to revisions of the protocol, and _not_ available to applications 
and others who want to extend the Kerberos protocol.  Nico is quite correct 
that applications should extend Kerberos _only_ through the use of typed 
holes and similar mechanisms expressly provided for that purpose.

I know I'm about to go down a rathole a bit here, but I think it's relevant 
to the upcoming discussions about how kerberos-extensions should be encoded 
and exactly what we need to add to new messages...

In the process of working on extensibility mechanisms over the past couple 
of years, I think we'd all pretty much assumed that it was not necessary to 
add a new typed hole to any message that already had one.  After all, the 
type space is quite large (infinite, if that's what we want, or 2^32, if we 
want to be reasonable about it), and the effect of any given item is 
defined entirely by the definition of that type, with no effect on 
implementations that don't understand it.

I can think of two major exceptions to this rule:

(1) authorization-data is special because unknown authorization data are 
critical.  That means that most extensions will have to be wrapped in 
AD-IF-RELEVANT.  I don't think this alone poses a problem; in fact, we may 
want to define *-CRITICAL wrappers for all of the other typed holes, to 
allow this behaviour in any of them.  It strikes me as unfortunate that the 
authorization data field works differently in this respect from every other 
typed hole in the protocol, but we've already argued that point and agreed 
upon the behaviour defined in kerberos-clarifications.

So, I don't think there's any _real_ problem with using authorization-data 
as a generic typed hole.  If, in fact, the working group concurs, then I 
think we should avoid adding a second hole to a message (or, in this case, 
message component) that already has one, since that will undoubtedly 
generate confusion among implementors and those wishing to extend the 
protocol as to which one should be used.

(2) The other potentially problematic case is the preauth data in KDC-REQ. 
I know that some KDC implementations, if they see any PA-DATA at all, will 
act as if preauth is required.  In other words, if they receive a KDC-REQ 
that contains PA-DATA, but none they understand, the request will be 
rejected even if preauth was not required.  This is relatively easy to work 
around, since you do get a KRB-ERROR back, but it does mean an extra round 
trip in some cases if you aren't careful.

In this case, I'm not sure how much a new typed hole helps us.  Still, we 
should probably think about what behaviour to recommend to applications 
using this hole, and especially about how best to handle negotiation of 
extensions support in the AS-REQ, if we're taking advantage of this hole to 
do so.

-- Jeff

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 8 Sep 2003 14:48:17 -0700

> I can think of two major exceptions to this rule:
[...]
> protocol as to which one should be used.
[...]

Note my point about possible interfaces to authorization data.  So for
AD we may want to have containers different from AD-IF-RELEVANT to
indicate that some hole extension is not really AD.

And note too that if all typed holes were general then we'd want a
conbined namespace for them all, but since they already have disjoint
namespaces we have to pick from several options: whether we create a
unified portion of the namespace for new hole extensions, a unified
namespace for all of Kerberos extensions (clean break), a generic
container for use in all holes to contain items with IDs from a unified
namespace, or whether we assign a type id per-typed-hole to each hole
extension.  (There are probably other options.)

So there's more than just two wrinkles to generalizing existing typed
holes.  Which doesn't mean that we can't do it - but there's more than
it may seem at first glance.

Nico
--

---

From: "Joel N. Weber II" <[email-masked]>
Date: Mon, 08 Sep 2003 19:26:22 -0400

Are there examples of things that people want to put in a typed hole
where the same structure will be used in both pa-data and in
authorization-data, and where the semantics can be sufficiently
similar that you actually care about having a unified namespace?  I
can't think of any offhand, but maybe there are.

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 08 Sep 2003 23:52:11 -0400

On Monday, September 08, 2003 14:48:17 -0700 Nicolas Williams 
<[email-masked]> wrote:

>> In the process of working on extensibility mechanisms over the past
>> couple  of years, I think we'd all pretty much assumed that it was not
>> necessary to  add a new typed hole to any message that already had one.
>> After all, the  type space is quite large (infinite, if that's what we
>> want, or 2^32, if we  want to be reasonable about it), and the effect of
>> any given item is  defined entirely by the definition of that type, with
>> no effect on  implementations that don't understand it.
>>
>> So, I don't think there's any _real_ problem with using
>> authorization-data  as a generic typed hole.  If, in fact, the working
>> group concurs, then I  think we should avoid adding a second hole to a
>> message (or, in this case,  message component) that already has one,
>> since that will undoubtedly  generate confusion among implementors and
>> those wishing to extend the  protocol as to which one should be used.
> [...]
>

Why does this matter?  If you know about an extension, then you know 
whether it's really AD or not.  And if you don't, then knowing whether it's 
critical is sufficient to decide whether to ignore it or reject the message.

> extension.  (There are probably other options.)

It's true that there may be extensions that make sense in more than one 
place.  However, with the exception of a handful of "meta" extensions like 
NOOP, CRITICAL, or IF-RELEVANT, I think it is unlikely that an extension 
will make sense in _every_ typed hole -- most are pretty well tied to the 
context in which they can appear.  I think it is better to maintain a 
separate namespace for each hole, and allocate multiple ID's in those cases 
where a particular extension makes sense in multiple places.

Yes, there are several issues to be resolved.  We should discuss them, 
preferably sooner rather than later -- if we're going to have arguments 
next week, I'd like to know what at least some of them will be about. :-)