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
