idnits 2.17.1 draft-thornburgh-rtmfp-flash-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- -- The document has an IETF Trust Provisions (28 Dec 2009) Section 6.c(i) Publication Limitation clause. 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 (September 2, 2014) is 3517 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '32' on line 737 -- Looks like a reference, but probably isn't: '16' on line 1157 -- Looks like a reference, but probably isn't: '2' on line 1395 ** Obsolete normative reference: RFC 5996 (Obsoleted by RFC 7296) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Thornburgh 3 Internet-Draft Adobe 4 Intended status: Informational September 2, 2014 5 Expires: March 6, 2015 7 Adobe's RTMFP Profile for Flash Communication 8 draft-thornburgh-rtmfp-flash-07 10 Abstract 12 This memo describes how to use Adobe's Secure Real-Time Media Flow 13 Protocol (RTMFP) to transport the video, audio, and data messages of 14 Adobe Flash platform communications. Aspects of this application 15 profile include cryptographic methods and data formats, flow metadata 16 formats, and protocol details for client-server and peer-to-peer 17 communication. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on March 6, 2015. 36 Copyright Notice 38 Copyright (c) 2014 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 This document may not be modified, and derivative works of it may not 52 be created, except to format it for publication as an RFC or to 53 translate it into languages other than English. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 3. Common Syntax Elements . . . . . . . . . . . . . . . . . . . 5 60 4. Cryptography Profile . . . . . . . . . . . . . . . . . . . . 5 61 4.1. Default Session Key . . . . . . . . . . . . . . . . . . . 5 62 4.2. Diffie-Hellman Groups . . . . . . . . . . . . . . . . . . 6 63 4.3. Certificates . . . . . . . . . . . . . . . . . . . . . . 6 64 4.3.1. Format . . . . . . . . . . . . . . . . . . . . . . . 6 65 4.3.2. Fingerprint . . . . . . . . . . . . . . . . . . . . . 7 66 4.3.3. Options . . . . . . . . . . . . . . . . . . . . . . . 7 67 4.3.3.1. Hostname . . . . . . . . . . . . . . . . . . . . 8 68 4.3.3.2. Accepts Ancillary Data . . . . . . . . . . . . . 8 69 4.3.3.3. Extra Randomness . . . . . . . . . . . . . . . . 8 70 4.3.3.4. Supported Ephemeral Diffie-Hellman Group . . . . 9 71 4.3.3.5. Static Diffie-Hellman Public Key . . . . . . . . 9 72 4.3.4. Authenticity . . . . . . . . . . . . . . . . . . . . 10 73 4.3.5. Signing and Verifying Messages . . . . . . . . . . . 10 74 4.3.5.1. Options . . . . . . . . . . . . . . . . . . . . . 11 75 4.3.5.1.1. Simple Password . . . . . . . . . . . . . . . 11 76 4.3.6. Glare Resolution . . . . . . . . . . . . . . . . . . 12 77 4.3.7. Session Override . . . . . . . . . . . . . . . . . . 13 78 4.4. Endpoint Discriminators . . . . . . . . . . . . . . . . . 13 79 4.4.1. Format . . . . . . . . . . . . . . . . . . . . . . . 13 80 4.4.2. Options . . . . . . . . . . . . . . . . . . . . . . . 14 81 4.4.2.1. Required Hostname . . . . . . . . . . . . . . . . 14 82 4.4.2.2. Ancillary Data . . . . . . . . . . . . . . . . . 14 83 4.4.2.3. Fingerprint . . . . . . . . . . . . . . . . . . . 15 84 4.4.3. Certificate Selection . . . . . . . . . . . . . . . . 15 85 4.4.4. Canonical Endpoint Discriminator . . . . . . . . . . 16 86 4.5. Session Keying Components . . . . . . . . . . . . . . . . 17 87 4.5.1. Format . . . . . . . . . . . . . . . . . . . . . . . 17 88 4.5.2. Options . . . . . . . . . . . . . . . . . . . . . . . 18 89 4.5.2.1. Ephemeral Diffie-Hellman Public Key . . . . . . . 18 90 4.5.2.2. Extra Randomness . . . . . . . . . . . . . . . . 19 91 4.5.2.3. Diffie-Hellman Group Select . . . . . . . . . . . 19 92 4.5.2.4. HMAC Negotiation . . . . . . . . . . . . . . . . 20 93 4.5.2.5. Session Sequence Number Negotiation . . . . . . . 21 94 4.6. Session Key Computation . . . . . . . . . . . . . . . . . 21 95 4.6.1. Public Key Selection . . . . . . . . . . . . . . . . 22 96 4.6.1.1. Initiator and Responder Ephemeral . . . . . . . . 22 97 4.6.1.2. Initiator Ephemeral and Responder Static . . . . 22 98 4.6.1.3. Initiator Static and Responder Ephemeral . . . . 22 99 4.6.1.4. Initiator and Responder Static . . . . . . . . . 23 100 4.6.2. Diffie-Hellman Shared Secret . . . . . . . . . . . . 23 101 4.6.3. Packet Encrypt/Decrypt Keys . . . . . . . . . . . . . 23 102 4.6.4. Packet HMAC Send/Receive Keys . . . . . . . . . . . . 24 103 4.6.5. Session Nonces . . . . . . . . . . . . . . . . . . . 25 104 4.6.6. Session Sequence Number . . . . . . . . . . . . . . . 25 105 4.7. Packet Encryption . . . . . . . . . . . . . . . . . . . . 26 106 4.7.1. Cipher . . . . . . . . . . . . . . . . . . . . . . . 26 107 4.7.2. Format . . . . . . . . . . . . . . . . . . . . . . . 26 108 4.7.3. Verification . . . . . . . . . . . . . . . . . . . . 28 109 4.7.3.1. Simple Checksum . . . . . . . . . . . . . . . . . 29 110 4.7.3.2. HMAC . . . . . . . . . . . . . . . . . . . . . . 29 111 4.7.3.3. Session Sequence Number . . . . . . . . . . . . . 30 112 5. Flash Communication . . . . . . . . . . . . . . . . . . . . . 30 113 5.1. RTMP Messages . . . . . . . . . . . . . . . . . . . . . . 30 114 5.1.1. Flow Metadata . . . . . . . . . . . . . . . . . . . . 31 115 5.1.2. Message Mapping . . . . . . . . . . . . . . . . . . . 33 116 5.2. Flow Synchronization . . . . . . . . . . . . . . . . . . 34 117 5.3. Client to Server Connection . . . . . . . . . . . . . . . 35 118 5.3.1. Connecting . . . . . . . . . . . . . . . . . . . . . 35 119 5.3.2. Server to Client Return Control Flow . . . . . . . . 36 120 5.3.3. setPeerInfo Command . . . . . . . . . . . . . . . . . 36 121 5.3.4. Set Keepalive Timers Command . . . . . . . . . . . . 37 122 5.3.5. Additional Flows For Streams . . . . . . . . . . . . 39 123 5.3.5.1. To Server . . . . . . . . . . . . . . . . . . . . 39 124 5.3.5.2. From Server . . . . . . . . . . . . . . . . . . . 39 125 5.3.5.3. Closing Stream Flows . . . . . . . . . . . . . . 39 126 5.3.6. Closing the Connection . . . . . . . . . . . . . . . 40 127 5.3.7. Example . . . . . . . . . . . . . . . . . . . . . . . 40 128 5.4. Direct Peer to Peer Streams . . . . . . . . . . . . . . . 42 129 5.4.1. Connecting . . . . . . . . . . . . . . . . . . . . . 42 130 5.4.2. Return Flows for Stream . . . . . . . . . . . . . . . 42 131 5.4.3. Closing the Connection . . . . . . . . . . . . . . . 43 132 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43 133 6.1. RTMFP URI Scheme Registration . . . . . . . . . . . . . . 43 134 7. Security Considerations . . . . . . . . . . . . . . . . . . . 45 135 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 46 136 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 46 137 9.1. Normative References . . . . . . . . . . . . . . . . . . 46 138 9.2. Informative References . . . . . . . . . . . . . . . . . 48 139 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 48 141 1. Introduction 143 Adobe's Secure Real-Time Media Flow Protocol (RTMFP) [RFC7016] is a 144 general purpose transport service for real-time media and bulk data 145 in IP networks, and is suited to client-server and peer-to-peer (P2P) 146 communication. RTMFP provides a generalized framework for securing 147 its communications according to the needs of its application. 149 The Flash platform comprises the Flash runtime (including Flash 150 Player) from Adobe Systems Incorporated, communication servers such 151 as Adobe Media Server, and interoperable clients and servers provided 152 by other parties. 154 Real-time streaming network communication for the Flash platform of 155 video, audio, and data typically uses Adobe's Real Time Messaging 156 Protocol (RTMP) [RTMP] messages. RTMP messages were originally 157 designed to be transported over RTMP Chunk Stream in TCP [RTMP]; 158 however, other transports (such as the one described in this memo) 159 are possible. 161 This memo specifies the syntax and semantics for transporting RTMP 162 messages over RTMFP, and extends Flash communication semantics to 163 include direct P2P communication. This memo further specifies a 164 concrete Cryptography Profile for RTMFP tailored to the application 165 and cryptographic needs of Flash platform client-server and P2P 166 communications. 168 These protocols and profiles were developed by Adobe Systems 169 Incorporated and are not the product of an IETF activity. 171 2. Terminology 173 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 174 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 175 "OPTIONAL" in this document are to be interpreted as described in 176 [RFC2119]. 178 "HMAC" means the HMAC Keyed Message Authentication Code algorithm 179 [RFC2104]. 181 "HMAC-SHA256" means HMAC using the SHA-256 Secure Hash Algorithm 182 [SHA256] [RFC6234]. 184 "HMAC-SHA256(K, M)" means to calculate the HMAC-SHA256 of message M 185 using key K. 187 3. Common Syntax Elements 189 Definitions of types and structures in this specification use 190 traditional text diagrams paired with procedural descriptions using a 191 C-like syntax. The C-like procedural descriptions SHALL be construed 192 as definitive. 194 Structures are packed to take only as many bytes as explicitly 195 indicated. There is no 32-bit alignment constraint, and fields are 196 not padded for alignment unless explicitly indicated or described. 197 Text diagrams may include a bit ruler across the top; this is a 198 convenience for counting bits in individual fields and does not 199 necessarily imply field alignment on a multiple of the ruler width. 201 Unless specified otherwise, reserved fields SHOULD be set to 0 by a 202 sender and MUST be ignored by a receiver. 204 The procedural syntax of this specification defines correct and 205 error-free encoded inputs to a parser. The procedural syntax does 206 not describe a fully featured parser, including error detection and 207 handling. Implementations MUST include means to identify error 208 circumstances, including truncations causing elementary or composed 209 types to not fit inside containing structures, fields or elements. 210 Unless specified otherwise, an error circumstance SHALL abort the 211 parsing and processing of an element and its enclosing elements. 213 This memo uses the elementary and composed types described in 214 Section 2.1 of RFC 7016. The definitions of that section are 215 incorporated by reference as though fully set forth here. 217 4. Cryptography Profile 219 RTMFP defines a general security framework but delegates specifics, 220 such as packet encryption ciphers and key agreement algorithms, to an 221 application-defined Cryptography Profile. 223 This section defines the RTMFP Cryptography Profile for Flash 224 platform communication. 226 4.1. Default Session Key 228 RTMFP uses a Default Session Key and associated default cipher 229 configuration during session startup handshaking, where session- 230 specific keys and ciphers are negotiated. 232 The default cipher is the Advanced Encryption Standard [AES] with 233 128-bit keys operating in Cipher Block Chaining mode [CBC], as 234 described in Section 4.7.1. The Default Session Key is the 16 bytes 235 of the UTF-8 [RFC3629] coded string "Adobe Systems 02": 237 Hex: 41 64 6F 62 65 20 53 79 73 74 65 6D 73 20 30 32 239 The Default Session Key uses checksum mode for packet verification 240 and does not use session sequence numbers (Section 4.7.3). 242 4.2. Diffie-Hellman Groups 244 Implementations conforming to this profile MUST support Diffie- 245 Hellman [DH] MODP group 2 (1024 bits) as defined in [RFC5996], and 246 SHOULD support Diffie-Hellman MODP group 5 (1536 bits) and group 14 247 (2048 bits) as defined in [RFC3526]. Implementations MAY support 248 additional groups. 250 4.3. Certificates 252 This section defines the certificate format for this Cryptography 253 Profile, and the mapping to the abstract properties and semantics for 254 RTMFP endpoint identities. 256 4.3.1. Format 258 A certificate in this profile is encoded as a sequence of zero or 259 more RTMFP Options and Markers (Section 2.1.3 of RFC 7016). The 260 first marker (if any) in the certificate separates the canonical 261 section of the certificate from the remainder. Some options are 262 ignored if they occur outside of the canonical section (that is, 263 after the first marker). 265 +~~~/~~~/~~~+ +~~~/~~~/~~~+~~~~~+~~~/~~~/~~~+ +~~~/~~~/~~~+ 266 | L \ T \ V |...| L \ T \ V | 0 | L \ T \ V |...| L \ T \ V | 267 +~~~/~~~/~~~+ +~~~/~~~/~~~+~~~~~+~~~/~~~/~~~+ +~~~/~~~/~~~+ 268 ^ ^ ^ ^ ^ 269 | Zero or more non-empty | | | Zero or more Options | 270 | Options | | +------ or Markers -------+ 271 | | | 272 +--- Canonical Section ---+ +---- First Marker 273 (if present) 275 struct certificate_t 276 { 277 canonicalStart = remainder(); 278 canonicalEnd = remainder(); 279 markerFound = false; 281 while(remainder() > 0) 282 { 283 option_t option :variable*8; 285 if(0 == option.length) 286 markerFound = true; 287 else if(!markerFound) 288 canonicalEnd = remainder(); 289 }; 291 canonicalSectionLength = canonicalStart - canonicalEnd; 292 } :variable*8; 294 4.3.2. Fingerprint 296 A certificate's fingerprint is the SHA-256 hash [SHA256] of the 297 canonical section of the certificate; that is, the hash of the first 298 canonicalSectionLength bytes of the certificate. 300 The certificate's fingerprint is also called the "peer ID". 302 4.3.3. Options 304 This section lists options that can appear in a certificate. The 305 following option type codes are defined: 307 0x00: Hostname (must be in canonical section) (Section 4.3.3.1) 309 0x0a: Accepts Ancillary Data (must be in canonical section) 310 (Section 4.3.3.2) 312 0x0e: Extra Randomness (Section 4.3.3.3) 313 0x15: Supported Ephemeral Diffie-Hellman Group (must be in canonical 314 section) (Section 4.3.3.4) 316 0x1d: Static Diffie-Hellman Public Key (must be in canonical 317 section) (Section 4.3.3.5) 319 An implementation MUST ignore a certificate option type that is not 320 understood. 322 4.3.3.1. Hostname 324 This option gives an optional hostname for the endpoint. This option 325 MUST be ignored if is not in the canonical section. This option MUST 326 NOT occur more than once in a certificate. 328 +-------------/-+-------------/-+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+ 329 | length \ | 0x00 \ | hostname | 330 +-------------/-+-------------/-+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~/ 332 struct hostnameCertOptionValue_t 333 { 334 uint8_t hostname[remainder()]; 335 } :remainder()*8; 337 4.3.3.2. Accepts Ancillary Data 339 This option indicates that the endpoint will accept an Endpoint 340 Discriminator encoding an Ancillary Data option (Section 4.4.2.2). 341 This option MUST be ignored if it is not in the canonical section. 343 +-------------/-+-------------/-+ 344 | length \ | 0x0a \ | 345 +-------------/-+-------------/-+ 347 4.3.3.3. Extra Randomness 349 This option can be used to add extra entropy or randomness to a 350 certificate that doesn't have any other cryptographic pseudorandom 351 members (such as a public key). This option is typically used so 352 that endpoints using ephemeral Diffie-Hellman keying can have a 353 unique certificate fingerprint. 355 +-------------/-+-------------/-+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+ 356 | length \ | 0x0e \ | extra randomness | 357 +-------------/-+-------------/-+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~/ 359 struct extraRandomnessCertOptionValue_t 360 { 361 uint_t extraRandomness[remainder()]; 362 } :remainder()*8; 364 4.3.3.4. Supported Ephemeral Diffie-Hellman Group 366 This option specifies a Diffie-Hellman group ID that is supported for 367 ephemeral keying. This option MUST be ignored if it is not in the 368 canonical section. This option may occur more than once in the 369 certificate; each instance indicates an additional group that is 370 supported for key agreement. 372 +-------------/-+-------------/-+-------------/-+ 373 | length \ | 0x15 \ | group ID \ | 374 +-------------/-+-------------/-+-------------/-+ 376 struct ephemeralDHGroupCertOptionValue_t 377 { 378 vlu_t groupID :variable*8; 379 } :variable*8; 381 The presence of this option means that the certificate uses ephemeral 382 Diffie-Hellman public keys only. The certificate MUST NOT contain a 383 Static Diffie-Hellman public key (Section 4.3.3.5). 385 4.3.3.5. Static Diffie-Hellman Public Key 387 This option specifies a Diffie-Hellman group ID and static public key 388 in that group. This option MUST be ignored if it is not in the 389 canonical section. This option MAY occur more than once in the 390 certificate; however, this option SHOULD NOT occur more than once for 391 each group ID. The behavior for specifying more than one public key 392 per group ID is not defined. 394 +-------------/-+-------------/-+-------------/-+ 395 | length \ | 0x1d \ | group ID \ | 396 +-------------/-+-------------/-+-------------/-+ 397 +------------------------------------------------------------------+ 398 | Diffie-Hellman Public Key | 399 +------------------------------------------------------------------/ 401 struct staticDHPublicKeyCertOptionValue_t 402 { 403 vlu_t groupID :variable*8; 404 uintn_t publicKey :remainder()*8; // network byte order 405 } :remainder()*8; 407 The presence of this option means that the certificate uses static 408 Diffie-Hellman public keys only. The certificate MUST NOT contain 409 any Supported Ephemeral Diffie-Hellman Group options 410 (Section 4.3.3.4). 412 4.3.4. Authenticity 414 This profile does not use a public key infrastructure, nor are there 415 signing keys present in certificates. Therefore, any properly 416 encoded certificate is considered authentic according to Section 3.2 417 of RFC 7016. 419 A certificate containing a static public key can only be used 420 successfully for session communication if the holder of the 421 certificate actually holds the private key associated with the public 422 key. Authenticity of an identity and its peer ID (Section 4.3.2) 423 having a certificate containing a static public key is implied by 424 successful encrypted communication with the associated endpoint 425 (Section 4.6). 427 See Section 7 for further discussion of security issues related to 428 identities. 430 4.3.5. Signing and Verifying Messages 432 RTMFP Initiator Initial Keying and Responder Initial Keying messages 433 have a field for the sender's digital signature of the keying 434 parameters (Sections 2.3.7 and 2.3.8 of RFC 7016). In this profile, 435 the signature field of those messages is encoded as a sequence of 436 zero or more RTMFP Options. 438 +~~~/~~~/~~~~~~~+ +~~~/~~~/~~~~~~~+ 439 | L \ T \ V |...............| L \ T \ V | 440 +~~~/~~~/~~~~~~~+ +~~~/~~~/~~~~~~~+ 441 ^ ^ 442 +------------- Zero or more Options ----------+ 444 struct initialKeyingSignature_t 445 { 446 while(remainder() > 0) 447 option_t option :variable*8; 448 } :remainder()*8; 450 If a signer has no signature options to send, it MAY encode a 451 signature as a UTF-8 capital "X" (hex 58) or as empty. A verifier 452 MUST interpret a malformed signature field or a signature field 453 consisting only of a UTF-8 capital "X" as though it was empty. 455 If a verifier does not require a signature, it SHALL consider any 456 signature field (including an empty or malformed one) to be valid. A 457 verifier MAY require a signature comprising one or more non-empty 458 options that are valid according to their respective types. 460 This profile does not use a public key infrastructure, nor are there 461 signing keys present in certificates. Section 4.3.5.1.1 defines a 462 simple ID/password credential system. 464 4.3.5.1. Options 466 This section lists options that can appear in an RTMFP Initial Keying 467 signature field. The following option type code is defined: 469 0x1d: Simple Password (Section 4.3.5.1.1) 471 Future or derived profiles may define additional signature field 472 options and semantics; therefore, a verifier SHOULD ignore option 473 types that are not understood. 475 4.3.5.1.1. Simple Password 477 This option encodes a password identifier (such as a user name, or an 478 application-specific or implementation-specific selector) and an HMAC 479 over the signed parameters using the identified password as the HMAC 480 key. This option can occur more than once (for example, to allow 481 interoperation between a current and a previous version of an 482 implementation using implementation-specific passwords). 484 To support the versioning use case, a verifier SHOULD ignore a Simple 485 Password option encoding an unrecognized password identifier. A 486 verifier SHOULD treat the entire signature as invalid if any Simple 487 Password option encodes a recognized password identifier with an 488 invalid password HMAC. 490 0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7 491 +-------------/-+-------------/-+ 492 | length \ | 0x1d \ | 493 +-------------/-+-------------/-+ 494 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 495 | | 496 + - - - - - - - + - - - - - - - + - - - - - - - + - - - - - - - + 497 | | 498 + - - - - - - - + - - - - - - - + - - - - - - - + - - - - - - - + 499 | | 500 + - - - - - - - + - - - - - - - + - - - - - - - + - - - - - - - + 501 | hmacSHA256 | 502 + - - - - - - - + - - - - - - - + - - - - - - - + - - - - - - - + 503 | | 504 + - - - - - - - + - - - - - - - + - - - - - - - + - - - - - - - + 505 | | 506 + - - - - - - - + - - - - - - - + - - - - - - - + - - - - - - - + 507 | | 508 + - - - - - - - + - - - - - - - + - - - - - - - + - - - - - - - + 509 | | 510 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 511 +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+ 512 | passwordID | 513 +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~/ 515 struct simplePasswordSignatureOptionValue_t 516 { 517 uint8_t hmacSHA256[32]; 518 uint8_t passwordID[remainder()]; 519 } :remainder()*8; 521 hmacSHA256: HMAC-SHA256(K, M), where K is the password associated 522 with passwordID, and M is the signed parameters. 524 passwordID: The identifier (such as a user name) for the password 525 used as the HMAC key. 527 4.3.6. Glare Resolution 529 Glare occurs when two endpoints initiate a session each to the other 530 concurrently. 532 Compare the near end's certificate to the far end's with a binary 533 lexicographic comparison, one byte at a time, up to the length of the 534 shorter certificate. At the first corresponding byte from each 535 certificate that is different, the certificate having the differing 536 byte (treated as an unsigned 8 bit integer) with the lower value is 537 ordered before the other certificate. If the certificates are not 538 the same length and they are identical up to the length of the 539 shorter certificate, then the shorter certificate is ordered before 540 the longer. 542 The near end prevails as the Initiator in case of glare if its 543 certificate is ordered before, or is identical to, the certificate of 544 the far end. Otherwise the near end's certificate is ordered after 545 the far end's certificate, and the near end assumes the role of 546 Responder. 548 4.3.7. Session Override 550 A new incoming session overrides an existing session only if the 551 certificate for the new session is identical to the certificate for 552 the existing session. 554 4.4. Endpoint Discriminators 556 This section describes the Endpoint Discriminator (EPD) (Section 3.2 557 of RFC 7016) format and semantics for this Cryptography Profile, and 558 the mapping to RTMFP's abstract certificate and identity selection 559 semantics. 561 4.4.1. Format 563 An EPD in this profile is encoded as a sequence of zero or more RTMFP 564 Options. 566 +~~~/~~~/~~~~~~~+ +~~~/~~~/~~~~~~~+ 567 | L \ T \ V |...............| L \ T \ V | 568 +~~~/~~~/~~~~~~~+ +~~~/~~~/~~~~~~~+ 569 ^ ^ 570 +------------- Zero or more Options ----------+ 572 struct endpointDiscriminator_t 573 { 574 while(remainder() > 0) 575 option_t option :variable*8; 576 } :remainder()*8; 578 4.4.2. Options 580 This section lists options that can appear in an EPD. The following 581 option type codes are defined: 583 0x00: Required Hostname (Section 4.4.2.1) 585 0x0a: Ancillary Data (Section 4.4.2.2) 587 0x0f: Fingerprint (Section 4.4.2.3) 589 The use of these options for selecting certificates is described in 590 Section 4.4.3. 592 An implementation MUST ignore EPD option types that are not 593 understood. 595 4.4.2.1. Required Hostname 597 This option indicates the hostname to match against the certificate's 598 Hostname option (Section 4.3.3.1). 600 +-------------/-+-------------/-+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+ 601 | length \ | 0x00 \ | hostname | 602 +-------------/-+-------------/-+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~/ 604 struct hostnameEPDOptionValue_t 605 { 606 uint8_t hostname[remainder()]; 607 } :remainder()*8; 609 This option MUST NOT occur more than once in an EPD. 611 4.4.2.2. Ancillary Data 613 In this profile, this option indicates the UTF-8 encoded server 614 Uniform Resource Identifier (URI) [RFC3986] to which a client is 615 connecting on this session, for example "rtmfp://server.example.com/ 616 app/instance". 618 +-------------/-+-------------/-+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+ 619 | length \ | 0x0a \ | ancillary data | 620 +-------------/-+-------------/-+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~/ 622 struct ancillaryDataEPDOptionValue_t 623 { 624 uint8_t ancillaryData[remainder()]; 625 } :remainder()*8; 626 This option MUST NOT occur more than once in an EPD. 628 4.4.2.3. Fingerprint 630 This option indicates the 256 bit (32 byte) fingerprint 631 (Section 4.3.2) of a certificate. 633 0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7 634 +-------------/-+-------------/-+ 635 | length \ | 0x0f \ | 636 +-------------/-+-------------/-+ 637 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 638 | | 639 + - - - - - - - + - - - - - - - + - - - - - - - + - - - - - - - + 640 | | 641 + - - - - - - - + - - - - - - - + - - - - - - - + - - - - - - - + 642 | | 643 + - - - - - - - + - - - - - - - + - - - - - - - + - - - - - - - + 644 | fingerprint | 645 + - - - - - - - + - - - - - - - + - - - - - - - + - - - - - - - + 646 | | 647 + - - - - - - - + - - - - - - - + - - - - - - - + - - - - - - - + 648 | | 649 + - - - - - - - + - - - - - - - + - - - - - - - + - - - - - - - + 650 | | 651 + - - - - - - - + - - - - - - - + - - - - - - - + - - - - - - - + 652 | | 653 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 655 struct fingerprintEPDOptionValue_t 656 { 657 uint8_t fingerprint[32]; 658 } :256; 660 This option MUST NOT occur more than once in an EPD. 662 4.4.3. Certificate Selection 664 This section describes the REQUIRED method of determining whether an 665 EPD selects a certificate. 667 An EPD MUST contain at least one of Fingerprint, Required Hostname, 668 or Ancillary Data options to select any certificate. 670 A Fingerprint EPD option selects or rejects a certificate no matter 671 what other options are present. 673 Without a Fingerprint option, a Required Hostname EPD option, if 674 present, REQUIRES an identical Hostname option in the certificate. 676 Without a Fingerprint option, an Ancillary Data EPD option, if 677 present, REQUIRES that the certificate has an Accepts Ancillary Data 678 option. 680 if EPD contains a Fingerprint option: 681 if certificate.fingerprint == option.fingerprint: 682 certificate is selected. stop. 683 else: 684 certificate is not selected. stop. 685 else: 686 if EPD contains a Required Hostname option: 687 if certificate contains a Hostname option: 688 if certificate.hostname != option.hostname: 689 certificate is not selected. stop. 690 else: 691 certificate is not selected. stop. 692 if EPD contains an Ancillary Data option: 693 if certificate doesn't have an Accepts Ancillary Data option: 694 certificate is not selected. stop. 695 else if EPD does not contain a Required Hostname option: 696 certificate is not selected. stop. 697 certificate is selected. stop. 699 Figure 1: Algorithm to test whether an EPD selects a certificate 701 4.4.4. Canonical Endpoint Discriminator 703 In this profile, a Canonical Endpoint Discriminator (Section 3.2 of 704 RFC 7016) contains only a Fingerprint option (Section 4.4.2.3) and no 705 other options. The option length and type code MUST be encoded as 706 one byte VLUs, even though VLU encoding allows those fields to be 707 encoded in arbitrarily many bytes. That is, the Canonical Endpoint 708 Discriminator MUST be exactly 34 bytes long, with a length field of 709 0x21 encoded as one byte, a type code of 0x0f encoded as one byte, 710 and 32 bytes of fingerprint. 712 0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7 713 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 714 | 0x21 | 0x0f | 715 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 716 | | 717 + - - - - - - - + - - - - - - - + - - - - - - - + - - - - - - - + 718 | | 719 + - - - - - - - + - - - - - - - + - - - - - - - + - - - - - - - + 720 | | 721 + - - - - - - - + - - - - - - - + - - - - - - - + - - - - - - - + 722 | fingerprint | 723 + - - - - - - - + - - - - - - - + - - - - - - - + - - - - - - - + 724 | | 725 + - - - - - - - + - - - - - - - + - - - - - - - + - - - - - - - + 726 | | 727 + - - - - - - - + - - - - - - - + - - - - - - - + - - - - - - - + 728 | | 729 + - - - - - - - + - - - - - - - + - - - - - - - + - - - - - - - + 730 | | 731 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 733 struct canonicalEndpointDiscriminator_t 734 { 735 uint8_t length = 0x21; 736 uint8_t type = 0x0f; 737 uint8_t fingerprint[32]; 738 } :272; 740 4.5. Session Keying Components 742 This section describes the format of the Session Key Initiator 743 Component of the Initiator Initial Keying RTMFP chunk and the Session 744 Key Responder Component of the Responder Initial Keying RTMFP chunk 745 (Sections 2.3.7 and 2.3.8 of RFC 7016). The Initiator and Responder 746 Session Keying Components have the same format. 748 4.5.1. Format 750 A Session Keying Component in this profile is encoded as a sequence 751 of zero or more RTMFP Options. 753 +~~~/~~~/~~~~~~~+ +~~~/~~~/~~~~~~~+ 754 | L \ T \ V |...............| L \ T \ V | 755 +~~~/~~~/~~~~~~~+ +~~~/~~~/~~~~~~~+ 756 ^ ^ 757 +------------- Zero or more Options ----------+ 759 struct sessionKeyingComponent_t 760 { 761 while(remainder() > 0) 762 option_t option :variable*8; 763 } :remainder()*8; 765 4.5.2. Options 767 This section lists options that can appear in a Session Keying 768 Component. The following option type codes are defined: 770 0x0d: Ephemeral Diffie-Hellman Public Key (Section 4.5.2.1) 772 0x0e: Extra Randomness (Section 4.5.2.2) 774 0x1d: Diffie-Hellman Group Select (Section 4.5.2.3) 776 0x1a: HMAC Negotiation (Section 4.5.2.4) 778 0x1e: Session Sequence Number Negotiation (Section 4.5.2.5) 780 An implementation MUST ignore a session keying component option type 781 that is not understood. 783 4.5.2.1. Ephemeral Diffie-Hellman Public Key 785 This option specifies a Diffie-Hellman group ID and public key in 786 that group. This option MUST NOT be sent if the sender's certificate 787 has a static Diffie-Hellman public key. This option MUST be sent if 788 the sender's certificate does not have a static Diffie-Hellman public 789 key. This option MUST NOT be sent more than once. 791 +-------------/-+-------------/-+-------------/-+ 792 | length \ | 0x0d \ | group ID \ | 793 +-------------/-+-------------/-+-------------/-+ 794 +------------------------------------------------------------------+ 795 | Diffie-Hellman Public Key | 796 +------------------------------------------------------------------/ 798 struct ephemeralDHPublicKeyKeyingOptionValue_t 799 { 800 vlu_t groupID :variable*8; 801 uintn_t publicKey :remainder()*8; // network byte order 802 } :remainder()*8; 804 4.5.2.2. Extra Randomness 806 This option can be used to add extra entropy or randomness to a 807 keying component, particularly when the sender uses a static public 808 key. When used for that purpose, the extra randomness SHOULD be 809 cryptographically strong pseudorandom bytes not less than 16 bytes 810 (for cryptographically significant entropy) and not more than 64 811 bytes (the length of a SHA-256 input block) in length. The extra 812 randomness serves as a salt when computing the session keys 813 (Section 4.6). 815 +-------------/-+-------------/-+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+ 816 | length \ | 0x0e \ | extra randomness | 817 +-------------/-+-------------/-+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~/ 819 struct extraRandomnessKeyingOptionValue_t 820 { 821 uint_t extraRandomness[remainder()]; 822 } :remainder()*8; 824 4.5.2.3. Diffie-Hellman Group Select 826 This option is sent by the Initiator to specify which Diffie-Hellman 827 group to use for key agreement. The Initiator MUST send this option 828 when it advertises a static Diffie-Hellman public key in its 829 certificate, and MUST NOT send this option if it sends an ephemeral 830 Diffie-Hellman public key. This option MUST NOT be sent more than 831 once. 833 +-------------/-+-------------/-+-------------/-+ 834 | length \ | 0x1d \ | group ID \ | 835 +-------------/-+-------------/-+-------------/-+ 837 struct staticDHGroupSelectKeyingOptionValue_t 838 { 839 vlu_t groupID :variable*8; 840 } :variable*8; 842 4.5.2.4. HMAC Negotiation 844 This option is used to negotiate sending and receiving of an HMAC 845 field for packet verification. 847 |0 1 2 3 4 5 6 7| 848 +-------------/-+-------------/-+-+-+-+-+-+-+-+-+-------------/-+ 849 | \ | \ | |S|S|R| \ | 850 | length / | 0x1a / | rsv |N|O|E| hmacLength / | 851 | \ | \ | |D|R|Q| \ | 852 +-------------/-+-------------/-+-+-+-+-+-+-+-+-+-------------/-+ 854 struct hmacNegotiationKeyingOptionValue_t 855 { 856 uintn_t reserved :5; // rsv 857 bool_t willSendAlways :1; // SND 858 bool_t willSendOnRequest :1; // SOR 859 bool_t request :1; // REQ 860 vlu_t hmacLength :variable*8; 861 } :variable*8; 863 willSendAlways: If set, the sender will send an HMAC on packets in 864 this session. 866 willSendOnRequest: If set, the sender will send an HMAC on packets 867 in this session if the other end sets the request flag in its HMAC 868 Negotiation. 870 request: If set, the sender would very much like the receiver to 871 send an HMAC on its packets. If the other end doesn't send an 872 HMAC on its packets, the session can fail. 874 hmacLength: If the sender negotiates to send an HMAC on its packets, 875 the HMAC field will be this many bytes long. This value MUST be 876 between 4 and 32 inclusive, or 0 if and only if willSendAlways and 877 willSendOnRequest are clear. 879 The handshake operational semantics for this option are described in 880 Section 4.6.4. 882 4.5.2.5. Session Sequence Number Negotiation 884 This option is used to negotiate sending and receiving of the Session 885 Sequence Number field for packet verification. 887 |0 1 2 3 4 5 6 7| 888 +-------------/-+-------------/-+-+-+-+-+-+-+-+-+ 889 | \ | \ | |S|S|R| 890 | length / | 0x1e / | rsv |N|O|E| 891 | \ | \ | |D|R|Q| 892 +-------------/-+-------------/-+-+-+-+-+-+-+-+-+ 894 struct sseqNegotiationKeyingOptionValue_t 895 { 896 uintn_t reserved :5; // rsv 897 bool_t willSendAlways :1; // SND 898 bool_t willSendOnRequest :1; // SOR 899 bool_t request :1; // REQ 900 } :8; 902 willSendAlways: If set, the sender will send a session sequence 903 number in packets in this session. 905 willSendOnRequest: If set, the sender will send a session sequence 906 number in packets in this session if the other end sets the 907 request flag in its Session Sequence Number Negotiation. 909 request: If set, the sender would very much like the receiver to 910 send a session sequence number in its packets. If the other end 911 doesn't send a session sequence number in its packets, the session 912 can fail. 914 The handshake operational semantics for this option are described in 915 Section 4.6.6. 917 4.6. Session Key Computation 919 This section describes how to compute the cryptographic keys and 920 other settings for packet encryption and verification. 922 The Session Key Near Component (SKNC) means the keying component sent 923 by the near end of the session; that is, it is the Session Key 924 Initiator Component at the Initiator, and the Session Key Responder 925 Component at the Responder. 927 The Session Key Far Component (SKFC) means the keying component sent 928 by the far end of the session; that is, it is the Session Key 929 Responder Component at the Initiator, and the Session Key Initiator 930 Component at the Responder. 932 4.6.1. Public Key Selection 934 This section enumerates the public key selection methods for all 935 possible combinations of static or ephemeral public key modes for 936 each endpoint according to their certificate options (Section 4.3.3). 938 4.6.1.1. Initiator and Responder Ephemeral 940 The Initiator and Responder list one or more Supported Ephemeral 941 Diffie-Hellman Group options (Section 4.3.3.4) in their certificates. 942 The Initiator sends exactly one Ephemeral Diffie-Hellman Public Key 943 option (Section 4.5.2.1) in its Session Key Initiator Component, 944 which selects one group from among those supported by the Responder 945 and Initiator. Responder sends exactly one Ephemeral Diffie-Hellman 946 Public Key option in its Session Key Responder Component, in the same 947 group as indicated by the Initiator. 949 4.6.1.2. Initiator Ephemeral and Responder Static 951 The Responder lists one or more Static Diffie-Hellman Public Key 952 options (Section 4.3.3.5) in its certificate. The Initiator lists 953 one or more Supported Ephemeral Diffie-Hellman Group options in its 954 certificate. The Initiator sends exactly one Ephemeral Diffie- 955 Hellman Public Key option in its Session Key Initiator Component, 956 which selects one group from among those supported by the Responder 957 and Initiator and the corresponding public key for the Responder. 958 Responder uses its public key from the indicated group, and sends 959 only an Extra Randomness option (Section 4.5.2.2) in its Session Key 960 Responder Component to salt the session keys. 962 4.6.1.3. Initiator Static and Responder Ephemeral 964 The Responder lists one or more Supported Ephemeral Diffie-Hellman 965 Group options in its certificate. The Initiator lists one or more 966 Static Diffie-Hellman Public Key options in its certificate. The 967 Initiator sends exactly one Diffie-Hellman Group Select option 968 (Section 4.5.2.3) in its Session Key Initiator Component, which 969 selects one group from among those supported by the Responder and 970 Initiator and the corresponding public key for the Initiator, plus an 971 Extra Randomness option to salt the session keys. The Responder 972 sends an Ephemeral Diffie-Hellman Public Key option in its Session 973 Key Responder Component in the same group as indicated by the 974 Initiator. 976 4.6.1.4. Initiator and Responder Static 978 The Initiator and Responder each list one or more Static Diffie- 979 Hellman Public Key options in their certificates. The Initiator 980 sends exactly one Diffie-Hellman Group Select option in its Session 981 Key Initiator Component, which selects one group and corresponding 982 public keys from among those supported by the Responder and 983 Initiator, and an Extra Randomness option to salt the session keys. 984 The Responder sends an Extra Randomness option in its Session Key 985 Responder Component to add its own salt to the session keys. 987 4.6.2. Diffie-Hellman Shared Secret 989 To be acceptable, a Diffie-Hellman public key MUST have all of the 990 following properties: 992 o Be at least 16777216 (2^24); 994 o Be at most the group's prime modulus minus 16777216; 996 o Have at least 16 "1" bits; 998 o Have at least 16 "0" bits, not including leading zeros. 1000 An endpoint MUST NOT complete to an S_OPEN session with a far 1001 endpoint using a public key that is not acceptable according to these 1002 criteria. 1004 Once the group and corresponding public key of the far end is 1005 determined, the far end's public key and the near end's private key 1006 are combined according to Diffie-Hellman [DH] to compute the Diffie- 1007 Hellman Shared Secret, an integer. 1009 In the following sections, DH_SECRET means the Diffie-Hellman Shared 1010 Secret encoded as a byte-aligned unsigned integer in network byte 1011 order with no leading zero bytes. For example, if the shared secret 1012 is 4886718345, DH_SECRET would be the five bytes: 1014 Hex: 01 23 45 67 89 1016 4.6.3. Packet Encrypt/Decrypt Keys 1018 Packets are encrypted using a symmetric cipher, such as the Advanced 1019 Encryption Standard [AES]. Distinct keys are used for sending and 1020 receiving packets. Each end's sending (encrypt) key is the other 1021 end's receiving (decrypt) key. 1023 The raw keys computed in this section for encryption and decryption 1024 are transformed in a manner specific to the cipher with which they 1025 are to be used. In this profile AES-128 is the only currently 1026 defined cipher. For this cipher, the first 128 bits (16 bytes) of 1027 the 256-bit output of the calculation are taken to be the AES-128 1028 key. 1030 Set ENCRYPT_KEY = HMAC-SHA256(DH_SECRET, HMAC-SHA256(SKFC, SKNC)); 1032 Set DECRYPT_KEY = HMAC-SHA256(DH_SECRET, HMAC-SHA256(SKNC, SKFC)); 1034 The full 256 bits of ENCRYPT_KEY and DECRYPT_KEY are used in the 1035 computations in the following sections. 1037 4.6.4. Packet HMAC Send/Receive Keys 1039 Packets can be verified that they were not corrupted or modified by 1040 appending a message authentication code (HMAC) to the packet. 1041 Whether to use an HMAC or a simple checksum is determined during the 1042 initial keying phase using the HMAC Negotiation option 1043 (Section 4.5.2.4). Distinct HMAC keys are used for sending and 1044 receiving packets. Each end's sending key is the other end's 1045 receiving key, and vice versa. 1047 Set HMAC_SEND_KEY = HMAC_SHA256(DH_SECRET, ENCRYPT_KEY); 1049 Set HMAC_RECV_KEY = HMAC_SHA256(DH_SECRET, DECRYPT_KEY); 1051 If an endpoint sets the willSendAlways flag in its HMAC Negotiation 1052 option, then it MUST send an HMAC on packets it sends with this 1053 session key. 1055 If an endpoint's willSendAlways flag is clear but its 1056 willSendOnRequest flag is set, then it MUST send an HMAC on packets 1057 it sends with this session key if and only if the other endpoint's 1058 request flag is set. 1060 If a sending endpoint's willSendAlways and willSendOnRequest flags 1061 are clear, then the receiving endpoint SHOULD reject that keying 1062 component if the receiving endpoint is configured to require the 1063 sending endpoint to send HMAC. 1065 If HMAC is negotiated to be used, the corresponding hmacLength MUST 1066 be between 4 and 32 inclusive. 1068 If HMAC is negotiated to not be used, a simple checksum is used for 1069 packet verification. 1071 The Default Session Key uses the simple checksum and does not use 1072 HMAC. 1074 4.6.5. Session Nonces 1076 Session nonces are per-session, cryptographically strong secret 1077 values known only to the two endpoints of the session. They can be 1078 used for application-layer cryptographic challenges (such as signing 1079 or password verification). These nonces are a convenience being pre- 1080 shared and pre-agreed-upon in a secure manner during the initial 1081 keying handshake. 1083 Each end's near nonce is the other end's far nonce, and vice versa. 1085 Set NEAR_NONCE = HMAC_SHA256(DH_SECRET, SKNC); 1087 Set FAR_NONCE = HMAC_SHA256(DH_SECRET, SKFC); 1089 4.6.6. Session Sequence Number 1091 Packets can be verified that they were not duplicated in the network 1092 by using an optional Session Sequence Number inside the encrypted 1093 packet. The session sequence number is a monotonically increasing 1094 unbounded integer and does not wrap. Session sequence numbers SHOULD 1095 start at zero and SHOULD increment by one for each packet sent using 1096 that session key. Implementations MUST handle session sequence 1097 numbers with no less than 64 bits of range. 1099 If an endpoint's willSendAlways flag in its Session Sequence Number 1100 Negotiation option (Section 4.5.2.5) is set, then it MUST send a 1101 session sequence number in packets it sends with this session key. 1103 If an endpoint's willSendAlways flag is clear but its 1104 willSendOnRequest flag is set, then it MUST send a session sequence 1105 number on packets it sends with this session key if and only if the 1106 other endpoint's request flag is set. 1108 If a sending endpoint's willSendAlways and willSendOnRequest flags 1109 are clear, then the receiving endpoint SHOULD reject that keying 1110 component if the receiving endpoint is configured to require the 1111 sending endpoint to send session sequence numbers. 1113 The Default Session key does not use session sequence numbers. 1115 4.7. Packet Encryption 1117 This section describes the concrete syntax and operational semantics 1118 of RTMFP packet encryption for this Cryptography Profile. 1120 4.7.1. Cipher 1122 This profile defines AES-128 [AES] in Cipher Block Chaining (CBC) 1123 [CBC] mode as the only cipher. Extensions to this profile can 1124 specify and negotiate additional ciphers and modes by defining 1125 certificate and keying component options and associated semantics. 1127 For AES-128-CBC, the initialization vector (IV) for each packet is 16 1128 zero bytes. The IV is not included in the packet. 1130 4.7.2. Format 1132 The Encrypted Packet is the encryptedPacket field of an RTMFP 1133 Multiplex packet (Section 2.2.2 of RFC 7016); that is, the portion of 1134 the multiplex packet following the scrambled session ID. The 1135 Encrypted Packet has the following format: 1137 +----------------+ +----------------+~~~~~~~~~~~~~~~~~~~~~~~+ 1138 | CBC Block 1 | ... | CBC Block N | truncatedHMAC | 1139 +----------------+ +----------------+~~~~~~~~~~~~~~~~~~~~~~~+ 1140 ^ ^ ^ 1141 | Zero or more AES-128 chained | hmacLength bytes long | 1142 +-------- cipher blocks -----------+--- (may be zero) ---+ 1144 struct flashProfileEncryptedPacket_t 1145 { 1146 if(HMAC is being used) 1147 hmacLength = negotiated length; 1148 else 1149 hmacLength = 0; 1151 struct 1152 { 1153 iv[16 bytes] = { 0 }; 1154 blockCount = 0; 1155 while((remainder() > hmacLength) && (remainder() >= 16)) 1156 { 1157 uint8_t cbcBlock[16]; 1158 blockCount++; 1159 } 1160 } chainedCipherBlocks :variable*16*8; 1162 if(HMAC is being used) 1163 { 1164 if(remainder() == hmacLength) 1165 uint8_t truncatedHMAC[hmacLength]; 1166 else 1167 packetVerificationFailed(); 1168 } 1169 else if(remainder() > 0) 1170 packetVerificationFailed(); 1171 } :encryptedPacket.length*8; 1173 cbcBlock: The next AES-128-CBC block. 1175 chainedCipherBlocks: The concatenation of every cipher block in the 1176 packet, over which the HMAC is computed. 1178 truncatedHMAC: If HMAC was negotiated to be used (Section 4.5.2.4), 1179 this field is the first negotiated hmacLength bytes of the HMAC of 1180 the chainedCipherBlocks. 1182 The plaintext data before encryption or after decryption has the 1183 following format: 1185 0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7 1186 +~~~~~~~~~~~~~/~+ 1187 | SSEQ (opt.) \ | 1188 +~~~~~~~~~~~~~/~+ 1189 +~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+ 1190 | Checksum (opt.) | 1191 +~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+ 1192 +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+ 1193 | Plain RTMFP Packet | 1194 +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~/ 1196 struct flashProfilePlainPacket_t 1197 { 1198 if(session sequence numbers being used) 1199 vlu_t sessionSequenceNumber :variable*8; // SSEQ 1200 if(HMAC not being used) 1201 uint16_t checksum; 1202 packet_t plainRTMFPPacket :variable*8; 1203 } :chainedCipherBlocks.blockCount*16*8; 1205 sessionSequenceNumber: If session sequence numbers were negotiated 1206 to be used (Section 4.6.6), this field is present and is the VLU 1207 session sequence number of this packet. 1209 checksum: If HMAC was not negotiated to be used, this field is 1210 present and is the simple checksum (Section 4.7.3.1) of the 1211 remaining bytes of this structure. 1213 plainRTMFPPacket: The (plain, unencrypted) RTMFP Packet 1214 (Section 2.2.4 of RFC 7016) plus any necessary padding. 1216 When assembling this structure and prior to calculating the checksum 1217 (if present), if the structure's total length is not an integer 1218 multiple of 16 bytes (the AES cipher block size), pad the end of 1219 plainRTMFPPacket with as many bytes having value 0xff as are needed 1220 to bring the structure's total length to an integer multiple of 16 1221 bytes. The receiver's RTMFP Packet parser (Section 2.2.4 of RFC 1222 7016) will consume this padding. 1224 4.7.3. Verification 1226 In RTMFP, the Cryptography Profile is responsible for packet 1227 verification. In this profile, packets are verified with an HMAC or 1228 a simple checksum, depending on the configuration of the endpoints, 1229 and optionally verified against replay or duplication using session 1230 sequence numbers. The simple checksum is inside the encrypted 1231 packet, so it becomes essentially a 16-bit cryptographic checksum. 1233 4.7.3.1. Simple Checksum 1235 The simple checksum is the 16 bit ones' complement of the 16 bit 1236 ones' complement sum of all 16 bit (2 bytes in network byte order) 1237 words to be checked. If there are an odd number of bytes to be 1238 checked, then for purposes of this checksum, treat the last byte as 1239 the lower 8 bits of a 16 bit word whose upper 8 bits are 0. This is 1240 also known as the "Internet Checksum" [RFC1071]. 1242 When present, the checksum is calculated over all bytes of the 1243 plaintext packet starting after the checksum field through the end of 1244 the plain packet. It cannot be calculated until the plain packet is 1245 padded, if necessary, to bring its length to an integer multiple of 1246 16 bytes (the AES cipher block size). The session sequence number 1247 field, if present, and the checksum field itself are not included in 1248 the checksum. 1250 On receiving a packet being verified with a checksum: calculate the 1251 checksum over all the bytes of the plaintext packet following the 1252 checksum field, and compare the checksum to the value in the checksum 1253 field. If they match, the packet verifies; if they do not match, the 1254 packet is corrupt and MUST be discarded as though it was never 1255 received. 1257 4.7.3.2. HMAC 1259 When present, the HMAC field is the last hmacLength bytes of the 1260 packet and is calculated over all of the encrypted cipher blocks of 1261 the packet preceding the HMAC field. The value of the HMAC field is 1262 the first hmacLength bytes of the HMAC-SHA256 of the checked data, 1263 using the computed HMAC keys (Section 4.6.4) and negotiated 1264 hmacLength (Section 4.5.2.4). Note each endpoint independently 1265 specifies the length of the HMAC it will send via its hmacLength 1266 field. 1268 When an endpoint has negotiated to send an HMAC, it encrypts the data 1269 blocks, then computes the HMAC over the encrypted data blocks using 1270 its HMAC_SEND_KEY, and appends the first hmacLength bytes of that 1271 hash after the final encrypted data block. 1273 When an endpoint has negotiated to receive an HMAC, the endpoint 1274 computes the HMAC over the encrypted data blocks using its 1275 HMAC_RECV_KEY, and then compares the first receive hmacLength bytes 1276 of the computed HMAC to the HMAC field in the packet. If they are 1277 identical, the packet verifies; if they are not identical, the packet 1278 is corrupt and MUST be discarded as though it was never received. 1280 HMAC and simple checksum verification are mutually exclusive. 1282 4.7.3.3. Session Sequence Number 1284 Session Sequence Numbers are used to detect and reject a packet that 1285 was duplicated in the network or replayed by an attacker, and to 1286 ensure the first chained cipher block of every packet is unique, in 1287 lieu of a full-block initialization vector. Sequence numbers start 1288 at zero, increase by one for each packet sent, do not wrap and do not 1289 repeat. 1291 When session sequence numbers are negotiated to be used, the receiver 1292 MUST allow for packets to be reordered in the network by up to at 1293 least 32 sequence numbers; note, however, that reordering by more 1294 than three packets can trigger loss detection and retransmission by 1295 negative acknowledgement, just as with TCP, and is therefore not 1296 likely to occur in the real Internet. 1298 [RFC4302], [RFC4303] and [RFC6479] describe Anti-Replay Window 1299 methods that can be employed to detect duplicate sequence numbers. 1300 Other methods are possible. 1302 Any packet received having a session sequence number that was already 1303 seen in that session, either directly or by being less than the 1304 lowest sequence number in the anti-replay window, is a duplicate and 1305 MUST be discarded as though never received. 1307 5. Flash Communication 1309 The Flash platform uses Real Time Messaging Protocol [RTMP] messages 1310 for media streaming and communication. This section describes how to 1311 transport RTMP messages over RTMFP flows, and additional messages and 1312 semantics unique to this transport. 1314 5.1. RTMP Messages 1316 An RTMP message comprises a virtual header and a payload. The 1317 virtual header comprises a Message Type, a Payload Length, a 1318 Timestamp, and a Stream ID. The format of the payload is dependent 1319 on the type of message. 1321 An RTMP message is mapped onto a lower transport layer, such as RTMP 1322 Chunk Stream [RTMP] or RTMFP. RTMP messages were initially designed 1323 along with, and for transport on, RTMP Chunk Stream. This design 1324 constrains the possible values of RTMP message header fields. In 1325 particular: 1327 Message Type is 8 bits wide, and is therefore constrained to 1328 values from 0 to 255 inclusive; 1329 Payload Length is 24 bits wide, so messages can be at most 1330 16777215 bytes long; 1332 Timestamp is 32 bits wide, so timestamps range from 0 to 1333 4294967295 and wrap around; 1335 Stream ID is 24 bits wide, and is therefore constrained to values 1336 from 0 to 16777215 inclusive. 1338 RTMP Chunk Stream Protocol Control messages (message types 1, 2, 3, 1339 5, and 6) are not used when transporting RTMP messages in RTMFP 1340 flows. Messages of those types SHOULD NOT be sent and MUST be 1341 ignored. 1343 5.1.1. Flow Metadata 1345 All messages in RTMFP are transported in flows. In this profile, an 1346 RTMFP flow for RTMP messages carries the messages for exactly one 1347 RTMP Stream ID. Multiple flows can carry messages for the same 1348 Stream ID; for example, the video and audio messages of a stream 1349 could be sent on separate flows, allowing the audio to be given 1350 higher transmission priority. 1352 The User Metadata for flows in this profile begins with a distinct 1353 signature to distinguish among different kinds of flows. The User 1354 Metadata for a flow used for RTMP messages begins with the two- 1355 character signature "TC". 1357 The Stream ID is encoded in the flow's User Metadata so that it 1358 doesn't need to be sent with each message. 1360 The sender can have a priori knowledge about the kind of media it 1361 intends to send on a flow and its intended use, and can give the 1362 receiver a hint as to whether messages should be delivered as soon as 1363 possible or in their original queuing order. For example, the sender 1364 might be sending real-time, delay-sensitive audio messages on a flow, 1365 and hint that the receiver should take delivery of the messages on 1366 that flow as soon as they arrive in the network, to reduce the end- 1367 to-end latency of the audio. 1369 The receiver can choose to take delivery of messages on flows as soon 1370 as they arrive in the network, or in the messages' original queuing 1371 order. A receiver that chooses to take delivery of messages as soon 1372 as they arrive in the network MUST be prepared for the messages to 1373 arrive out-of-order. For example, a receiver may choose not to 1374 render a newly received audio message having a timestamp earlier than 1375 the most recently rendered audio timestamp. 1377 The sender can choose to abandon a message that it has queued in a 1378 flow before the message has been delivered to the receiver. For 1379 example, the sender may abandon a real-time, delay-sensitive audio 1380 message that has not been delivered within one second, to avoid 1381 spending transmission resources on stale media that is no longer 1382 relevant. Note: A gap will cause a delay at the receiver of at least 1383 one round trip time if the receiver is taking delivery of messages in 1384 original queuing order. 1386 0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7 1387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+~~~~~~~~~~~~~/~+ 1388 | | | |S|r|R| \ | 1389 | 0x54 'T' | 0x43 'C' | rsv |I|s|X| streamID / | 1390 | | | |D|v|I| \ | 1391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+~~~~~~~~~~~~~/~+ 1393 struct RTMPMetadata_t 1394 { 1395 uint8_t signature[2] == { 'T', 'C' }; 1396 uintn_t reserved1 :5; // rsv 1397 bool_t streamIDPresent :1; // SID 1398 uintn_t reserved2 :1; // rsv 1399 uintn_t receiveIntent :1; // RXI 1400 // 0: original queuing order, 1: network arrival order 1401 if(streamIDPresent) 1402 vlu_t streamID :variable*8; 1403 } :variable*8; 1405 signature: Metadata signature for RTMP message flows, being the two 1406 UTF-8 coded characters "TC". 1408 streamIDPresent: A boolean flag indicating whether the streamID 1409 field is present. In this profile, this flag MUST be set. 1411 receiveIntent: A hint by the sender as to the best order in which to 1412 take delivery of messages from the flow. A value of zero 1413 indicates a hint that the flow's messages should be received in 1414 the order they were originally queued by the sender (that is, in 1415 ascending sequence number order); a value of one indicates a hint 1416 that the flow's messages should be received in the order they 1417 arrive in the network, even if there are sequence number gaps or 1418 reordering. Network arrival order is typically hinted for live, 1419 delay-sensitive flows, such as for audio media. To take delivery 1420 of a message as soon as it arrives in the network: receive it from 1421 the receiving flow's RECV_BUFFER as soon as it becomes complete 1422 (Section 3.6.3.3 of RFC 7016), and remove it from the RECV_BUFFER. 1423 Section 3.6.3.3 of RFC 7016 describes how to take delivery of 1424 messages in original queuing order. 1426 streamID: If the streamIDPresent flag is set, this field is present 1427 and is the RTMP stream ID to which the messages in this flow 1428 belong. In this profile, this field MUST be present. 1430 A receiver SHOULD reject an RTMP message flow if its streamIDPresent 1431 flag is clear. This profile doesn't define a stream mapping for this 1432 case. 1434 Derived or composed profiles can define additional flow types and 1435 corresponding metadata signatures. A receiver SHOULD reject a flow 1436 having an unrecognized metadata signature. 1438 5.1.2. Message Mapping 1440 This section describes the format of an RTMP message (Section 5.1) in 1441 an RTMFP flow. 1443 0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7 1444 +-+-+-+-+-+-+-+-+ 1445 | messageType | 1446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1447 | timestamp | 1448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1449 | messagePayload | 1450 +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~/ 1452 struct RTMPMessage_t 1453 { 1454 uint8_t messageType; 1455 uint32_t timestamp; 1456 uint8_t messagePayload[remainder()]; 1457 } :flowMessageLength*8; 1459 messageType: The RTMP Message Type; 1461 timestamp: The RTMP Timestamp, in network byte order; 1463 messagePayload: The payload of the RTMP message; 1465 payload length: The RTMP message payload length is inferred from the 1466 length of the RTMFP message; 1468 Stream ID: The Stream ID for this message is taken from the metadata 1469 of the flow on which this message was received. 1471 5.2. Flow Synchronization 1473 RTMFP flows are independent, and have no inter-flow ordering 1474 guarantee. RTMP was designed for transport over a single, reliable, 1475 strictly ordered byte stream. Some RTMP message semantics take 1476 advantage of this ordering; for example, a Stream EOF User Control 1477 event must not be processed until after all media messages for the 1478 corresponding stream have been received. Flow Synchronization 1479 messages provide a barrier to align message delivery across flows 1480 when required by RTMP semantics. 1482 A Flow Synchronization message is coded as a User Control event 1483 message (Type 4) having Event Type 34. Message timestamps are 1484 ignored and MAY be set to 0. 1486 0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7 1487 +-+-+-+-+-+-+-+-+ 1488 | 4 | 1489 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1490 | timestamp | 1491 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1492 | eventType = 34 | 1493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1494 | syncID | 1495 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1496 | count | 1497 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1499 struct flowSyncUserControlMessagePayload_t 1500 { 1501 uint16_t eventType = 34; 1502 uint32_t syncID; 1503 uint32_t count; 1504 } :10*8; 1506 eventType: The RTMP User Control Message Event Type. Flow 1507 Synchronization messages have type 34 (0x22); 1509 syncID: The identifier for this barrier; 1511 count: The number of flows being synchronized by syncID. This field 1512 MUST be at least 1 and SHOULD be at least 2. 1514 On receipt of a Flow Synchronization message, a receiver SHOULD 1515 suspend receipt of further messages on that flow until count Flow 1516 Synchronization messages (including this one) with the same syncID 1517 have been received on flows in the same flow association tree. 1519 Example: Consider flows F1 and F2 in the same NetConnection carrying 1520 messages M, and let Sync(syncID,count) denote a Flow Synchronization 1521 message. 1523 | | 1524 F1: M1 M2 M4 Sync(8,2) | Sync(13,2).....| M7 1525 | | 1526 F2: M3 Sync(8,2).......| M5 Sync(13,2) | M6 1527 | | 1528 Barrier 8 Barrier 13 1530 Figure 2: Example Flow Synchronization Barriers 1532 Flow Synchronization messages form a delivery barrier to impart at 1533 least a partial message ordering across flows. In this example, 1534 message M5 comes after M1..4 and before M6..7; however, M3 could be 1535 delivered before or after any of M1, M2, or M4, and M6 could come 1536 before or after M7. 1538 Flow Synchronization can cause a priority inversion; therefore, it 1539 SHOULD NOT be used except when necessary to preserve RTMP ordering 1540 semantics. 1542 5.3. Client to Server Connection 1544 The client connects to a server. The connection comprises one main 1545 control flow in each direction from client to server and from server 1546 to client for NetConnection messages, and zero or more flows in each 1547 direction for NetStream media messages. NetStream flows may come and 1548 go naturally over time according to media transport needs. An 1549 exception on a NetConnection control sending flow indicates the 1550 closure by the other end of the NetConnection and all associated 1551 NetStreams. 1553 The client MUST NOT use the same client certificate for more than one 1554 server connection; that is, a client's peer ID MUST NOT be re-used. 1556 5.3.1. Connecting 1558 The client desires a connection to a server having an RTMFP URI, for 1559 example "rtmfp://server.example.com/app/instance". The client 1560 gathers one or more initial candidate addresses for the server named 1561 in the URI, for example by using the Domain Name System (DNS) 1562 [RFC1035]. The client creates an EPD having an Ancillary Data option 1563 (Section 4.4.2.2) encoding the URI. The client initiates an RTMFP 1564 session to the one or more candidate addresses using the EPD. 1566 When the session transitions to the S_OPEN state, the client opens a 1567 new flow in that session for Stream ID 0 and Receive Intent 0 1568 "original queuing order". This is the client's NetConnection main 1569 control flow. The client sends an RTMP "connect" command on the flow 1570 and waits for a response or exception. 1572 5.3.2. Server to Client Return Control Flow 1574 The server, on accepting the client's NetConnection control flow, and 1575 receiving and accepting the "connect" command, opens one or more 1576 return flows to the client having Stream ID 0 and associated to the 1577 control flow from the client. Flows for Stream ID 0 are the server's 1578 NetConnection control flows. The server sends a "_result" or 1579 "_error" transaction response for the client's connect command. 1581 When the client receives the first return flow from the server for 1582 Stream ID 0 and associated to the client's NetConnection control 1583 flow, the client assumes that flow is the canonical return 1584 NetConnection control flow from the server, to which all new client- 1585 to-server flows should be associated. 1587 On receipt of a "_result" transaction response on Stream ID 0 for the 1588 client's connect command, the connection is up. 1590 The client MAY open additional return control flows to the server on 1591 Stream ID 0, associated to the server's canonical NetConnection 1592 control flow. 1594 5.3.3. setPeerInfo Command 1596 The "setPeerInfo" command is sent by the client to the server over 1597 the NetConnection control flow to inform the server of candidate 1598 socket addresses through which the client might be reachable. This 1599 list SHOULD include all directly connected interface addresses and 1600 proxy addresses except as provided below. The list MAY be empty. 1601 The list need not include the address of the server, even if the 1602 server is to act as an introducer for the client. The list SHOULD 1603 NOT include link-local or loopback addresses. 1605 This command is sent as a regular RTMP NetConnection command; that 1606 is, as an RTMP Type 20 Command Message or an RTMP Type 17 Command 1607 Extended Message on Stream ID 0. A Type 20 Command Message SHOULD be 1608 used if the object encoding negotiated during the "connect" and 1609 "_result" handshake is AMF0 [AMF0], and a Type 17 Command Extended 1610 Message SHOULD be used if the negotiated object encoding is AMF3 1611 [AMF3]. 1613 Note: A Type 20 Command Message payload is a sequence of AMF objects 1614 encoded in AMF0. 1616 Note: A Type 17 Command Extended Message payload begins with a format 1617 selector byte, followed by a sequence of objects in a format-specific 1618 encoding. At the time of writing, only format 0 is defined; 1619 therefore, the format selector byte MUST be 0. Format 0 is a 1620 sequence of AMF objects, each encoded in AMF0 by default; AMF3 1621 encoding for an object can be selected by prefixing it with an 1622 "avmplus-object-marker" (0x11) as defined in [AMF0]. 1624 To complete the RTMFP NetConnection handshake, an RTMFP client MUST 1625 send a setPeerInfo command to the server after receiving a successful 1626 response to the "connect" command. 1628 ( 1629 "setPeerInfo", // AMF String, command name 1630 0.0, // AMF Number, transaction ID 1631 NULL, // AMF Null, no command object 1632 ... // zero or more AMF Strings, each an address 1633 ) 1635 Each listed socket address includes an IPv4 or IPv6 address in 1636 presentation format and a UDP port number in decimal, separated by a 1637 colon. Since the IPv6 address presentation format uses colons, IPv6 1638 addresses are enclosed in square brackets [RFC3986]. 1640 ( 1641 "setPeerInfo", 1642 0.0, 1643 NULL, 1644 "192.0.2.129:50001", 1645 "[2001:db8:1::2]:50002" 1646 ) 1648 Figure 3: Example setPeerInfo Command 1650 A server SHOULD assume that the client is behind a Network Address 1651 Translator (NAT) if and only if the observed far endpoint address of 1652 the session for the flow on which this command was received does not 1653 appear in the setPeerInfo address list. 1655 5.3.4. Set Keepalive Timers Command 1657 The server can advise the client to set or change the client's 1658 session keepalive timer periods for its connection to the server and 1659 for its P2P connections. The server MAY choose keepalive periods 1660 based on static configuration, application- or deployment-specific 1661 circumstances, whether the client appears to be behind a Network 1662 Address Translator (NAT), or for any other reason. 1664 The Set Keepalive Timers command is sent by the server to the client 1665 on Stream ID 0 as a User Control event message (Type 4) having Event 1666 Type 41. Message timestamps are ignored and MAY be set to 0. 1668 0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7 1669 +-+-+-+-+-+-+-+-+ 1670 | 4 | 1671 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1672 | timestamp | 1673 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1674 | eventType = 41 | 1675 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1676 | serverKeepalivePeriodMsec | 1677 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1678 | peerKeepalivePeriodMsec | 1679 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1681 struct setKeepaliveUserControlMessagePayload_t 1682 { 1683 uint16_t eventType = 41; 1684 uint32_t serverKeepalivePeriodMsec; 1685 uint32_t peerKeepalivePeriodMsec; 1686 } :10*8; 1688 eventType: The RTMP User Control Message Event Type. Set Keepalive 1689 Timers messages have type 41 (0x29); 1691 serverKeepalivePeriodMsec: The keepalive period, in milliseconds, 1692 that the client is advised to set on its RTMFP session with the 1693 server; 1695 peerKeepalivePeriodMsec: The keepalive period, in milliseconds, that 1696 the client is advised to use on its RTMFP sessions with any peer 1697 that is not the server. 1699 The client MUST define minimum values for these keepalive periods, 1700 below which it will not set them, regardless of the values in this 1701 message. The minimum keepalive timer periods SHOULD be at least five 1702 seconds. The client MAY define maximum values for these keepalive 1703 periods, above which it will not set them. 1705 On receipt of this message from the server, a client SHOULD set its 1706 RTMFP server and peer keepalive timer periods to the indicated values 1707 subject to the client's minimum and maximum values. The server MAY 1708 send this message more than once, particularly if conditions that it 1709 uses to determine the timer periods change. 1711 5.3.5. Additional Flows For Streams 1713 The client or server opens additional flows to the other side to 1714 carry messages for any stream. Additional flows are associated to 1715 the canonical NetConnection control flow from the other side. 1717 Client Server 1718 ------>--C2S-Control-Flow------------------------->--+ 1719 | 1720 +--<------------------------S2C-Control-Flow---<--+ 1721 | | 1722 | <------------------------S2C-Stream-Flow-1--<--+ 1723 | : | 1724 | <------------------------S2C-Stream-Flow-M--<--+ 1725 | 1726 +-->--C2S-Stream-Flow-1------------------------> 1727 | : 1728 +-->--C2S-Stream-Flow-N------------------------> 1730 Figure 4: Schematic Flow Association Tree for a NetConnection 1732 5.3.5.1. To Server 1734 Additional flows from the client to the server for stream messages 1735 are opened with the Stream ID for that stream, and associated in 1736 return to the server's canonical NetConnection control flow. 1738 The client MAY create as many flows as desired for any Stream ID 1739 (including Stream ID 0) at any time. 1741 5.3.5.2. From Server 1743 Additional flows from the server to the client for stream messages 1744 are opened with the Stream ID for that stream, and associated in 1745 return to the client's NetConnection control flow. 1747 The server MAY create as many flows as desired for any Stream ID 1748 (including Stream ID 0) at any time. 1750 5.3.5.3. Closing Stream Flows 1752 Either end MAY close a sending flow that is not for Stream ID 0 at 1753 any time with no semantic meaning for the stream. 1755 Either end MAY at any time reject a receiving flow that is not one of 1756 the other end's NetConnection control flows. No flow exception codes 1757 are defined by this profile, so the receiving end SHOULD use 1758 exception code 0 when rejecting the flow. The sending end, on 1759 notification of any exception for a stream flow, SHOULD NOT open a 1760 new flow to take the rejected flow's place for transport of messages 1761 for that stream. If an end rejects any flow for a stream, it SHOULD 1762 reject all the flows for that stream, otherwise Flow Synchronization 1763 messages (Section 5.2) that were in flight could be discarded and 1764 some flows might become or remain stuck in a suspended state. 1766 5.3.6. Closing the Connection 1768 The client or server can signal an orderly close of the connection by 1769 closing its NetConnection control sending flows and all stream 1770 sending flows. The other end, on receiving a close/complete 1771 notification for the canonical NetConnection control receiving flow, 1772 closes its sending flows. When both ends observe all receiving flows 1773 have closed and completed, the connection has cleanly terminated. 1775 Either end can abruptly terminate the connection by rejecting the 1776 NetConnection control receiving flows, or by closing the underlying 1777 RTMFP session. On notification of any exception on a NetConnection 1778 control sending flow, the end seeing the exception knows the other 1779 end has terminated abruptly, and can immediately close all sending 1780 and receiving flows for that connection. 1782 5.3.7. Example 1783 Client Server 1784 |IHello (EPD:anc=URI) | 1785 -+- |------------------------>| 1786 | | | 1787 | | RHello (RCert:anc)| 1788 RTMFP | |<------------------------| 1789 Session| | | 1790 Hand- | |IIKeying | 1791 shake | |------------------------>| 1792 | | | 1793 | | RIKeying| 1794 -+- |<------------------------| 1795 | | 1796 -+- |"connect" command | 1797 (Str.ID=0)|-CFlow-0---------------->| 1798 | | | 1799 | | "_result" response| 1800 RTMP | |<----------------SFlow-0-|(Str.ID=0, 1801 Connect| | | Assoc=CFlow-0) 1802 Hand- | |"setPeerInfo" command | 1803 shake | |-CFlow-0---------------->| 1804 -+- | | 1805 |"createStream" command | 1806 -+- |-CFlow-0---------------->| 1807 | | | 1808 | | "_result" (str.ID=5)| 1809 | |<----------------SFlow-0-| 1810 | | | 1811 | |"play" command | 1812 (Str.ID=5,|-CFlow-1---------------->| 1813 Assoc=SFlow-0)| | 1814 | | StreamBegin User Control| 1815 | |<----------------SFlow-1-|(Str.ID=5, 1816 | | | Assoc=CFlow-0) 1817 | | (RTMP stream events) | 1818 Streaming | |<----------------SFlow-1-| 1819 | | | 1820 | | Audio Data | 1821 | |<----------------SFlow-2-|(Str.ID=5, 1822 | | | Assoc=CFlow-0) 1823 | | Video Data | 1824 | |<----------------SFlow-3-|(Str.ID=5, 1825 | | : | Assoc=CFlow-0) 1826 | : | 1828 Figure 5: Example NetConnection Message Exchange 1830 5.4. Direct Peer to Peer Streams 1832 Clients can connect directly to other clients for peer-to-peer (P2P) 1833 streaming and data exchange. A client MAY have multiple separate P2P 1834 NetStreams with a peer in one RTMFP session, each a separate logical 1835 connection. P2P NetStreams are unidirectional, initiated by a 1836 subscriber (the side issuing the "play" command") to a publisher. 1837 The subscribing peer has a control flow to the publisher. The 1838 publisher has zero or more return flows to the subscriber, associated 1839 to the subscriber's control flow, for the stream media and data. 1841 5.4.1. Connecting 1843 A client desires to subscribe directly to a stream being published in 1844 P2P mode by a publishing peer. The client learns the peer ID of the 1845 publisher and the stream name through application-specific means. 1847 If the client does not already have an RTMFP session with that peer 1848 ID, it initiates a new session, creating an EPD containing a 1849 Fingerprint option (Section 4.4.2.3) for the publisher's peer ID and 1850 using the server session's DESTADDR as the initial candidate address 1851 for the session to the peer. The server acts as an Introducer 1852 (Section 3.5.1.6 of RFC 7016), using forward and redirect messages to 1853 help the client and the peer establish a session. 1855 When an S_OPEN session exists to the desired peer, the client creates 1856 a new independent flow to that peer. The flow MUST have a non-zero 1857 Stream ID. The client sends an RTMP "play" command over the flow, 1858 giving the name of the desired stream at the publisher. This flow is 1859 the subscriber's control flow. 1861 5.4.2. Return Flows for Stream 1863 The publisher, on accepting a new flow not indicating a return 1864 association with any of its sending flows and having a non-zero 1865 Stream ID, receives and processes the "play" command. If and when 1866 the request is acceptable to the publisher, it opens one or more 1867 return flows to the subscribing peer, associated to the subscriber's 1868 control flow and having the same Stream ID. The publisher sends a 1869 StreamBegin User Control message, appropriate RTMP status events, and 1870 the stream media over the one or more return flows. 1872 The subscriber uses the return association of the media flows to the 1873 subscriber control flow to determine the stream to which the media 1874 belongs. 1876 The publisher MAY open any number of media flows for the stream, and 1877 close them at any time. The opening and closing of media flows has 1878 no semantic meaning for the stream, except that the opening of at 1879 least one flow and the reception of at least one media message or a 1880 StreamBegin User Control message indicates that the publisher is 1881 publishing the requested stream to the subscriber. 1883 Subscriber Publisher 1884 ------>--Subscriber-Control-Flow------------------>--+ 1885 | 1886 <------------------Publisher-Stream-Flow-1--<--+ 1887 : | 1888 <------------------Publisher-Stream-Flow-N--<--+ 1890 Figure 6: Schematic Flow Association Tree for a P2P Direct Connection 1892 5.4.3. Closing the Connection 1894 Either end can close the stream by closing or rejecting the 1895 subscriber's control flow. The publisher SHOULD close and unpublish 1896 to the subscriber on receipt of a close/complete of the control flow. 1897 The subscriber SHOULD consider the stream closed on notification of 1898 any exception on the control flow. 1900 6. IANA Considerations 1902 This memo specifies option type code values for Certificate fields 1903 (Section 4.3.3), Endpoint Discriminator fields (Section 4.4.2), and 1904 Session Keying Component fields (Section 4.5.2), and specifies a flow 1905 metadata signature (Section 5.1.1). The type code values and 1906 signatures for this profile are assigned and maintained by Adobe, and 1907 therefore require no action from IANA. 1909 6.1. RTMFP URI Scheme Registration 1911 This memo describes use of an RTMFP URI scheme (Section 4.4.2.2, 1912 Section 5.3.1, Figure 5). This section requests registration of the 1913 "rtmfp" URI scheme by IANA. 1915 The syntax and semantics of this URI scheme are described using the 1916 Augmented Backus-Naur Form (ABNF) [RFC5234] rules from RFC 3986. 1918 URI scheme name: rtmfp 1920 Status: provisional 1922 URI scheme syntax: 1924 rtmfp-uri-scheme = "rtmfp:" 1925 / "rtmfp://" host [ ":" port ] path-abempty 1927 URI scheme semantics: The first form is used in the APIs of some 1928 implementations to indicate instantiation of an RTMFP client 1929 according to this memo, but without connecting to a server. Such 1930 an instantiation might be used for pure peer-to-peer 1931 communication. 1933 The second form provides location information for the server to 1934 which to connect, and optional additional information to pass to 1935 the server. The only operation for this URI form is to connect to 1936 a server (initial candidate address(es) for which are named by 1937 host and port) according to Section 5.3. The UDP port for initial 1938 candidate addresses, if not specified, is 1935. If the host is a 1939 reg-name, the initial candidate address set SHOULD comprise all 1940 IPv4 and IPv6 addresses to which reg-name resolves. The semantics 1941 of path-abempty are specific to the server. Connections are made 1942 using RTMFP as specified by this memo. 1944 Encoding considerations: The path-abempty component represents 1945 textual data consisting of characters from the Universal Character 1946 Set. This component SHOULD be encoded according to Section 2.5 of 1947 RFC 3986. 1949 Applications/protocols that use this URI scheme name: The Flash 1950 runtime (including Flash Player) from Adobe Systems Incorporated, 1951 communication servers such as Adobe Media Server, and 1952 interoperable clients and servers provided by other parties, using 1953 RTMFP according to this memo. 1955 Interoperability considerations: This scheme requires use of RTMFP 1956 as defined by RFC 7016 in the manner described by this memo. 1958 Security considerations: See Security Considerations (Section 7) in 1959 this memo. 1961 Contact: Michael Thornburgh, Adobe Systems Incorporated, 1962 . 1964 Author/Change controller: Michael Thornburgh, Adobe Systems 1965 Incorporated, . 1967 References: 1968 Thornburgh, M., "Adobe's Secure Real-Time Media Flow Protocol", 1969 RFC 7016, November 2013. 1971 This memo. 1973 7. Security Considerations 1975 Section 4 details the cryptographic aspects of this profile. 1977 This profile does not define or use a Public Key Infrastructure 1978 (PKI). Clients SHOULD use static Diffie-Hellman keys in their 1979 certificates (Section 4.3.3.5). Clients MUST create a new 1980 certificate with a distinct fingerprint for each new NetConnection 1981 (Section 5.3). These constraints make client identities ephemeral 1982 but unable to be forged. A man-in-the-middle cannot successfully 1983 interpose itself in a connection to a target client addressed by its 1984 fingerprint/peer ID if the target client uses a static Diffie-Hellman 1985 public key. 1987 Servers can have long-lived RTMFP instances, so they SHOULD use 1988 ephemeral Diffie-Hellman public keys for forward secrecy. This 1989 allows server peer IDs to be forged; however, clients do not connect 1990 to servers by peer ID, so this is irrelevant. 1992 When a client connects to a server, the client will accept the 1993 response of any endpoint claiming to be "a server". It is assumed 1994 that an attacker that can passively observe traffic on a network 1995 segment can also inject its own packets with any source or 1996 destination and any payload. An attacker can trick a client into 1997 connecting to a rogue server or man-in-the-middle, either by 1998 observing Initiator Hello packets from the client and responding 1999 earliest with a matching Responder Hello, or by using tricks such as 2000 DNS spoofing or poisoning to direct a client to connect directly to 2001 the rogue. A TCP-based transport would be vulnerable to similar 2002 attacks. Since there is no PKI, this profile gives no guarantee that 2003 the client has actually connected to the desired server, versus a 2004 rogue or man-in-the-middle. In circumstances where assurance is 2005 required that the connection is directly to the desired server, the 2006 client can use the Session Nonces (Section 4.6.5) to challenge the 2007 server, for example over a different channel having acceptable 2008 security properties (such as an HTTPS), to transitively establish the 2009 server's identity and verify that the end-to-end communication is 2010 private and authentic. 2012 When Session Sequence Numbers (Section 4.7.3.3) are not used, it is 2013 possible for an attacker to use traffic analysis techniques and 2014 record encrypted packets containing the start of a new flow, and 2015 later to replay those packets after the flow has closed, which can 2016 look to the receiver like a brand new flow. In circumstances where 2017 this can be detrimental, Session Sequence Numbers SHOULD be used. 2018 Replay of packets for existing flows is not detrimental as the 2019 receiver detects and discards duplicate flow sequence numbers, and 2020 flow sequence numbers do not wrap or otherwise repeat. 2022 Packet encryption uses CBC with the same (null) initialization vector 2023 for each packet. This can reveal to an observer whether two packets 2024 contain identical plaintext. However, the maximum-length RTMFP 2025 common header and User Data or Data Acknowledgement header, including 2026 flow sequence number, always fit within the first 16-byte cipher 2027 block, so each initial cipher block for most packets will already be 2028 unique even if timestamps are suppressed. Sending identical messages 2029 in a flow uses unique flow sequence numbers, so cipher blocks will be 2030 unique in this case. Keepalive pings and retransmission of lost data 2031 can result in identical cipher blocks; however, traffic analysis can 2032 also reveal likely keepalives or retransmissions, and retransmission 2033 only occurs as a result of observable network loss, so this is 2034 usually irrelevant. In circumstances where any identical cipher 2035 block is unacceptable, Session Sequence Numbers SHOULD be used as 2036 they guarantee each initial cipher block will be unique. 2038 Packet verification can use a 16-bit simple checksum 2039 (Section 4.7.3.1). The checksum is inside the encrypted packet, so 2040 for external packet modifications the checksum is equivalent to a 2041 16-bit cryptographic digest. In circumstances where this is 2042 insufficient, HMAC verification (Section 4.7.3.2) SHOULD be used. 2044 8. Acknowledgements 2046 Special thanks go to Glenn Eguchi, Matthew Kaufman, and Adam Lane for 2047 their contributions to the design of this profile. 2049 Thanks to Philipp Hancke, Kevin Igoe, Paul Kyzivat, and Milos 2050 Trboljevac for their detailed reviews of this memo. 2052 9. References 2054 9.1. Normative References 2056 [AES] United States of America, National Institute of Standards 2057 and Technology, "Advanced Encryption Standard", Federal 2058 Information Processing Standard (FIPS) 197, November 2001, 2059 . 2062 [AMF0] Adobe Systems Incorporated, "Action Message Format -- AMF 2063 0", December 2007, . 2065 [AMF3] Adobe Systems Incorporated, "Action Message Format -- AMF 2066 3", January 2013, . 2068 [CBC] Dworkin, M., "Recommendation for Block Cipher Modes of 2069 Operation", NIST Special Publication 800-38A, December 2070 2001, . 2073 [DH] Diffie, W. and M. Hellman, "New Directions in 2074 Cryptography", IEEE Transactions on Information Theory, V. 2075 IT-22, n. 6, June 1977. 2077 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 2078 Hashing for Message Authentication", RFC 2104, February 2079 1997. 2081 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2082 Requirement Levels", BCP 14, RFC 2119, March 1997. 2084 [RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) 2085 Diffie-Hellman groups for Internet Key Exchange (IKE)", 2086 RFC 3526, May 2003. 2088 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 2089 10646", STD 63, RFC 3629, November 2003. 2091 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 2092 Resource Identifier (URI): Generic Syntax", STD 66, RFC 2093 3986, January 2005. 2095 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 2096 Specifications: ABNF", STD 68, RFC 5234, January 2008. 2098 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, 2099 "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 2100 5996, September 2010. 2102 [RFC6234] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms 2103 (SHA and SHA-based HMAC and HKDF)", RFC 6234, May 2011. 2105 [RFC7016] Thornburgh, M., "Adobe's Secure Real-Time Media Flow 2106 Protocol", RFC 7016, November 2013. 2108 [RTMP] Adobe Systems Incorporated, "Real-Time Messaging Protocol 2109 (RTMP) specification", December 2012, 2110 . 2112 [SHA256] United States of America, National Institute of Standards 2113 and Technology, "Secure Hash Standard", Federal 2114 Information Processing Standard (FIPS) 180-2, August 2002, 2115 . 2118 9.2. Informative References 2120 [RFC1035] Mockapetris, P., "Domain names - implementation and 2121 specification", STD 13, RFC 1035, November 1987. 2123 [RFC1071] Braden, R., Borman, D., Partridge, C., and W. Plummer, 2124 "Computing the Internet checksum", RFC 1071, September 2125 1988. 2127 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 2128 2005. 2130 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 2131 4303, December 2005. 2133 [RFC6479] Zhang, X. and T. Tsou, "IPsec Anti-Replay Algorithm 2134 without Bit Shifting", RFC 6479, January 2012. 2136 Author's Address 2138 Michael C. Thornburgh 2139 Adobe Systems Incorporated 2140 345 Park Avenue 2141 San Jose, CA 95110-2704 2142 US 2144 Phone: +1 408 536 6000 2145 Email: mthornbu@adobe.com 2146 URI: http://www.adobe.com/