Subject: [kitten] Options for IAKERB compatibility issue

From: Greg Hudson <[email-masked]>
Date: Mon, 06 May 2013 14:34:23 -0400

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

---

From: Nico Williams <[email-masked]>
Date: Mon, 6 May 2013 13:56:41 -0500

>    means the standard wouldn't interoperate with either OSX's or Apple's

The new mech OID would interop with one of the existing
implementations, and the other implementation would have to support
the old and new mech OIDs in order to get past non-iteroperability.
What's wrong with that?

In any case, something has to be done, some tears may have to be shed.
 It'd be useful to have an idea of what deployments exist.  Perhaps we
should start by polling for deployments.

Nico
--

---

From: Greg Hudson <[email-masked]>
Date: Tue, 07 May 2013 13:38:08 -0400

> implementations

Not under any reasonable definition of "interoperate".  If the standard
uses a different OID from 1.3.6.1.5.2.5, then an implementation of the
standard won't interoperate with an existing MIT krb5 or OSX implementation.

One could potentially use the same or similar code for both OIDs, but
that's not interoperating; that's code sharing.

---

From: Love Hörnquist Åstrand <[email-masked]>
Date: Tue, 7 May 2013 11:02:05 -0700

2 is not an option, its 5 or 1. prefer 1. doubtless after doing interop testing we'll find more issues.

Love

6 maj 2013 kl. 11:34 skrev Greg Hudson <[email-masked]>:

> _______________________________________________
> Kitten mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/kitten

---

From: Greg Hudson <[email-masked]>
Date: Tue, 07 May 2013 14:16:16 -0400

> testing we'll find more issues.

Can you please explain your objection to #3?

---

From: Love Hörnquist Åstrand <[email-masked]>
Date: Tue, 7 May 2013 11:22:47 -0700

> Can you please explain your objection to #3?

it require changes. I fine with saying REQUIRE framing, but if you want to interop, you better consider accept unframed too.

Love

---

From: Greg Hudson <[email-masked]>
Date: Tue, 07 May 2013 14:38:28 -0400

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.

---

From: Sam Hartman <[email-masked]>
Date: Wed, 08 May 2013 11:47:30 -0400

Greg, presumably MIt would need to send unframed messages if it gets an
unframed acceptor message as well.

That is, I think your option works but your description of the appendix
is incomplete.

---

From: Greg Hudson <[email-masked]>
Date: Wed, 08 May 2013 11:52:39 -0400

> unframed acceptor message as well.

No, this is unnecessary.  Our implementation will happily process framed
messages for all context tokens.  (Verified experimentally.)