For Kerberos, I was a minor foot soldier in the Crypto Wars.<p>Back in the mid 90s, Kerberos was restricted from export due to ITAR regulations (I had thought ITAR was obsolete, but just this year we had trouble purchasing some hardware <i>in the USA</i> due to ITAR restrictions).<p>Since IIRC Kerberos could be downloaded from MIT it's not clear how well these restrictions worked.<p>Nevertheless John Gilmore and I (maybe proposed by another of the Cypherpunks?) decided that we should get an ITAR-legal version of Kerberos in global circulation.<p>Before I ever left or contacted anyone about this a policy lawyer blessed it, and even talked about it with some people from the Commerce Dept, so everything was legal and above board. I'm pretty sure NSA knew about it too (this was back when NSA took Information Assurance seriously -- I think back then it might even have been a whole directorate).<p>The first step was to make a version with all the encryption stubbed out. That "worked" in that two copies of this code would connect to each other etc...with all communication in the clear with no encryption at all and no pretend-encrypted anything either. I think it was OK to take a password and copy it into another buffer and then send the contents to the other side of the connection, but honestly I don't remember and actually (see below) don't know.<p>I then went to Switzerland where I arranged for a local cryptographer to take our neutered code and make it compliant with the published papers on Kerberos. At that time <i>I</i> knew nothing about Kerberos's encryption and hadn't even look at source (neutered or original) so I wasn't even accidentally "exporting" anything in my head and could be sure I couldn't say anything to make the work easier. It was literally "can you make this package work as described in the literature".<p>After they got it working they connected to some sites in the US and all worked properly. And then we "imported" the swiss version and put it on our FTP server at Cygnus (Cygnus paid all the bills too) for other US people to use. Now there was a single copy of the source that could be used to protect people anywhere. Until then, even US companies couldn't use it to communicate with overseas divisions, even ones staffed entirely by US persons.
I worked at a commercial Kerberos vendor in the 90s. We had a lot of work to do to clean up after the various student projects and partial refactors that inhabited the codebase.<p>The single biggest pain point in deployed systems in the 90s: lack of reliable system time on authenticated clients (mostly PCs), leading to clock_skew errors.<p>Kerberos was clearly built for organization networks with multi-user Unix hosts running software built from source and a willingness to customize their services. The inbuilt support for major packages was often stuck on v4 even though v5 had been out for a while.<p>Kerberos was not built for the internet, or poorly-administered PCs, or closed-source commercial software services (which required painful kerberization).
cryptonector and I also specified a Kerberos-like protocol [1] based on Mozilla’s defunct BrowserID protocol. I demonstrated it as a drop-in replacement for Kerberos with Exchange, having built a Windows SSP and credential provider as well as a GSS-API implementation (the latter which is open source [3]).<p>Unfortunately after Mozilla cancelled Persona, this never went anywhere.<p>[1] <a href="https://datatracker.ietf.org/doc/html/draft-howard-gss-browserid-07" rel="nofollow">https://datatracker.ietf.org/doc/html/draft-howard-gss-brows...</a><p>[2] <a href="https://hacks.mozilla.org/2013/04/mozilla-persona-for-the-non-web/" rel="nofollow">https://hacks.mozilla.org/2013/04/mozilla-persona-for-the-no...</a><p>[3] <a href="https://github.com/PADL/libbrowserid">https://github.com/PADL/libbrowserid</a>
Shout out to attendees of the Nov. 1996 MIT Kerberos Workshop!<p><a href="http://web.mit.edu/pbh/www/workshop.html" rel="nofollow">http://web.mit.edu/pbh/www/workshop.html</a><p><a href="http://web.mit.edu/pbh/www/krb-attendees.html" rel="nofollow">http://web.mit.edu/pbh/www/krb-attendees.html</a>
Yes, I've been seeing Needham-Schroeder as a possible optimization in a PQ world, but in order to make it so we'll need a true Kerberos-ish infrastructure.<p>I've played a lot (in my mind, mainly, though I've done some implementation work) with using PKINIT and DANE to build something like the PKCROSS that never happened. I.e., we could use PKI (DANE preferably, as opposed to x.509) to bootstrap Kerberos symmetric trusts as needed / on demand.<p>There's a lot to think about before jumping in, like:<p><pre><code> - can we simplify Kerberos V5 and/or fix
various problems in it, or start from
scratch (and simpler)?
(IMO: start from scratch)
- think that symmetrically-encrypted JWT
is a lot like Kerberos' AP protocol
- we should strive to have an RFC 4559
style bearer token profile that can be
used with much less code than Kerberos
is traditionally implemented with
- we should strive to have Needham-Schroeder
in TLS so that we don't need all of the
awful krb5_...() APIs nor GSS-API
- though keep in mind that GSS-API is a
good basis for a TLS API (that's what
SChannel is: TLS as an SSP using the
SSPI, and SSPI is the MSFT equivalent
of GSS-API)
- let's make sure there's JSON-ish
extensibility in token/ticket/whatever
metadata
- let's make sure various Kerberos V5
mistakes get fixed / not remade
</code></pre>
> Revocation by CAs is easy and can be immediately effective.<p>This is also true with DANE for the same reason: you're relying on a DNS RR being removed, both from its zone and from caches (so, low TTLs, though not excruciatingly low).<p>It's also true in Kerberos V5 because tickets are typically short-lived. PKIX could do this too (short-lived certificates).<p>> The client finds three of these CA records where the UUID matches a CA that the client trusts.<p>I'm really not fond of the idea that we should repeat the non-hierarchical mistakes of WebPKI. I'd rather we find a way to live with the DNSSEC PKI and increase trust in it by making it harder to subvert:<p><pre><code> 1) always use QName minification in
making DNS queries,
2) add CT to DNSSEC,
3) make client detect and inform users
about unexpected changes in zone
pubkeys
</code></pre>
(1) means that an MITMing root zone or TLD zone doesn't get to know [from the query] the full name you're trying to resolve, which means they need to commit to MITMing before knowing how interested they might be in MITMing, and then this forces them to stay in the middle.<p>(2) is obvious: try to catch the root and TLDs MITMing.<p>(3) is also about clients noticing possible MITMing.
Go Blue<p>LDAP + Kerberos == Microsoft Active Directory<p>This was standard at U of M before the latter was invented. I'm guessing someone from AA invented it?
This is a nice reminder that symmetric cryptography is PQ-safe, but barebones kerberos does not solve the initial authentication problem - the exact purpose of a TLS handshake.<p>Kerberos relies on the client and kerberos authority (KDC) having a pre-shared password; the KDC uses it to send encrypted messages to the client, and also for giving the client a message encrypted for a service the client wishes to talk to (these are kerberos tickets). In that sense, Kerberos does look a lot like a trusted third party facilitating a TLS handshake with all-symmetric cryptography! A very neat analogy.<p>It would be ludicrous to require all clients to have a pre-shared secret password with the CA, and to require the CA be an available participant in every handshake in an uncacheable way. Still, it's fun to imagine this.<p>Anyway, some notes for completeness: there does exist a PKINIT extension for Kerberos, where an x.509 certificate from a trusted authority authenticates the kerberos authority (KDC) for the clients, and authenticates the clients without a password. This relies on a signature system, so that's out of scope if we're talking about ditching TLS in a PQ setting. I suppose one could imagine distributing kerberos keytabs instead of certificates.