idnits 2.17.1 draft-jholland-mboned-ambi-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 26, 2019) is 1821 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Unused Reference: 'DIGSIGN' is defined on line 890, but no explicit reference was found in the text == Outdated reference: A later version (-32) exists of draft-ietf-tsvwg-udp-options-07 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Mboned J. Holland 3 Internet-Draft K. Rose 4 Intended status: Experimental Akamai Technologies, Inc. 5 Expires: October 28, 2019 April 26, 2019 7 Asymmetric Manifest Based Integrity 8 draft-jholland-mboned-ambi-02 10 Abstract 12 This document defines Asymmetric Manifest-Based Integrity (AMBI). 13 AMBI allows each receiver of a stream of multicast packets to check 14 the integrity of the contents of each packet in the data stream. 15 AMBI operates by passing cryptographically verifiable manifests for 16 the data packets, over out-of-band communication channels. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at https://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on October 28, 2019. 35 Copyright Notice 37 Copyright (c) 2019 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (https://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 1.1. Comparison with TESLA . . . . . . . . . . . . . . . . . . 4 54 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 55 2. Protocol Specification . . . . . . . . . . . . . . . . . . . 4 56 2.1. Packet Identifiers . . . . . . . . . . . . . . . . . . . 4 57 2.1.1. Overview . . . . . . . . . . . . . . . . . . . . . . 4 58 2.1.2. RTP Sequence Number . . . . . . . . . . . . . . . . . 5 59 2.1.3. SRTP Sequence Number . . . . . . . . . . . . . . . . 5 60 2.1.4. UDP Option . . . . . . . . . . . . . . . . . . . . . 5 61 2.2. Anchor Message . . . . . . . . . . . . . . . . . . . . . 5 62 2.2.1. Overview . . . . . . . . . . . . . . . . . . . . . . 6 63 2.2.2. DNS-based Anchor URI Bootstrap . . . . . . . . . . . 6 64 2.2.3. Anchor Message YANG model . . . . . . . . . . . . . . 7 65 2.2.4. Example Anchor Message . . . . . . . . . . . . . . . 14 66 2.3. Manifests . . . . . . . . . . . . . . . . . . . . . . . . 15 67 2.3.1. Overview . . . . . . . . . . . . . . . . . . . . . . 15 68 2.3.2. Manifest Layout . . . . . . . . . . . . . . . . . . . 15 69 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 70 4. Security Considerations . . . . . . . . . . . . . . . . . . . 18 71 4.1. Packet Identifiers . . . . . . . . . . . . . . . . . . . 18 72 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 73 5.1. Normative References . . . . . . . . . . . . . . . . . . 19 74 5.2. Informative References . . . . . . . . . . . . . . . . . 19 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 77 1. Introduction 79 Multicast transport poses security problems that are not easily 80 addressed by the same security mechanisms used for unicast transport. 82 The "Introduction" sections of the documents describing TESLA 83 [RFC4082], and TESLA in SRTP [RFC4383], and TESLA with ALC and NORM 84 [RFC5776] present excellent overviews of the challenges unique to 85 multicast authentication, briefly summarized here: 87 o A MAC based on a symmetric shared secret cannot be used because 88 each packet has multiple receivers that do not trust each other. 90 o Asymmetric per-packet signatures can handle only very low bit- 91 rates because of the computational overhead. 93 o An asymmetric signature of a larger message comprising multiple 94 packets requires reliable receipt of all such packets, something 95 that cannot be guaranteed in a timely manner even for protocols 96 that do provide reliable delivery, and the retransmission of which 97 may anyway exceed the useful lifetime for data formats that can 98 otherwise tolerate some degree of loss. 100 Aymmetric Manifest-Based Integrity (AMBI) specifies a method for 101 receivers or middle boxes to cryptographically authenticate and 102 verify the integrity of a stream of packets, by communicating packet 103 "manifests" (described in Section 2.3) via an out-of-band 104 communication channel that provides authentication and verifiable 105 integrity. 107 Each manifest contains cryptographic hashes of packet payloads 108 corresponding to specific packets in the authenticated data stream. 110 Each manifest MUST be delivered in a manner that provides 111 cryptographic integrity of the manifest. For example, TLS or IPSec 112 may be used to deliver a stream of manifests with unicast from a 113 trusted sender to many receivers, or another mechanism that provides 114 authentication for a multicast stream, such as a protocol which signs 115 each packet, could be used to provide authentication for the 116 manifests. 118 Upon successful verification of the contents of a manifest and 119 receipt of any subset of the corresponding data packets, the receiver 120 has proof of the integrity of the contents of the data packets listed 121 in the manifest. 123 An "anchor message", described in Section 2.2, provides the link 124 between an authenticated data stream and the out-of-band channel of 125 manifests that authenticates it. This document defines a DNS-based 126 method for a sender to advertise a URI that can be used to retrieve 127 the anchor message over a secure transport. The anchor message MAY 128 also be provided by other out-of-band mechanisms that provide 129 integrity guarantees for the anchor message. Describing alternate 130 methods is out of scope for this document. 132 Authenticating the integrity of the data packets depends on: 134 o authentication of the anchor message that provides the linkage 135 between the manifest channel and the data stream; and 137 o the secrecy and cryptographic strength of private keys used for 138 signing manifests, or the authentication of the secure channels 139 used for transmitting manifests; and 141 o the difficulty of generating a collision for the packet hashes in 142 the manifest. 144 1.1. Comparison with TESLA 146 AMBI and TESLA [RFC4082] and [RFC5776] attempt to achieve a similar 147 goal of authenticating the integrity of streams of multicast packets. 148 AMBI imposes a higher overhead, as measured in the amount of extra 149 data required, than TESLA imposes. In exchange, AMBI provides non- 150 repudiation (which TESLA does not), and relaxes the requirement for 151 establishing an upper bound on clock synchronization between sender 152 and receiver. 154 This tradeoff enables new capabilities for AMBI, relative to TESLA. 155 In particular, when receiving multicast traffic from an untrusted 156 transit network, AMBI can be used by a middle box to authenticate 157 packets from a trusted source before forwarding traffic through the 158 network, and the receiver also can separately authenticate the 159 packets. (This use case is not possible with TESLA because the data 160 packets can't be authenticated until a key is disclosed, so either 161 the middlebox has to forward data packets without first 162 authenticating so that the receiver has them prior to key disclosure, 163 or the middlebox has to hold packets until the key is disclosed, at 164 which point the receiver can no longer establish their authenticity.) 166 1.2. Terminology 168 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 169 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 170 document are to be interpreted as described in [RFC2119]. 172 2. Protocol Specification 174 2.1. Packet Identifiers 176 2.1.1. Overview 178 Packet identifiers are a sequence number contained within the 179 authenticated payload of the packet. This sequence number is used 180 inside a manifest to associate each packet hash with a specific 181 packet. Each authenticated packet MUST contain a packet identifier. 182 See Section 4.1 for a discussion of the security implications. 184 This document defines a new UDP option in Section 2.1.4 for use as a 185 packet identifier. 187 Some multicast-capable transport protocols have a sequence number 188 embedded in data packets in the protocol. The sequence numbers in 189 these protocols MAY be used instead of the new UDP option, to avoid 190 introducing extra overhead in the authenticated data packets. 192 In Section 2.1.2, Section 2.1.3, and Section 2.1.4, this document 193 defines some sample ways to specify packet identifiers based on such 194 sequence numbers embedded in existing protocols. 196 Other appropriate sequence number systems may exist, such as the 197 anti-replay Sequence Number field in Section 3.1 of [RFC6584], when 198 NORM or FLUTE operates with an authentication profile that uses it 199 (however, since that example already provides authentication, it is 200 not added as an option in this document). The AMBI anchor message 201 format can be extended in future documents to support those or other 202 suitable schemes by adding values to the registry defined in 203 Section 3. 205 In some deployments, in contrast to using the new UDP option, the 206 approach of using an existing sequence number may carry a benefit 207 because it requires no change to the stream of packets being 208 authenticated, enabling interoperability with existing unmodified 209 sending and receiving applications. 211 2.1.2. RTP Sequence Number 213 Sequence number from Section 5.1 of [RFC3550]. 215 TBD: discussion of security consequences of using 16 bits-recommend a 216 bigger hash in manifests for this case? 218 2.1.3. SRTP Sequence Number 220 Packet Index from Section 3.3.1 of [RFC3711]. 222 2.1.4. UDP Option 224 Define a new UDP option [I-D.ietf-tsvwg-udp-options] (TBD2). 226 0 1 2 3 227 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 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 229 | UDP Kind=TBD2 | Length=6 | 32-bit sequence number | 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 | | 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 2.2. Anchor Message 235 2.2.1. Overview 237 An anchor message provides the information that makes it possible to 238 associate the manifests with the data packets they authenticate. ID 239 values that appear as text integers in the anchor message also appear 240 in the manifest binary data, with the anchor message providing 241 context on how to interpret the values. 243 An anchor message MAY be discovered and transmitted by any means 244 which provides adequate source authentication and data integrity to 245 meet the security needs of the receiver. 247 In order to support middle-box authentication, it is RECOMMENDED that 248 senders arrange to distribute anchor messages according to the method 249 outlined in Section 2.2.2. 251 2.2.2. DNS-based Anchor URI Bootstrap 253 This document defines a new DNS resource record (RR) to communicate a 254 URI for an AMBI anchor message to remote receivers of the sender's 255 traffic, so they can use it to authenticate traffic from the sender. 257 The sender is the owner of the RR, and configures the zone so that it 258 contains an RR that provides a URI that can provide secure delivery 259 of the an anchor message appropriate to authenticate all the sender's 260 multicast traffic. 262 This mechanism only works for source-specific multicast (SSM) 263 channels. The source address of the (S,G) is reversed and used as an 264 index into one of the reverse mapping trees (in-addr.arpa for IPv4, 265 as described in Section 3.5 of [RFC1035], or ip6.arpa for IPv6, as 266 described in Section 2.5 of [RFC3596]). 268 When a middle box or receiver processes a join for a new source, if 269 it is configured to perform authentication on SSM multicast channels 270 it can forward, the middle box can discover a URI to obtain the 271 anchor message by issuing a DNS request for the AMBI record of the 272 reverse IP of the source of the (S,G), then fetch the contents of the 273 resulting URI, validate it, and use it to authenticate traffic from 274 the source. 276 TBD: consider breaking up anchor message to avoid large, frequently 277 changing anchors for sources with many groups. 279 TBD: consider graceful rollover for anchors, instead of synchronized 280 update of anchor hash. 282 2.2.3. Anchor Message YANG model 284 The anchor message is composed of a YANG instance object that 285 validates against the YANG model below. 287 file "ietf-ambi-anchor.yang" 288 module ietf-ambi-anchor { 289 yang-version 1.1; 291 namespace "urn:ietf:params:xml:ns:yang:ietf-ambi-anchor"; 292 prefix "ambi"; 294 import ietf-yang-types { 295 prefix "yang"; 296 reference "RFC6991 Section 3"; 297 } 299 import ietf-inet-types { 300 prefix "inet"; 301 reference "RFC6991 Section 4"; 302 } 304 import ietf-routing-types { 305 prefix "rt-types"; 306 reference "RFC8294"; 307 } 309 organization "IETF"; 311 contact 312 "Author: Jake Holland 313 314 Author: Kyle Rose 315 316 "; 318 description 319 "This module contains the definition for the AMBI anchor 320 message data type. 322 Copyright (c) 2018 IETF Trust and the persons identified as 323 authors of the code. All rights reserved. 325 Redistribution and use in source and binary forms, with or 326 without modification, is permitted pursuant to, and subject 327 to the license terms contained in, the Simplified BSD License 328 set forth in Section 4.c of the IETF Trust's Legal Provisions 329 Relating to IETF Documents 330 (http://trustee.ietf.org/license-info). 332 This version of this YANG module is part of 333 draft-jholland-mboned-ambi, [TBD: change] 334 see the internet draft itself for full legal notices."; 336 revision 2018-06-27 { 337 description "Initial revision."; 338 reference 339 ""; 340 } 342 /* TBD: copied some from https://tools.ietf.org/html/rfc8177, 343 but the model doesn't seem to match what I want. is there another 344 I can import instead of making these here? Or a registry 345 to reference? */ 346 identity crypto-hash { 347 description 348 "Base identity of cryptographic hash options. "; 349 } 351 identity sha-256 { 352 base crypto-hash; 353 description 354 "The SHA-256 algorithm."; 355 } 357 identity blake2b { 358 base crypto-hash; 359 description 360 "The BLAKE2b algorithm."; 361 } 363 identity crypto-signature { 364 description 365 "Base identity of cryptographic asymmetric signature 366 options."; 367 } 369 identity ed25519 { 370 base crypto-signature; 371 description 372 "The Ed25519 algorithm."; 373 } 375 identity rsa { 376 base crypto-signature; 377 description 378 "The RSA algorithm."; 379 } 381 identity sequence-type { 382 description 383 "Base identity for sequence number type options."; 384 } 386 identity rtp { 387 base sequence-type; 388 description 389 "The sequence number from RTP."; 390 } 392 identity srtp { 393 base sequence-type; 394 description 395 "The sequence number from SRTP."; 396 } 398 identity udp { 399 base sequence-type; 400 description 401 "The sequence number from UDP."; 402 } 403 typedef key-identifier { 404 type uint16 { 405 range 1..65535; 406 } 407 description "Key identifier within a manifest"; 408 } 410 typedef bitrate { 411 type string { 412 pattern '[1-9][0-9]*[GMK]?bps'; 413 } 414 description "Bit-rate of a data stream"; 415 } 417 typedef packetrate { 418 type string { 419 pattern '[1-9][0-9]*[GMK]?pps'; 420 } 421 description "Packet rate of a data stream"; 422 } 424 typedef manifest-transport { 425 type union { 426 type leafref { 427 path "/anchor/data_stream/id"; 428 } 429 type inet:uri; 430 } 431 description "Transport method for a manifest stream"; 432 } 434 container anchor { 435 container self { 436 presence "An anchor message exists"; 437 description 438 "Self-referential properties about the anchor message"; 439 leaf uri { 440 type inet:uri; 441 mandatory true; 442 description 443 "The canonical URI for this anchor message."; 444 } 445 leaf version { 446 type uint16; 447 mandatory true; 448 description 449 "The version number for this anchor message."; 450 } 451 leaf hash_algorithm { 452 type identityref { 453 base crypto-hash; 454 } 455 mandatory true; 456 description 457 "The algorithm for the anchor message hash provided 458 in a manifest."; 459 } 460 leaf hash_bits { 461 type uint16; 462 mandatory true; 463 description 464 "The number of bits for the anchor's hash provided 465 in a manifest."; 466 } 467 leaf expires { 468 type yang:date-and-time; 469 mandatory true; 470 description 471 "The expiration time for this anchor message."; 472 } 473 } 474 description "Anchor message for AMBI"; 476 list public_key { 477 key id; 478 description "Public key for ALTI signatures."; 479 leaf id { 480 type key-identifier; 481 mandatory true; 482 description 483 "The key identifier referenced in a manifest."; 484 } 485 leaf algorithm { 486 type identityref { 487 base crypto-signature; 488 } 489 mandatory true; 490 description 491 "The signature algorithm for use with this key."; 492 } 493 leaf signature_bits { 494 type uint16; 495 mandatory true; 496 description 497 "The length of the signature provided in manifests 498 signed with this key."; 499 } 500 leaf value { 501 type string; 502 mandatory true; 503 description 504 "The base64-encoded value of the public key."; 505 } 506 } 508 list data_stream { 509 key id; 510 unique "source destination port"; 511 description "Stream of data packets to be authenticated"; 512 leaf id { 513 type uint16; 514 mandatory true; 515 description 516 "The datastream_id referenced by a 517 manifest_stream."; 518 } 519 leaf source { 520 type inet:ip-address; 521 mandatory true; 522 description 523 "The source IP address of the authenticated data 524 stream."; 525 } 526 leaf destination { 527 type rt-types:ip-multicast-group-address; 528 mandatory true; 529 description 530 "The destination group IP address of the 531 authenticated data stream."; 532 } 533 leaf port { 534 type uint16; 535 mandatory true; 536 description 537 "The destination UDP port of the authenticated data 538 stream."; 539 } 540 leaf max_bitrate { 541 type bitrate; 542 mandatory true; 543 description 544 "The maximum bitrate expected for this data 545 stream."; 546 } 547 leaf max_packetrate { 548 type packetrate; 549 mandatory true; 550 description 551 "The maximum packetrate expected for this data 552 stream."; 553 } 554 list authenticator { 555 key manifest_id; 556 description 557 "A manifest stream that authenticates this data"; 558 leaf manifest_id { 559 type leafref { 560 path "/anchor/manifest_stream/id"; 561 } 562 mandatory true; 563 description 564 "The ID of a manifest stream that provides 565 authentication for this data stream."; 566 } 567 } 568 } 569 list manifest_stream { 570 key id; 571 description "Stream of manifests"; 572 leaf id { 573 type uint16; 574 mandatory true; 575 description "The Manifest ID referenced in a manifest."; 576 } 577 leaf transport { 578 type manifest-transport; 579 mandatory true; 580 description 581 "The ID of the data stream that carries this 582 manifest stream or a uri that provides a websocket 583 with the stream of manifests."; 584 } 585 leaf hash_algorithm { 586 type identityref { 587 base crypto-hash; 588 } 589 mandatory true; 590 description 591 "The hash algorithm for the packet hashes within 592 manifests in this stream."; 593 } 594 leaf hash_bits { 595 type uint16; 596 mandatory true; 597 description 598 "The number of bits of hash provided for packet 599 hashes."; 600 } 601 leaf sequence_type { 602 type identityref { 603 base sequence-type; 604 } 605 mandatory true; 606 description 607 "The linkage to the data packet sequence numbers in 608 the manifest."; 609 } 610 } 611 } 612 } 613 615 Figure 1: Anchor Message YANG model 617 2.2.4. Example Anchor Message 619 { 620 "ietf-ambi-anchor:anchor": { 621 "self": { 622 "uri": "https://example.com/ambi/anchor/example_1.json", 623 "version": 1, 624 "hash_algorithm": "blake2b", 625 "hash_bits": 256, 626 "expires": "2018-03-05T23:59:59Z" 627 }, 628 "public_key": [ 629 { 630 "id": 1, 631 "algorithm": "ed25519", 632 "signature_bits": 256, 633 "value": "VGhpcyBpcyBub3QgYSBnb29kIGtleSB0byB1c2UuLi4NCg==" 634 } 635 ], 636 "data_stream": [ 637 { 638 "id": 10, 639 "source": "192.0.2.10", 640 "destination": "232.10.10.1", 641 "port": 18001, 642 "max_bitrate": "10Mbps", 643 "max_packetrate": "1Kpps", 644 "authenticator": [ 645 { 646 "manifest_id": 1 647 } 648 ] 649 }, 650 { 651 "id": 20, 652 "source": "192.0.2.10", 653 "destination": "232.10.10.1", 654 "port": 18002, 655 "max_bitrate": "400Kbps", 656 "max_packetrate": "40pps", 657 "authenticator": [ 658 { 659 "manifest_id": 2 660 } 661 ] 662 } 663 ], 664 "manifest_stream": [ 665 { 666 "id": 1, 667 "transport": 20, 668 "hash_algorithm": "blake2b", 669 "hash_bits": 80, 670 "sequence_type": "udp" 671 }, 672 { 673 "id": 2, 674 "transport": "https://example.com/ambi/manifest_stream/3", 675 "hash_algorithm": "blake2b", 676 "hash_bits": 80, 677 "sequence_type": "udp" 678 } 679 ] 680 } 681 } 683 Figure 2: Example Anchor Message 685 2.3. Manifests 687 2.3.1. Overview 689 A manifest cannot be interpreted except in context of a known anchor 690 message. 692 In order for a manifest to be considered as potentially 693 authenticating a set of packets, the Anchor Version MUST match the 694 value in a known unexpired anchor message, and the Anchor Hash MUST 695 match the hash of the contents of that anchor message, according to 696 the /anchor/self/hash_algorithm and /anchor/self/hash_bits fields, in 697 order for a manifest to be accepted for use as evidence of 698 authenticity and integrity. 700 A manifest also MUST NOT be accepted unless it has verified 701 authenticity and integrity, either because it contains a 702 cryptographic signature, or because it appeared in a secured unicast 703 stream, or because another verified manifest has provided the packet 704 hash for a packet containing this manifest. 706 2.3.2. Manifest Layout 707 0 1 2 3 708 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 709 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 710 | Ver=0 | Reserved=0 |P|S| Anchor Version | 711 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 712 | Anchor Hash (variable length, 4-octet aligned, 0-padded) | 713 | ... | 714 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 715 | Manifest ID | Packet Hash Count | 716 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 717 | First Packet Hash Identifier | 718 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 719 | Packet Identifier Step (if S-bit set) | 720 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 721 | | 722 | ... Packet Hashes ... | 723 | | 724 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 726 2.3.2.1. Ver (Protocol Version) 728 MUST be set to 0 by senders, and if a nonzero value is received this 729 message MUST NOT be accepted or processed as a manifest. 731 For manifests streams which were authenticated by a means other than 732 cryptographic signature, it is RECOMMENDED that authenticators stop 733 following this manifest stream and refresh the anchor if they receive 734 an invalid version. 736 For manifest streams authenticated by signature, it is RECOMMENDED 737 that authenticators remain joined to this stream and ignore this 738 packet, as the manifest MAY have been sent maliciously. 740 An authenticator MAY implement a rate limit on invalid manifests and 741 drop the stream if the rate is exceeded. 743 2.3.2.2. Reserved 745 MUST be set to 0 by senders and MUST be ignored by receivers. 747 2.3.2.3. P ("Purge" bit) 749 If this bit is 1, the anchor message this manifest specifies MUST be 750 purged by authenticators who accept this manifest, so that it cannot 751 be used to authenticate future manifests unless it was re-fetched. 753 2.3.2.4. S ("Step" bit) 755 If this bit is 1, the "Packet Identifier Step" field is present in 756 this manifest, else it is not. 758 2.3.2.5. Anchor Version 760 The value from the "/anchor/self/version" field in the anchor 761 message. If no unexpired anchor message with this version is known 762 to the authenticator, this manifest MUST NOT be accepted. 764 2.3.2.6. Anchor Hash 766 The hash of the anchor message, using the algorithm indicated by the 767 "/anchor/self/hash_algorithm" field, using the first bits from the 768 hash up to the number of bits indicated by the "/anchor/self/ 769 hash_bits" field in the anchor message. 771 If the hash of an anchor message with this version does not match the 772 bits in this field, this manifest MUST NOT be accepted. 774 This field is padded at the end with 0-bits until the end is 4-octet 775 aligned. 777 2.3.2.7. Manifest ID 779 The value from "/anchor/manifest_stream/id" in the anchor message 780 corresponding to the manifest stream this manifest is a part of. 782 2.3.2.8. First Packet Hash Identifier 784 The packet number corresponding to the first packet hash that's 785 contained in this manifest. This refers to a value in a data packet 786 described by the "/anchor/manifest_stream/sequence_type" field for 787 this manifest stream. 789 2.3.2.9. Packet Identifier Step 791 If the "S bit" is 0, this field is not present in the manifest. 793 If the "S bit" is 1, this field is repeatedly added to the First 794 Packet Hash Identifier using 32-bit signed arithmetic to determine 795 the packet number of subsequent hashes. 797 2.3.2.10. Packet Hash Count 799 The number of hashes contained in the Packet Hashes section. 801 2.3.2.11. Packet Hashes 803 Concatenated Hashes of the data packets authenticated by this 804 manifest. The hash covers the IP payload of the packet, it is 805 calculated with the algorithm indicated by the "/anchor/ 806 manifest_stream" object from the anchor message, with an "id" field 807 matching the "Manifest ID" field, with the algorithm and number of 808 bits equal to the "hash_algorithm" and "hash_bits"field from that 809 object. The hashes are concatenated without padding, except the last 810 octet is padded with 0 if necessary. 812 3. IANA Considerations 814 TBD1: Request a "Specification Required" registry for Packet 815 identifier methods, from https://tools.ietf.org/html/rfc5226#section- 816 4.1 . Reserve anything beginning with "experimental:"? 818 TBD2: Add a new entry to the "UDP Option Kind" numbers registry: 819 https://tools.ietf.org/html/draft-ietf-tsvwg-udp-options- 820 02#section-14 822 TBD: check guidelines in https://tools.ietf.org/html/rfc5226 and 823 remove this paragraph 825 Example from: https://tools.ietf.org/html/rfc5226#section-5.1 827 TBD: new Resource Record type with a URI in the RRData? Or should 828 this be done as a NAPTR + URI chain? 830 [TO BE REMOVED: Please add the yang model in Section 2.2.3 to: 831 https://www.iana.org/assignments/yang-parameters/yang- 832 parameters.xhtml 834 Name:ietf-ambi-anchor Maintained by IANA: N Namespace: 835 urn:ietf:params:xml:ns:yang:ietf-ambi-anchor Prefix: anchor 836 Reference: I-D.draft-jholland-mboned-ambi Notes: ] 838 4. Security Considerations 840 4.1. Packet Identifiers 842 TBD: explain attack from generating malicious packets and then 843 looking for collisions, as opposed to having to generate a collision 844 including a sequence number and then hitting a match 845 TBD: DNSSEC vis-a-vis anchor url discovery. (we need a diagram about 846 for middle-box handling of a revers-path propagated join?) Explain 847 why malicious DNS could deny service, but cannot cause accepting 848 attack packets. 850 TBD: Is the purge bit sufficient to cover when a key is found to be 851 leaked? 853 TBD: follow the rest of the guidelines: https://tools.ietf.org/html/ 854 rfc3552 856 5. References 858 5.1. Normative References 860 [I-D.ietf-tsvwg-udp-options] 861 Touch, J., "Transport Options for UDP", draft-ietf-tsvwg- 862 udp-options-07 (work in progress), March 2019. 864 [RFC1035] Mockapetris, P., "Domain names - implementation and 865 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 866 November 1987, . 868 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 869 Requirement Levels", BCP 14, RFC 2119, 870 DOI 10.17487/RFC2119, March 1997, 871 . 873 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 874 Jacobson, "RTP: A Transport Protocol for Real-Time 875 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 876 July 2003, . 878 [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, 879 "DNS Extensions to Support IP Version 6", STD 88, 880 RFC 3596, DOI 10.17487/RFC3596, October 2003, 881 . 883 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 884 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 885 RFC 3711, DOI 10.17487/RFC3711, March 2004, 886 . 888 5.2. Informative References 890 [DIGSIGN] Rohatgi, P., "How to Sign Digital Streams", 1997, 891 . 894 Published in CRYPTO '97 "Proceedings of the 17th Annual 895 International Cryptology Conference on Advances in 896 Cryptology", Pages 180-197 898 [RFC4082] Perrig, A., Song, D., Canetti, R., Tygar, J., and B. 899 Briscoe, "Timed Efficient Stream Loss-Tolerant 900 Authentication (TESLA): Multicast Source Authentication 901 Transform Introduction", RFC 4082, DOI 10.17487/RFC4082, 902 June 2005, . 904 [RFC4383] Baugher, M. and E. Carrara, "The Use of Timed Efficient 905 Stream Loss-Tolerant Authentication (TESLA) in the Secure 906 Real-time Transport Protocol (SRTP)", RFC 4383, 907 DOI 10.17487/RFC4383, February 2006, 908 . 910 [RFC5776] Roca, V., Francillon, A., and S. Faurite, "Use of Timed 911 Efficient Stream Loss-Tolerant Authentication (TESLA) in 912 the Asynchronous Layered Coding (ALC) and NACK-Oriented 913 Reliable Multicast (NORM) Protocols", RFC 5776, 914 DOI 10.17487/RFC5776, April 2010, 915 . 917 [RFC6584] Roca, V., "Simple Authentication Schemes for the 918 Asynchronous Layered Coding (ALC) and NACK-Oriented 919 Reliable Multicast (NORM) Protocols", RFC 6584, 920 DOI 10.17487/RFC6584, April 2012, 921 . 923 Authors' Addresses 925 Jake Holland 926 Akamai Technologies, Inc. 927 150 Broadway 928 Cambridge, MA 02144 929 United States of America 931 Email: jakeholland.net@gmail.com 933 Kyle Rose 934 Akamai Technologies, Inc. 935 150 Broadway 936 Cambridge, MA 02144 937 United States of America 939 Email: krose@krose.org