[saag] Re: SKEX bof comment

On Sun, Mar 16, 2025 at 11:19 PM Michael Richardson <[email protected]>
wrote:

>
> {not a BOF proponent. Speaking out of my ass based upon the IETF119 side
> meeting contents}
>
> Stephen Farrell <[email protected]> wrote:
>     > My first thought based on the intro/problem statement was: "why isn't
>     > kerberos enough?" and if it's not, "why not extend it to make it good
>     > enough?" (Or at least, say why that doesn't work.)
>
> Kerberos is enough within an enterprise, but it does not presently work
> well
> between enterprises.  This is mostly because they don't bother, but also
> looking forward, because inter-enterprise use involves "pkinit", that is,
> using RSA or ECDSA to initialize a ticket generating ticket between
> enterprises.
>

The reason that this is needed is because each enterprise wants to run
its own KDC. If there was just one global KDC then you wouldn't need
this. That's effectively the topology that SKEX assumes. It's true that
they contemplate multiple KDCs, but those KDCs don't federate like
with Kerberos, they're just run in parallel.



> We could (and should) make this quantum-safe, but if one is
> pessimistic about long-term safety of the quantum-safe algoritms, then it
> becomes the weak point, while the rest of the enterprise is safe.
>

See above: you can  just run Kerberos in a pure symmetric mode.


(Kerberos within the enterprise is essentially bootstrapped on a new desktop
> by the admin sitting down and enrolling the desktop using an admin
> password.
> That's an important point to consider.  It works well on the campus.  But,
> it's why new laptops for new employees visit IT first...)
>
> SKEX won't be cheap in my opinion.  Possibly including bonded couriers.
> The model you might think about is Johnny Nmemonic :-)
> (Go watch the movie if you never have.  Especially when he "logs in" to the
> Internet...  And remember that Gibson wrote that book on a typewriter)
>

It seems to me that from a practical perspective, Kerberos and SKEX are
isomorphic here. In both cases you need to share some symmetric keying
material. Kerberos is designed with a short key and then you use KDFs
to produce traffic keys, whereas KEX assumes you share a large key
and send out pieces of it, providing some element of FS, but I imagine
we could invent some kind of Kerberos ratcheting thing if we wanted to.





> A problem with Kerberos is that the KDC knows all the keys!
>

This is just as true for SKEX.


> The description of the possible SKEX protocols from the side meeting last
> year suggested that by using/mixing keys from multiple "KDC" that it
> reduces
> the value/impact of capturing the "KDC".  An attacker would have to capture
> multiple key distribution systems.


Right, but you could use Kerberos the same way.



>
>
> Salz, Rich <[email protected]> wrote:
>     > Overall, I'd like to see something that could be more naturally fit
> to
>     > peer-to-peer, is more efficient, and has improved security
>     > properties. This is not to mention the separate question of the best
>     > way to do unmediated key refreshment. None of this is meant to
> detract
>     > from Kerberos.
>
>     > It would be very helpful if you could explain what is missing from
>     > Kerberos.  For example, do you want to make sure that you get the
> same
>     > key for A/B communication no matter who asks first?
>
> I don't know if any present browsers can use GSSAPI/Kerberos to do HTTPS.
> I know that some libraries can do it.  And for non-browser HTTPAI, it's
> probably gonna work.
>

I don't believe they do.


Kerberos is not deployed to the home (maybe to some people on this list,
> yes); but neither do I think SKEX would be deployed to the home.   In a
> quantum-unsafe future (where lattice methods have fallen to some convential
> attack),  I imagine residential users being enrolled into their ISPs'
> Kerberos, and the ISPs using SKEX to establish inter-enterprise Kerberos.


It's hard to project ourselves forward into a world where there's no public
key cryptography for key establishment at all [0]. With that said, this is
not
really the topology I envision [1]: we already have a whole policy apparatus
for identifying endpoints, which is to say the WebPKI, so the natural thing
to do is to have the CAs become KDCs This is of course a logistical
nightmare,
but it matches the current trust relationships. I certainly don't want to
have
to trust my ISP to authenticate servers to me: one of the reasons to use
encryption is that you don't trust your network provider!

-Ekr

[0] We'll presumably still have hash signatures.
[1]
https://educatedguesswork.org/posts/pq-emergency/#what-if-the-pq-algorithms-aren't-secure%3F

_______________________________________________
saag mailing list -- [email protected]
To unsubscribe send an email to [email protected]