idnits 2.17.1 draft-chen-trusted-resolution-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** The abstract seems to contain references ([2], [3], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Y. Chen 2 Internet Draft J. Wang 3 Intended status: Informational B. Zhang 4 Expires: May 15, 2022 Z. Fan 5 X. Ma 6 Z. Li 7 J. Xie 8 November 15, 2021 9 China Academy of Information and Communications Technology 11 Trusted Resolution System and Protocol Extension 12 draft-chen-trusted-resolution-02 14 Status of this Memo 16 This Internet-Draft is submitted in full conformance with the 17 provisions of BCP 78 and BCP 79. This memo provides information for 18 the Internet community. It does not specify an Internet standard of 19 any kind. Distribution of this memo is unlimited. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html 36 This Internet-Draft will expire on May 15, 2022. 38 Copyright Notice 40 Copyright (c) 2020 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (https://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with 48 respect to this document. 50 Abstract 52 The Handle System [1][2]is a name service system for handle 53 resolution and management over the public Internet. Handle System 54 protocol [3] is designed to be transmitted as a byte stream via a TCP 55 connection. This document describes a Trusted Resolution System and 56 the protocol extension based on Handle System protocol. Trusted 57 resolution aims to achieve credibility verification through data 58 signing. The Trusted Resolution System determines whether to perform 59 trusted resolution and verification on the response according to the 60 trusted flag requested by the client. 62 Table of Contents 64 1. Introduction...................................................2 65 2. Conventions used in this document..............................3 66 3. Connection Establishment.......................................3 67 4. Trusted Resolution Overview....................................3 68 4.1. Trusted Resolution Process................................3 69 4.2. Trusted Root..............................................4 70 4.3. Trusted Handle............................................4 71 4.3.1. Handle Signatures....................................4 72 4.3.2. Handle Certificates..................................5 73 4.4. Signature Algorithms......................................6 74 5. Trust resolution protocol......................................6 75 5.1. Trusted Query request.....................................7 76 5.2. Successful verification...................................7 77 5.3. Unsuccessful verification.................................7 78 6. Security Considerations........................................7 79 7. IANA Considerations............................................7 80 8. References.....................................................7 81 8.1. Normative References......................................7 82 9. Acknowledgments................................................7 84 1. Introduction 86 RFC 3650-RFC 3652[1],[2][3] provide an open protocol, a general- 87 purpose global name service, and a reference implementation of the 88 protocol. In this document, the Trusted Resolution System receives 89 requests from the client and requests to each handle resolution 90 service according to the redirection information to obtain the final 91 response data. The client could choose whether or not to request 92 trusted resolution result when resolving. If the trust-flag in the 93 request is set to 1, the server is expected to return responses 94 including signatures and verifications that would be verified. 96 2. Conventions used in this document 98 In this document, handle name and bytes stream are case sensitive, 99 unless otherwise stated. 101 3. Connection Establishment 103 In order to send a sequence of bytes stream information based on TCP, 104 a connection between the client and the Trusted Resolution System 105 must be established. The Trusted Resolution System then establishes 106 TCP connections to Handle System respectively. 108 4. Trusted Resolution Overview 110 4.1. Trusted Resolution Process 112 The Handle System is an extensible hierarchical service system, which 113 typically consists of the Global Handle Registry (GHR) and Local 114 Handle Services (LHS). 116 Trusted resolution is developed to realize credibility verification 117 through data signing and issuing certificates in the Handle System. 118 Signatures and certificates are generated for security purpose. The 119 Trusted Resolution System would verify the signature using the public 120 key available from the service information. By default, handle 121 resolution does not require any trusted resolution. 123 Figure 1 shows an example of the process of the trusted resolution. 125 Query: for any given handle, the Trusted Resolution System can 126 query the GHR for its naming authority. The system obtained 127 final handle information after recurse request to the LHS using 128 local service information returned by the GHR. 130 Build a verification chain: the Trusted Resolution System builds 131 up a chain based on the resolution results. 133 Verify: the verification is completed by verifying handle values, 134 the verification chain. In each step, the verification results 135 are printed in the log and are reported the client ultimately. 137 +---------------------------------------------------------------+ 138 | Trusted Resolution System +----------+| 139 | +-----------------+ request | || 140 | | +-------------+ +---------------->+ || 141 | | | query | |server location | GHR || 142 | | +-------------+ <-----------------+ || 143 | | +-------------+ | | || 144 | +------+ | |verification | | +----------+| 145 | |Client+---->+ | Chain | | | 146 | +------+ | +-------------+ | | 147 | | +-------------+ | recurse +----------+| 148 | | |verify | +---------------->+ || 149 | | +-------------+ <-----------------+ || 150 | +-----------------+ | LHS || 151 | | || 152 | +----------+| 153 +---------------------------------------------------------------+ 154 Figure 1 An Example of Trusted Resolution Process 156 4.2. Trusted Root 158 Trusted root of should be globally unique within the whole Handle 159 System. Certificate and public key of the trusted root are stored in 160 the configuration files of the Trusted Resolution System. Self-signed 161 certificate of the trust root is generated and verified when the 162 system starts up. 164 4.3. Trusted Handle 166 4.3.1. Handle Signatures 168 Each node in the handle system has a unique pair of public and 169 private key. To ensure that the handles at all levels could be 170 verified, it is necessary to use the private key of the upper node to 171 sign, that is, to generate the signature value. 173 According to reference Handle System implementation, signatures of 174 handle values are built up and stored in HS_SIGNAURE data type of 175 which data contains a typical JWT(Json Web Token) structure [4]. 177 There are two ways to generate a signature to ensure that no data is 178 tampered: 180 o Sign handle values partially 182 o Sign all handle value 184 Signatures of the handle values are generated in the following 185 process: 187 1. Get the signer information, private key, Handle, index, etc.; 188 2. Generate payload from data to be signed which includes handle name, 189 values, singer information, expiration, sign digest, "iss" that 190 represents signer while "sub" represents the handle been signed. 192 3. Generate the signature data. 194 4.3.2. Handle Certificates 196 The PKI (Public Key Infrastructure) system technically solves 197 security issues such as network identity authentication and data the 198 integrity. Public Key Infrastructure is a universal security 199 infrastructure that uses the principles and technologies of 200 asymmetric encryption algorithms to implement and provide security 201 services. 203 A digital certificate is a combination of a user's identity and the 204 public key held by it. Before the combination, a trusted authority- 205 Certificate Authority (CA) is used to verify the user's identity. The 206 certificate combined with the user's identity and the corresponding 207 public key is digitally signed to prove the validity of the 208 certificate. 210 The certificates of the top-level naming authority handles, which are 211 managed by GHR, are issued by the trust root. Each naming authority 212 is entitled to issue certificates of its sub-naming authorities. LHS 213 is entitled to manage handles under given sets of naming authorities, 214 and no certificates need to be issued to local handles. 216 According to reference Handle System implementation, public key and 217 certificates chain information of handle values are built up and 218 stored in HS_CERT data type of which data contains a typical JWT(Json 219 Web Token) structure [4]. 221 Information such as the issuer, the subject, expiration, and 222 authority are defined when issuing. The HS_CERT data type provides a 223 structure to store JWT in its handle data field. JWT is composed of 224 header, payload, and signature, each part of the which is encoded by 225 Base64URLSafe before processed. 227 Process of generating certificates of a sub-naming authority is as 228 follows: 230 1. Obtain the issuer information (signer information), namely private 231 key, handle, index of the handle value where the signer's public 232 key is stored. 234 2. Get certificate information prepared, including information of 235 issuer, expiration time, start time, permissions. 237 3. Generate the message payload, sign it with the private key of the 238 signer, and generate the certificate body. 240 4. Load the public key of the sub-naming authority and re-sign for 241 verification. 243 4.4. Signature Algorithms 245 Trusted Resolution System in the handle system would check that 246 whether the signature algorithm type matches the public key type. 247 Following kind of signature algorithm types are used in the system: 249 o RSA-sha256 algorithm is used to generate base64 string in the 250 certification data and signatures. 252 o SM2 is a new cryptographic algorithm published by the Chinese 253 State Cryptography Administration, and its encryption strength is 254 256 bits. 256 o SM3 is a cryptographic hash algorithm, the hash value length is 32 257 bytes. Sm3 algorithm is used when generate digest data of the 258 handle values for the SM2 signing. 260 5. Trust resolution protocol 262 The is a 32-bit bit-mask that defines various control 263 options for protocol operation according to [3]. In addition to the 264 predefined bits, bit30 and bit31 of are used for trusted 265 resolutions. 267 1 1 1 1 1 1 269 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 271 .---------------------------------------------------------------. 273 |AT |CT |ENC|REC|CA |CN |KC |PO |RD | Reserved | 275 |---------------------------------------------------------------| 277 | Reserved |DT TR | 279 '---------------------------------------------------------------' 281 DT - bit30 of , bit that indicates whether to do trusted 282 resolution. DT bit is the trust request flag that indicates whether 283 the client would verify message from the server. If the DT bit is set 284 (to 1), results from the server would be verified. Otherwise, no 285 verification would be performed. 287 TR - bit31 of , trusted resolution result bit. TR bit is the 288 trust result flag that indicates whether the message verification 289 succeed. If the TR bit is set (to 1), the response is trusted. 290 Otherwise, the response verification failed. 292 5.1. Trusted Query request 294 The Message Header of any trust query request must set its DT bit of 296 < OpFlag > (to 1). The default value of this bit is 0 which means 297 that the response would not be checked. 299 5.2. Successful verification 301 TR bit of < OpFlag > should be set (to 1) if the response is trusted. 302 Successful verification indicates that the signature of the handle 303 value and certificate matches keypair of the server, the signer of 304 the signature has sufficient permission to sign the handle, and that 305 the signature has not expired. 307 5.3. Unsuccessful verification 309 A zero value for TR bit of < OpFlag > indicates that the response 310 fails to pass the trusted resolution. Value set of the requested 311 handle would be returned in response to any handle resolution request 312 whether it is trusted or not. 314 6. Security Considerations 316 Data integrity under the protocol is achieved via the server's 317 digital signature. Care must be taken to protect the server's private 318 key from any impersonation attack. 320 7. IANA Considerations 322 8. References 324 8.1. Normative References 326 [1] Sun, S. and L. Lannom, "Handle System Overview", RFC 3650 327 November 2003. 329 [2] Sun, S., Reilly, S. and L. Lannom, "Handle System Namespace 330 and Service Definition", RFC 3651, November 2003. 332 [3] Sun, S. and L. Lannom, "Handle System Overview", RFC 3652 333 November 2003. 335 [4] Jones, et al.,"JSON Web Token (JWT)", RFC 7519, May 2015. 337 9. Acknowledgments 339 This document was prepared using 2-Word-v2.0.template.dot. The 340 Trusted Resolution System described in this document relies on works 341 and protocols put forward by RFC 3650, RFC 3651,RFC 3652[1][2][3]. 343 Authors' Addresses 345 Yuying Chen 346 CAICT 347 No.52 Huayuan North Road, Haidian District 348 Beijing, Beijing, 100191 349 China 351 Phone: +86 188 1008 2358 352 Email: chenyuying@caict.ac.cn 354 Jiahui Wang 355 CAICT 356 No.52 Huayuan North Road, Haidian District 357 Beijing, Beijing, 100191 358 China 360 Phone: +86 186 0156 0021 361 Email: wangjiahui@caict.ac.cn 363 Bo Zhang 364 CAICT 365 No.52 Huayuan North Road, Haidian District 366 Beijing, Beijing, 100191 367 China 368 Phone: +86 159 1112 3285 369 Email: zhangbo3@caict.ac.cn 371 Zhipeng Fan 372 CAICT 373 No.52 Huayuan North Road, Haidian District 374 Beijing, Beijing, 100191 375 China 377 Phone: +86 159 1112 3285 378 Email: fanzhipeng@caict.ac.cn 380 Xufeng Ma 381 CAICT 382 No.52 Huayuan North Road, Haidian District 383 Beijing, Beijing, 100191 384 China 386 Phone: +86 188 1143 3140 387 Email: maxufeng@caict.ac.cn 389 Zhiping Li 390 CAICT 391 No.52 Huayuan North Road, Haidian District 392 Beijing, Beijing, 100191 393 China 394 Phone: +86 185 1107 1386 395 Email: lizhiping@caict.ac.cn 397 Jiagui Xie 398 CAICT 399 No.52 Huayuan North Road, Haidian District 400 Beijing, Beijing, 100191 401 China 403 Phone: +86 150 0138 5070 404 Email: xiejiagui@caict.ac.cn