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

Hi Wei PAN,

On Mon, Mar 17, 2025 at 11:54 AM Panwei (William) <[email protected]>
wrote:

> 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 my curiosity, is this standardized or described somewhere? I couldn't
really find much myself but I might be looking in the wrong place.


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

This concern applies to any system. However, deploying the central nodes,
whether for DSKE or any other protocol, across separate physical and
virtual environments (such as on-premises data centers, private clouds, and
public clouds) can significantly mitigate risks. Each environment may have
different security measures, access controls, and threat models, making it
much harder for a single vulnerability to compromise all security hubs
simultaneously. Diversifying deployment reduces the likelihood of a
systemic failure due to a shared vulnerability.

Best,
Melchior



>
>
> 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]>
> *Date: *Monday, 17 March 2025 at 08:22
> *To: *Daniel Shiu <[email protected]>, [email protected] <[email protected]>,
> [email protected] <[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]> 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://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]