Subject: Extensibility and GSSAPI-CFX

From: [email-masked] (Sam Hartman)
Date: Mon, 15 Dec 2003 13:14:37 -0500 (EST)

This is not specifically a last call comment to the working group.  In
particular I am not proposing a change to the document nor objecting
to it.  However I'm warning the working group about the consequences
of a decision that we have made.  OThers may wish to turn this warning
into an objection.  I hope not; doing so would slow down the process.
But I'd rather have that objection now than have it pop up later.

The current CFX spec requires implementations to add an extra round
trip if the acceptor receives an unknown token ID.  We had hoped to
use this as a way to get extensible tokens.  If the initiator sends a
even-newer-than-CFX token and the acceptor only supports CFX, then the
acceptor will return the unknown token error and downgrade to CFX.  We
can secure this downgrade by allocating a flag in the future.

This feature has not met with implementation success.  The first
problem is actually implementing it in the CFX library.  I think we're
dealing with that; the MIT implementation will produce unknown tokens
to test this behavior and so we're catching implementation bugs in the
CFX libraries.

However the second problem is more serious.  Martin mentioned that
applications tended to assume the Kerberos mechanism was 0.5/1 round
trip.  I knew of some applications that did this, and a few major
applications (Microsoft HTTP) but did not realize how widespread the
problem is.

Basically there is a lot of code out there that cannot deal with
acceptor returning continue_needed.  Our extensibility model isn't
great for this code because the initiator needs to know whether the
acceptor actually supports unknown tokens before it sends one.

An alternative extensibility model we could have used is to define a
new format context token for the first exchange.  Larry convinced us
we didn't want to do that.  If we had gone down that path the
initiator could have offered capabilities it supported in the first
token and only acceptors that supported these capabilities could have
acted on them.

The reasons we didn't do this were as follows:

1) A probable fork between how Microsoft did context setup and
   everyone else.

2) Specification complexity now

3) Testing unused implementation complexity.

Unfortunately all three of these reasons are more compelling now than
when we made our original decision.

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 15 Dec 2003 20:51:34 -0800

> can secure this downgrade by allocating a flag in the future.

Perhaps if we use something inside the Authenticator to indicate the
desire to do something newer than CFX...  At least such a flag would be
integrity protected, whereas the token ID is not.

The criticality of the checksum 0x8003 flags field (acceptors ignore
unknown) makes that an attractive vehicle for this and could be used for
future extensions without changes to CFX...

We should consider how new versions of the mech after CFX would prevent
downgrades to CFX.  And we should consider whether the CFX I-D should
have any text about this.

Currently my thought is that new versions of the mech after CFX MUST
have a different AP-REP token that binds the context to the initiator's
request for the new version.

And CFX interop tests must check that acceptors do ignore unknown
context flags.

> token and only acceptors that supported these capabilities could have

We can certainly do this when the initiator knows that the acceptor
should support the new tokens (again, newer enctypes, Kerberos V
extensions, and all that).  I'm not sure this buys us much though,
unless my late night thoughts on newer-than-CFX negotiation are just
wrong.  See above.

The delegated credential length field, however, ight be a problem for
Larry if MS really intends to use other methods for negotiating between
rfc1964 and CFX than the ones discussed n the draft.

> when we made our original decision.

We can still get it right.  Here's three possible decisions we can make
that I see clearly atm:

a) to hell with CFX extensibility
b) agree that the context flags criticality (they're not critical) is
   the ticket to extensibility
c) make some context token changes to better support extensibility

IMO, and maybe it's too late right now, (b) is the correct decision.

LAST CALL COMMENT:

If (b) then we should remove the last paragraph of section 4.1

Cheers,

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 15 Dec 2003 21:10:17 -0800

Further, I would like at least one bit of the context flags to be
specifically reserved for use by future extensions to CFX, as opposed to
all context flags being reserved for allocation by extensions to the
GSS-API (they being GSS-API context flags and they having the same
values as given in rfc2744 that is the conclusion readers may be tempted
to draw).

Besides the reserved flag bit(s), should the remaining bits be defined
to be as the GSS-API, using values from the C-Bindings of the GSS-API?

Nico
--

---

From: Sam Hartman <[email-masked]>
Date: Tue, 16 Dec 2003 16:15:54 -0500

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

    Nicolas> Further, I would like at least one bit of the context
    Nicolas> flags to be specifically reserved for use by future
    Nicolas> extensions to CFX, as opposed to all context flags being
    Nicolas> reserved for allocation by extensions to the GSS-API
    Nicolas> (they being GSS-API context flags and they having the
    Nicolas> same values as given in rfc2744 that is the conclusion
    Nicolas> readers may be tempted to draw).

I thought all the context flags that Larry did not reserve for
Microsoft use were reserved for future use in Kerberos GSSAPI
mechanisms.