
Designing an Authentication System: A Dialogue in Four Scenes (1988) - itsspring
https://web.mit.edu/kerberos/dialogue.html
======
andyjpb
Kerberos is an underrated and underused authorization protocol.

(Last time I used it) V5 was reasonably safe to use on the open Internet. It
integrates well with MacOS, Linux, BSD and other Unix auth systems and also
with SSH.

I never really understood why we don't see more of it in "Cloud" models,
especially given how decoupled a Kerberos Principal is from the underlying
Unix UID.

Rather than using SSH keys everywhere and thus having to manage
.authorized_keys files all over an estate, the users can `kinit` in a terminal
(even on a stock MacOS) and they're away. The credentials are managed
centrally. It has service/user and delegation properties similar to oAuth and
friends.

I've not looked at it with a modern and critical cryptographic eye but, for
example, there is (configurable) support for not giving out the initial set of
tickets (which is encrypted with the user's password) until the client has
proven it knows the user's password.

Many browsers (especially on the MS platform, but definitely also Firefox on
all platforms as well) can be configured to use the tickets for HTTP
authentication (like BASIC or DIGEST, but using a different scheme) at
configured domains. Lots of web servers and web apps are easily configurable
to put the correct things in the correct environment variables or HTTP headers
so integration with random web services is straightforward.

Once you've got SSH and Browsing covered with a single credential, you're well
on your way to a really versatile SSO scheme.

~~~
cryptonector
Kerberos doesn't really scale to the Web at this time. It could, but it would
be much better if we could just improve the WebPKI and make a true
hierarchical PKI that mirrors the DNS. The latter can be done either by having
registries and registrars operate name-constrained (possibly by convention)
CAs, or by adopting DANE (DNSSEC Authenticated Network Entities).

~~~
tptacek
This is a proposal that we delegate not just domain names, and not just TLS
certificates, but _authentication for applications themselves_ to a tree-
structured PKIs whose trunks are controlled _de jure_ by world governments.

~~~
tialaramex
_de jure_ the sovereign entities that you're labelling "world governments"
already control everything, that's sort of the point of being a sovereign
entity.

Even to the extent that there are exceptions to the rules they make, they made
those exceptions too.

For example, the sovereign entities agreed centuries ago that none of them
owns the open oceans but vessels that sail on those oceans shall display the
flag of a sovereign entity and the entity thus flagged shall be responsible
for that vessel's conduct and operation. This flag state regime proves to be
problematic in certain ways in practice.

So what happened? Did some alternate power arise to challenge the sovereign
entities in this regard? Nope. The European countries, annoyed by "flags of
convenience" on the vessels they saw just arbitrarily instituted a new policy,
under the Paris Memorandum Of Understanding. No need to "challenge" any
existing rules, as sovereign entities they were entitled to just make up new
ones. Vessels entering a European port needed to obey the Paris MOU rules,
sometimes getting inspected and if necessary prevented from leaving until they
rectified any problems to the port's satisfaction. Was that legal? It was now
because sovereign entities had agreed that it was so. The new model was a big
success and similar Port State Inspection rules soon followed elsewhere.

~~~
cryptonector
u/tptacek has made this argument a lot before. It's a fallacious argument
because we can all see that when government X says JUMP, the companies they
order either JUMP or EXIT, and when those companies lack an EXIT option, they
always JUMP. The reason for this is that no cryptography can beat the rubber
hose, and no cryptographic protocol can either.

No PKI, whether loose like WebPKI, rooted like DNSSEC (or as PKI was intended
to be), or with multiple roots sharing subtrees (e.g., as DNSSEC would be if,
say, Russia decided to require Russians to use Russian roots that happen to
sign com and such as they are), can possibly get around the fact that the
certification authorities that make it up are subject to the jurisdiction of
some government. It's why we all don't want the CN NIC in our trust anchor
sets, for example, or only want it if name-constrained.

There is not getting around this. So u/tptacek doesn't trust the DNS root, but
so what, why should he trust any WebPKI CA at all, or all of them? Any one of
them can be compromised by the end of a gun, and then all who have it in the
trust anchors will be compromised too.

Sure, there's CT (certificate transparency), but there is nothing so PKIX-
specific to CT that it couldn't be applied to DNSSEC, and anyways, I'm
unconvinced that it's enough. There comes a point where certain governments
don't even care if they leave evidence of their nasty behavior for all to see
-- when push comes to shove, any government with jurisdiction over you can end
your happiness and even your life. Oh? The world can see? But what can the
world do for, e.g., HK? A big fat not much.

~~~
cryptonector
Also, DNSSEC does have one thing PKIX doesn't and can't have: QName
minimization. That's where instead of sending the full domainname for any
query to the root and all intermediate zones, you only ever ask each zone for
its domainname + the next label of the domainname you really want.

Imagine you're a subject of interest to the U.S. government, and they're
willing to risk public knowledge of their access to root keys, say, in order
to spy on you. And say you're vising some site like antifa.github.io. So you
ask . for io, and io for github.io, and github.io for antifa.github.io, and
only at the last hop can the LEO/TLA system spying on you decide that yes,
they want to MITM you there. So either they have to MITM you everywhere, or
they have to MITM you only at zones they can control, and this is a decision
they have to make online. That's a big deal. If they decide to MITM you when
you asked for io, but you expected this so you had io's public keys, and .
tells you different keys, then you've detected the espionage attempt. WebPKI
can't do this. By the time some server (or MITM) sees your SNI they've also
seen your DNS queries. Even if you're using DoH/DoE (which also gets you
similar protection in a DNSSEC world), if the SNI is not encrypted, still,
they know what to do. And so on. Let's say you're using DoH/DoE with a
resolver the LEO/TLA can't control, then they could simply kick your door in
and take your stuff and beat you up. Crypto can make things harder for them,
but not infinitely harder. The CCP won't give a damn about leaving evidence in
CT logs, for example -- maybe today they do, but when push comes to shove,
forget about it.

