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 09:55:49 -0700

I include a summary for the offline discussion with Nicolas.

The proposed change is:

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

Jeffrey Hutzelman wrote:
>> Except that you can't do that, because it changes the message in a
way 
>> that is not backward-compatible.  So you end up either specifying a
new, 
>> backward-incompatible version of Kerberos or specifying a Kerberos
GSS 
>> mechanism which does not use Kerberos messages.  Neither is
desirable.

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 will use the OPTIONAL "options" if and only if we know the
implementations for both the sender and the receiver support this new
message definition, possibly because of the use of "newer" enctypes,
similarly to the treatment of the new per-message/context-deletion token
formats.

The problem, however, is that we'd still end up with several different
versions of Kerberos (rfc1510/clarifications, the mech, Kerberos V
extensions), unless we commit to building extensions on top of this
proposed extension.  We should discuss this at the interim meeting.  

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.

Thx.

Larry

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

On Sunday, September 07, 2003 10:57:15 -0700 "Liqiang(Larry) Zhu" 
<[email-masked]> wrote:

> I still think it is easier if we just insert an OPTIONAL typed hole
into
> the AP_REP

Except that you can't do that, because it changes the message in a way
that 
is not backward-compatible.  So you end up either specifying a new, 
backward-incompatible version of Kerberos or specifying a Kerberos GSS 
mechanism which does not use Kerberos messages.  Neither is desirable.

We will be working on adding typed holes to messages that are missing
them 
as part of extensions.  In order to do this, we'll likely end up
specifying 
new kinds of messages with new application tags, as well as a precise
model 
for determining when to send new messages vs old ones.  This is
necessary 
because there are existing deployed implementations of RFC1510 (and
soon, 
perhaps, kerberos-clarifications) which will reject badly-formed
messages.

-- Jeffrey T. Hutzelman (N3NHS) <[email-masked]>
   Sr. Research Systems Programmer
   School of Computer Science - Research Computing Facility
   Carnegie Mellon University - Pittsburgh, PA

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 8 Sep 2003 09:58:44 -0700

> 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.

> backward-compatible, but we can get away with that and we already

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.

> 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: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 08 Sep 2003 13:23:05 -0400

> backward-compatible, but we can get away with that and we already

You've crossed the line in the GSS mechanism, and that's fine.  But again, 
either you're talking about specifying a new version of Kerberos which does 
not interoperate with old versions (and presumably, you decide within the 
mechanism when to use which version) or you are specifying a "Kerberos" 
mechanism which does not use Kerberos messages.  Both are undesirable.

Specifying a new version of Kerberos should be left for extensions.  I 
don't think it's OK to define a new AP-REP message as part of this 
mechanism and assume that it will be the same as what comes out of 
extensions.  We saw plenty of contention on this issue just in the process 
of getting to the clarifications/extensions split, and the proposals for 
what new messages should look like have changed several times.  Given the 
set of people who will be attending next week's meeting, it would not at 
all surprise me if we came to some agreement on what these messages should 
look like, then found out that someone who didn't come to the meeting had a 
fundamental objection.

> proposed extension.

This is backwards.  We should commit to building the revised GSS mechanism 
on top of kerberos-extensions, not the other way around.  Or, the mechanism 
should be designed to work on top of kerberos-clarifications without 
requiring any backwards-incompatible messages.

> the Kerberos clarifications or this draft.

No, this is not an open question.  The new AP-REP message you propose would 
require negotiation within the Kerberos protocol, which involves changes to 
KDC-REQ, KDC-REP, and AP-REQ, at a minimum. In other words, you can't rev 
this one message without solving the whole problem.

Even if that were not the case, we have clear working group concensus that 
this work does _not_ belong in kerberos-clarifications; in fact, that is 
one of the main reasons for the document split.

---

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

So, if there's any coherent list of proposals for how to do extensions
somewhere, I'm not aware of it.  Maybe what I'm saying here is even
something someone else has already thought of.

But it seems to me that if you are willing to accept that
authorization-data should be reallocated to be a general-purpose typed
hole, then it ought to be fairly straightforward to deal with adding a
typed hole to AP-REP: you define a new message, which you call
AP-REP2, or AP-REP-X, or whatever, which is like the existing AP-REP
but adds an authorization-data field.  And then you have the
application server decide whether to use AP-REP or AP-REP2 by looking
at the authorization-data in the authenticator: if it contains at
least one element which clearly implies that the client understands
extensions, the server uses AP-REP2; otherwise, it uses AP-REP.  If a
client wants to use extensions but also be compatible with a
non-extensions server, it can use the appropriate authorization-data
element to mark stuff as optional.

