Subject: [Ietf-krb-wg] Progress of Kerberos 5.3

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 29 Nov 2007 17:13:42 -0500 (EST)

I've been thinking a lot lately about FAST, STARTTLS, the proposal that
Sam, Tom, Nico, and Larry made that we talked about in Chicago, and the
fact that we haven't made much progress since then on Kerberos 5.3.

When Nico commented recently that we had consensus on FAST+PKINIT being
the "primary" solution in the protecting-the-AS-REQ-exchange space, I
replied privately that I didn't think we had actually made that
decision.  I believe we agreed with the direction the preauth framework
document has taken, and the result will be a standards-track document on
which other standards-track documents will build, including mechanisms
like the OTP mechanism Gareth Richards is currently working on.
However, it's not clear that we actually reached a consensus that using
FAST is "the" way to protect the AS exchange.  Nico asked me to issue a
consensus call on that question, and I will, though probably not until
after Vancouver.

However, I think there are several more-or-less interrelated issues
here, and we should consider all of them and come to consensus on a
coherent set of answers.  I'd like to have a discussion, starting here
and then continuing in Vancouver if necessary, on these points.
Eventually, my hope is that this will resolve into something on which I
can issue a consensus call.

I have the following questions in mind.  Note that these are somewhat
interdependent, in that the answers to some may depend on others:

(1) Do we want to proceed with Kerberos 5.3 along the lines of the
    proposal Sam sent to the mailing list on June 6 and which was
    discussed in Chicago?  Particularly, I'm talking about the following
    points:
    (a) Tying negotiation of new protocol messages to negotiation of
        FAST(*); that is, new messages are used when and only when FAST.
    (b) Using FAST(*) as the basis for authenticated cleartext.
    (c) Simplified versions of new protocol messages.
    (d) The ticket-extensions-as-magic-enctype hack.
    (e) Structuring the new specification as a set of updates to
        RFC4120, rather than a complete replacement.

    (*) Or something like it -- it's been pointed out that STARTTLS
        could be used in an equivalent way.

(2) Should support for FAST be REQUIRED?  RECOMMENDED?

(3) Should support for FAST be taken to indicate support for krb5.3?

(4) Should support for STARTTLS be REQUIRED?  RECOMMENDED?

(5) Should support for STARTTLS be taken to indicate support for krb5.3?

(6) Should STARTTLS be standards track?

Now, I'm deliberately treating the i18n issues somewhat separately.
I think we can discuss how i18n needs to work separately from the
question of exactly what the new messages look like and how we decide
when to use them.  However, I do think we need to discuss i18n and
settle on some answers, so we can get a document written.

The Sam/Tom/Nico/Larry proposal includes a partial description of how
internationalization could work; I'd like to suggest that people go
back and read and comment on it.  There's also the question of what
form of preparation needs to be applied to UTF-8 strings, when, and
by whom.  I would be thrilled if someone who's been thinking about
these issues would make some proposals we can discuss.

-- Jeff

_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg