[saag] Re: SKEX bof comment

Michael Richardson <[email protected]> Mon, 17 Mar 2025 13:18:43 +0700
Newsgroups	gmane.ietf.saag
Message-ID	<742172.1742192323@dyas>
{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.
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.

(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)

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

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.

    > A while later I thought: "is this a QKD thing and trying to not quite
    > be seen as that?" (The first mention of QKD is in section 9.)

My understanding is that it doesn't have to use entangled qubits, but it could.

Daniel Shiu <[email protected]> wrote:
    > supposed to enrol with separate mediation services). This might fit
    > well with TLS, say, but for IPsec, MACsec, or peer to peer applications
    > the model is not so good. Splitting between two mediation services

I know that for IKE, and TLS we *can* (or used to be able) use GSSAPI for
authentication (which is usually, but not necessarily Kerberos underneath).
Maybe that's now through some EAP mechanism now, I'd have to go look.

I'm unclear if we can generate all the keys that way, or just authenticate.
Usually, we've *WANTED* some amount of PFS via doing DH in IKEv2/TLS, so we
didn't generate session keys that.  But, if all the DH-based PFS methods are
suspect, then we'd want to get the session keys that way too.

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.

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.

--
Michael Richardson <[email protected]>, Sandelman Software Works
 -= IPv6 IoT consulting =-                      *I*LIKE*TRAINS*

_______________________________________________
saag mailing list -- [email protected]
To unsubscribe send an email to [email protected]
signature.asc (application/pgp-signature, 658 B)