Subject: RE: Extensibility and GSSAPI-CFX

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Mon, 15 Dec 2003 22:21:13 -0800

We (MS) rely on the extra round-trips (we call it "legs", 1 round-trips
== 2 legs) to do things like virtual clocking (namely where the server
has a time skew and we do the virtual clock mechanism and recalculate
the authenticator) and key re-synchronization (when a server changes its
keys and a cached service ticket fails to decrypt), etc.  

These advanced capabilities are shipped since win2k gold, and we have
been advocating diligently that applications should migrate to the
context-establishment-loop approach. We would certainly hope by the time
when we need an update to GSSAPI-CFX, applications that are hard-coded
to handle no more than 3 legs would have gone away.

Nevertheless, I think Nicolas' proposal for extensions in the separated
email is acceptable: the MS-shipped codebase ignores any trailing data
after the Dlgth; the level of complexity thus introduced is comparable
to what we would replace it with, and it is fairly easy to test (we
should make sure it is covered in the interop test).

Hence I am willing to trade his proposal with the extra leg idea for
negotiating CFX-bis. 

Thanks,

Larry

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Sam Hartman
Sent: Monday, December 15, 2003 10:15 AM
To: [email-masked]
Subject: Extensibility and GSSAPI-CFX

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.