[kitten] Options for IAKERB compatibility issue

[Greg Hudson <[e-mail]>]

Here are some options for addressing the superficial incompatibilities
between MIT's implementation of draft-zhu-ws-kerb and the current
draft-kitten-ietf-iakerb (see [1] and [2] for details).

1. We can ignore the problem.  MIT's implementation won't be compatible
   with the standard and we won't be able to make it compatible without
   breaking compatibility with ourselves.

2. We can revert to the draft-zhu-ws-kerb superficialities.  This works
   great for MIT, but presents OSX with the same problem as MIT would
   have in #1.

3. We can make the standard semi-compatible with both implementations:
   - always generate generic token framing
   - process framed or unframed messages after the first initiator token
   - acceptors must process either kind of finished extension
   - initiators may send either kind of finished extension
   A standard acceptor would work with MIT and OSX initiators.  A
   standard initiator can only be compatible with MIT or OSX acceptors
   (it has to guess which type of finished extension to send), but will
   always be compatible with a standard acceptor.

4. Possibly in addition to #3, we could extend IAKERB-HEADER with a new
   field that acts as an "I implement the standard" cue.  This option
   would give MIT a path to generating the pku2u-style of finished
   extension, but it doesn't create a better compatibility matrix than
   just requiring acceptors to allow both kinds of finished extension.

5. We can define a new mech OID for the standard.  I don't like this
   option because I don't like proliferating krb5 mech OIDs.  It also
   means the standard wouldn't interoperate with either OSX's or Apple's
   implementation.

[1] http://www.ietf.org/mail-archive/web/kitten/current/msg03919.html
[2] http://www.ietf.org/mail-archive/web/kitten/current/msg03984.html