------
cryptonector
Using Kerberos as originally intended, meaning that you exchange AP messages
(or GSS-API security context tokens) to authenticate and set up session keys,
which you then use for session protection using KRB messages (or GSS-API per-
message tokens), then it turns out the vast majority of applications don't
even need replay caches. The reason is simple: most application _protocols_
follow up the exchange with data that is not sensitive to replays.

Relatively few application protocols actually use Kerberos as originally
intended though. Many SASL apps run over TLS and don't use Kerberos for
session protection, for example, in which case you have to make sure that the
server certificate PKI is as good as Kerberos (this is not a big deal in
corporate networks). And HTTP/Negotiate uses Kerberos as a bearer token. There
are some extensions to do channel binding of Negotiate tokens to TLS, but
those are not universally easy to use because of complications to do with
reverse proxies and less-than-universal client support.

Anyways the "dialogue" exposition is pretty neat and stands the test of time.

------
danappelxx
Interesting, this dialogue is from 1988, and since then we’re really re-
invented the wheel with JWT, which by my understanding still allows for some
forms of MITM and replay attacks, relying heavily on token expiration. Though
I suppose the landscape has changed since most connections are now assumed
encrypted.

~~~
ahelwer
It definitely allows replay attacks. If you manage to get someone's JWT you
can impersonate them for a couple of hours before it expires, unless the
website has additional identity verification measures like known IP addresses
and such. As you say, connections are now all encrypted so the old prank
methods of stealing peoples' tokens off university wifi networks won't work
anymore. I've definitely seen JWTs show up in logs, though.

~~~
user5994461
"known IP addresses and such" does not work for websites authentication and
such. Mobile clients are changing IP all the time as they move between WIFIs
and mobile networks.

That's one of the many limitations of kerberos. It's really not intended to
work outside of a company intranet.

~~~
cryptonector
Uh, u/ahelwer was talking about JWT, not Kerberos.

Kerberos doesn't scale to the Internet as it stands, but used properly it's
secure. The problem that u/ahelwer says JWT... Kerberos also has when used in
HTTP -- as opposed to other uses of Kerberos that don't have this problem.
That problem is that they are used as "bearer tokens" without any "channel
binding", so if you use them over HTTP without TLS, you lose to any
eavesdroppers, and if you use them over HTTPS using the WebPKI and some CA is
being (ab)used to MITM you, then you lose. This isn't specific to JWT (or
Kerberos) but generic to all small-b bearer token schemes.

~~~
user5994461
I thought this was talking about JWT not restricting by IP specifically
because Kerberos does.

Kerberos has very stringent requirements to onboard and preregister user
devices, that works in limited contexts like desktop or server authentication
in an intranet. JWT is intended to cover other use cases like web
authentication. Their (non) limitations are simply reflections of their use
cases.

------
dang
Posted quite a few times but a small thread from 2018 has the only previous
comments:
[https://news.ycombinator.com/item?id=17829319](https://news.ycombinator.com/item?id=17829319)

