[HN Gopher] Let's Kerberos
___________________________________________________________________
Let's Kerberos
Author : tatersolid
Score : 54 points
Date : 2024-04-08 06:59 UTC (1 days ago)
(HTM) web link (www.imperialviolet.org)
(TXT) w3m dump (www.imperialviolet.org)
| cryptonector wrote:
| 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.
|
| 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.
|
| There's a lot to think about before jumping in, like:
| - 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
|
| > Revocation by CAs is easy and can be immediately effective.
|
| 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).
|
| It's also true in Kerberos V5 because tickets are typically
| short-lived. PKIX could do this too (short-lived certificates).
|
| > The client finds three of these CA records where the UUID
| matches a CA that the client trusts.
|
| 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: 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
|
| (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.
|
| (2) is obvious: try to catch the root and TLDs MITMing.
|
| (3) is also about clients noticing possible MITMing.
| jakupovic wrote:
| Go Blue
|
| LDAP + Kerberos == Microsoft Active Directory
|
| This was standard at U of M before the latter was invented. I'm
| guessing someone from AA invented it?
| tptacek wrote:
| Kerb was an Athena thing (an interesting project!) at MIT.
| cryptonector wrote:
| Yes, but Microsoft really did do the missing integration of
| Kerberos V5 into the rest of the system (LDAP and the login
| system). MSFT started this work ("NT5") in 1995, just a bare
| few years after MIT published the first implementation of
| Kerberos V5 (though Kerberos IV came half a decade earlier
| still). That took MSFT ~5 years to complete, and they shipped
| this as Windows 2000.
|
| Sun Microsystems, Inc. (RIP), completely failed to respond
| appropriately to that, and Active Directory ate Sun DS's
| lunch eventually.
| lasermike026 wrote:
| Now there's a name I haven't heard in a long time... long time.
| gumby wrote:
| For Kerberos, I was a minor foot soldier in the Crypto Wars.
|
| 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 _in the USA_ due to
| ITAR restrictions).
|
| Since IIRC Kerberos could be downloaded from MIT it's not clear
| how well these restrictions worked.
|
| 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.
|
| 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).
|
| 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.
|
| 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_ 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".
|
| 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.
| cryptonector wrote:
| The Swedes also started their own from-scratch implementation,
| known as Heimdal (https://github.com/heimdal/heimdal), which
| has a bunch of nifty things in it including a from-scratch
| PKIX/x.509 implementation and a from-scratch ASN.1 compiler and
| library.
| schoen wrote:
| As far as I know, NSA still has an Information Assurance
| Directorate, they just seem to focus on government, military,
| and government and military contractors' information security,
| rather than the general public's.
|
| A big contribution of the cypherpunks and hacker community has
| been cultivating the intuition that everybody deserves
| information security (even if information security efforts for
| the general public aren't always very well-funded). (And thank
| you for contributing to that!)
| e12e wrote:
| Which implementation was this? Does the code linger somewhere?
| schoen wrote:
| Probably this one?
|
| https://kerberos.org/dist/historic.html#CNS
| shermantanktop wrote:
| 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.
|
| 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.
|
| 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.
|
| Kerberos was not built for the internet, or poorly-administered
| PCs, or closed-source commercial software services (which
| required painful kerberization).
| cryptonector wrote:
| > 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.
|
| Kerberos can be used to get time from the KDCs though! Sure,
| MIT's grad students didn't build a program for doing that, but
| they could (and should) have. Say you send an AS-REQ or TGS-REQ
| w/ incorrect time to the AS/TGS, so you get back a KRB-ERROR
| telling you that your time is wrong, but also telling you the
| KDC's time. Well, ok, the KDC's time would not be
| authenticated, but you'd first get an initial ticket (AS) then
| you'd do this again using a TGS exchange, and if it works then
| you know you got a KDC time reading that's good enough. (You'd
| want to do this mainly with randomly-generated service keys,
| not with user passwords.) Now with the FAST extensions you get
| authenticated time.
|
| Microsoft had a wonky, crappy NTP-secured-with-Kerberos, too.
___________________________________________________________________
(page generated 2024-04-09 23:01 UTC)