[saag] Re: [skex] Re: SKEX bof comment

Hi,

For Kerberos or any other Key Server systems, the clients can use several Key Servers to solve the one central point issue. The final key is constructed from the keys from multiple Key Servers, no one Key Servers knows the final key. How many Key Servers are used and what kind of Key Servers are used is the choice of the clients, there is no need for having a protocol among the Key Servers.

For DSKE, if one security hub can be compromised, the other hubs can be compromised too, because these security hubs are the same type devices and have the same vulnerability.

Regards & Thanks！
Wei PAN (潘伟)

From: Melchior Aelmans <[email protected]>
Sent: Monday, March 17, 2025 3:38 PM
To: Stephen Farrell <[email protected]>; Daniel Shiu <[email protected]>; [email protected]; [email protected]
Subject: [skex] Re: SKEX bof comment

Hi Stephen,

I guess the main point is that Kerberos relies on a (or multiple) KDC that not only mediates authentication but also knows and distributes key material. This centralization introduces a single point of compromise. If the KDC is breached, all session keys are potentially exposed. In DSKE (one of the proposed proposals for SKEX to work on) there is no single central point of compromise as the central nodes don’t have knowledge of the key material. in USKE there aren’t central nodes.

Best,
Melchior


From: Stephen Farrell <[email protected]<mailto:[email protected]>>
Date: Monday, 17 March 2025 at 08:22
To: Daniel Shiu <[email protected]<mailto:[email protected]>>, [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>>, [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>>
Subject: [skex] Re: SKEX bof comment

Hiya,

On 17/03/2025 02:40, Daniel Shiu wrote:
> 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.

I don't see that that's the case: IPsec, MACsec etc may or may
not need changes to support PSK use, but what's at issue here is
how to establish a PSK, which presumably would require another
protocol and more round-trips, which is a role that kerberos
could fill.

I'm not arguing that you should use kerberos as-is, I am saying
that you do need to explain (to this audience) exactly why that
does not work.

Cheers,
S.


> 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]<mailto:[email protected]>> Sent: Monday, March 17, 2025 00:58 To:
> [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]> <[email protected]<mailto:[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://datatracker.ietf.org/doc/draft-mwag-dske/<https://<https://datatracker.ietf.org/doc/draft-mwag-dske/%3chttps:/>
> 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]