diff --git a/draft-ftl-specification-00.xml b/draft-ftl-specification-00.xml index 743de73..2f10895 100644 --- a/draft-ftl-specification-00.xml +++ b/draft-ftl-specification-00.xml @@ -258,10 +258,85 @@ Option2: 1234\r\n\r\n
- TDB + + A Charon client handshake opens with the HMAC command which is used for authentication, and requests a payload to sign as to show ownership of a channel. + + After receiving this command, The server will generate a random byte array from here on known as the Authentication Challenge. + The server will then respond with the FTL_OK response status followed by the hex encoded value of the Authentication Challenge, as shown in the following figure. +
+ +
+ + + The Authentication Challenge SHOULD be derived from a Cryptographically Secure Pseudo-Random Number Generator (CSPRNG) and MUST be unique for every session. + A Charon client MUST be agnostic about the casing of the hexidecimal data, and for that reason no standard is provided, and the examples of the following figure are the same value. + +
- TDB + After a Charon client has received and succesfully decoded the Authentication Challenge from it's hexidecimal presentation, the Charon client will use their shared key to sign the Authentication Challenge by the use of HMAC-SHA512. + The Authentication Challenge will be used as message data and the shared key will be used as key. + The resulting payload of this hasing function will be hex encoded and will from here on be known as the Proof. + + The Charon client will then respond to the server with the CONNECT command, by providing their identifier and the Proof which is prefixed with a dollar sign ($). + A valid command based on the example response given for HMAC is shown in the following figure. + The secret key used for this example is charon + +
+ +
+ + When the Charon server is unable to validate the proof the Charon server MUST respond with the FTL_INVALID_STREAM_KEY response code, as shown in the following figure. + +
+ +
+ + + Just like the Authentication Challenge, a server MUST be agnostic about the casing of the hexidecimal data of the Proof. + + +
+
+ + Once the Charon client has authenticated with the server, the client will send the server the metadata about the stream the client wants to publish. + + The Metadata Fields will be sent in key value parts, split by a colon (:) and then followed by newlines, the client will terminte the metadata stream with a line containing only a singular dot (.) + A simple definition of this is shown in the following figure. + + +
+ * "." + + +metadata-field = ":" ? + + +metadata-key = +metadata-value = +]]> +
+ + + While the Charon client sends metadata fields the server MUST only respond once it receives the terminator. + + + while the Charon metadata definition might resemble MIME Header Fields (RFC 822 3.2) it is not compliant and MUST NOT be treated as such.
TBD