(You also need to think a little bit about downgrade attacks; a naive
implementation of the previous paragraph might allow an attacker to
take the contents of the AP-REP2, strip out the authorization-data,
and send the rest in an AP-REP.  Picking a different key usage value
for AP-REP2 than what is used for AP-REP may be a sufficient solution,
or it might be worth perturbing the message format in some other way.)

I am a bit concerned that creating a new typed hole in addition to
authorization-data is likely to increase the complexity of the code,
and is likely to make it harder to negotiate extensions vs not in a
way that protects against a man in the middle performing a downgrade
attack.

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 8 Sep 2003 12:36:20 -0700

> something someone else has already thought of.

There was a lot of ASN.1 exchanged (mostly written by Sam) 18-24 months
ago.  There was plenty of discussion at two interim meetings and there
are minutes, but we have to solidify a proposal and resolve outstanding
issues.  We expect to make headway at the upcomming interim meeting.

> or it might be worth perturbing the message format in some other way.)

Negotiation has been dealt with already.  I.e., we have consensus on how
Kerberos V extensions will be negotiated.

(And how on earth could an attacker strip out plaintext items that are
sent confidentiality protected?)

> way that protects against a man in the middle performing a downgrade

One has to consider too the different criticality rules, and the
possibility that there may be interfaces which pass unknown
"authorization data" types to applications for them to interpret, so
reallocating the authorization-data typed holes may not be as trivial as
all that (it may require the creation of a container, which like
AD-IF-RELEVANT indicates non-criticality, but also that the contained
data aren't quite "authorization data."

We're going down a rat hole.

Nico
--

---

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

> Kerberos V extensions will be negotiated.

Is this documented in some more helpful way than ``go spend hours
looking through the archive, and hope that you happen to stumble
across it?''

> sent confidentiality protected?)

If they're all sent in one blob of integrity protected data, you
can't.  I should have looked at the ASN.1 before sending that mesage;
I was thinking that if you added a new field to AP-REP and encrypted
it seprately, there'd be a problem, but of course the sensible thing
to do would be to add a field to EncAPRepPart.

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 8 Sep 2003 19:52:13 -0700

> looking through the archive, and hope that you happen to stumble

Go spend hours in the archives.

Sorry, this is the IETF, we produce I-Ds, RFCs, BCPs and STDs.  If we
had documented those discussions well enough to publish an I-D on
Kerberos extensions then we'd be pretty close to done right now.  But
it's not like the WG has done nothing since then...

Nico
--

---

From: Sam Hartman <[email-masked]>
Date: Wed, 10 Sep 2003 17:05:34 -0400

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

    Nicolas> On Mon, Sep 08, 2003 at 03:26:47PM -0400, Joel N. Weber
    Nicolas> II wrote:
    >> So, if there's any coherent list of proposals for how to do
    >> extensions somewhere, I'm not aware of it.  Maybe what I'm
    >> saying here is even something someone else has already thought
    >> of.

    Nicolas> There was a lot of ASN.1 exchanged (mostly written by
    Nicolas> Sam) 18-24 months ago.  There was plenty of discussion at
    Nicolas> two interim meetings and there are minutes, but we have
    Nicolas> to solidify a proposal and resolve outstanding issues.
    Nicolas> We expect to make headway at the upcomming interim
    Nicolas> meeting.

No, the ASN.1 was all written by Tom; the presentations and a lot of
thetext-level  design was stuff I worked on though.

Read the presentation from the IETF 52 minutes.

---

From: Sam Hartman <[email-masked]>
Date: Wed, 10 Sep 2003 17:04:18 -0400

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

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

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

So, I'm with Nico--it's OK to use such an extension only if we plan to
adopt it for Kerberos in general.  ANd I remind people of Ken's point:
it is very unfortunate if we end up adopting a slightly different
actual extension mechanism for ap-rep.  I.E. using an extensions
ap-rep is OK; using something between clarifications and extensions is
not.

Also, I question whether the GSSAPI optional token features are really
protocol elements at the Kerberos level.  Applications should not use
the typed holes in Kerberos as a substitute for protocol design.
I.E. if I were doing GSSAPI today, the 8003 checksum should not go in
the authenticator at all.

I could go either way on the second point--I'm fairly certain the
GSSAPI data elements are not  Kerberos protocol elements, but we're already committing that sin.  

--Sam