idnits 2.17.1 draft-krose-mboned-alta-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 : ---------------------------------------------------------------------------- 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 (July 08, 2019) is 1751 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group K. Rose 3 Internet-Draft J. Holland 4 Intended status: Experimental Akamai Technologies, Inc. 5 Expires: January 9, 2020 July 08, 2019 7 Asymmetric Loss-Tolerant Authentication 8 draft-krose-mboned-alta-01 10 Abstract 12 Establishing authenticity of a stream of datagrams in the presence of 13 multiple receivers is naively achieved through the use of per-packet 14 asymmetric digital signatures, but at high computational cost for 15 both senders and receivers. Timed Efficient Stream Loss-Tolerant 16 Authentication (TESLA) instead employs relatively cheap symmetric 17 authentication, achieving asymmetry via time-delayed key disclosure, 18 while adding latency to verification and imposing requirements on 19 time synchronization between receivers and the sender to prevent 20 forgery. This document introduces Asymmetric Loss-Tolerant 21 Authentication (ALTA), which employs an acyclic graph of message 22 authentication codes (MACs) transmitted alongside data payloads, with 23 redundancy to enable authentication of all received payloads in the 24 presence of certain patterns of loss, along with regularly paced 25 digital signatures. ALTA requires no time synchronization and 26 enables authentication of payloads as soon as sufficient 27 authentication material has been received. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at https://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on January 9, 2020. 46 Copyright Notice 48 Copyright (c) 2019 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (https://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 64 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 4 65 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 4 66 4. Protocol Details . . . . . . . . . . . . . . . . . . . . . . 6 67 4.1. ALTA Payload . . . . . . . . . . . . . . . . . . . . . . 6 68 4.1.1. Authentication Tag . . . . . . . . . . . . . . . . . 7 69 4.2. Digital Signature . . . . . . . . . . . . . . . . . . . . 8 70 4.2.1. Application Data . . . . . . . . . . . . . . . . . . 8 71 4.3. Scheme Construction . . . . . . . . . . . . . . . . . . . 8 72 5. ALTA Configuration . . . . . . . . . . . . . . . . . . . . . 9 73 5.1. Performance Considerations . . . . . . . . . . . . . . . 9 74 5.1.1. MAC selection . . . . . . . . . . . . . . . . . . . . 9 75 5.1.2. Digital signature selection . . . . . . . . . . . . . 9 76 5.2. Out-of-band Metadata . . . . . . . . . . . . . . . . . . 9 77 6. Operational Considerations . . . . . . . . . . . . . . . . . 9 78 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 79 7.1. Parsing an ill-formed or inconsistent payload . . . . . . 9 80 7.2. Index overflow . . . . . . . . . . . . . . . . . . . . . 9 81 7.3. Truncated MACs . . . . . . . . . . . . . . . . . . . . . 9 82 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 83 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 84 9.1. Normative References . . . . . . . . . . . . . . . . . . 9 85 9.2. Informative References . . . . . . . . . . . . . . . . . 9 86 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 10 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 89 1. Introduction 91 Authenticity of streaming data may be inexpensively established via 92 symmetric message authentication codes (MACs) using keys pre-shared 93 exclusively between two parties, as the receiver knows it did not 94 originate the data and that only one other party has access to the 95 key. In the presence of multiple receivers, however, this is not 96 possible because all receivers must have access to the same key, 97 giving any one of them the ability to forge messages. Consequently, 98 authentication must be made asymmetric, such that only the sender has 99 the ability to produce messages that correct receivers will verify as 100 authentic. 102 Naively, a sender may sign individual datagrams using an asymmetric 103 digital signature algorithm, such as RSA or Ed25519, but this carries 104 high computational cost for both the sender and receivers. In the 105 case of streaming video delivery, while the sender's computational 106 load may be dominated by CPU-intensive video encoding, the receiver 107 is often a device with hardware dedicated to efficient video decoding 108 and with limited general purpose computing hardware and/or battery 109 available for high-rate digital signature authentication. 111 Timed Efficient Stream Loss-Tolerant Authentication (TESLA) [RFC4082] 112 addresses this problem through the use of symmetric authentication by 113 delaying the release of keying material to a deadline at which any 114 packets protected by said key that are subsequently received must be 115 discarded by a receiver. While this reintroduces asymmetry between 116 sender and receiver, it requires the sender and each receiver to 117 (loosely) synchronize clocks and imposes authentication latency 118 relative to RTT and to a pre-declared upper bound on clock skew. 120 Clock synchronization is not as trivial as it appears: internet- 121 connected hosts often have significant clock skew relative to stratum 122 0 NTP servers [timeskew], and anyway enterprises serving valuable 123 assets do not regard NTP as a reliable interdomain security protocol. 124 Together with the need to avoid attacks that delay packets required 125 for synchronization, this implies the need for an interactive unicast 126 authenticated clock synchronization protocol, which is complicated by 127 the need to maintain clock synchronization across both the stream 128 publisher and multiple geographically-distributed nodes in a content 129 delivery network (CDN). 131 This document introduces Asymmetric Loss-Tolerant Authentication 132 (ALTA), which eschews time synchronization for an application of 133 digital signatures to an acyclic graph of symmetric message 134 authentication codes with redundancy sufficient to tolerate certain 135 patterns of loss, and with digital signature authentication load 136 greatly reduced relative to the naive approach. This algorithm is 137 based on research by Golle and Modadugu, as published in [STRAUTH]. 138 Live multicast streaming over an unreliable transport is the intended 139 application for ALTA: object-based integrity solutions or transport 140 security may be more appropriate for unicast transmission or for 141 static objects pulled on-demand. 143 2. Conventions and Definitions 145 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 146 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 147 "OPTIONAL" in this document are to be interpreted as described in BCP 148 14 [RFC2119] [RFC8174] when, and only when, they appear in all 149 capitals, as shown here. 151 3. Protocol Overview 153 ALTA is intended for streaming datagram use cases in which the 154 receiving application has a deadline for the utility of received data 155 and can tolerate a degree of random packet loss. It combines a 156 segment of application data with a variable-length authentication tag 157 into an ALTA payload to be sent as a unit in a single datagram, with 158 the authentication tags constructed in such a way that a receiver 159 will be able to authenticate nearly all such ALTA payloads received 160 by the deadline under certain patterns of random packet loss. 162 An authentication tag is a combination of zero or more symmetric 163 message authentication codes (MACs) and either zero or one digital 164 signature. Each MAC is of another ALTA payload in the stream, while 165 the digital signature is of the containing ALTA payload with the 166 signature field itself replaced by all zeroes. 168 The MACs included in a given authentication tag are determined by a 169 scheme, as defined in section 3 of [STRAUTH]. Conceptually, a scheme 170 is a mostly backward-looking directed acyclic graph of ALTA payloads 171 such that the MAC of a given payload is contained in two or more 172 other payloads in the stream, enabling the loss of one of these to be 173 tolerated without losing the ability to authenticate the given 174 payload. 176 For purposes of illustration, a simple example scheme is one in which 177 the ith ALTA payload's authentication tag contains MACs for the 178 (i-1)th and (i-2)th payload: 180 . 181 . 182 . 183 +-------------+------+ | 184 | payload i+1 | MACs | | 185 | | | | 186 | | i <---------------------+ | 187 | | i-1 <-----------------+ | | 188 +---------+---+------+ | | | 189 | +----------+---------+ 190 +------------------->| MAC of payload i+1 | 191 +--------------------+ 192 +-------------+------+ | | 193 | payload i | MACs | | | 194 | | | | | 195 | | i-1 <-----------------+ | 196 | | i-2 <-------------+ | | 197 +---------+---+------+ | | | 198 | +--------+---------+ 199 +------------------->| MAC of payload i | 200 +------------------+ 201 +-------------+------+ | | 202 | payload i-1 | MACs | | | 203 | | | | | 204 | | i-2 <-------------+ | 205 | | i-3 <--------+ | | 206 +---------+---+------+ | | | 207 | | +----+-+-------------+ 208 +------------------->| MAC of payload i-1 | 209 | +--------------------+ 210 +-------------+------+ | | 211 | payload i-2 | MACs | | | 212 | | | | | 213 | | i-3 <--------+ | 214 | | i-4 <----+ | | 215 +---------+---+------+ | | | 216 | | | ++-+-----------------+ 217 +------------------->| MAC of payload i-2 | 218 | | +--------------------+ 219 | | 220 | | 221 . . 222 . . 223 . . 225 The recommended scheme is more complex and will be covered in detail 226 in Section 4.3. 228 Encoding a scheme relies on ALTA payloads being addressable 229 deterministically by an index even in the presence of reordering or 230 loss. This index may be deduced from the application data (e.g., 231 making use of an existing sequence number) or by a payload index 232 explicitly encoded in the authentication tag. Two modes are 233 supported: 235 o If the index starts at zero and increments by exactly one for each 236 payload in the stream, and if the scheme is known to both sender 237 and receiver, then indices are not required to be encoded for each 238 MAC in an authentication tag as they can be deduced from a given 239 payload's index and from the DAG associated with the scheme. 240 Hereafter, this is referred to as _implicit offset mode_. 242 o If the index increments unpredictably, or if the scheme is not 243 known to the receiver, then each MAC in an authentication tag must 244 be paired with the explicit index of the ALTA payload from which 245 the MAC is computed. For compactness, this index will be encoded 246 as an offset relative to the index of the containing payload. 247 Hereafter this is referred to as _explicit offset mode_. 249 Authenticity of a payload is established by a chain of MACs rooted in 250 an ALTA payload whose authentication tag contains a digital signature 251 created by a key in which trust has been established out-of-band. 252 Delivery of application data must be delayed until a payload has been 253 authenticated. Note that a given payload may be authenticated by a 254 digital signature as well as by one or more MAC chains; within 255 authentication deadline constraints, receivers should prefer to 256 authenticate by MAC, minimizing the computational load imposed by 257 digital signature authentication. 259 The variable length of authentication tags in ALTA has implications 260 for application data segmentation when constant-length datagrams are 261 desired (e.g., to maximize data per UDP packet with a given path MTU 262 while avoiding fragmentation). 264 4. Protocol Details 266 4.1. ALTA Payload 268 An ALTA payload comprises the following elements (defined below) 269 concatenated in-order: 271 o Authentication tag 273 * Options octet 275 * Optional payload index 276 * Sequence of chained MACs 278 * Optional digital signature 280 o Application data 282 4.1.1. Authentication Tag 284 The authentication tag is the metadata emitted by an ALTA-compliant 285 sender that is required, in combination with other out-of-band 286 metadata, by an ALTA-compliant receiver to authenticate a stream of 287 packets in a manner tolerant to loss and reordering. 289 4.1.1.1. Options Octet 291 0 1 2 3 4 5 6 7 292 +-+-+-+-+-+-+-+-+ 293 |MACct|S| rsvd | 294 +-+-+-+-+-+-+-+-+ 296 Figure 1: Options Octet 298 The first octet of the authentication tag contains the count of MACs 299 included ("MACct") as well as a flag "S" indicating whether the tag 300 also contains a digital signature. It also contains four reserved 301 bits which MUST be set to 0 by senders and ignored by receivers. 303 4.1.1.2. Payload Index 305 0 1 306 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 ... 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 308 | payload index ... 309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 311 Figure 2: Payload Index 313 If the payload index cannot be deduced from the application data in 314 this payload, it must be specified explicitly in the authentication 315 tag as an unsigned quantity of a fixed length specified by out-of- 316 band metadata. 318 Whether explicit or deduced, the payload index uniquely identifies a 319 single ALTA stream payload within a rollover window of size "2^N" for 320 some "N" specified in out-of-band metadata. The payload index MUST 321 start at zero and increment by one for each payload transmitted, with 322 rollover to zero on overflow. 324 4.1.1.3. Chained MACs 326 0 1 327 0 1 2 3 4 5 6 7 8 9 0 1 ... 328 +-+-+-+-+-+-+-+-+-+-+-+-+-+- 329 | offset | MAC ... 330 +-+-+-+-+-+-+-+-+-+-+-+-+-+- 332 Figure 3: Example MAC with explicit index 334 In explicit offset mode, each MAC encoded in the payload comprises an 335 offset from the payload's index, expressed as a signed octet in two's 336 complement, followed by a fixed-length MAC. The length and semantics 337 of the MAC are a function of the MAC algorithm, which is specified by 338 out-of-band metadata. The offset space given in the example in 339 Figure 3 is one octet, ranging from -128 to 127, but may be of any 340 number of whole octets, as specified by out-of-band metadata. 342 In implicit offset mode, the receiver knows the scheme being employed 343 and so can deduce the indices of the chained MACs from the current 344 payload's index. Consequently, the MACs are simply concatenated in 345 ascending order of source index according to the scheme. 347 4.2. Digital Signature 349 0 1 2 3 4 5 6 ... 350 +-+-+-+-+-+-+-+-+- 351 | signature ... 352 +-+-+-+-+-+-+-+-+- 354 Figure 4: Digital Signature 356 If "S=1" in the options octet, then a digital signature is included 357 in the tag. The length and content of this digital signature are a 358 function of the signature algorithm, which is specified by out-of- 359 band metadata. 361 4.2.1. Application Data 363 The application data is opaque, with the exception of the payload 364 index if not specified explicitly in the authentication tag. 366 4.3. Scheme Construction 368 In the ALTA context, a scheme describes the directed acyclic graph of 369 payload MACs embedded in other payloads for purposes of chained 370 authentication. The recommended scheme is that described in section 371 3.2 of [STRAUTH], with "a=3" and "p=5". 373 FIXME: Describe how to construct this scheme in pseudocode. 375 5. ALTA Configuration 377 5.1. Performance Considerations 379 5.1.1. MAC selection 381 5.1.2. Digital signature selection 383 5.2. Out-of-band Metadata 385 6. Operational Considerations 387 As ALTA requires an out-of-band channel for provisioning of metadata, 388 including digital signature keys and cryptographic algorithms, 389 versioning of the protocol to support a future ALTA revision may be 390 performed there and acted upon by the application. 392 7. Security Considerations 394 7.1. Parsing an ill-formed or inconsistent payload 396 7.2. Index overflow 398 7.3. Truncated MACs 400 8. IANA Considerations 402 This document has no IANA actions. 404 9. References 406 9.1. Normative References 408 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 409 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 410 May 2017, . 412 9.2. Informative References 414 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 415 Requirement Levels", BCP 14, RFC 2119, 416 DOI 10.17487/RFC2119, March 1997, 417 . 419 [RFC4082] Perrig, A., Song, D., Canetti, R., Tygar, J., and B. 420 Briscoe, "Timed Efficient Stream Loss-Tolerant 421 Authentication (TESLA): Multicast Source Authentication 422 Transform Introduction", RFC 4082, DOI 10.17487/RFC4082, 423 June 2005, . 425 [STRAUTH] Modadugu, N., "Authenticating Streamed Data in the 426 Presence of Random Packet Loss", 2001, 427 . 429 ISOC Network and Distributed System Security Symposium 431 [timeskew] 432 "FIXME reference for how bad time sync is", n.d.. 434 Acknowledgments 436 The author wishes to acknowledge Eric Rescorla, who introduced the 437 author to the paper describing the loss-tolerant symmetric 438 authentication scheme used as the basis for ALTA. 440 Authors' Addresses 442 Kyle Rose 443 Akamai Technologies, Inc. 444 150 Broadway 445 Cambridge, MA 02144 446 United States of America 448 Email: krose@krose.org 450 Jake Holland 451 Akamai Technologies, Inc. 452 150 Broadway 453 Cambridge, MA 02144 454 United States of America 456 Email: jakeholland.net@gmail.com