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) [RFC6071] and Internet Key Exchange (IKE) [RFC5996] in endpoint-to-endpoint transport mode for even better performance in term of latency of DID resolution.¶
+(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.¶
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.
+However, privacy issues can arise when the client resolves the server's DID on a public DLT node. The DLT node can monitor all the servers a client connects to. This problem disappears when DLT nodes are deployed as an integral part of the IoT system itself.¶
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/rfc/rfc2119>.
-
[RFC5996]
+
[RFC4301]
-Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 5996, DOI 10.17487/RFC5996, , <https://www.rfc-editor.org/rfc/rfc5996>.
Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., Weiler, S., and T. Kivinen, "Using Raw Public Keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, , <https://www.rfc-editor.org/rfc/rfc7250>.
+
[RFC7296]
+
+Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. Kivinen, "Internet Key Exchange Protocol Version 2 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, , <https://www.rfc-editor.org/rfc/rfc7296>.
+
[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/rfc/rfc8174>.
diff --git a/draft-vesco-vcauthtls.txt b/draft-vesco-vcauthtls.txt
index 411a7fc..2a67f8f 100644
--- a/draft-vesco-vcauthtls.txt
+++ b/draft-vesco-vcauthtls.txt
@@ -5,7 +5,7 @@
WG A. Vesco
Internet-Draft L. Perugini
Intended status: Standards Track LINKS Foundation
-Expires: 19 August 2024 16 February 2024
+Expires: 19 January 2025 18 July 2024
Transport Layer Security (TLS) Authentication with Verifiable Credential
@@ -48,7 +48,7 @@ Status of This Memo
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
- This Internet-Draft will expire on 19 August 2024.
+ This Internet-Draft will expire on 19 January 2025.
Copyright Notice
@@ -86,10 +86,11 @@ Table of Contents
6.4. Mutual authentication with Client using X.509 Certificate
and Server using Verifiable Credential
7. Security Considerations
- 8. IANA Considerations
- 9. References
- 9.1. Normative References
- 9.2. Informative References
+ 8. Privacy Considerations
+ 9. IANA Considerations
+ 10. References
+ 10.1. Normative References
+ 10.2. Informative References
Acknowledgments
Authors' Addresses
@@ -266,9 +267,9 @@ Figure 1: Generation of the identity compliant with the SSI model and
extension is shown below.
enum {
- btcr(0),
- ethr(1),
- iota(2),
+ name0(0),
+ name1(1),
+ name2(2),
..
(65535)
} DIDMethod
@@ -607,27 +608,36 @@ Figure 1: Generation of the identity compliant with the SSI model and
(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)
- [RFC6071] and Internet Key Exchange (IKE) [RFC5996] in endpoint-to-
- endpoint transport mode for even better performance in term of
- latency of DID resolution.
+ [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.
-8. IANA Considerations
+8. 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. However, privacy issues can arise
+ when the client resolves the server's DID on a public DLT node. The
+ DLT node can monitor all the servers a client connects to. This
+ problem disappears when DLT nodes are deployed as an integral part of
+ the IoT system itself.
+
+9. IANA Considerations
To be addressed
-9. References
+10. References
-9.1. Normative References
+10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
.
- [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen,
- "Internet Key Exchange Protocol Version 2 (IKEv2)",
- RFC 5996, DOI 10.17487/RFC5996, September 2010,
- .
+ [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
+ Internet Protocol", RFC 4301, DOI 10.17487/RFC4301,
+ December 2005, .
[RFC6071] Frankel, S. and S. Krishnan, "IP Security (IPsec) and
Internet Key Exchange (IKE) Document Roadmap", RFC 6071,
@@ -640,6 +650,11 @@ Figure 1: Generation of the identity compliant with the SSI model and
Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250,
June 2014, .
+ [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T.
+ Kivinen, "Internet Key Exchange Protocol Version 2
+ (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October
+ 2014, .
+
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, .
@@ -648,7 +663,7 @@ Figure 1: Generation of the identity compliant with the SSI model and
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
.
-9.2. Informative References
+10.2. Informative References
[DID] W3C, "Decentralized Identifiers (DIDs) v1.0", July 2022,
.