idnits 2.17.1 draft-li-icnrg-hopauth-01.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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (November 16, 2019) is 1624 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-10) exists of draft-irtf-icnrg-disaster-07 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Information-Centric Networking Research Group R. Li 3 Internet-Draft H. Asaeda 4 Intended status: Informational NICT 5 Expires: May 19, 2020 November 16, 2019 7 Hop-by-Hop Authentication in Content-Centric Networking/Named Data 8 Networking 9 draft-li-icnrg-hopauth-01 11 Abstract 13 The unpredictability of consumers, routers, copyholders, and 14 publishers for the in-network data retrievals in Content-Centric 15 Networking (CCN) / Named Data Networking (NDN) poses a challenge to 16 design an authentication mechanism to inhibit the malicious consumers 17 to flood data requests and prevent the fake data from being provided. 18 Signature is adopted as the fundamental function in CCN / NDN, which 19 however can only provide publisher authentication with additional 20 certificate acquisition. This document describes the the Hop-by-Hop 21 Authentication mechanism (HopAuth) integrating certificate collection 22 and packet forwarding potentially with the assistance from 23 certificate authority to provide consumer authentication, copyholder 24 authentication and path authentication to enable the in-network data 25 retrieval to be trustworthy, besides the publisher authentication. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at https://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on May 19, 2020. 44 Copyright Notice 46 Copyright (c) 2019 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (https://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 3. System Descriptions . . . . . . . . . . . . . . . . . . . . . 5 64 4. HopAuth Designs . . . . . . . . . . . . . . . . . . . . . . . 7 65 4.1. Initial Trust Establishment . . . . . . . . . . . . . . . 7 66 4.2. Data-centric Certificate Management . . . . . . . . . . . 8 67 4.2.1. Certificate Exchange . . . . . . . . . . . . . . . . 8 68 4.2.2. Certificate Update and Revocation . . . . . . . . . . 9 69 4.3. Forwarding-Integrated Authenticable Data Retrieval . . . 10 70 4.4. Suspension-Chain Model (SCM) . . . . . . . . . . . . . . 11 71 5. Protocol Message Format . . . . . . . . . . . . . . . . . . . 12 72 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 73 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 74 7.1. Normative References . . . . . . . . . . . . . . . . . . 13 75 7.2. Informative References . . . . . . . . . . . . . . . . . 13 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 78 1. Introduction 80 Information-Centric Networks in general, and Content-Centric 81 Networking (CCN) [3] or Named Data Networking (NDN) [4] in 82 particular, are the emerging network architectures enabling in- 83 network caching and data retrievals through their names. In CCN/NDN, 84 data can be cached at the intermediate routers, close to consumers 85 for reducing delay and redundant bandwidth consumption or for the 86 robustness under dynamic network environment. It has been noticed 87 that CCN/NDN is a promising approach for the application scenarios in 88 disaster networking [5], video streaming [6], and Internet of Things 89 (IoT) [8]. 91 In CCN/NDN, the basic network operations and these use scenarios with 92 in-network data caching and retrievals lead the network to be 93 seriously vulnerable under a variety of attacks, such as the 94 impersonation attack, malicious-request attack [9], [10], [11], and 95 the data poisoning attack [12], [13], [14]. The unpredictability of 96 consumers, routers, copy holders, and publishers during data 97 retrievals in CCN/NDN poses the novel challenge to design data- 98 centric authentication to prevent these attacks. This novel 99 authentication should potentially enable the consumer authentication, 100 copyholder authentication to authenticate the identity of the entity 101 providing data, path authentication to authenticate the path from 102 which data are retrieved, in addition to the publisher 103 authentication. 105 On the other hand, signature is already adopted as the fundamental 106 function in CCN/NDN, which promises to achieve the integrity and 107 publisher authentication. It can partially prevent the above attacks 108 and but still is insufficient to protect the unpredictable data 109 retrievals in CCN/NDN. The unpredictability with which copy holders 110 provide data, routers cache data, and consumers request data leads to 111 great difficulty in inhibiting malicious-request attacks and data- 112 poisoning attacks. To prevent data poisoning, consumers and routers 113 need to verify data before caching them. If the data are found to be 114 fake, the copy holder providing the data and the path to retrieve the 115 data also need to be discovered in order to disable the further 116 spread of that fake data. To prevent malicious-request attacks, copy 117 holders need to verify the identities of the consumers. 119 There are many authentication mechanisms with key management schemes 120 in the Internet, such as Kerberos [15], MSEC [16], X.509 [17], PGP 121 [18], RPKI [19]. They are designed to achieve different purposes 122 with centralized or decentralized approach based on end-to-end 123 communication paradigm in the Internet. They can only provide the 124 authentications of consumers and publishers or the link between them. 125 In other words, they do not consider data-centric authentication, 126 that is aimed to protect data in the networks. 128 For data-centric authentication, the key is to protect or prevent 129 data-poisoning and malicious-request attacks. Regarding the data 130 poisoning attacks, if the fake or corrupted data are cached along the 131 path, consumers who use the path always retrieve the wrong data, 132 because the router does not detect the cached data validity (as it is 133 signed by attacker correctly). The fake or corrupted data are 134 further cached, which pollute the routers as virus spreads. These 135 routers will provide the fake or corrupted data to other potential 136 consumers. Therefore, to inhibit the data poisoning attacks, routers 137 need to verify the data before caching them and consumers need to 138 verify the copyholder and the path to retrieve data. 140 For malicious requests, even malicious Interests can be reduced by 141 restricting sending rate, part of malicious Interests still can reach 142 the copyholder. If copyholders verify the Interests before replying 143 the data, the effect to inhibit the Interest flooding attack can be 144 improved. Hence, the authentication from any consumer or router to 145 Interest, data, copyholder, and the data retrieval path plays crucial 146 role to inhibit the data poisoning and malicious-request attacks, 147 besides the identity authentication to the publisher. 149 Another concern is that most of the existing authentication 150 mechanisms rely on centralized servers to acquire keys or 151 certificates, thereby increasing authentication delays, which we 152 refer to herein as the delay-enlargement problem. Obviously, they 153 cannot satisfy the following performance requirements for the 154 emerging data-centric communication paradigm in CCN/NDN: any consumer 155 or router needs to authenticate Interest, data, copyholder (including 156 publisher), and the data retrieval path without additional messaging 157 delay. 159 In this document, we describe a secure mechanism named HopAuth, where 160 forwarding-integrated hop-by-hop certificate collection is performed 161 together with the adaptive replacement for parts of chain with highly 162 trustworthy certificates. This specification derives directly from 163 the design published in [20]. In HopAuth, a suspension-chain model 164 (SCM) is used as the trust model, where the neighbor-trust-based 165 certificate chain is suspended by certificate authority (CA)-based 166 trust. The HopAuth avoids reliance on centralized server(s) for 167 chain construction and solves the delay-enlargement problem. 169 2. Terminology 171 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 172 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 173 document are to be interpreted as described in RFC 2119 [1]. 175 The following terminology is used throughout this document. 177 o Cryptographic key: A string of bits used by a cryptographic 178 algorithm to transform plain-text into cipher-text or vice versa. 180 o Signature: A cryptographic value calculated through public key 181 algorithm from the data and a secret key only known by the signer. 182 It is to validate the authenticity and integrity of a message. 184 o Certificate: A data structure used to verifiably bind an identity 185 to a cryptographic key. 187 o Consumer: A node requesting data. It initiates communication by 188 sending an interest packets. 190 o Publisher: A node providing data. It originally creates or owns 191 the data. 193 o Router: A node forwarding data. It may hold memory to cache the 194 data. 196 o Forwarding Information Base (FIB): A lookup table in a router 197 containing the name prefix and corresponding destination interface 198 to forward the interest packets. 200 o Pending Interest Table (PIT): A lookup table populated by the 201 interest packets containing the name prefix of the requested data, 202 and the outgoing interface used to forward the received data 203 packets. 205 o Content Store (CS): A storage space for a router to cache data 206 objects. It is also known as in-network cache. 208 o Physical entity: an entity that communicates using a physical 209 device. This could be a router or a publisher node (PN) that 210 hosts applications. 212 o Logical entity: an entity that is involved in an application. 213 This can be an authorizer, a sub-authorizer, or a publisher. 215 3. System Descriptions 217 Here we briefly explain the background and basic network operations 218 of CCN/NDN. Different from the end-to-end communications in the 219 Internet, CCN/NDN provides data-name-based retrievals as in Fig. 1. 220 It further requires the data-centric authentication, instead of the 221 current end-to-end secure channel establishment. 223 1.Interest 2.Interest 3.Interest 4.Interest 224 +----+ +----+ +----+ +----+ 225 | | | | | | | | 226 | v | v | v | v 227 +--------+ +--------+ +--------+ +--------+ +---------+ 228 |Consumer|----| Router |----| Router |----| Router |----|Copy | 229 | | | A | | B | | C | |Holder | 230 +--------+ +--------+ +--------+ +--------+ +---------+ 231 ^ | ^ | ^ | ^ | 232 | | | | | | | | 233 +----+ +----+ +----+ +----+ 234 8.Data 7.Data 6.Data 5.Data 236 Figure 1: Request and reply messages forwarded by consumer, copy 237 holder and routers. 239 In a CCN/NDN network, each router in a CCN/NDN network has three main 240 data structures: a FIB for forwarding Interests, a CS for caching 241 data, and a PIT for forwarding data. Basically there are two types 242 of packets: interest and data. As in Fig. 1, consumer requests data 243 by throwing an "interest" packet with the name of data to the 244 network. Regarding the difference to note here between CCN [3] and 245 NDN [4] is that in later versions of CCN, interest packet must carry 246 a full data name, while in NDN it may carry a data name prefix. 248 Once a router receives an "interest" packet, it performs a series of 249 the following look-up. 251 The router first checks in the CS to see whether it holds the 252 corresponding data or not. If there is, it returns the data through 253 the reverse path for forwarding interest packet as the copy holder in 254 Fig. 1. If not, it performs a look-up of the PIT. If there is 255 already a PIT entry matching the name of requested data, it is 256 updated with the incoming interface of this new request and the 257 interest is discarded. If there is no matching entry, it creates an 258 entry in the PIT that lists the data name and the interfaces from 259 which it received the interest. Then, the interest undergoes a FIB 260 lookup to discover the outgoing interface. 262 Once a copy of the "data" packet is retrieved, the router sends it 263 back to the data requester(s) using the trail of PIT entries and 264 remove the PIT state every time that an interest is satisfied. 265 Additionally, it may store the data in its CS. 267 However, data retrieval with in-network caching in CCN/NDN has been 268 identified to suffer from malicious data-request attacks [9], [10], 269 [11], and the data poisoning attacks [12], [13], [14]. In the 270 former, adversaries impersonate consumers to create a flood of 271 interests, and in the latter, they impersonate copy holders (e.g., 272 routers or publishers) to provide fake data. These attacks are 273 severe, because data are cached in a distributed manner, and copy 274 holders have no way to verify consumers' identities, consumers/ 275 routers have no way to verify copy holders' identities to avoid 276 caching fake data, and the path to retrieve data cannot be verified. 277 This form of attack can quickly pollute the router caches as the 278 virus spreads, because routers cache the fake data, redistribute 279 them, and other intermediate routers re-cache them. It finally 280 consumes much in-network caches and prevents consumers from 281 retrieving the correct data. 283 4. HopAuth Designs 285 Herein we elaborate the basic design of HopAuth, which has three 286 phases: 1) initial trust-establishment, 2) data-centric certificate 287 management, and 3) forwarding-integrated authenticable data- 288 retrieval. The trust model for HopAuth is given by a suspension 289 chain model (SCM) later explained. 291 For the first phase, certificates are issued for neighboring entities 292 and the certificate authority (CA) potentially issues certificates to 293 a set of routers to form the highly trusted router group (HTRG). Let 294 CE(A->B) represent the public-key certificate issued from A to B. In 295 the second phase, routers exchange certificates within their 296 neighborhoods, and any compromised entity can be shut down quickly. 297 Finally, the third phase provides a hop-by-hop method for 298 constructing a chain consisting of a physical-entity certificate 299 chain (peCEChain) and a logical-entity certificate chain (leCEChain) 300 for data-centric authentication. 302 4.1. Initial Trust Establishment 304 The initial trust establishment has two components: self-certifiable 305 naming and certificate issuing. 307 Self-certifiable naming defines the rule for naming the principals, 308 including entities, keys, and certificates, to enable the entities to 309 be self-certifiable. As the extension of the cryptographically 310 generated address (CGA) [7], we merge the hash-based self-certifying 311 names with hierarchical naming. It embeds the public key into the 312 name, which is self-certifiable. The purpose of self-certifiable 313 naming is to prevent stealing and spoofing of existing names. The 314 public key of the name owner is bound cryptographically to the name. 315 The name owner can use the corresponding private key to assert its 316 ownership and to sign messages sent from the entity with that name. 317 In fact, an attacker can create a new name from an arbitrary public 318 key. However, the attacker cannot impersonate somebody else's name. 320 To issue a certificate, an entity should be convinced that a given 321 public key truly belongs to another entity. Under that situation, it 322 issues a certificate for this entity such that the public key is 323 bound to the entity name by its signature. In HopAuth, certificate 324 issuing is the initial trust establishment among entities having 325 trust relationships, namely as neighbor-based trust for physical 326 entities, CA-based trust, and authorization relationships for logical 327 entities. 329 For neighbor-based trust, a physical entity creates a public key and 330 the corresponding private key locally by itself. It generates the 331 names using the public key based on the self-certifiable naming 332 method. If physical entity B is a neighbor of entity A, B can 333 announce its public key to A with the key name and A generates the 334 certificate for B. 336 CA-based trust between two entities is established using the CA as 337 the "introducer". The CA is managed by the network operator, and 338 provides certificates to the owner's entities and the highly trusted 339 physical entities close to them in the HTRG. The entities in the 340 HTRG then confer CA-based trust relationships and issue certificates 341 to each other. 343 All the highly trustable entities register at CA. CA has the whole 344 view of these entities and determines the neighboring relations among 345 the entities in HTRG. After determination of the neighboring 346 relations, an entity, A, sends interest to CA to request the 347 certificates of its neighbors. CA replies with the related 348 certificates to A, such as CE(CA->B). After A receiving the 349 certificates, A verifies them, issues certificates from itself to 350 those neighbors, such as CE(A->B), and sends to CA. CA verifies this 351 certificate and forwards it to B when B requests. 353 In HopAuth, the physical entities pre-keep the certificates and 354 associate certificates with interfaces in FIB. The physical entity 355 knows the next hop of one interface, and it associates the 356 certificate from that entity to itself with the forwarding interface. 357 This mechanism enables the appending of the relevant certificate to 358 the packets as required when forwarding them. 360 For logical entities, the trust relationship is defined by the 361 application. Each logical entity also generates a public/private key 362 pair by itself. If logical entity A authorizes the right for entity 363 B to manage a sub-category or publish data, A should provide a 364 certificate for the true public key of B. 366 4.2. Data-centric Certificate Management 368 4.2.1. Certificate Exchange 370 Certificate exchange allows entities to share the certificates that 371 they issue and hold. Each physical entity has a local repository in 372 which to store certificates securely. In HopAuth, the physical 373 entities request and keep all the certificates issued for or by their 374 nearby highly trusted entities in the HTRG and by common neighboring 375 physical entities. To exchange the information of certificates they 376 hold, each entity hashes the names of certificates and exchange 377 hashes to see if there is one missed in the neighborhood. If there 378 is, the entity will send interest to its neighbor to retrieve that 379 certificate. Finally, the physical entities hold all the 380 certificates within a two-hop distance and the certificates with 381 nearby highly trusted entities in the HTRG. These certificates are 382 used to construct chains hop by hop, shorten certificate chains, and 383 check the certificates appended by an up-stream entity. This 384 certificate check is performed by the next hop of the entity to check 385 whether the certificate appended by this entity is the same as the 386 one stored by it. If the certificates are the same, the certificate 387 passes the check. Otherwise, this packet will be dropped because of 388 the fake certificate. 390 The certificates of the logical entities in an application should be 391 stored in the repository of the PN. When data are published, the 392 trust chain from the PN to the publisher can be automatically formed 393 and appended to the packet. Meanwhile, the neighbors of the PN also 394 keep all the certificates of the PN in order to check them during 395 transmissions. 397 4.2.2. Certificate Update and Revocation 399 To guarantee its validity, each certificate in the network is issued 400 with a certificate expiration time, after which the certificate is 401 invalid. 403 For certificate updates using neighbor-based trust, the subject 404 entity of the certificate should notify the issuer of its interest in 405 updating the certificate. On receiving this interest, the issuer 406 checks whether this entity has been compromised. It then checks 407 whether the mapping between the name and the public key satisfies the 408 naming rule. If all the checks are passed, the issuer considers 409 whether the public key of the subject entity is still trustworthy, 410 generates an updated certificate, and replies with this updated 411 certificate. If any check is failed, the issuer does not provide a 412 certificate update to that entity. For certificate updates using CA- 413 based trust in the HTRG, the subject entity of the certificate 414 requests the CA to issue an updated certificate and provide it to the 415 related nearby highly trusted routers, who can further issue update 416 certificates. 418 If one entity no longer wishes to trust another entity, the former 419 may revoke the certificate that it originally issued. Because 420 certificates are issued over a one-hop distance, it is easy to detect 421 the misbehavior of an entity. To revoke a certificate quickly, the 422 revocation is announced over a two-hop distance. The revocation 423 initiator broadcasts the revocation information to all the entities 424 within a two-hop distance. Each entity receiving this information 425 adds the compromised entity or certificate to its blacklist. All the 426 packets from the compromised entities are dropped for a rapid local 427 shutdown. 429 4.3. Forwarding-Integrated Authenticable Data Retrieval 431 Here, when forwarding interests and data, we define a forwarding- 432 integrated hop-by-hop approach to construct the suspended chain from 433 unpredictable copy holders to a consumer for authenticating interest, 434 and from a consumer or router to data for authenticating copy holders 435 or publishers or path to retrieve data. We let highly trusted 436 routers replace the parts of chain with highly trusted certificates 437 induced by CA's suspended trust to enhance trustworthiness. 439 The steps for data retrieval are as follows. 441 Step 1: The consumer issues an interest appended with its signature. 442 It knows its next hop is the router to which it is connected. It 443 then appends to this interest the certificate from the next-hop 444 router to itself. Finally, it sends out the interest. 446 Step 2: When the interest is received by an router, it checks whether 447 the previous certificates are correct. If the check succeeds and it 448 belongs to the HTRG, this router attempts to find the previous highly 449 trusted router to replace the related part of the certificate chain 450 with one highly trusted certificate in the suspended chain. If this 451 IPE does not belong to the HTRG, it directly finds the interface to 452 the next hop and appends to the interest the relevant certificate 453 from the next-hop router to itself. 455 Step 3: This is executed if an router holds the requested data in its 456 cache. The router checks the suspended chain from it to the consumer 457 through the process described later in the SCM. If the verification 458 succeeds, this router replies with the data packet. In the data 459 packet, the suspended chain from this router to the publisher and the 460 certificate from the next router to this router are appended. This 461 router sends this data packet to the interface in reply as specified 462 in the PIT. 464 Step 4: If the PN receives the interest, it verifies the suspended 465 chain from itself to the consumer. If the verification succeeds, the 466 PN discovers the suspended chain from itself to the publisher in its 467 storage, and appends this certificate chain with the certificate from 468 the first router to itself. Next, the PN replies with these data 469 using the reverse path of the interest. 471 Step 5: After the router receives the data packet, it performs 472 forwarding and possibly caching. When the router intends to cache 473 the data, it first caches them in a temporary cache, which is 474 separated from the data cache. Second, it checks the suspended chain 475 from itself to the publisher. Only if the verification passes, these 476 data can be cached in the data memory and the suspended chain from 477 this router to the publisher will be cached along with the data. The 478 verification is performed offline, which does not affect the speed of 479 data retrieval. At the same time, this router checks the previous 480 certificate. If the check is successful and it belongs to the HTRG, 481 it will discover the previous entity in the suspended chain belonging 482 to the HTRG. If there is a previous entity, the router replaces part 483 of the related certificate path with a highly trusted certificate. 484 Otherwise, the router directly finds the interface to the 485 corresponding certificate from the next hop to itself and appends 486 this certificate to the packet, then forwards this packet to the 487 interface. 489 Step 6: After the consumer receives the data packet, there should be 490 a certificate chain from it to the publisher. It verifies this 491 suspended chain. If the verification passes, it believes that it 492 gets the authentic public key of the publisher, and utilizes the key 493 to verify the signature of the data. The consumer can also verify 494 the copy holder or the routers on the path. 496 4.4. Suspension-Chain Model (SCM) 498 A suspension-chain model (SCM) is the trust model in HopAuth. It is 499 a flexible series of neighbor-trust-based certificates suspended by 500 CA's trust, which form a suspension chain. In SCM, neighbor-based 501 trust forms the certificate chain to realize data-centric 502 authentication, whereas CA-based trust reduces the length of the 503 chain to solve the trust degradation problem for certificate chain. 504 For CA's trust, the CA assigns certificates to highly trusted routers 505 as the suspension points based on CA's trust, which is the pre-trust 506 between these routers and CA. 508 Public-key verification is the process for one entity to verify the 509 authenticity of the public key of another entity. Entity X 510 authenticates the public key of the entity Y by verifying the 511 suspension chain in the following steps. First, X verifies the first 512 certificate by its private key. If it is correct, each intermediate 513 public key is used to verify the next direct associated certificate. 514 This process continues for multiple rounds until the final 515 certificate is verified. Finally, X obtains the true public key of 516 the entity Y. 518 5. Protocol Message Format 520 HopAuth messages are encoded in the CCNx TLV format [2]. An example 521 of HopAuth packet format with a certificate chain from consumer C0 to 522 router R_n, (CE1(C0->R1), ..., CE_n(R_(n-1)->R_n)), is provided in 523 Figure 2. As in Figure 2, the HopAuth message consists HopAuth 524 header, and HopAuth certificate TLVs. 526 1 2 3 527 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 528 +---------------+---------------+---------------+---------------+ 529 | Version | PT_CONTENT | PacketLength | 530 +---------------+---------------+---------------+---------------+ 531 | Reserved | Flags | HeaderLength | 532 +===============+===============+===============+===============+ 533 | T_HOPAUTH | Length(=n) | 534 +---------------+---------------+---------------+---------------+ 535 | Total length of inserted T_HOPAUTH_CERT TLVs | 536 +===============+===============+===============+===============+ 537 | T_Object | Object Message Length | 538 +---------------+---------------+---------------+---------------+ 539 / Object Message / 540 +---------------+---------------+---------------+---------------+ 541 | T_VALIDATION_ALG | Validation Algorithm Length | 542 +---------------+---------------+---------------+---------------+ 543 / Validation Algorithm Data / 544 +---------------+---------------+---------------+---------------+ 545 | T_VALIDATION_PAYLOAD | Signature Length | 546 +---------------+---------------+---------------+---------------+ 547 / Signature Data / 548 +---------------+---------------+---------------+---------------+ 549 | T_HOPAUTH_CERT | CE1 Length | 550 +---------------+---------------+---------------+---------------+ 551 / CE1(C0->R1) / 552 +---------------+---------------+---------------+---------------+ 553 / . / 554 / . / 555 +---------------+---------------+---------------+---------------+ 556 | T_HOPAUTH_CERT | CE_n Length | 557 +---------------+---------------+---------------+---------------+ 558 / CE_n(R_(n-1)->R_n) / 559 +===============+===============+===============+===============+ 561 Figure 2: An Example of HopAuth packet format 563 The HopAuth header is composed of the fields of type, Length, and 564 Total length of inserted T_HOPAUTH_CERT's TLVs. The type is 565 T_HOPAUTH, the Length shows the number of inserted certificates, and 566 Total length of inserted T_HOPAUTH_CERT's TLVs describes the total 567 number of bits occupied by certificate TLVs. In the part of HopAuth 568 certificate TLVs, the certificate name, length and certificate data 569 are included. Take CE1(C0->R1) in Figure 2 as example. The type is 570 T_HOPAUTH_CERT, CE1 Length is the length of certificate CE1(C0->R1), 571 and CE1(C0->R1) is the certificate data for CE1(C0->R1). 573 6. Security Considerations 575 This document is entirely about an authentication mechanism in CCN/ 576 NDN. 578 7. References 580 7.1. Normative References 582 [1] Bradner, S., "Key words for use in RFCs to Indicate 583 Requirement Levels", BCP 14, RFC 2119, 584 DOI 10.17487/RFC2119, March 1997, 585 . 587 [2] Mosko, M., Solis, I., and C. Wood, "CCNx Messages in TLV 588 Format", RFC 8609, July 2019. 590 7.2. Informative References 592 [3] Jacobson, V., Smetters, D., Thornton, J., Plass, M., 593 Briggs, N., and R. Braynard, "Networking Named Content", 594 Proc. CoNEXT, ACM, December 2009. 596 [4] Zhang, L., Afanasyev, A., Burke, J., Jacobson, V., Claffy, 597 K., Crowley, P., Papadopoulos, C., Wang, L., and B. Zhang, 598 "Named data networking", ACM Comput. Commun. Rev., vol. 599 44, no. 3, July 2014. 601 [5] Seedorf, J., Arumaithurai, M., Tgami, A., Ramakrishnan, 602 K., and N. Melazzi, "Research Directions for Using ICN in 603 Disaster Scenarios", draft-irtf-icnrg-disaster-07 (work in 604 progress), June 2019. 606 [6] Westphal, C., Lederer, S., Posch, D., Timmerer, C., Azgin, 607 A., Liu, W., Mueller, C., Detti, A., Corujo, D., Wang, J., 608 Montpetit, M., and N. Murray, "Adaptive Video Streaming 609 over Information-Centric Networking (ICN)", RFC 7933, 610 August 2016. 612 [7] Aura, T., "Cryptographically Generated Addresses (CGA)", 613 RFC 3972, March 2005. 615 [8] Ravindran, R., Zhang, Y., Grieco, L., Lindgren, A., Burke, 616 J., Ahlgren, B., and A. Azgin, "Design Considerations for 617 Applying ICN to IoT", draft-irtf-icnrg-icniot-03 (work in 618 progress), May 2019. 620 [9] Afanasyev, A., Mahadevan, P., Moiseenko, I., Uzun, E., and 621 L. Zhang, "Interest flooding attack and countermeasures in 622 named data networking", Proc. IFIP Networking, IFIP, May 623 2013. 625 [10] Compagno, A., Conti, M., Gasti, P., and G. Tsudik, 626 "Poseidon: mitigating interest flooding ddos attacks in 627 named data networking", Proc. LCN 2013, IEEE, October 628 2013. 630 [11] Nguyen, T., Cogranne, R., and G. Doyen, "An optimal 631 statistical test for robust detection against interest 632 flooding attacks in ccn", Proc. International Symposium on 633 Integrated Network Management (INM), IFIP/IEEE, May 2015. 635 [12] Ghali, C., Tsudik, G., and E. Uzun, "Network-layer trust 636 in named-data networking", ACM SIGCOMM Computer 637 Communication Review, vol.44, no. 5, October 2014. 639 [13] Kim, D., Nam, S., Bi, J., and I. Yeom, "Efficient content 640 verification in named data networking", Proc. ACM 641 Conference on Information-Centric Networking, ACM, 642 September 2015. 644 [14] Gasti, P., Tsudik, G., Uzun, E., and L. Zhang, "Dos and 645 ddos in named data networking", Proc. IEEE ICCCN 646 2013, IEEE, August 2013. 648 [15] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 649 Kerberos Network Authentication Service (V5)", RFC 4120, 650 July 2005. 652 [16] Baugher, M., Canetti, R., Dondeti, L., and F. Lindholm, 653 "Multicast Security (MSEC) Group Key Management 654 Architecture", RFC 4046, April 2005. 656 [17] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 657 Housley, R., and W. Polk, "Internet X.509 Public Key 658 Infrastructure Certificate and Certificate Revocation List 659 (CRL) Profile", RFC 5280, May 2008. 661 [18] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. 662 Thayer, "OpenPGP Message Format", RFC 4880, November 2007. 664 [19] Bush, R. and R. Austein, "The Resource Public Key 665 Infrastructure (RPKI) to Router Protocol Version 1", 666 RFC 8210, September 2017. 668 [20] Li, R., Asaeda, H., and J. Wu, "DCAuth: Data-Centric 669 Authentication for Secure In-Network Big-Data Retrieval", 670 IEEE Transactions on Network Science and Engineering, DOI: 671 10.1109/TNSE.2018.2872049, September 2018. 673 Authors' Addresses 675 Ruidong Li 676 National Institute of Information and Communications Technology 677 4-2-1 Nukui-Kitamachi 678 Koganei, Tokyo 184-8795 679 Japan 681 Email: lrd@nict.go.jp 683 Hitoshi Asaeda 684 National Institute of Information and Communications Technology 685 4-2-1 Nukui-Kitamachi 686 Koganei, Tokyo 184-8795 687 Japan 689 Email: asaeda@nict.go.jp