Subject: initial analysis of semantic-diff for discussion

From: Tom Yu <[email-masked]>
Date: 19 Jul 2001 16:48:46 -0400

The following is a copy of a message that I had previously circulated
in a smaller audience; it contains some analysis of the message
changes between RFC 1510 and draft-07, and discusses some of the
backwards-compatibility problems inherent with those changes.  For the
most part, the protocol changes betwen RFC 1510 and draft-07 can NOT
be implemented without some serious thought and further development
applied to backwards compatibility issues.

--------------------

So the most significant changes between 1510 and draft-07 may be
broken into two gross categories for further discussion:

1. changes that make a previously required field optional

2. changes that add optional field(s) to existing types

The first category may be further subdivided:

1a. the KDC-REQ-BODY inner type.

1b. the application message inner types KRB-SAFE-BODY and
    EncKrbPrivPart

In the second category, these are Ticket and KRB-ERROR.

In general, I believe that it may be best to back out these changes
for now, due to the degree of complexity that backwards compatibility
would introduce; this may be somewhat mitigated by creating distinct
types (and tags) for the changed messages.  This enables decoders to
know fairly immediately whether they are dealing with an old-style or
new-style message.

Even if the approach of identifying changed messages at the outermost
layer is adopted, the number of ways that different parties in the
overall protocol that need to keep track of each other's capabilities
is large enough that we will likely want to drop these changes until
we come up with a complete set of changes that we are fairly certain
will cover all future changes to the protocol that involve the various
parties in the protocol keeping track of the capabilities of other
parties, essentially batching all such changes into an all-or-nothing
jumbo change.

Detailed descriptions of the backwards-compatibility implications of
changes to each message follow.

Previously required fields becoming optional:
---------------------------------------------

The general problems inherent in the first category of changes involve
sending of messages while omitting the previously required fields.
Implementations may very well reject these messages as malformed.  Any
implementation that will generate messages that are missing previously
required fields will need some authenticated means of detecting
whether the other side understands the new message.

KDC-REQ-BODY.till:

We can look at KDC-REQ-BODY first; the analysis for omitting
KDC-REQ-BODY.till in AS-REQ is rather simple: you can't.  A client
that has no way of knowing the capabilities of the implementation it's
talking to *cannot* send an AS-REQ with KDC-REQ-BODY.till omitted; at
least MIT krb5 will fail to return an error at all if the message
isn't parsable.

In the case of TGS-REQ, it may be possible to work around this
problem, but it requires the client finding out in securely whether
the KDC supports the omission of KDC-REQ-BODY.till.  The only even
moderately easy way I see of doing this securely is by setting some
ticket flag.

There may be a way to do similar things for AS-REQ, but it would
require an additional roundtrip, possibly involving authenticated
padata in the KRB-ERROR, so we probably should discount that
possibility for now.

app message inner types:

For the client to indicate to the server whether it can support the
omission of perviously required fields, ap-options may be used, or
possibly authorization-data might be used.  The first has the bug that
it's not authenticated.  The second is rather kludgey.  In any case,
the client needs some way to discover whether the server supports
omission of previously required fields.

It may be possible for the client to learn of whether a service
supports omission of previously required fields by having the KDC
indicate this in the ticket (or more precisely, in the KDC-REP).

New optional fields:
--------------------

The general problems inherent in the second category of changes are
that implementations may not understand the extension fields, and may
reject the message, crash, or simply drop the extension fields.  Older
MIT krb5 implementations will crash upon being presented with
unrecognized new fields.  It may, however, be safe to make the
simplifying assumption that the worst that an "old" implementation
will do is reject the message.

The ASN.1 spec is moderately ambiguous about how extended types are to
be handled, but it does strongly imply that only extensible types may
have their decoders parse without error the encoding of a type with an
unrecognized extension.  We may imply that all our types are
retroactively extensible, but I really don't like this possibility, as
it may have difficult-to-analyze consequences.

Ticket.extensions:

The main problem here is that the client has to securely indicate to
the KDC whether it will accept ticket extensions, which is essentially
impossible in an AS-REQ.  The client may indicate its willingness to
accept a new-style Ticket in a flag, but that may be modified by a
man-in-the-middle.

Even if the client can accept ticket extensions, the KDC must know
whether the application server will accept the ticket extensions,
which creates tremendous amounts of administrative hassle.

KRB-ERROR.e-cksum:

Analysis of this message is somewhat difficult, since it is used in
both the KDC protocol and the application protocol.

In the KDC protocol case, the client must indicate whether it can
support the e-cksum field.  As in the ticket extension case, it is not
possible to do this easily in a secure way via the AS-REQ exchange.

In the application protocol case, the scenario reduces to something
similar to the the application message inner types, with similar
kludgery.

--------------------

This turned out to be somewhat longer than I expected, but hopefully
it makes somewhat clear the magnitude of some of the difficulties
involved.

---Tom