[saag] Re: [skex] SKEX bof comment

Hi Stephen,

Many thanks for the interest in SKEX. With regard to your "Isn't Kerberos good enough?" question, let me first say that I think Kerberos is founded on some good principles and its success at the enterprise level speaks for itself. It is however very strongly predicated on the Client-Server model (to the extent that clients and services are 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 separates credential management into a bipartite graph, which may be helpful in some cases, but does add to the number of round trips that are required (Client to Authentication Server to Client to Ticket Granting Server to Client to Service Server to Client) as well as the number of encryptions/decryptions required per connection.

Kerberos has some good verifiable security properties (say under the Dolaev-Yao with natural assumptions on the security of the primitives), but was designed before some more modern security properties such as key injectivity, explicit confirmation, and key integrity were fully articulated.

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.

Best regards,

Daniel

________________________________
From: Stephen Farrell <[email protected]>
Sent: Monday, March 17, 2025 00:58
To: [email protected] <[email protected]>; [email protected] <[email protected]>
Subject: [skex] SKEX bof comment


Hiya,

I quickly scanned [1].

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

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 conclusion from scanning the draft was that yes, this was an
effort to try make QKD more scalable, for some reason without
being very clear that that was the main goal.

I'm not convinced that dkse works for that purpose, (but maybe
it does), but am convinced that not having a clear focus on the
actual main goal could well be fatal for an effort like this.

Cheers,
S.

[1] https://gbr01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-mwag-dske%2F&data=05%7C02%7Cdaniel.shiu%40arqit.uk%7C40a2be8e787f477f280508dd64ef0aa6%7Cc2495bab6f1b47aead1cab1f33272e94%7C0%7C0%7C638777700032138979%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C4000%7C%7C%7C&sdata=hCUPgfiW3lfALgxesp4%2F5CgWn1tbdfkVkZmkOE1snh8%3D&reserved=0<https://datatracker.ietf.org/doc/draft-mwag-dske/>

CAUTION: External Sender. This email originated from outside of Arqit. Do not click links or open attachments unless you recognize the sender and know the content is safe.

CONFIDENTIALITY NOTICE: This e-mail message and any attachments are only for the use of the intended recipient and may contain information that is privileged, confidential or exempt from disclosure under applicable law. If you are not the intended recipient, any disclosure, distribution or other use of this e-mail message or attachments is prohibited. If you have received this e-mail message in error, please delete and notify the sender immediately. Thank you.

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