Hi, Scott, Thanks for your comments on [draft-wang-ipsecme-kem-auth-ikev2].
You are right for that we did not provide good details on the processing steps that both sides do. Specifically, some details are missing in Fig. 1. I have did some preliminary check to see if one or two addtional steps are allowed in the IKE authentication frame due to use of KEM for authentication, via IKE_AUTH and/or The INTERMEDIATE exchanges. It seems ok. PS. Are you at the IETF venue? I would love to discuss these details with you but have yet failed to find you. Cheers, Guilin ________________________________ Wang Guilin Mobile: +65-86920345 Mail: wang.gui...@huawei.com From:Scott Fluhrer (sfluhrer) <sfluhrer=40cisco....@dmarc.ietf.org<mailto:sfluhrer=40cisco....@dmarc.ietf.org>> To:ipsec <ipsec@ietf.org<mailto:ipsec@ietf.org>> Date:2025-03-15 13:40:02 Subject:[IPsec] draft-wang-ipsecme-kem-auth-ikev2 I went through this draft, and I was struck how underspecified this is. In particular, they do not mention what processing that each side does. This would not appear to be a trivial point; it is hard to see how we are supposed to verify that the protocol achieves its security goals if we aren’t given the details of the protocol (and the operations that both sides do are ‘parts of the protocol’). Furthermore, I don’t see how a KEM-based authentication scheme can be as efficient (in number of exchanges) as a signature-based one. For signature authentication (for Alice to authenticate to Bob), Alice passes her public key (within her certificate) and a signature of something (which ties this to this specific exchange); Bob verifies the certificate and the signature. For KEM authentication, what would appear to be necessary is that Alice passes her public key (within her certificate), Bob generates a shared secret/ciphertext with Alice’s public key, and passes the ciphertext to Alice, who then decrypts it, and then send back a message to Bob that depends on the decryption. Now, it would appear to me that this additional message passing would require additional exchanges – not a deal breaker, but is certainly an additional cost (and exactly how you do it would need to be spelled out) Actually, this is a long standing nit I have with IETF documents that do crypto – they are very good at ‘bits-on-the-wire’ formats, but often less good on ‘what is the other side supposed to do with those bits’. In crypto, that latter part is usually critical.
_______________________________________________ IPsec mailing list -- ipsec@ietf.org To unsubscribe send an email to ipsec-le...@ietf.org
