IKEv2 auth

draft-vesco-vcauthtls.md

@@ -414,7 +414,7 @@ All the security considerations presented in {{RFC8446}} applies to this documen
 Further considerations can be made on the DID resolution process. Assuming that a DID resolution is performed in clear, a man-in-the-middle could impersonate the DLT node, forge a DID Document containing the authenticating endpoint's DID, associate it with a key pair that he owns, and then return it to the DID resolver. Thus, the attacker is able to compute a valid CertificateVerify message by possessing the long term private key. In practice, the man-in-the-middle attacker breaks in transit the immutability feature provided by the DLT, i.e. the RoT for the public keys.
 A possible solution to this attack is to esthablish a TLS channel towards the DLT node and authenticate only the latter to rely on the received data. The DLT node MUST be authenticated through an X.509 certificate. The session resumption and 0 round-trip time (0-RTT) features of TLS 1.3 can be used to reduce the overhead of establishing this TLS channel.
 In addition, the communication with the DLT node can be protected with Internet Protocol Security
-(IPsec) {{RFC4301}} {{RFC6071}}  and Internet Key Exchange Version 2 (IKEv2) {{RFC7296}} in endpoint-to-endpoint transport mode for even better performance in term of latency of DID resolution.
+(IPsec) {{RFC4301}} {{RFC6071}} in endpoint-to-endpoint transport mode for even better performance in term of latency of DID resolution. Mutual authentication in Internet Key Exchange Version 2 (IKEv2) {{RFC7296}} can be performed with raw public keys.
 
 # Privacy Considerations
 Even though the ``did_methods`` extension in the ``ClientHello`` message is sent in clear no privacy issues arise as its content is not considered strictly confidential.