summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc7425.txt
diff options
context:
space:
mode:
authorThomas Voss <mail@thomasvoss.com> 2024-11-27 20:54:24 +0100
committerThomas Voss <mail@thomasvoss.com> 2024-11-27 20:54:24 +0100
commit4bfd864f10b68b71482b35c818559068ef8d5797 (patch)
treee3989f47a7994642eb325063d46e8f08ffa681dc /doc/rfc/rfc7425.txt
parentea76e11061bda059ae9f9ad130a9895cc85607db (diff)
doc: Add RFC documents
Diffstat (limited to 'doc/rfc/rfc7425.txt')
-rw-r--r--doc/rfc/rfc7425.txt2747
1 files changed, 2747 insertions, 0 deletions
diff --git a/doc/rfc/rfc7425.txt b/doc/rfc/rfc7425.txt
new file mode 100644
index 0000000..e988f67
--- /dev/null
+++ b/doc/rfc/rfc7425.txt
@@ -0,0 +1,2747 @@
+
+
+
+
+
+
+Independent Submission M. Thornburgh
+Request for Comments: 7425 Adobe
+Category: Informational December 2014
+ISSN: 2070-1721
+
+
+ Adobe's RTMFP Profile for Flash Communication
+
+Abstract
+
+ This memo describes how to use Adobe's Secure Real-Time Media Flow
+ Protocol (RTMFP) to transport the video, audio, and data messages of
+ Adobe Flash platform communications. Aspects of this application
+ profile include cryptographic methods and data formats, flow metadata
+ formats, and protocol details for client-server and peer-to-peer
+ communication.
+
+Status of This Memo
+
+ This document is not an Internet Standards Track specification; it is
+ published for informational purposes.
+
+ This is a contribution to the RFC Series, independently of any other
+ RFC stream. The RFC Editor has chosen to publish this document at
+ its discretion and makes no statement about its value for
+ implementation or deployment. Documents approved for publication by
+ the RFC Editor are not a candidate for any level of Internet
+ Standard; see Section 2 of RFC 5741.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ http://www.rfc-editor.org/info/rfc7425.
+
+Copyright Notice
+
+ Copyright (c) 2014 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+ This document is subject to BCP 78 and the IETF Trust's Legal
+ Provisions Relating to IETF Documents
+ (http://trustee.ietf.org/license-info) in effect on the date of
+ publication of this document. Please review these documents
+ carefully, as they describe your rights and restrictions with respect
+ to this document.
+
+ This document may not be modified, and derivative works of it may not
+ be created, except to format it for publication as an RFC or to
+ translate it into languages other than English.
+
+
+
+Thornburgh Informational [Page 1]
+
+RFC 7425 Adobe RTMFP for Flash Communication December 2014
+
+
+Table of Contents
+
+ 1. Introduction ....................................................3
+ 2. Terminology .....................................................4
+ 3. Common Syntax Elements ..........................................4
+ 4. Cryptography Profile ............................................5
+ 4.1. Default Session Key ........................................5
+ 4.2. Diffie-Hellman Groups ......................................6
+ 4.3. Certificates ...............................................6
+ 4.3.1. Format ..............................................6
+ 4.3.2. Fingerprint .........................................7
+ 4.3.3. Options .............................................7
+ 4.3.3.1. Hostname ...................................8
+ 4.3.3.2. Accepts Ancillary Data .....................8
+ 4.3.3.3. Extra Randomness ...........................8
+ 4.3.3.4. Supported Ephemeral Diffie-Hellman Group ...9
+ 4.3.3.5. Static Diffie-Hellman Public Key ...........9
+ 4.3.4. Authenticity .......................................10
+ 4.3.5. Signing and Verifying Messages .....................10
+ 4.3.5.1. Options ...................................11
+ 4.3.5.1.1. Simple Password ................11
+ 4.3.6. Glare Resolution ...................................13
+ 4.3.7. Session Override ...................................13
+ 4.4. Endpoint Discriminators ...................................13
+ 4.4.1. Format .............................................14
+ 4.4.2. Options ............................................14
+ 4.4.2.1. Required Hostname .........................15
+ 4.4.2.2. Ancillary Data ............................15
+ 4.4.2.3. Fingerprint ...............................16
+ 4.4.3. Certificate Selection ..............................16
+ 4.4.4. Canonical Endpoint Discriminator ...................17
+ 4.5. Session Keying Components .................................18
+ 4.5.1. Format .............................................19
+ 4.5.2. Options ............................................19
+ 4.5.2.1. Ephemeral Diffie-Hellman Public Key .......20
+ 4.5.2.2. Extra Randomness ..........................20
+ 4.5.2.3. Diffie-Hellman Group Select ...............21
+ 4.5.2.4. HMAC Negotiation ..........................21
+ 4.5.2.5. Session Sequence Number Negotiation .......22
+ 4.6. Session Key Computation ...................................23
+ 4.6.1. Public Key Selection ...............................23
+ 4.6.1.1. Initiator and Responder Ephemeral .........23
+ 4.6.1.2. Initiator Ephemeral and Responder Static ..23
+ 4.6.1.3. Initiator Static and Responder Ephemeral ..24
+ 4.6.1.4. Initiator and Responder Static ............24
+ 4.6.2. Diffie-Hellman Shared Secret .......................24
+ 4.6.3. Packet Encrypt/Decrypt Keys ........................25
+ 4.6.4. Packet HMAC Send/Receive Keys ......................25
+
+
+
+Thornburgh Informational [Page 2]
+
+RFC 7425 Adobe RTMFP for Flash Communication December 2014
+
+
+ 4.6.5. Session Nonces .....................................26
+ 4.6.6. Session Sequence Number ............................26
+ 4.7. Packet Encryption .........................................27
+ 4.7.1. Cipher .............................................27
+ 4.7.2. Format .............................................27
+ 4.7.3. Verification .......................................29
+ 4.7.3.1. Simple Checksum ...........................30
+ 4.7.3.2. HMAC ......................................30
+ 4.7.3.3. Session Sequence Number ...................31
+ 5. Flash Communication ............................................31
+ 5.1. RTMP Messages .............................................31
+ 5.1.1. Flow Metadata ......................................32
+ 5.1.2. Message Mapping ....................................34
+ 5.2. Flow Synchronization ......................................35
+ 5.3. Client-to-Server Connection ...............................36
+ 5.3.1. Connecting .........................................36
+ 5.3.2. Server-to-Client Return Control Flow ...............37
+ 5.3.3. setPeerInfo Command ................................37
+ 5.3.4. Set Keepalive Timers Command .......................39
+ 5.3.5. Additional Flows for Streams .......................40
+ 5.3.5.1. To Server .................................40
+ 5.3.5.2. From Server ...............................40
+ 5.3.5.3. Closing Stream Flows ......................41
+ 5.3.6. Closing the Connection .............................41
+ 5.3.7. Example ............................................42
+ 5.4. Direct Peer-to-Peer Streams ...............................43
+ 5.4.1. Connecting .........................................43
+ 5.4.2. Return Flows for Stream ............................43
+ 5.4.3. Closing the Connection .............................44
+ 6. IANA Considerations ............................................44
+ 6.1. RTMFP URI Scheme Registration .............................44
+ 7. Security Considerations ........................................46
+ 8. References .....................................................47
+ 8.1. Normative References ......................................47
+ 8.2. Informative References ....................................49
+ Acknowledgements ..................................................49
+ Author's Address ..................................................49
+
+1. Introduction
+
+ Adobe's Secure Real-Time Media Flow Protocol (RTMFP) [RFC7016] is a
+ general-purpose transport service for real-time media and bulk data
+ in IP networks, and it is suited to client-server and peer-to-peer
+ (P2P) communication. RTMFP provides a generalized framework for
+ securing its communications according to the needs of its
+ application.
+
+
+
+
+
+Thornburgh Informational [Page 3]
+
+RFC 7425 Adobe RTMFP for Flash Communication December 2014
+
+
+ The Flash platform comprises the Flash runtime (including Flash
+ Player) from Adobe Systems Incorporated, communication servers such
+ as Adobe Media Server, and interoperable clients and servers provided
+ by other parties.
+
+ Real-time streaming network communication for the Flash platform of
+ video, audio, and data typically uses Adobe's Real-Time Messaging
+ Protocol (RTMP) [RTMP] messages. RTMP messages were originally
+ designed to be transported over RTMP Chunk Stream in TCP [RTMP];
+ however, other transports (such as the one described in this memo)
+ are possible.
+
+ This memo specifies the syntax and semantics for transporting RTMP
+ messages over RTMFP, and it extends Flash communication semantics to
+ include direct P2P communication. This memo further specifies a
+ concrete Cryptography Profile for RTMFP tailored to the application
+ and cryptographic needs of Flash platform client-server and P2P
+ communications.
+
+ These protocols and profiles were developed by Adobe Systems
+ Incorporated and are not the product of an IETF activity.
+
+2. Terminology
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
+ "OPTIONAL" in this document are to be interpreted as described in
+ [RFC2119].
+
+ "HMAC" means the Keyed-Hash Message Authentication Code (HMAC)
+ algorithm [RFC2104].
+
+ "HMAC-SHA256" means HMAC using the SHA-256 Secure Hash Algorithm
+ [SHA256] [RFC6234].
+
+ "HMAC-SHA256(K, M)" means the calculation of the HMAC-SHA256 of
+ message M using key K.
+
+3. Common Syntax Elements
+
+ Definitions of types and structures in this specification use
+ traditional text diagrams paired with procedural descriptions using a
+ C-like syntax. The C-like procedural descriptions SHALL be construed
+ as definitive.
+
+
+
+
+
+
+
+Thornburgh Informational [Page 4]
+
+RFC 7425 Adobe RTMFP for Flash Communication December 2014
+
+
+ Structures are packed to take only as many bytes as explicitly
+ indicated. There is no 32-bit alignment constraint, and fields are
+ not padded for alignment unless explicitly indicated or described.
+ Text diagrams may include a bit ruler across the top; this is a
+ convenience for counting bits in individual fields and does not
+ necessarily imply field alignment on a multiple of the ruler width.
+
+ Unless specified otherwise, reserved fields SHOULD be set to 0 by a
+ sender and MUST be ignored by a receiver.
+
+ The procedural syntax of this specification defines correct and
+ error-free encoded inputs to a parser. The procedural syntax does
+ not describe a fully featured parser, including error detection and
+ handling. Implementations MUST include means to identify error
+ circumstances, including truncations causing elementary or composed
+ types not to fit inside containing structures, fields, or elements.
+ Unless specified otherwise, an error circumstance SHALL abort the
+ parsing and processing of an element and its enclosing elements.
+
+ This memo uses the elementary and composed types described in
+ Section 2.1 of RFC 7016. The definitions of that section are
+ incorporated by reference as though fully set forth here.
+
+4. Cryptography Profile
+
+ RTMFP defines a general security framework but delegates specifics,
+ such as packet encryption ciphers and key agreement algorithms, to an
+ application-defined Cryptography Profile.
+
+ This section defines the RTMFP Cryptography Profile for Flash
+ platform communication.
+
+4.1. Default Session Key
+
+ RTMFP uses a Default Session Key and associated default cipher
+ configuration during session startup handshaking, where session-
+ specific keys and ciphers are negotiated.
+
+ The default cipher is the Advanced Encryption Standard [AES] with
+ 128-bit keys operating in Cipher Block Chaining [CBC] mode, as
+ described in Section 4.7.1. The Default Session Key is the 16 bytes
+ of the string "Adobe Systems 02" encoded in UTF-8 [RFC3629]:
+
+ Hex: 41 64 6F 62 65 20 53 79 73 74 65 6D 73 20 30 32
+
+ The Default Session Key uses checksum mode for packet verification
+ and does not use session sequence numbers (Section 4.7.3).
+
+
+
+
+Thornburgh Informational [Page 5]
+
+RFC 7425 Adobe RTMFP for Flash Communication December 2014
+
+
+4.2. Diffie-Hellman Groups
+
+ Implementations conforming to this profile MUST support Diffie-
+ Hellman [DH] modular exponentiation (MODP) group 2 (1024 bits) as
+ defined in [RFC7296], and SHOULD support Diffie-Hellman MODP group 5
+ (1536 bits) and group 14 (2048 bits) as defined in [RFC3526].
+ Implementations MAY support additional groups.
+
+4.3. Certificates
+
+ This section defines the certificate format for this Cryptography
+ Profile, and the mapping to the abstract properties and semantics for
+ RTMFP endpoint identities.
+
+4.3.1. Format
+
+ A certificate in this profile is encoded as a sequence of zero or
+ more RTMFP Options and Markers (Section 2.1.3 of RFC 7016). The
+ first marker (if any) in the certificate separates the canonical
+ section of the certificate from the remainder. Some options are
+ ignored if they occur outside of the canonical section (that is,
+ after the first marker).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Thornburgh Informational [Page 6]
+
+RFC 7425 Adobe RTMFP for Flash Communication December 2014
+
+
+ +~~~/~~~/~~~+ +~~~/~~~/~~~+~~~~~+~~~/~~~/~~~+ +~~~/~~~/~~~+
+ | L \ T \ V |...| L \ T \ V | 0 | L \ T \ V |...| L \ T \ V |
+ +~~~/~~~/~~~+ +~~~/~~~/~~~+~~~~~+~~~/~~~/~~~+ +~~~/~~~/~~~+
+ ^ ^ ^ ^ ^
+ | Zero or more non-empty | | | Zero or more Options |
+ | Options | | +------ or Markers -------+
+ | | |
+ +--- Canonical Section ---+ +---- First Marker
+ (if present)
+
+ struct certificate_t
+ {
+ canonicalStart = remainder();
+ canonicalEnd = remainder();
+ markerFound = false;
+
+ while(remainder() > 0)
+ {
+ option_t option :variable*8;
+
+ if(0 == option.length)
+ markerFound = true;
+ else if(!markerFound)
+ canonicalEnd = remainder();
+ };
+
+ canonicalSectionLength = canonicalStart - canonicalEnd;
+ } :variable*8;
+
+4.3.2. Fingerprint
+
+ A certificate's fingerprint is the SHA-256 hash [SHA256] of the
+ canonical section of the certificate (that is, the hash of the first
+ canonicalSectionLength bytes of the certificate).
+
+ The certificate's fingerprint is also called the "peer ID".
+
+4.3.3. Options
+
+ This section lists options that can appear in a certificate. The
+ following option type codes are defined:
+
+ 0x00: Hostname (must be in canonical section) (Section 4.3.3.1)
+
+ 0x0a: Accepts Ancillary Data (must be in canonical section)
+ (Section 4.3.3.2)
+
+ 0x0e: Extra Randomness (Section 4.3.3.3)
+
+
+
+Thornburgh Informational [Page 7]
+
+RFC 7425 Adobe RTMFP for Flash Communication December 2014
+
+
+ 0x15: Supported Ephemeral Diffie-Hellman Group (must be in
+ canonical section) (Section 4.3.3.4)
+
+ 0x1d: Static Diffie-Hellman Public Key (must be in canonical
+ section) (Section 4.3.3.5)
+
+ An implementation MUST ignore a certificate option type that is not
+ understood.
+
+4.3.3.1. Hostname
+
+ This option gives an optional hostname for the endpoint. This option
+ MUST be ignored if is not in the canonical section. This option MUST
+ NOT occur more than once in a certificate.
+
+ +-------------/-+-------------/-+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+
+ | length \ | 0x00 \ | hostname |
+ +-------------/-+-------------/-+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~/
+
+ struct hostnameCertOptionValue_t
+ {
+ uint8_t hostname[remainder()];
+ } :remainder()*8;
+
+4.3.3.2. Accepts Ancillary Data
+
+ This option indicates that the endpoint will accept an Endpoint
+ Discriminator encoding an Ancillary Data option (Section 4.4.2.2).
+ This option MUST be ignored if it is not in the canonical section.
+
+ +-------------/-+-------------/-+
+ | length \ | 0x0a \ |
+ +-------------/-+-------------/-+
+
+4.3.3.3. Extra Randomness
+
+ This option can be used to add extra entropy or randomness to a
+ certificate that doesn't have any other cryptographic pseudorandom
+ members (such as a public key). This option is typically used so
+ that endpoints using ephemeral Diffie-Hellman keying can have a
+ unique certificate fingerprint.
+
+
+
+
+
+
+
+
+
+
+Thornburgh Informational [Page 8]
+
+RFC 7425 Adobe RTMFP for Flash Communication December 2014
+
+
+ +-------------/-+-------------/-+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+
+ | length \ | 0x0e \ | extra randomness |
+ +-------------/-+-------------/-+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~/
+
+ struct extraRandomnessCertOptionValue_t
+ {
+ uint_t extraRandomness[remainder()];
+ } :remainder()*8;
+
+4.3.3.4. Supported Ephemeral Diffie-Hellman Group
+
+ This option specifies a Diffie-Hellman group ID that is supported for
+ ephemeral keying. This option MUST be ignored if it is not in the
+ canonical section. This option may occur more than once in the
+ certificate; each instance indicates an additional group that is
+ supported for key agreement.
+
+ +-------------/-+-------------/-+-------------/-+
+ | length \ | 0x15 \ | group ID \ |
+ +-------------/-+-------------/-+-------------/-+
+
+ struct ephemeralDHGroupCertOptionValue_t
+ {
+ vlu_t groupID :variable*8;
+ } :variable*8;
+
+ The presence of this option means that the certificate uses ephemeral
+ Diffie-Hellman public keys only. The certificate MUST NOT contain a
+ Static Diffie-Hellman public key (Section 4.3.3.5).
+
+4.3.3.5. Static Diffie-Hellman Public Key
+
+ This option specifies a Diffie-Hellman group ID and static public key
+ in that group. This option MUST be ignored if it is not in the
+ canonical section. This option MAY occur more than once in the
+ certificate; however, this option SHOULD NOT occur more than once for
+ each group ID. The behavior for specifying more than one public key
+ per group ID is not defined.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Thornburgh Informational [Page 9]
+
+RFC 7425 Adobe RTMFP for Flash Communication December 2014
+
+
+ +-------------/-+-------------/-+-------------/-+
+ | length \ | 0x1d \ | group ID \ |
+ +-------------/-+-------------/-+-------------/-+
+ +------------------------------------------------------------------+
+ | Diffie-Hellman Public Key |
+ +------------------------------------------------------------------/
+
+ struct staticDHPublicKeyCertOptionValue_t
+ {
+ vlu_t groupID :variable*8;
+ uintn_t publicKey :remainder()*8; // network byte order
+ } :remainder()*8;
+
+ The presence of this option means that the certificate uses static
+ Diffie-Hellman public keys only. The certificate MUST NOT contain
+ any Supported Ephemeral Diffie-Hellman Group options
+ (Section 4.3.3.4).
+
+4.3.4. Authenticity
+
+ This profile does not use a public key infrastructure, nor are there
+ signing keys present in certificates. Therefore, any properly
+ encoded certificate is considered authentic according to Section 3.2
+ of RFC 7016.
+
+ A certificate containing a static public key can only be used
+ successfully for session communication if the holder of the
+ certificate actually holds the private key associated with the public
+ key. Authenticity of an identity and its peer ID (Section 4.3.2)
+ having a certificate containing a static public key is implied by
+ successful encrypted communication with the associated endpoint
+ (Section 4.6).
+
+ See Section 7 for further discussion of security issues related to
+ identities.
+
+4.3.5. Signing and Verifying Messages
+
+ RTMFP Initiator Initial Keying and Responder Initial Keying messages
+ have a field for the sender's digital signature of the keying
+ parameters (Sections 2.3.7 and 2.3.8 of RFC 7016). In this profile,
+ the signature field of those messages is encoded as a sequence of
+ zero or more RTMFP Options.
+
+
+
+
+
+
+
+
+Thornburgh Informational [Page 10]
+
+RFC 7425 Adobe RTMFP for Flash Communication December 2014
+
+
+ +~~~/~~~/~~~~~~~+ +~~~/~~~/~~~~~~~+
+ | L \ T \ V |...............| L \ T \ V |
+ +~~~/~~~/~~~~~~~+ +~~~/~~~/~~~~~~~+
+ ^ ^
+ +------------- Zero or more Options ----------+
+
+ struct initialKeyingSignature_t
+ {
+ while(remainder() > 0)
+ option_t option :variable*8;
+ } :remainder()*8;
+
+ If a signer has no signature options to send, it MAY encode a
+ signature as a UTF-8 capital "X" (hex 58) or as empty. A verifier
+ MUST interpret a malformed signature field or a signature field
+ consisting only of a UTF-8 capital "X" as though it was empty.
+
+ If a verifier does not require a signature, it SHALL consider any
+ signature field (including an empty or malformed one) to be valid. A
+ verifier MAY require a signature comprising one or more non-empty
+ options that are valid according to their respective types.
+
+ This profile does not use a public key infrastructure, nor are there
+ signing keys present in certificates. Section 4.3.5.1.1 defines a
+ simple ID/password credential system.
+
+4.3.5.1. Options
+
+ This section lists options that can appear in an RTMFP Initial Keying
+ signature field. The following option type code is defined:
+
+ 0x1d: Simple Password (Section 4.3.5.1.1)
+
+ Future or derived profiles may define additional signature field
+ options and semantics; therefore, a verifier SHOULD ignore option
+ types that are not understood.
+
+4.3.5.1.1. Simple Password
+
+ This option encodes a password identifier (such as a user name, or an
+ application-specific or implementation-specific selector) and an HMAC
+ over the signed parameters using the identified password as the HMAC
+ key. This option can occur more than once (for example, to allow
+ interoperation between a current and a previous version of an
+ implementation using implementation-specific passwords).
+
+
+
+
+
+
+Thornburgh Informational [Page 11]
+
+RFC 7425 Adobe RTMFP for Flash Communication December 2014
+
+
+ To support the versioning use case, a verifier SHOULD ignore a Simple
+ Password option encoding an unrecognized password identifier. A
+ verifier SHOULD treat the entire signature as invalid if any Simple
+ Password option encodes a recognized password identifier with an
+ invalid password HMAC.
+
+ 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
+ +-------------/-+-------------/-+
+ | length \ | 0x1d \ |
+ +-------------/-+-------------/-+
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | |
+ + - - - - - - - + - - - - - - - + - - - - - - - + - - - - - - - +
+ | |
+ + - - - - - - - + - - - - - - - + - - - - - - - + - - - - - - - +
+ | |
+ + - - - - - - - + - - - - - - - + - - - - - - - + - - - - - - - +
+ | hmacSHA256 |
+ + - - - - - - - + - - - - - - - + - - - - - - - + - - - - - - - +
+ | |
+ + - - - - - - - + - - - - - - - + - - - - - - - + - - - - - - - +
+ | |
+ + - - - - - - - + - - - - - - - + - - - - - - - + - - - - - - - +
+ | |
+ + - - - - - - - + - - - - - - - + - - - - - - - + - - - - - - - +
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+
+ | passwordID |
+ +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~/
+
+ struct simplePasswordSignatureOptionValue_t
+ {
+ uint8_t hmacSHA256[32];
+ uint8_t passwordID[remainder()];
+ } :remainder()*8;
+
+ hmacSHA256: HMAC-SHA256(K, M), where K is the password associated
+ with passwordID, and M is the signed parameters.
+
+ passwordID: The identifier (such as a user name) for the password
+ used as the HMAC key.
+
+
+
+
+
+
+
+
+
+Thornburgh Informational [Page 12]
+
+RFC 7425 Adobe RTMFP for Flash Communication December 2014
+
+
+4.3.6. Glare Resolution
+
+ Glare occurs when two endpoints initiate a session each to the other
+ concurrently.
+
+ Compare the near end's certificate to the far end's with a binary
+ lexicographic comparison, one byte at a time, up to the length of the
+ shorter certificate. At the first corresponding byte from each
+ certificate that is different, the certificate having the differing
+ byte (treated as an unsigned 8-bit integer) with the lower value is
+ ordered before the other certificate. If the certificates are not
+ the same length and they are identical up to the length of the
+ shorter certificate, then the shorter certificate is ordered before
+ the longer.
+
+ The near end prevails as the Initiator in case of glare if its
+ certificate is ordered before, or is identical to, the certificate of
+ the far end. Otherwise, the near end's certificate is ordered after
+ the far end's certificate, and the near end assumes the role of
+ Responder.
+
+4.3.7. Session Override
+
+ A new incoming session overrides an existing session only if the
+ certificate for the new session is identical to the certificate for
+ the existing session.
+
+4.4. Endpoint Discriminators
+
+ This section describes the Endpoint Discriminator (EPD) (Section 3.2
+ of RFC 7016) format and semantics for this Cryptography Profile, and
+ the mapping to RTMFP's abstract certificate and identity selection
+ semantics.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Thornburgh Informational [Page 13]
+
+RFC 7425 Adobe RTMFP for Flash Communication December 2014
+
+
+4.4.1. Format
+
+ An EPD in this profile is encoded as a sequence of zero or more RTMFP
+ Options.
+
+ +~~~/~~~/~~~~~~~+ +~~~/~~~/~~~~~~~+
+ | L \ T \ V |...............| L \ T \ V |
+ +~~~/~~~/~~~~~~~+ +~~~/~~~/~~~~~~~+
+ ^ ^
+ +------------- Zero or more Options ----------+
+
+ struct endpointDiscriminator_t
+ {
+ while(remainder() > 0)
+ option_t option :variable*8;
+ } :remainder()*8;
+
+4.4.2. Options
+
+ This section lists options that can appear in an EPD. The following
+ option type codes are defined:
+
+ 0x00: Required Hostname (Section 4.4.2.1)
+
+ 0x0a: Ancillary Data (Section 4.4.2.2)
+
+ 0x0f: Fingerprint (Section 4.4.2.3)
+
+ The use of these options for selecting certificates is described in
+ Section 4.4.3.
+
+ An implementation MUST ignore EPD option types that are not
+ understood.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Thornburgh Informational [Page 14]
+
+RFC 7425 Adobe RTMFP for Flash Communication December 2014
+
+
+4.4.2.1. Required Hostname
+
+ This option indicates the hostname to match against the certificate's
+ Hostname option (Section 4.3.3.1).
+
+ +-------------/-+-------------/-+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+
+ | length \ | 0x00 \ | hostname |
+ +-------------/-+-------------/-+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~/
+
+ struct hostnameEPDOptionValue_t
+ {
+ uint8_t hostname[remainder()];
+ } :remainder()*8;
+
+ This option MUST NOT occur more than once in an EPD.
+
+4.4.2.2. Ancillary Data
+
+ In this profile, this option indicates the server Uniform Resource
+ Identifier (URI) [RFC3986] encoded in UTF-8 to which a client is
+ connecting on this session, for example,
+ "rtmfp://server.example.com/app/instance".
+
+ +-------------/-+-------------/-+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+
+ | length \ | 0x0a \ | ancillary data |
+ +-------------/-+-------------/-+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~/
+
+ struct ancillaryDataEPDOptionValue_t
+ {
+ uint8_t ancillaryData[remainder()];
+ } :remainder()*8;
+
+ This option MUST NOT occur more than once in an EPD.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Thornburgh Informational [Page 15]
+
+RFC 7425 Adobe RTMFP for Flash Communication December 2014
+
+
+4.4.2.3. Fingerprint
+
+ This option indicates the 256-bit (32-byte) fingerprint
+ (Section 4.3.2) of a certificate.
+
+ 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
+ +-------------/-+-------------/-+
+ | length \ | 0x0f \ |
+ +-------------/-+-------------/-+
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | |
+ + - - - - - - - + - - - - - - - + - - - - - - - + - - - - - - - +
+ | |
+ + - - - - - - - + - - - - - - - + - - - - - - - + - - - - - - - +
+ | |
+ + - - - - - - - + - - - - - - - + - - - - - - - + - - - - - - - +
+ | fingerprint |
+ + - - - - - - - + - - - - - - - + - - - - - - - + - - - - - - - +
+ | |
+ + - - - - - - - + - - - - - - - + - - - - - - - + - - - - - - - +
+ | |
+ + - - - - - - - + - - - - - - - + - - - - - - - + - - - - - - - +
+ | |
+ + - - - - - - - + - - - - - - - + - - - - - - - + - - - - - - - +
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ struct fingerprintEPDOptionValue_t
+ {
+ uint8_t fingerprint[32];
+ } :256;
+
+ This option MUST NOT occur more than once in an EPD.
+
+4.4.3. Certificate Selection
+
+ This section describes the REQUIRED method of determining whether an
+ EPD selects a certificate.
+
+ An EPD MUST contain at least one of Fingerprint, Required Hostname,
+ or Ancillary Data options to select any certificate.
+
+ A Fingerprint EPD option selects or rejects a certificate no matter
+ what other options are present.
+
+ Without a Fingerprint option, a Required Hostname EPD option, if
+ present, REQUIRES an identical Hostname option in the certificate.
+
+
+
+
+Thornburgh Informational [Page 16]
+
+RFC 7425 Adobe RTMFP for Flash Communication December 2014
+
+
+ Without a Fingerprint option, an Ancillary Data EPD option, if
+ present, REQUIRES that the certificate has an Accepts Ancillary Data
+ option.
+
+ if EPD contains a Fingerprint option:
+ if certificate.fingerprint == option.fingerprint:
+ certificate is selected. stop.
+ else:
+ certificate is not selected. stop.
+ else:
+ if EPD contains a Required Hostname option:
+ if certificate contains a Hostname option:
+ if certificate.hostname != option.hostname:
+ certificate is not selected. stop.
+ else:
+ certificate is not selected. stop.
+ if EPD contains an Ancillary Data option:
+ if certificate doesn't have an Accepts Ancillary Data option:
+ certificate is not selected. stop.
+ else if EPD does not contain a Required Hostname option:
+ certificate is not selected. stop.
+ certificate is selected. stop.
+
+ Figure 1: Algorithm to Test Whether an EPD Selects a Certificate
+
+4.4.4. Canonical Endpoint Discriminator
+
+ In this profile, a Canonical Endpoint Discriminator (Section 3.2 of
+ RFC 7016) contains only a Fingerprint option (Section 4.4.2.3) and no
+ other options. The option length and type code MUST be encoded as
+ 1-byte VLUs, even though VLU encoding allows those fields to be
+ encoded in an arbitrary number of bytes. That is, the Canonical
+ Endpoint Discriminator MUST be exactly 34 bytes long, with a length
+ field of 0x21 encoded as one byte, a type code of 0x0f encoded as one
+ byte, and 32 bytes of fingerprint.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Thornburgh Informational [Page 17]
+
+RFC 7425 Adobe RTMFP for Flash Communication December 2014
+
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | 0x21 | 0x0f |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | |
+ + - - - - - - - + - - - - - - - + - - - - - - - + - - - - - - - +
+ | |
+ + - - - - - - - + - - - - - - - + - - - - - - - + - - - - - - - +
+ | |
+ + - - - - - - - + - - - - - - - + - - - - - - - + - - - - - - - +
+ | fingerprint |
+ + - - - - - - - + - - - - - - - + - - - - - - - + - - - - - - - +
+ | |
+ + - - - - - - - + - - - - - - - + - - - - - - - + - - - - - - - +
+ | |
+ + - - - - - - - + - - - - - - - + - - - - - - - + - - - - - - - +
+ | |
+ + - - - - - - - + - - - - - - - + - - - - - - - + - - - - - - - +
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ struct canonicalEndpointDiscriminator_t
+ {
+ uint8_t length = 0x21;
+ uint8_t type = 0x0f;
+ uint8_t fingerprint[32];
+ } :272;
+
+4.5. Session Keying Components
+
+ This section describes the format of the Session Key Initiator
+ Component of the Initiator Initial Keying RTMFP chunk and the Session
+ Key Responder Component of the Responder Initial Keying RTMFP chunk
+ (Sections 2.3.7 and 2.3.8 of RFC 7016). The Initiator and Responder
+ Session Keying Components have the same format.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Thornburgh Informational [Page 18]
+
+RFC 7425 Adobe RTMFP for Flash Communication December 2014
+
+
+4.5.1. Format
+
+ A Session Keying Component in this profile is encoded as a sequence
+ of zero or more RTMFP Options.
+
+ +~~~/~~~/~~~~~~~+ +~~~/~~~/~~~~~~~+
+ | L \ T \ V |...............| L \ T \ V |
+ +~~~/~~~/~~~~~~~+ +~~~/~~~/~~~~~~~+
+ ^ ^
+ +------------- Zero or more Options ----------+
+
+ struct sessionKeyingComponent_t
+ {
+ while(remainder() > 0)
+ option_t option :variable*8;
+ } :remainder()*8;
+
+4.5.2. Options
+
+ This section lists options that can appear in a Session Keying
+ Component. The following option type codes are defined:
+
+ 0x0d: Ephemeral Diffie-Hellman Public Key (Section 4.5.2.1)
+
+ 0x0e: Extra Randomness (Section 4.5.2.2)
+
+ 0x1d: Diffie-Hellman Group Select (Section 4.5.2.3)
+
+ 0x1a: HMAC Negotiation (Section 4.5.2.4)
+
+ 0x1e: Session Sequence Number Negotiation (Section 4.5.2.5)
+
+ An implementation MUST ignore a session keying component option type
+ that is not understood.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Thornburgh Informational [Page 19]
+
+RFC 7425 Adobe RTMFP for Flash Communication December 2014
+
+
+4.5.2.1. Ephemeral Diffie-Hellman Public Key
+
+ This option specifies a Diffie-Hellman group ID and public key in
+ that group. This option MUST NOT be sent if the sender's certificate
+ has a static Diffie-Hellman public key. This option MUST be sent if
+ the sender's certificate does not have a static Diffie-Hellman public
+ key. This option MUST NOT be sent more than once.
+
+ +-------------/-+-------------/-+-------------/-+
+ | length \ | 0x0d \ | group ID \ |
+ +-------------/-+-------------/-+-------------/-+
+ +------------------------------------------------------------------+
+ | Diffie-Hellman Public Key |
+ +------------------------------------------------------------------/
+
+ struct ephemeralDHPublicKeyKeyingOptionValue_t
+ {
+ vlu_t groupID :variable*8;
+ uintn_t publicKey :remainder()*8; // network byte order
+ } :remainder()*8;
+
+4.5.2.2. Extra Randomness
+
+ This option can be used to add extra entropy or randomness to a
+ keying component, particularly when the sender uses a static public
+ key. When used for that purpose, the extra randomness SHOULD be
+ cryptographically strong pseudorandom bytes not less than 16 bytes
+ (for cryptographically significant entropy) and not more than 64
+ bytes (the length of a SHA-256 input block) in length. The extra
+ randomness serves as a salt when computing the session keys
+ (Section 4.6).
+
+ +-------------/-+-------------/-+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+
+ | length \ | 0x0e \ | extra randomness |
+ +-------------/-+-------------/-+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~/
+
+ struct extraRandomnessKeyingOptionValue_t
+ {
+ uint_t extraRandomness[remainder()];
+ } :remainder()*8;
+
+
+
+
+
+
+
+
+
+
+
+Thornburgh Informational [Page 20]
+
+RFC 7425 Adobe RTMFP for Flash Communication December 2014
+
+
+4.5.2.3. Diffie-Hellman Group Select
+
+ This option is sent by the Initiator to specify which Diffie-Hellman
+ group to use for key agreement. The Initiator MUST send this option
+ when it advertises a static Diffie-Hellman public key in its
+ certificate and MUST NOT send this option if it sends an ephemeral
+ Diffie-Hellman public key. This option MUST NOT be sent more than
+ once.
+
+ +-------------/-+-------------/-+-------------/-+
+ | length \ | 0x1d \ | group ID \ |
+ +-------------/-+-------------/-+-------------/-+
+
+ struct staticDHGroupSelectKeyingOptionValue_t
+ {
+ vlu_t groupID :variable*8;
+ } :variable*8;
+
+4.5.2.4. HMAC Negotiation
+
+ This option is used to negotiate sending and receiving of an HMAC
+ field for packet verification.
+
+ |0 1 2 3 4 5 6 7|
+ +-------------/-+-------------/-+-+-+-+-+-+-+-+-+-------------/-+
+ | \ | \ | |S|S|R| \ |
+ | length / | 0x1a / | rsv |N|O|E| hmacLength / |
+ | \ | \ | |D|R|Q| \ |
+ +-------------/-+-------------/-+-+-+-+-+-+-+-+-+-------------/-+
+
+ struct hmacNegotiationKeyingOptionValue_t
+ {
+ uintn_t reserved :5; // rsv
+ bool_t willSendAlways :1; // SND
+ bool_t willSendOnRequest :1; // SOR
+ bool_t request :1; // REQ
+ vlu_t hmacLength :variable*8;
+ } :variable*8;
+
+ willSendAlways: If set, the sender will send an HMAC on packets in
+ this session.
+
+ willSendOnRequest: If set, the sender will send an HMAC on packets
+ in this session if the other end sets the request flag in its HMAC
+ Negotiation.
+
+
+
+
+
+
+Thornburgh Informational [Page 21]
+
+RFC 7425 Adobe RTMFP for Flash Communication December 2014
+
+
+ request: If set, the sender would very much like the receiver to
+ send an HMAC on its packets. If the other end doesn't send an
+ HMAC on its packets, the session can fail.
+
+ hmacLength: If the sender negotiates to send an HMAC on its packets,
+ the HMAC field will be this many bytes long. This value MUST be
+ between 4 and 32 inclusive, or 0 if and only if willSendAlways and
+ willSendOnRequest are clear.
+
+ The handshake operational semantics for this option are described in
+ Section 4.6.4.
+
+4.5.2.5. Session Sequence Number Negotiation
+
+ This option is used to negotiate sending and receiving of the Session
+ Sequence Number field for packet verification.
+
+ |0 1 2 3 4 5 6 7|
+ +-------------/-+-------------/-+-+-+-+-+-+-+-+-+
+ | \ | \ | |S|S|R|
+ | length / | 0x1e / | rsv |N|O|E|
+ | \ | \ | |D|R|Q|
+ +-------------/-+-------------/-+-+-+-+-+-+-+-+-+
+
+ struct sseqNegotiationKeyingOptionValue_t
+ {
+ uintn_t reserved :5; // rsv
+ bool_t willSendAlways :1; // SND
+ bool_t willSendOnRequest :1; // SOR
+ bool_t request :1; // REQ
+ } :8;
+
+ willSendAlways: If set, the sender will send a session sequence
+ number in packets in this session.
+
+ willSendOnRequest: If set, the sender will send a session sequence
+ number in packets in this session if the other end sets the
+ request flag in its Session Sequence Number Negotiation.
+
+ request: If set, the sender would very much like the receiver to
+ send a session sequence number in its packets. If the other end
+ doesn't send a session sequence number in its packets, the session
+ can fail.
+
+ The handshake operational semantics for this option are described in
+ Section 4.6.6.
+
+
+
+
+
+Thornburgh Informational [Page 22]
+
+RFC 7425 Adobe RTMFP for Flash Communication December 2014
+
+
+4.6. Session Key Computation
+
+ This section describes how to compute the cryptographic keys and
+ other settings for packet encryption and verification.
+
+ The Session Key Near Component (SKNC) means the keying component sent
+ by the near end of the session; that is, it is the Session Key
+ Initiator Component at the Initiator and the Session Key Responder
+ Component at the Responder.
+
+ The Session Key Far Component (SKFC) means the keying component sent
+ by the far end of the session; that is, it is the Session Key
+ Responder Component at the Initiator and the Session Key Initiator
+ Component at the Responder.
+
+4.6.1. Public Key Selection
+
+ This section enumerates the public key selection methods for all
+ possible combinations of static or ephemeral public key modes for
+ each endpoint according to their certificate options (Section 4.3.3).
+
+4.6.1.1. Initiator and Responder Ephemeral
+
+ The Initiator and Responder list one or more Supported Ephemeral
+ Diffie-Hellman Group options (Section 4.3.3.4) in their certificates.
+ The Initiator sends exactly one Ephemeral Diffie-Hellman Public Key
+ option (Section 4.5.2.1) in its Session Key Initiator Component,
+ which selects one group from among those supported by the Responder
+ and Initiator. Responder sends exactly one Ephemeral Diffie-Hellman
+ Public Key option in its Session Key Responder Component, in the same
+ group as indicated by the Initiator.
+
+4.6.1.2. Initiator Ephemeral and Responder Static
+
+ The Responder lists one or more Static Diffie-Hellman Public Key
+ options (Section 4.3.3.5) in its certificate. The Initiator lists
+ one or more Supported Ephemeral Diffie-Hellman Group options in its
+ certificate. The Initiator sends exactly one Ephemeral Diffie-
+ Hellman Public Key option in its Session Key Initiator Component,
+ which selects one group from among those supported by the Responder
+ and Initiator and the corresponding public key for the Responder.
+ Responder uses its public key from the indicated group, and sends
+ only an Extra Randomness option (Section 4.5.2.2) in its Session Key
+ Responder Component to salt the session keys.
+
+
+
+
+
+
+
+Thornburgh Informational [Page 23]
+
+RFC 7425 Adobe RTMFP for Flash Communication December 2014
+
+
+4.6.1.3. Initiator Static and Responder Ephemeral
+
+ The Responder lists one or more Supported Ephemeral Diffie-Hellman
+ Group options in its certificate. The Initiator lists one or more
+ Static Diffie-Hellman Public Key options in its certificate. The
+ Initiator sends exactly one Diffie-Hellman Group Select option
+ (Section 4.5.2.3) in its Session Key Initiator Component, which
+ selects one group from among those supported by the Responder and
+ Initiator and the corresponding public key for the Initiator, plus an
+ Extra Randomness option to salt the session keys. The Responder
+ sends an Ephemeral Diffie-Hellman Public Key option in its Session
+ Key Responder Component in the same group as indicated by the
+ Initiator.
+
+4.6.1.4. Initiator and Responder Static
+
+ The Initiator and Responder each list one or more Static Diffie-
+ Hellman Public Key options in their certificates. The Initiator
+ sends exactly one Diffie-Hellman Group Select option in its Session
+ Key Initiator Component, which selects one group and corresponding
+ public keys from among those supported by the Responder and
+ Initiator, and an Extra Randomness option to salt the session keys.
+ The Responder sends an Extra Randomness option in its Session Key
+ Responder Component to add its own salt to the session keys.
+
+4.6.2. Diffie-Hellman Shared Secret
+
+ To be acceptable, a Diffie-Hellman public key MUST have all of the
+ following properties:
+
+ o Be at least 16777216 (2^24);
+
+ o Be at most the group's prime modulus minus 16777216;
+
+ o Have at least 16 "1" bits;
+
+ o Have at least 16 "0" bits, not including leading zeros.
+
+ An endpoint MUST NOT complete to an S_OPEN session with a far
+ endpoint using a public key that is not acceptable according to these
+ criteria.
+
+ Once the group and corresponding public key of the far end is
+ determined, the far end's public key and the near end's private key
+ are combined according to Diffie-Hellman [DH] to compute the Diffie-
+ Hellman Shared Secret, an integer.
+
+
+
+
+
+Thornburgh Informational [Page 24]
+
+RFC 7425 Adobe RTMFP for Flash Communication December 2014
+
+
+ In the following sections, DH_SECRET means the Diffie-Hellman Shared
+ Secret encoded as a byte-aligned unsigned integer in network byte
+ order with no leading zero bytes. For example, if the shared secret
+ is 4886718345, DH_SECRET would be the five bytes:
+
+ Hex: 01 23 45 67 89
+
+4.6.3. Packet Encrypt/Decrypt Keys
+
+ Packets are encrypted using a symmetric cipher, such as the Advanced
+ Encryption Standard [AES]. Distinct keys are used for sending and
+ receiving packets. Each end's sending (encrypt) key is the other
+ end's receiving (decrypt) key.
+
+ The raw keys computed in this section for encryption and decryption
+ are transformed in a manner specific to the cipher with which they
+ are to be used. In this profile, AES-128 is the only currently
+ defined cipher. For this cipher, the first 128 bits (16 bytes) of
+ the 256-bit output of the calculation are taken to be the AES-128
+ key.
+
+ Set ENCRYPT_KEY = HMAC-SHA256(DH_SECRET, HMAC-SHA256(SKFC, SKNC));
+
+ Set DECRYPT_KEY = HMAC-SHA256(DH_SECRET, HMAC-SHA256(SKNC, SKFC));
+
+ The full 256 bits of ENCRYPT_KEY and DECRYPT_KEY are used in the
+ computations in the following sections.
+
+4.6.4. Packet HMAC Send/Receive Keys
+
+ Packets can be verified that they were not corrupted or modified by
+ appending an HMAC to the packet. Whether to use an HMAC or a simple
+ checksum is determined during the initial keying phase using the HMAC
+ Negotiation option (Section 4.5.2.4). Distinct HMAC keys are used
+ for sending and receiving packets. Each end's sending key is the
+ other end's receiving key, and vice versa.
+
+ Set HMAC_SEND_KEY = HMAC_SHA256(DH_SECRET, ENCRYPT_KEY);
+
+ Set HMAC_RECV_KEY = HMAC_SHA256(DH_SECRET, DECRYPT_KEY);
+
+ If an endpoint sets the willSendAlways flag in its HMAC Negotiation
+ option, then it MUST send an HMAC on packets it sends with this
+ session key.
+
+
+
+
+
+
+
+Thornburgh Informational [Page 25]
+
+RFC 7425 Adobe RTMFP for Flash Communication December 2014
+
+
+ If an endpoint's willSendAlways flag is clear but its
+ willSendOnRequest flag is set, then it MUST send an HMAC on packets
+ it sends with this session key if and only if the other endpoint's
+ request flag is set.
+
+ If a sending endpoint's willSendAlways and willSendOnRequest flags
+ are clear, then the receiving endpoint SHOULD reject that keying
+ component if the receiving endpoint is configured to require the
+ sending endpoint to send HMAC.
+
+ If HMAC is negotiated to be used, the corresponding hmacLength MUST
+ be between 4 and 32 inclusive.
+
+ If HMAC is negotiated not to be used, a simple checksum is used for
+ packet verification.
+
+ The Default Session Key uses the simple checksum and does not use
+ HMAC.
+
+4.6.5. Session Nonces
+
+ Session nonces are per-session, cryptographically strong secret
+ values known only to the two endpoints of the session. They can be
+ used for application-layer cryptographic challenges (such as signing
+ or password verification). These nonces are a convenience being pre-
+ shared and pre-agreed-upon in a secure manner during the initial
+ keying handshake.
+
+ Each end's near nonce is the other end's far nonce, and vice versa.
+
+ Set NEAR_NONCE = HMAC_SHA256(DH_SECRET, SKNC);
+
+ Set FAR_NONCE = HMAC_SHA256(DH_SECRET, SKFC);
+
+4.6.6. Session Sequence Number
+
+ Duplicate packets can be detected and rejected by using an optional
+ session sequence number inside the encrypted packets. The session
+ sequence number is a monotonically increasing unbounded integer and
+ does not wrap. Session sequence numbers SHOULD start at zero and
+ SHOULD increment by one for each packet sent using that session key.
+ Implementations MUST handle session sequence numbers with no less
+ than 64 bits of range.
+
+ If an endpoint's willSendAlways flag in its Session Sequence Number
+ Negotiation option (Section 4.5.2.5) is set, then it MUST send a
+ session sequence number in packets it sends with this session key.
+
+
+
+
+Thornburgh Informational [Page 26]
+
+RFC 7425 Adobe RTMFP for Flash Communication December 2014
+
+
+ If an endpoint's willSendAlways flag is clear but its
+ willSendOnRequest flag is set, then it MUST send a session sequence
+ number on packets it sends with this session key if and only if the
+ other endpoint's request flag is set.
+
+ If a sending endpoint's willSendAlways and willSendOnRequest flags
+ are clear, then the receiving endpoint SHOULD reject that keying
+ component if the receiving endpoint is configured to require the
+ sending endpoint to send session sequence numbers.
+
+ The Default Session Key does not use session sequence numbers.
+
+4.7. Packet Encryption
+
+ This section describes the concrete syntax and operational semantics
+ of RTMFP packet encryption for this Cryptography Profile.
+
+4.7.1. Cipher
+
+ This profile defines AES-128 [AES] in CBC [CBC] mode as the only
+ cipher. Extensions to this profile can specify and negotiate
+ additional ciphers and modes by defining certificate and keying
+ component options and associated semantics.
+
+ For AES-128-CBC, the initialization vector (IV) for each packet is 16
+ zero bytes. The IV is not included in the packet.
+
+4.7.2. Format
+
+ The Encrypted Packet is the encryptedPacket field of an RTMFP
+ Multiplex packet (Section 2.2.2 of RFC 7016); that is, the portion of
+ the Multiplex packet following the scrambled session ID. The
+ Encrypted Packet has the following format:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Thornburgh Informational [Page 27]
+
+RFC 7425 Adobe RTMFP for Flash Communication December 2014
+
+
+ +----------------+ +----------------+~~~~~~~~~~~~~~~~~~~~~~~+
+ | CBC Block 1 | ... | CBC Block N | truncatedHMAC |
+ +----------------+ +----------------+~~~~~~~~~~~~~~~~~~~~~~~+
+ ^ ^ ^
+ | Zero or more AES-128 chained | hmacLength bytes long |
+ +-------- cipher blocks -----------+--- (may be zero) ---+
+
+ struct flashProfileEncryptedPacket_t
+ {
+ if(HMAC is being used)
+ hmacLength = negotiated length;
+ else
+ hmacLength = 0;
+
+ struct
+ {
+ iv[16 bytes] = { 0 };
+ blockCount = 0;
+ while((remainder() > hmacLength) && (remainder() >= 16))
+ {
+ uint8_t cbcBlock[16];
+ blockCount++;
+ }
+ } chainedCipherBlocks :variable*16*8;
+
+ if(HMAC is being used)
+ {
+ if(remainder() == hmacLength)
+ uint8_t truncatedHMAC[hmacLength];
+ else
+ packetVerificationFailed();
+ }
+ else if(remainder() > 0)
+ packetVerificationFailed();
+ } :encryptedPacket.length*8;
+
+ cbcBlock: The next AES-128-CBC block.
+
+ chainedCipherBlocks: The concatenation of every cipher block in the
+ packet (over which the HMAC is computed).
+
+ truncatedHMAC: If HMAC was negotiated to be used (Section 4.5.2.4),
+ this field is set to the first negotiated hmacLength bytes of the
+ HMAC of the chainedCipherBlocks.
+
+ The plaintext data before encryption or after decryption has the
+ following format:
+
+
+
+
+Thornburgh Informational [Page 28]
+
+RFC 7425 Adobe RTMFP for Flash Communication December 2014
+
+
+ 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
+ +~~~~~~~~~~~~~/~+
+ | SSEQ (opt.) \ |
+ +~~~~~~~~~~~~~/~+
+ +~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+
+ | Checksum (opt.) |
+ +~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+
+ +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+
+ | Plain RTMFP Packet |
+ +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~/
+
+ struct flashProfilePlainPacket_t
+ {
+ if(session sequence numbers being used)
+ vlu_t sessionSequenceNumber :variable*8; // SSEQ
+ if(HMAC not being used)
+ uint16_t checksum;
+ packet_t plainRTMFPPacket :variable*8;
+ } :chainedCipherBlocks.blockCount*16*8;
+
+ sessionSequenceNumber: If session sequence numbers were negotiated
+ to be used (Section 4.6.6), this field is present and is the VLU
+ session sequence number of this packet.
+
+ checksum: If HMAC was not negotiated to be used, this field is
+ present and is the simple checksum (Section 4.7.3.1) of the
+ remaining bytes of this structure.
+
+ plainRTMFPPacket: The (plain, unencrypted) RTMFP Packet
+ (Section 2.2.4 of RFC 7016) plus any necessary padding.
+
+ When assembling this structure and prior to calculating the checksum
+ (if present), if the structure's total length is not an integer
+ multiple of 16 bytes (the AES cipher block size), pad the end of
+ plainRTMFPPacket with as many bytes having a value of 0xff as are
+ needed to bring the structure's total length to an integer multiple
+ of 16 bytes. The receiver's RTMFP Packet parser (Section 2.2.4 of
+ RFC 7016) will consume this padding.
+
+4.7.3. Verification
+
+ In RTMFP, the Cryptography Profile is responsible for packet
+ verification. In this profile, packets are verified with an HMAC or
+ a simple checksum, depending on the configuration of the endpoints,
+ and optionally verified against replay or duplication using session
+ sequence numbers. The simple checksum is inside the encrypted
+ packet, so it becomes essentially a 16-bit cryptographic checksum.
+
+
+
+
+Thornburgh Informational [Page 29]
+
+RFC 7425 Adobe RTMFP for Flash Communication December 2014
+
+
+4.7.3.1. Simple Checksum
+
+ The simple checksum is the 16-bit ones' complement of the 16-bit
+ ones' complement sum of all 16-bit (2 bytes in network byte order)
+ words to be checked. If there are an odd number of bytes to be
+ checked, then for purposes of this checksum, treat the last byte as
+ the lower 8 bits of a 16-bit word whose upper 8 bits are 0. This is
+ also known as the "Internet Checksum" [RFC1071].
+
+ When present, the checksum is calculated over all bytes of the
+ plaintext packet starting after the checksum field through the end of
+ the plain packet. It cannot be calculated until the plain packet is
+ padded, if necessary, to bring its length to an integer multiple of
+ 16 bytes (the AES cipher block size). The session sequence number
+ field, if present, and the checksum field itself are not included in
+ the checksum.
+
+ On receiving a packet being verified with a checksum: calculate the
+ checksum over all the bytes of the plaintext packet following the
+ checksum field and compare the checksum to the value in the checksum
+ field. If they match, the packet is verified; if they do not match,
+ the packet is corrupt and MUST be discarded as though it was never
+ received.
+
+4.7.3.2. HMAC
+
+ When present, the HMAC field is the last hmacLength bytes of the
+ packet and is calculated over all of the encrypted cipher blocks of
+ the packet preceding the HMAC field. The value of the HMAC field is
+ the first hmacLength bytes of the HMAC-SHA256 of the checked data,
+ using the computed HMAC keys (Section 4.6.4) and negotiated
+ hmacLength (Section 4.5.2.4). Note each endpoint independently
+ specifies the length of the HMAC it will send via its hmacLength
+ field.
+
+ When an endpoint has negotiated to send an HMAC, it encrypts the data
+ blocks, computes the HMAC over the encrypted data blocks using its
+ HMAC_SEND_KEY, and appends the first hmacLength bytes of that hash
+ after the final encrypted data block.
+
+ When an endpoint has negotiated to receive an HMAC, the endpoint
+ computes the HMAC over the encrypted data blocks using its
+ HMAC_RECV_KEY and then compares the first receive hmacLength bytes of
+ the computed HMAC to the HMAC field in the packet. If they are
+ identical, the packet is verified; if they are not identical, the
+ packet is corrupt and MUST be discarded as though it was never
+ received.
+
+
+
+
+Thornburgh Informational [Page 30]
+
+RFC 7425 Adobe RTMFP for Flash Communication December 2014
+
+
+ HMAC and simple checksum verification are mutually exclusive.
+
+4.7.3.3. Session Sequence Number
+
+ Session sequence numbers are used to detect and reject a packet that
+ was duplicated in the network or replayed by an attacker and to
+ ensure the first chained cipher block of every packet is unique, in
+ lieu of a full-block initialization vector. Sequence numbers start
+ at zero, increase by one for each packet sent in the session, do not
+ wrap, and do not repeat.
+
+ When session sequence numbers are negotiated to be used, the receiver
+ MUST allow for packets to be reordered in the network by up to at
+ least 32 sequence numbers; note, however, that reordering by more
+ than three packets can trigger loss detection and retransmission by
+ negative acknowledgement, just as with TCP, and is therefore not
+ likely to occur in the real Internet.
+
+ [RFC4302], [RFC4303], and [RFC6479] describe Anti-Replay Window
+ methods that can be employed to detect duplicate sequence numbers.
+ Other methods are possible.
+
+ Any packet received having a session sequence number that was already
+ seen in that session, either directly or by being less than the
+ lowest sequence number in the Anti-Replay Window, is a duplicate and
+ MUST be discarded as though never received.
+
+5. Flash Communication
+
+ The Flash platform uses RTMP [RTMP] messages for media streaming and
+ communication. This section describes how to transport RTMP messages
+ over RTMFP flows and additional messages and semantics unique to this
+ transport.
+
+5.1. RTMP Messages
+
+ An RTMP message comprises a virtual header and a payload. The
+ virtual header comprises a Message Type, a Payload Length, a
+ Timestamp, and a Stream ID. The format of the payload is dependent
+ on the type of message.
+
+ An RTMP message is mapped onto a lower transport layer, such as RTMP
+ Chunk Stream [RTMP] or RTMFP. RTMP messages were initially designed
+ along with, and for transport on, RTMP Chunk Stream. This design
+ constrains the possible values of RTMP message header fields. In
+ particular:
+
+
+
+
+
+Thornburgh Informational [Page 31]
+
+RFC 7425 Adobe RTMFP for Flash Communication December 2014
+
+
+ Message Type is 8 bits wide, and is therefore constrained to
+ values from 0 to 255 inclusive;
+
+ Payload Length is 24 bits wide, so messages can be at most
+ 16777215 bytes long;
+
+ Timestamp is 32 bits wide, so timestamps range from 0 to
+ 4294967295 and wrap around;
+
+ Stream ID is 24 bits wide, and is therefore constrained to values
+ from 0 to 16777215 inclusive.
+
+ RTMP Chunk Stream Protocol Control messages (message types 1, 2, 3,
+ 5, and 6) are not used when transporting RTMP messages in RTMFP
+ flows. Messages of those types SHOULD NOT be sent and MUST be
+ ignored.
+
+5.1.1. Flow Metadata
+
+ All messages in RTMFP are transported in flows. In this profile, an
+ RTMFP flow for RTMP messages carries the messages for exactly one
+ RTMP Stream ID. Multiple flows can carry messages for the same
+ Stream ID; for example, the video and audio messages of a stream
+ could be sent on separate flows, allowing the audio to be given
+ higher transmission priority.
+
+ The User Metadata for flows in this profile begins with a distinct
+ signature to distinguish among different kinds of flows. The User
+ Metadata for a flow used for RTMP messages begins with the two-
+ character signature "TC".
+
+ The Stream ID is encoded in the flow's User Metadata so that it
+ doesn't need to be sent with each message.
+
+ The sender can have a priori knowledge about the kind of media it
+ intends to send on a flow and its intended use and can give the
+ receiver a hint as to whether messages should be delivered as soon as
+ possible or in their original queuing order. For example, the sender
+ might be sending real-time, delay-sensitive audio messages on a flow,
+ and hint that the receiver should take delivery of the messages on
+ that flow as soon as they arrive in the network, to reduce the end-
+ to-end latency of the audio.
+
+ The receiver can choose to take delivery of messages on flows as soon
+ as they arrive in the network or in the messages' original queuing
+ order. A receiver that chooses to take delivery of messages as soon
+ as they arrive in the network MUST be prepared for the messages to
+
+
+
+
+Thornburgh Informational [Page 32]
+
+RFC 7425 Adobe RTMFP for Flash Communication December 2014
+
+
+ arrive out-of-order. For example, a receiver may choose not to
+ render a newly received audio message having a timestamp earlier than
+ the most recently rendered audio timestamp.
+
+ The sender can choose to abandon a message that it has queued in a
+ flow before the message has been delivered to the receiver. For
+ example, the sender may abandon a real-time, delay-sensitive audio
+ message that has not been delivered within one second, to avoid
+ spending transmission resources on stale media that is no longer
+ relevant.
+
+ Note: A gap will cause a delay at the receiver of at least one round-
+ trip time if the receiver is taking delivery of messages in original
+ queuing order.
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+~~~~~~~~~~~~~/~+
+ | | | |S|r|R| \ |
+ | 0x54 'T' | 0x43 'C' | rsv |I|s|X| streamID / |
+ | | | |D|v|I| \ |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+~~~~~~~~~~~~~/~+
+
+ struct RTMPMetadata_t
+ {
+ uint8_t signature[2] == { 'T', 'C' };
+ uintn_t reserved1 :5; // rsv
+ bool_t streamIDPresent :1; // SID
+ uintn_t reserved2 :1; // rsv
+ uintn_t receiveIntent :1; // RXI
+ // 0: original queuing order, 1: network arrival order
+ if(streamIDPresent)
+ vlu_t streamID :variable*8;
+ } :variable*8;
+
+ signature: Metadata signature for RTMP message flows, being the two
+ UTF-8 coded characters "TC".
+
+ streamIDPresent: A boolean flag indicating whether the streamID
+ field is present. In this profile, this flag MUST be set.
+
+ receiveIntent: A hint by the sender as to the best order in which to
+ take delivery of messages from the flow. A value of zero
+ indicates a hint that the flow's messages should be received in
+ the order they were originally queued by the sender (that is, in
+ ascending sequence number order); a value of one indicates a hint
+ that the flow's messages should be received in the order they
+ arrive in the network, even if there are sequence number gaps or
+ reordering. Network arrival order is typically hinted for live,
+
+
+
+Thornburgh Informational [Page 33]
+
+RFC 7425 Adobe RTMFP for Flash Communication December 2014
+
+
+ delay-sensitive flows, such as for audio media. To take delivery
+ of a message as soon as it arrives in the network: receive it from
+ the receiving flow's RECV_BUFFER as soon as it becomes complete
+ (Section 3.6.3.3 of RFC 7016), and remove it from the RECV_BUFFER.
+ Section 3.6.3.3 of RFC 7016 describes how to take delivery of
+ messages in original queuing order.
+
+ streamID: If the streamIDPresent flag is set, this field is present
+ and is the RTMP stream ID to which the messages in this flow
+ belong. In this profile, this field MUST be present.
+
+ A receiver SHOULD reject an RTMP message flow if its streamIDPresent
+ flag is clear. This profile doesn't define a stream mapping for this
+ case.
+
+ Derived or composed profiles can define additional flow types and
+ corresponding metadata signatures. A receiver SHOULD reject a flow
+ having an unrecognized metadata signature.
+
+5.1.2. Message Mapping
+
+ This section describes the format of an RTMP message (Section 5.1) in
+ an RTMFP flow.
+
+ 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
+ +-+-+-+-+-+-+-+-+
+ | messageType |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | timestamp |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | messagePayload |
+ +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~/
+
+ struct RTMPMessage_t
+ {
+ uint8_t messageType;
+ uint32_t timestamp;
+ uint8_t messagePayload[remainder()];
+ } :flowMessageLength*8;
+
+ messageType: The RTMP Message Type;
+
+ timestamp: The RTMP Timestamp, in network byte order;
+
+ messagePayload: The payload of the RTMP message;
+
+ payload length: The RTMP message payload length is inferred from the
+ length of the RTMFP message;
+
+
+
+Thornburgh Informational [Page 34]
+
+RFC 7425 Adobe RTMFP for Flash Communication December 2014
+
+
+ Stream ID: The Stream ID for this message is taken from the metadata
+ of the flow on which this message was received.
+
+5.2. Flow Synchronization
+
+ RTMFP flows are independent and have no inter-flow ordering
+ guarantee. RTMP was designed for transport over a single, reliable,
+ strictly ordered byte stream. Some RTMP message semantics take
+ advantage of this ordering; for example, a Stream EOF User Control
+ event must not be processed until after all media messages for the
+ corresponding stream have been received. Flow Synchronization
+ messages provide a barrier to align message delivery across flows
+ when required by RTMP semantics.
+
+ A Flow Synchronization message is coded as a User Control event
+ message (Type 4) having Event Type 34. Message timestamps are
+ ignored and MAY be set to 0.
+
+ 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
+ +-+-+-+-+-+-+-+-+
+ | 4 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | timestamp |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | eventType = 34 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | syncID |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | count |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ struct flowSyncUserControlMessagePayload_t
+ {
+ uint16_t eventType = 34;
+ uint32_t syncID;
+ uint32_t count;
+ } :10*8;
+
+ eventType: The RTMP User Control Message Event Type. Flow
+ Synchronization messages have type 34 (0x22);
+
+ syncID: The identifier for this barrier;
+
+ count: The number of flows being synchronized by syncID. This field
+ MUST be at least 1 and SHOULD be at least 2.
+
+
+
+
+
+
+Thornburgh Informational [Page 35]
+
+RFC 7425 Adobe RTMFP for Flash Communication December 2014
+
+
+ On receipt of a Flow Synchronization message, a receiver SHOULD
+ suspend receipt of further messages on that flow until count Flow
+ Synchronization messages (including this one) with the same syncID
+ have been received on flows in the same flow association tree.
+
+ Example: Consider flows F1 and F2 in the same NetConnection carrying
+ messages M, and let Sync(syncID,count) denote a Flow Synchronization
+ message.
+
+ | |
+ F1: M1 M2 M4 Sync(8,2) | Sync(13,2).....| M7
+ | |
+ F2: M3 Sync(8,2).......| M5 Sync(13,2) | M6
+ | |
+ Barrier 8 Barrier 13
+
+ Figure 2: Example Flow Synchronization Barriers
+
+ Flow Synchronization messages form a delivery barrier to impart at
+ least a partial message ordering across flows. In this example,
+ message M5 comes after M1..4 and before M6..7; however, M3 could be
+ delivered before or after any of M1, M2, or M4, and M6 could come
+ before or after M7.
+
+ Flow Synchronization can cause a priority inversion; therefore, it
+ SHOULD NOT be used except when necessary to preserve RTMP ordering
+ semantics.
+
+5.3. Client-to-Server Connection
+
+ The client connects to a server. The connection comprises one main
+ control flow in each direction from client to server and from server
+ to client for NetConnection messages, and zero or more flows in each
+ direction for NetStream media messages. NetStream flows may come and
+ go naturally over time according to media transport needs. An
+ exception on a NetConnection control sending flow indicates the
+ closure by the other end of the NetConnection and all associated
+ NetStreams.
+
+ The client MUST NOT use the same client certificate for more than one
+ server connection; that is, a client's peer ID MUST NOT be reused.
+
+5.3.1. Connecting
+
+ The client desires a connection to a server having an RTMFP URI, for
+ example, "rtmfp://server.example.com/app/instance". The client
+ gathers one or more initial candidate addresses for the server named
+ in the URI (for example, by using the Domain Name System (DNS)
+
+
+
+Thornburgh Informational [Page 36]
+
+RFC 7425 Adobe RTMFP for Flash Communication December 2014
+
+
+ [RFC1035]). The client creates an EPD having an Ancillary Data
+ option (Section 4.4.2.2) encoding the URI. The client initiates an
+ RTMFP session to the one or more candidate addresses using the EPD.
+
+ When the session transitions to the S_OPEN state, the client opens a
+ new flow in that session for Stream ID 0 and Receive Intent 0
+ "original queuing order". This is the client's NetConnection main
+ control flow. The client sends an RTMP "connect" command on the flow
+ and waits for a response or exception.
+
+5.3.2. Server-to-Client Return Control Flow
+
+ The server, on accepting the client's NetConnection control flow, and
+ receiving and accepting the "connect" command, opens one or more
+ return flows to the client having Stream ID 0 and associated to the
+ control flow from the client. Flows for Stream ID 0 are the server's
+ NetConnection control flows. The server sends a "_result" or
+ "_error" transaction response for the client's connect command.
+
+ When the client receives the first return flow from the server for
+ Stream ID 0 and associated to the client's NetConnection control
+ flow, the client assumes that flow is the canonical return
+ NetConnection control flow from the server, to which all new client-
+ to-server flows should be associated.
+
+ On receipt of a "_result" transaction response on Stream ID 0 for the
+ client's connect command, the connection is up.
+
+ The client MAY open additional return control flows to the server on
+ Stream ID 0, associated to the server's canonical NetConnection
+ control flow.
+
+5.3.3. setPeerInfo Command
+
+ The "setPeerInfo" command is sent by the client to the server over
+ the NetConnection control flow to inform the server of candidate
+ socket addresses through which the client might be reachable. This
+ list SHOULD include all directly connected interface addresses and
+ proxy addresses except as provided below. The list MAY be empty.
+ The list need not include the address of the server, even if the
+ server is to act as an introducer for the client. The list SHOULD
+ NOT include link-local or loopback addresses.
+
+ This command is sent as a regular RTMP NetConnection command; that
+ is, as an RTMP Type 20 Command Message or an RTMP Type 17 Command
+ Extended Message on Stream ID 0. A Type 20 Command Message SHOULD be
+ used if the object encoding negotiated during the "connect" and
+
+
+
+
+Thornburgh Informational [Page 37]
+
+RFC 7425 Adobe RTMFP for Flash Communication December 2014
+
+
+ "_result" handshake is AMF0 [AMF0], and a Type 17 Command Extended
+ Message SHOULD be used if the negotiated object encoding is AMF3
+ [AMF3].
+
+ Note: A Type 20 Command Message payload is a sequence of AMF objects
+ encoded in AMF0.
+
+ Note: A Type 17 Command Extended Message payload begins with a format
+ selector byte, followed by a sequence of objects in a format-specific
+ encoding. At the time of writing, only format 0 is defined;
+ therefore, the format selector byte MUST be 0. Format 0 is a
+ sequence of AMF objects, each encoded in AMF0 by default; AMF3
+ encoding for an object can be selected by prefixing it with an
+ "avmplus-object-marker" (0x11) as defined in [AMF0].
+
+ To complete the RTMFP NetConnection handshake, an RTMFP client MUST
+ send a setPeerInfo command to the server after receiving a successful
+ response to the "connect" command.
+
+ (
+ "setPeerInfo", // AMF String, command name
+ 0.0, // AMF Number, transaction ID
+ NULL, // AMF Null, no command object
+ ... // zero or more AMF Strings, each an address
+ )
+
+ Each listed socket address includes an IPv4 or IPv6 address in
+ presentation format and a UDP port number in decimal, separated by a
+ colon. Since the IPv6 address presentation format uses colons, IPv6
+ addresses are enclosed in square brackets [RFC3986].
+
+ (
+ "setPeerInfo",
+ 0.0,
+ NULL,
+ "192.0.2.129:50001",
+ "[2001:db8:1::2]:50002"
+ )
+
+ Figure 3: Example setPeerInfo Command
+
+ A server SHOULD assume that the client is behind a Network Address
+ Translator (NAT) if and only if the observed far endpoint address of
+ the session for the flow on which this command was received does not
+ appear in the setPeerInfo address list.
+
+
+
+
+
+
+Thornburgh Informational [Page 38]
+
+RFC 7425 Adobe RTMFP for Flash Communication December 2014
+
+
+5.3.4. Set Keepalive Timers Command
+
+ The server can advise the client to set or change the client's
+ session keepalive timer periods for its connection to the server and
+ for its P2P connections. The server MAY choose keepalive periods
+ based on static configuration, application- or deployment-specific
+ circumstances, whether the client appears to be behind a NAT, or for
+ any other reason.
+
+ The Set Keepalive Timers command is sent by the server to the client
+ on Stream ID 0 as a User Control event message (Type 4) having Event
+ Type 41. Message timestamps are ignored and MAY be set to 0.
+
+ 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
+ +-+-+-+-+-+-+-+-+
+ | 4 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | timestamp |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | eventType = 41 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | serverKeepalivePeriodMsec |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | peerKeepalivePeriodMsec |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ struct setKeepaliveUserControlMessagePayload_t
+ {
+ uint16_t eventType = 41;
+ uint32_t serverKeepalivePeriodMsec;
+ uint32_t peerKeepalivePeriodMsec;
+ } :10*8;
+
+ eventType: The RTMP User Control Message Event Type. Set Keepalive
+ Timers messages have type 41 (0x29);
+
+ serverKeepalivePeriodMsec: The keepalive period, in milliseconds,
+ that the client is advised to set on its RTMFP session with the
+ server;
+
+ peerKeepalivePeriodMsec: The keepalive period, in milliseconds, that
+ the client is advised to use on its RTMFP sessions with any peer
+ that is not the server.
+
+
+
+
+
+
+
+
+Thornburgh Informational [Page 39]
+
+RFC 7425 Adobe RTMFP for Flash Communication December 2014
+
+
+ The client MUST define minimum values for these keepalive periods,
+ below which it will not set them, regardless of the values in this
+ message. The minimum keepalive timer periods SHOULD be at least five
+ seconds. The client MAY define maximum values for these keepalive
+ periods, above which it will not set them.
+
+ On receipt of this message from the server, a client SHOULD set its
+ RTMFP server and peer keepalive timer periods to the indicated values
+ subject to the client's minimum and maximum values. The server MAY
+ send this message more than once, particularly if conditions that it
+ uses to determine the timer periods change.
+
+5.3.5. Additional Flows for Streams
+
+ The client or server opens additional flows to the other side to
+ carry messages for any stream. Additional flows are associated to
+ the canonical NetConnection control flow from the other side.
+
+ Client Server
+ ------>--C2S-Control-Flow------------------------->--+
+ |
+ +--<------------------------S2C-Control-Flow---<--+
+ | |
+ | <------------------------S2C-Stream-Flow-1--<--+
+ | : |
+ | <------------------------S2C-Stream-Flow-M--<--+
+ |
+ +-->--C2S-Stream-Flow-1------------------------>
+ | :
+ +-->--C2S-Stream-Flow-N------------------------>
+
+ Figure 4: Schematic Flow Association Tree for a NetConnection
+
+5.3.5.1. To Server
+
+ Additional flows from the client to the server for stream messages
+ are opened with the Stream ID for that stream and associated in
+ return to the server's canonical NetConnection control flow.
+
+ The client MAY create as many flows as desired for any Stream ID
+ (including Stream ID 0) at any time.
+
+5.3.5.2. From Server
+
+ Additional flows from the server to the client for stream messages
+ are opened with the Stream ID for that stream, and associated in
+ return to the client's NetConnection control flow.
+
+
+
+
+Thornburgh Informational [Page 40]
+
+RFC 7425 Adobe RTMFP for Flash Communication December 2014
+
+
+ The server MAY create as many flows as desired for any Stream ID
+ (including Stream ID 0) at any time.
+
+5.3.5.3. Closing Stream Flows
+
+ Either end MAY close a sending flow that is not for Stream ID 0 at
+ any time with no semantic meaning for the stream.
+
+ At any time, either end MAY reject a receiving flow that is not one
+ of the other end's NetConnection control flows. No flow exception
+ codes are defined by this profile, so the receiving end SHOULD use
+ exception code 0 when rejecting the flow. The sending end, on
+ notification of any exception for a stream flow, SHOULD NOT open a
+ new flow to take the rejected flow's place for transport of messages
+ for that stream. If an end rejects any flow for a stream, it SHOULD
+ reject all the flows for that stream, otherwise Flow Synchronization
+ messages (Section 5.2) that were in flight could be discarded and
+ some flows might become or remain stuck in a suspended state.
+
+5.3.6. Closing the Connection
+
+ The client or server can signal an orderly close of the connection by
+ closing its NetConnection control sending flows and all stream
+ sending flows. The other end, on receiving a close/complete
+ notification for the canonical NetConnection control receiving flow,
+ closes its sending flows. When both ends observe all receiving flows
+ have closed and completed, the connection has cleanly terminated.
+
+ Either end can abruptly terminate the connection by rejecting the
+ NetConnection control receiving flows or by closing the underlying
+ RTMFP session. On notification of any exception on a NetConnection
+ control sending flow, the end seeing the exception knows the other
+ end has terminated abruptly, and can immediately close all sending
+ and receiving flows for that connection.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Thornburgh Informational [Page 41]
+
+RFC 7425 Adobe RTMFP for Flash Communication December 2014
+
+
+5.3.7. Example
+
+ Client Server
+ |IHello (EPD:anc=URI) |
+ -+- |------------------------>|
+ | | |
+ | | RHello (RCert:anc)|
+ RTMFP | |<------------------------|
+ Session| | |
+ Hand- | |IIKeying |
+ shake | |------------------------>|
+ | | |
+ | | RIKeying|
+ -+- |<------------------------|
+ | |
+ -+- |"connect" command |
+ (Str.ID=0)|-CFlow-0---------------->|
+ | | |
+ | | "_result" response|
+ RTMP | |<----------------SFlow-0-|(Str.ID=0,
+ Connect| | | Assoc=CFlow-0)
+ Hand- | |"setPeerInfo" command |
+ shake | |-CFlow-0---------------->|
+ -+- | |
+ |"createStream" command |
+ -+- |-CFlow-0---------------->|
+ | | |
+ | | "_result" (str.ID=5)|
+ | |<----------------SFlow-0-|
+ | | |
+ | |"play" command |
+ (Str.ID=5,|-CFlow-1---------------->|
+ Assoc=SFlow-0)| |
+ | | StreamBegin User Control|
+ | |<----------------SFlow-1-|(Str.ID=5,
+ | | | Assoc=CFlow-0)
+ | | (RTMP stream events) |
+ Streaming | |<----------------SFlow-1-|
+ | | |
+ | | Audio Data |
+ | |<----------------SFlow-2-|(Str.ID=5,
+ | | | Assoc=CFlow-0)
+ | | Video Data |
+ | |<----------------SFlow-3-|(Str.ID=5,
+ | | : | Assoc=CFlow-0)
+ | : |
+
+ Figure 5: Example NetConnection Message Exchange
+
+
+
+Thornburgh Informational [Page 42]
+
+RFC 7425 Adobe RTMFP for Flash Communication December 2014
+
+
+5.4. Direct Peer-to-Peer Streams
+
+ Clients can connect directly to other clients for P2P streaming and
+ data exchange. A client MAY have multiple separate P2P NetStreams
+ with a peer in one RTMFP session, each a separate logical connection.
+ P2P NetStreams are unidirectional, initiated by a subscriber (the
+ side issuing the "play" command) to a publisher. The subscribing
+ peer has a control flow to the publisher. The publisher has zero or
+ more return flows to the subscriber associated to the subscriber's
+ control flow, for the stream media and data.
+
+5.4.1. Connecting
+
+ A client desires to subscribe directly to a stream being published in
+ P2P mode by a publishing peer. The client learns the peer ID of the
+ publisher and the stream name through application-specific means.
+
+ If the client does not already have an RTMFP session with that peer
+ ID, it initiates a new session, creating an EPD containing a
+ Fingerprint option (Section 4.4.2.3) for the publisher's peer ID and
+ using the server session's DESTADDR as the initial candidate address
+ for the session to the peer. The server acts as an Introducer
+ (Section 3.5.1.6 of RFC 7016), using forward and redirect messages to
+ help the client and the peer establish a session.
+
+ When an S_OPEN session exists to the desired peer, the client creates
+ a new independent flow to that peer. The flow MUST have a non-zero
+ Stream ID. The client sends an RTMP "play" command over the flow,
+ giving the name of the desired stream at the publisher. This flow is
+ the subscriber's control flow.
+
+5.4.2. Return Flows for Stream
+
+ The publisher, on accepting a new flow not indicating a return
+ association with any of its sending flows and having a non-zero
+ Stream ID, receives and processes the "play" command. If and when
+ the request is acceptable to the publisher, it opens one or more
+ return flows to the subscribing peer, associated to the subscriber's
+ control flow and having the same Stream ID. The publisher sends a
+ StreamBegin User Control message, appropriate RTMP status events, and
+ the stream media over the one or more return flows.
+
+ The subscriber uses the return association of the media flows to the
+ subscriber control flow to determine the stream to which the media
+ belongs.
+
+
+
+
+
+
+Thornburgh Informational [Page 43]
+
+RFC 7425 Adobe RTMFP for Flash Communication December 2014
+
+
+ The publisher MAY open any number of media flows for the stream and
+ close them at any time. The opening and closing of media flows has
+ no semantic meaning for the stream, except that the opening of at
+ least one flow and the reception of at least one media message or a
+ StreamBegin User Control message indicates that the publisher is
+ publishing the requested stream to the subscriber.
+
+ Subscriber Publisher
+ ------>--Subscriber-Control-Flow------------------>--+
+ |
+ <------------------Publisher-Stream-Flow-1--<--+
+ : |
+ <------------------Publisher-Stream-Flow-N--<--+
+
+ Figure 6: Schematic Flow Association Tree for a P2P Direct Connection
+
+5.4.3. Closing the Connection
+
+ Either end can close the stream by closing or rejecting the
+ subscriber's control flow. The publisher SHOULD close and unpublish
+ to the subscriber on receipt of a close/complete of the control flow.
+ The subscriber SHOULD consider the stream closed on notification of
+ any exception on the control flow.
+
+6. IANA Considerations
+
+ This memo specifies option type code values for Certificate fields
+ (Section 4.3.3), Endpoint Discriminator fields (Section 4.4.2), and
+ Session Keying Component fields (Section 4.5.2). It also specifies a
+ flow metadata signature (Section 5.1.1). The type code values and
+ signatures for this profile are assigned and maintained by Adobe, and
+ therefore require no action from IANA.
+
+6.1. RTMFP URI Scheme Registration
+
+ This memo describes use of an RTMFP URI scheme (Section 4.4.2.2,
+ Section 5.3.1, Figure 5). Per this section, the "rtmfp" URI scheme
+ has been registered by IANA.
+
+ The syntax and semantics of this URI scheme are described using the
+ Augmented Backus-Naur Form (ABNF) [RFC5234] rules from RFC 3986.
+
+
+
+
+
+
+
+
+
+
+Thornburgh Informational [Page 44]
+
+RFC 7425 Adobe RTMFP for Flash Communication December 2014
+
+
+ URI scheme name: rtmfp
+
+ Status: provisional
+
+ URI scheme syntax:
+
+ rtmfp-uri-scheme = "rtmfp:"
+ / "rtmfp://" host [ ":" port ] path-abempty
+
+ URI scheme semantics: The first form is used in the APIs of some
+ implementations to indicate instantiation of an RTMFP client
+ according to this memo, but without connecting to a server. Such
+ an instantiation might be used for pure peer-to-peer
+ communication.
+
+ The second form provides location information for the server to
+ which to connect and optional additional information to pass to
+ the server. The only operation for this URI form is to connect to
+ a server (initial candidate address(es) for which are named by
+ host and port) according to Section 5.3. The UDP port for initial
+ candidate addresses, if not specified, is 1935. If the host is a
+ reg-name, the initial candidate address set SHOULD comprise all
+ IPv4 and IPv6 addresses to which reg-name resolves. The semantics
+ of path-abempty are specific to the server. Connections are made
+ using RTMFP as specified by this memo.
+
+ Encoding considerations: The path-abempty component represents
+ textual data consisting of characters from the Universal Character
+ Set. This component SHOULD be encoded according to Section 2.5 of
+ RFC 3986.
+
+ Applications/protocols that use this URI scheme name: The Flash
+ runtime (including Flash Player) from Adobe Systems Incorporated,
+ communication servers such as Adobe Media Server, and
+ interoperable clients and servers provided by other parties, using
+ RTMFP according to this memo.
+
+ Interoperability considerations: This scheme requires use of RTMFP
+ as defined by RFC 7016 in the manner described by this memo.
+
+ Security considerations: See Security Considerations (Section 7) in
+ this memo.
+
+ Contact: Michael Thornburgh, Adobe Systems Incorporated,
+ <mthornbu@adobe.com>.
+
+ Author/Change controller: Michael Thornburgh, Adobe Systems
+ Incorporated, <mthornbu@adobe.com>.
+
+
+
+Thornburgh Informational [Page 45]
+
+RFC 7425 Adobe RTMFP for Flash Communication December 2014
+
+
+ References:
+ Thornburgh, M., "Adobe's Secure Real-Time Media Flow Protocol",
+ RFC 7016, November 2013.
+
+ This memo.
+
+7. Security Considerations
+
+ Section 4 details the cryptographic aspects of this profile.
+
+ This profile does not define or use a Public Key Infrastructure
+ (PKI). Clients SHOULD use static Diffie-Hellman keys in their
+ certificates (Section 4.3.3.5). Clients MUST create a new
+ certificate with a distinct fingerprint for each new NetConnection
+ (Section 5.3). These constraints make client identities ephemeral
+ but unable to be forged. A man-in-the-middle cannot successfully
+ interpose itself in a connection to a target client addressed by its
+ fingerprint/peer ID if the target client uses a static Diffie-Hellman
+ public key.
+
+ Servers can have long-lived RTMFP instances, so they SHOULD use
+ ephemeral Diffie-Hellman public keys for forward secrecy. This
+ allows server peer IDs to be forged; however, clients do not connect
+ to servers by peer ID, so this is irrelevant.
+
+ When a client connects to a server, the client will accept the
+ response of any endpoint claiming to be "a server". It is assumed
+ that an attacker that can passively observe traffic on a network
+ segment can also inject its own packets with any source or
+ destination and any payload. An attacker can trick a client into
+ connecting to a rogue server or man-in-the-middle, either by
+ observing Initiator Hello packets from the client and responding
+ earliest with a matching Responder Hello or by using tricks such as
+ DNS spoofing or poisoning to direct a client to connect directly to
+ the rogue. A TCP-based transport would be vulnerable to similar
+ attacks. Since there is no PKI, this profile gives no guarantee that
+ the client has actually connected to the desired server, versus a
+ rogue or man-in-the-middle. In circumstances where assurance is
+ required that the connection is directly to the desired server, the
+ client can use the Session Nonces (Section 4.6.5) to challenge the
+ server, for example, over a different channel having acceptable
+ security properties (such as an HTTPS) to transitively establish the
+ server's identity and verify that the end-to-end communication is
+ private and authentic.
+
+ When session sequence numbers (Section 4.7.3.3) are not used, it is
+ possible for an attacker to use traffic analysis techniques and
+ record encrypted packets containing the start of a new flow, and
+
+
+
+Thornburgh Informational [Page 46]
+
+RFC 7425 Adobe RTMFP for Flash Communication December 2014
+
+
+ later to replay those packets after the flow has closed, which can
+ look to the receiver like a brand new flow. In circumstances where
+ this can be detrimental, session sequence numbers SHOULD be used.
+ Replay of packets for existing flows is not detrimental as the
+ receiver detects and discards duplicate flow sequence numbers, and
+ flow sequence numbers do not wrap or otherwise repeat.
+
+ Packet encryption uses CBC with the same (null) initialization vector
+ for each packet. This can reveal to an observer whether two packets
+ contain identical plaintext. However, the maximum-length RTMFP
+ common header and User Data or Data Acknowledgement header, including
+ flow sequence number, always fit within the first 16-byte cipher
+ block, so each initial cipher block for most packets will already be
+ unique even if timestamps are suppressed. Sending identical messages
+ in a flow uses unique flow sequence numbers, so cipher blocks will be
+ unique in this case. Keepalive pings and retransmission of lost data
+ can result in identical cipher blocks; however, traffic analysis can
+ also reveal likely keepalives or retransmissions, and retransmission
+ only occurs as a result of observable network loss, so this is
+ usually irrelevant. In circumstances where any identical cipher
+ block is unacceptable, session sequence numbers SHOULD be used as
+ they guarantee each initial cipher block will be unique.
+
+ Packet verification can use a 16-bit simple checksum
+ (Section 4.7.3.1). The checksum is inside the encrypted packet, so
+ for external packet modifications the checksum is equivalent to a
+ 16-bit cryptographic digest. In circumstances where this is
+ insufficient, HMAC verification (Section 4.7.3.2) SHOULD be used.
+
+8. References
+
+8.1. Normative References
+
+ [AES] National Institute of Standards and Technology, "Advanced
+ Encryption Standard (AES)", FIPS PUB 197, November 2001,
+ <http://csrc.nist.gov/publications/fips/fips197/
+ fips-197.pdf>.
+
+ [AMF0] Adobe Systems Incorporated, "Action Message Format -- AMF
+ 0", December 2007, <http://www.adobe.com/go/spec_amf0>.
+
+ [AMF3] Adobe Systems Incorporated, "Action Message Format -- AMF
+ 3", January 2013, <http://www.adobe.com/go/spec_amf3>.
+
+ [CBC] Dworkin, M., "Recommendation for Block Cipher Modes of
+ Operation", NIST Special Publication 800-38A, December
+ 2001, <http://csrc.nist.gov/publications/nistpubs/800-38a/
+ sp800-38a.pdf>.
+
+
+
+Thornburgh Informational [Page 47]
+
+RFC 7425 Adobe RTMFP for Flash Communication December 2014
+
+
+ [DH] Diffie, W. and M. Hellman, "New Directions in
+ Cryptography", IEEE Transactions on Information Theory, V.
+ IT-22, n. 6, June 1977.
+
+ [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
+ Hashing for Message Authentication", RFC 2104, February
+ 1997, <http://www.rfc-editor.org/info/rfc2104>.
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997,
+ <http://www.rfc-editor.org/info/rfc2119>.
+
+ [RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP)
+ Diffie-Hellman groups for Internet Key Exchange (IKE)",
+ RFC 3526, May 2003,
+ <http://www.rfc-editor.org/info/rfc3526>.
+
+ [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
+ 10646", STD 63, RFC 3629, November 2003,
+ <http://www.rfc-editor.org/info/rfc3629>.
+
+ [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
+ Resource Identifier (URI): Generic Syntax", STD 66, RFC
+ 3986, January 2005,
+ <http://www.rfc-editor.org/info/rfc3986>.
+
+ [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
+ Specifications: ABNF", STD 68, RFC 5234, January 2008,
+ <http://www.rfc-editor.org/info/rfc5234>.
+
+ [RFC6234] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms
+ (SHA and SHA-based HMAC and HKDF)", RFC 6234, May 2011,
+ <http://www.rfc-editor.org/info/rfc6234>.
+
+ [RFC7016] Thornburgh, M., "Adobe's Secure Real-Time Media Flow
+ Protocol", RFC 7016, November 2013,
+ <http://www.rfc-editor.org/info/rfc7016>.
+
+ [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T.
+ Kivinen, "Internet Key Exchange Protocol Version 2
+ (IKEv2)", STD 79, RFC 7296, October 2014,
+ <http://www.rfc-editor.org/info/rfc7296>.
+
+ [RTMP] Adobe Systems Incorporated, "Real-Time Messaging Protocol
+ (RTMP) specification", December 2012,
+ <http://www.adobe.com/go/spec_rtmp>.
+
+
+
+
+
+Thornburgh Informational [Page 48]
+
+RFC 7425 Adobe RTMFP for Flash Communication December 2014
+
+
+ [SHA256] National Institute of Standards and Technology, "Secure
+ Hash Standard", FIPS PUB 180-4, March 2012,
+ <http://csrc.nist.gov/publications/fips/fips180-4/
+ fips-180-4.pdf>.
+
+8.2. Informative References
+
+ [RFC1035] Mockapetris, P., "Domain names - implementation and
+ specification", STD 13, RFC 1035, November 1987,
+ <http://www.rfc-editor.org/info/rfc1035>.
+
+ [RFC1071] Braden, R., Borman, D., Partridge, C., and W. Plummer,
+ "Computing the Internet checksum", RFC 1071, September
+ 1988, <http://www.rfc-editor.org/info/rfc1071>.
+
+ [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December
+ 2005, <http://www.rfc-editor.org/info/rfc4302>.
+
+ [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC
+ 4303, December 2005,
+ <http://www.rfc-editor.org/info/rfc4303>.
+
+ [RFC6479] Zhang, X. and T. Tsou, "IPsec Anti-Replay Algorithm
+ without Bit Shifting", RFC 6479, January 2012,
+ <http://www.rfc-editor.org/info/rfc6479>.
+
+Acknowledgements
+
+ Special thanks go to Glenn Eguchi, Matthew Kaufman, and Adam Lane for
+ their contributions to the design of this profile.
+
+ Thanks to Philipp Hancke, Kevin Igoe, Paul Kyzivat, and Milos
+ Trboljevac for their detailed reviews of this memo.
+
+Author's Address
+
+ Michael C. Thornburgh
+ Adobe Systems Incorporated
+ 345 Park Avenue
+ San Jose, CA 95110-2704
+ United States
+
+ Phone: +1 408 536 6000
+ EMail: mthornbu@adobe.com
+ URI: http://www.adobe.com/
+
+
+
+
+
+
+Thornburgh Informational [Page 49]
+