Re: [kitten] Options for IAKERB compatibility issue

[Greg Hudson <[e-mail]>]

I just realized that we can use the absence of framing to detect an MIT
IAKERB implementation.  This makes the problem much more tractable.

So here is option 6 (a variation of option 1), which is my preferred option:

6. The main text of the standard stays as-is.  We add an appendix
describing how to be compatible with the current MIT implementation:

- Process messages without framing after the first initiator token.

- If you're the initiator and you see an unframed acceptor token, use
the MIT variant of the finished extension in the AP-REQ  checksum
(extension type 1 and key usage 42).

- If you're the acceptor, process either variant of the finished extension.

If we go in this direction, the MIT implementation can change to
generate framing on all tokens, send the standard variant of the
finished extension in the AP-REQ checksum if it sees a framed acceptor
token, and process either variant of the finished extension in the acceptor.

Sorry I didn't realize this yesterday; I could have cut out a
substantial amount of noise.