Subject: Proposal: FAST as an alternative to RFC 1510ter

From: Sam Hartman <[email-masked]>
Date: Wed, 06 Jun 2007 16:39:32 -0400

<hat role="individual">

Nico, Larry, Tom and I would like to ask the working group to consider
an alternative to the direction we chose for Kerberos Extensions at IETF 53.

The problem with extensions is that few if any implementers plan to
implement them.  There is a lot of complexity for relatively little
gain.  The major things you get from implementing extensions are
support for internationalization, support for ticket extensions and
support for authenticated cleartext.

These are all good to have.  The problem is that the cost seems to be
too high for anyone to schedule the work.

We'd like to find an alternative way to accomplish these goals that is
easier to implement.

We believe that by leveraging the fast proposal we may be able to do
that.  First of all, by combining with fast, we get additional
leverage: fixing preauth is something that people definitely want to
do.

Nico started things off by pointing out that we probably wanted to
include a full kdc req body in fast, not just the client name field.

Then one of us wondered what type of string we should use there: UTF8
or general string.  ANd we realized that we had actually done the
first part of the extensions negotiation.

In particular, we propose to extend that KerberosString be replaced
with a choice type containing general string and utf8 string.  In a
given message you can only use one of these two arms of the choice.
We propose rules for figuring out what to use.

In the kdc request included in fast armor you use the new string.  In
a encrypted ticket part issued to a new server you use the utf8 arm.

In a ticket (the unencrypted part) given to a new client for a new
server you use the utf8 arm.

In an ap-req you use the utf8 arm if your ticket is using the utf8
arm.

That solves internationalization.  There are of course a few more
details to work through but we've basically dealt with most of them
for extensions.

FASt also gets you significant help with the authenticated cleartext
issue.

It turns out there is a clever or disgusting (depending on how you
think about it) hack that we can use for ticket extensions.  We can
define a new enctype (say 666) whose ciphertext contains a sequence.
The first element of this sequence is an enctype, followed by the real
ciphertext followed by a sequence of integer octet-string bindings.
Such tickets could be issued to any new service.  One advantage of
this approach is that even existing clients will preserve ticket
extensions in this model.
That might make pk-cross much easier to deploy.

Obviously, this is just a sketch of the proposal.  Is this interesting
enough to dedicate time to discuss in Chicago?

--Sam

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 6 Jun 2007 15:51:47 -0500

> enough to dedicate time to discuss in Chicago?

Yes.

I'll note that what you described can also be done with the starttls
proposal.  The whole thing hinges on using tunneling as the negotiation
for extensions.

Nico
--

---

From: KAMADA Ken'ichi <[email-masked]>
Date: Thu, 07 Jun 2007 09:09:56 +0900

At Wed, 06 Jun 2007 16:39:32 -0400,

Yes.

The alternative ticket extensions is most interesting for me.
Its advantage outweighs my uncomfortable feeling for the hack.

-- 
KAMADA Ken'ichi <[email-masked]>

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 6 Jun 2007 19:13:19 -0500

> Its advantage outweighs my uncomfortable feeling for the hack.

That's how I feel too.  Gross, but good.