[saag] Re: [skex] 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://
> 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]

-----BEGIN PGP SIGNATURE-----

wnsEABYIACMWIQQwbnhHy1kPJkWsM6fk2On5l6gz3QUCZ9fMHQUDAAAAAAAKCRDk2On5l6gz3R0F
AQC8evJACcdMg2V1Mnowkc0vHMsAYX/kbQfuhUH6yMO4TgEArOe7wfOwTlaUYu41G4SFhxAv+TG8
/7od2sBi8h5XlQI=
=Anlb
-----END PGP SIGNATURE-----