Goals
- No replays
- No spoofing
- Minimal sessions
No signatures for data, sender must be able to deny sending ala OTR, but recipient must be confident that the sender sent the data.
Fields
- protocol - The main version #, 2 in this case
- sub-proto - Something identifying this as a unicast datagram
destination - CAKE ID of destination
source - CAKE ID of source
- message id - Consisting of the subfields 'session' and 'sequence'
- (Only if sequence is 0) crypto data - encrypted and signed block cipher key and MAC key
- service - The service this message is destined for
message parts - all parts of flag 0 until the very last part which has a flag 1 - The total length of all the parts must not exceeed 276 bytes.
- end flag - 0 if this is a data part, 1 for the MAC block at the end.
- For a flag of 0
- length
- encrypted body
- For a flag of 1
- encrypted 256 bit MAC block for the concatenation of all the decrypted message bodies plus the header.
- For a flag of 0
- end flag - 0 if this is a data part, 1 for the MAC block at the end.
Session IDs, sequence numbers and Message IDs
A session represents a particular block cipher key and MAC key.
It's suggested that sessions be remembered for at least 5 seconds, but it is not required.
All sessions start with sequence # 0. Messages with a sequence # of 0 MUST contain a block cipher key and a MAC key signed by the source encrypted to the destination that the destination can retrieve and verify with no further messages exchanged with the source (provided that it already knows the source's full public key).
Handling of message IDs
A message id is considered a globally unique identifier for a message from the source to the destination. As such, there is some processing that should occur to ensure this rule is properly maintained.
A message id taken as a whole is a monotonically increasing number. This means that you can base a sliding window on the message id and toss out messages that are too 'old' to fit in the window. This greatly simplifies protection against replay attacks as you only have to remember the specific message ids you've recieved within the window.
Use of protocol data in higher layer protocols
The service receiving the message knows the source, the destination, and the message id. It should not worry about the internal structure of the message id. It may use these fields in its messages and reference previously seen messages by their message id.
In particular, when acknowledging reciept of data, reference to the message id being acknowledged is encouraged.