Subject: [Ietf-krb-wg] Oops, I didn't actually implement the spec when implementing anonymous pkinit

From: Sam Hartman <[email-masked]>
Date: Mon, 14 Feb 2011 21:45:48 -0500

Anonymous is in auth48.
Reading it one last time, I realized that section 4.1.1 doesn't say what
I thought it did when implementing anonymous pkinit for MIT Kerberos.

It says that an implementation should generate SignedData with no
signerInfos.  I thought (entirely out of my own delusions apparently)
that rather than generating a SignedData, the implementation should use
the Data content type.

Both would be legal things to do.

I think it's worth discussing with the WG what to do at this point.

First, if there's someone who is actually interoperable with the current
spec, I think it's fairly clear that we should stick with the current
spec.  (If you have such an implementation and don't feel comfortable
saying so on the list, please write to one of the authors of anonymous,
one of the WG chairs, or our AD).

I'm aware of two implementations MIT, which is not interoperable in the
way I described above.  Heimdal, which at least the last time I checked
didn't implement section 7 of the spec.  I don't know if anyone else has
shipped an implementation.

I don't think there is really any technical reason to prefer either what
the spec does or what MIT shipped. I think both are legal, and I can
make arguments that both are superior (which generally means neither
is.)

Obviously, with my implementor hat on, I'd prefer that we changed the
spec to do what our implementation does.

Assuming no one has shipped something interoperable with the spec, I
think it would be reasonable to do that, but  there are a few reasons we
might not want to:

1) It would favor MIT Kerberos. I can understand why the Heimdal folks
could be frustrated by this: at the time they implemented anonymous
PKINIT section 7 didn't exist.

2) There might be some implementation out there tracking the drafts but
not participating in the WG.

I'll admit that I find reason 2 kind of uncompelling.
I would find it quite compelling if someone stepped forward in response
to this message and said they had an implementation they believed met
the spec. It's the fear of breaking non-participants prior to RFC
publication I find problematic.

3) If we do not change the spec, are we willing to make things easier
for MIT in terms of transition? For example we could have the RFC
require advertizing explicit support for anonymous pkinit.

Anyway, I'm quite embarrassed about this and would appreciate any
comments people have.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Love Hörnquist Åstrand <[email-masked]>
Date: Mon, 14 Feb 2011 22:46:09 -0800

Heimdal uses zero signer SignerData and I would it to stay that way.

I'm fine with adding more announcement flags.

Love

---

From: Sam Hartman <[email-masked]>
Date: Tue, 15 Feb 2011 07:10:48 -0500

>>>>> "Love" == Love Hörnquist Åstrand <[email-masked]> writes:

    Love> Heimdal uses zero signer SignerData and I would it to stay
    Love> that way.

Ah, if I'm understanding correctly Heimdal produces a client request
that complies with the current spec.
A spec client cannot accept a request from a Heimdal KDC, although you
could create a client that accepted the Heimdal KDC response if you were
validating the KDC certificate.

    Love> I'm fine with adding more announcement flags.

How about requiring anonymous implementations to advertize PA_PKINIT_KX
with an empty padata value?  This has the advantage of being able to
discover (assuming you have a principal) if a KDC supports anonymous
pkinit and gives us a transition strategy.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg