Problem - Kevin Tafuro

ut they shouldn’t tolerate reordering, because doing so means foregoing standard
capture replay prevention. You can always drop out-of-order messages or explicitly
keep track of recent message numbers that have been seen, then drop any duplicates
or any messages with a number that comes before that window.
Particularly if you’re using TCP, if a message fails to authenticate cryptographically,
recovering is tremendously difficult. Accidental errors will almost always be caught
at the TCP level, and you can assume that if the cryptography catches it, an attacker
is tampering. In such a case, a smart attacker can cause a denial of service, no matter
what. It’s generally easiest to terminate the connection, perhaps sending back an
error packet first.
Often, unrecoverable errors result in plaintext error messages. In such cases, you
should be conservative and send no reason code signaling why you failed. There are
instances in major protocols where verbose errors led to an important information
leak.
When you’re designing your protocol for client-server communications, you should
include a sequence of messages between both parties to communicate to the other
side that the connection is being terminated normally. That way, when a connection
is prematurely terminated, both sides of the connection have some way of knowing
whether the connection was terminated legitimately or was the result of a possible
attack. In the latter case, you may wish to take appropriate action. For example, if
the connection is prematurely terminated in the process of performing some database
operation, you may want to roll back any changes that were made.
The next consideration is what the message format should look like. Generally, a
message format will start out with a plaintext, fixed-size field encoding the length of
the remainder of the message. Then, there may or may not be plaintext values, such
as the message number (the message number can go inside the ciphertext, but often
it’s useful for computing the nonce, as opposed to assuming it). Finally comes the
ciphertext and the MAC value (which may be one unit, depending on whether you
use an authenticating encryption mode such as CWC).
Any unencrypted data in the message should be authenticated in a secure manner
along with the encrypted data. Modes like CWC and CCM allow you to authenticate
both plaintext and ciphertext with a single MAC value. CMAC has the same
capability. With other MACs, you can simulate this behavior by MAC’ing the length
of the plaintext portion, concatenated with the plaintext portion, concatenated with
the ciphertext. To do this correctly, however, you must always include the plaintext
length, even if it is zero.
Assume that we’ve established a TCP connection and exchanged a 128-bit key using
a protocol such as PAX (as discussed in Recipe 8.15). Now, what should we do with
that key? The answer depends on a few things. First, we might need separate keys for
encryption and MAC’ing if we’re not using a dual-use mode such as CWC. Second,
Building an Authenticated Secure Channel Without SSL | 493
This is the Title of the Book, eMatter Edition
Copyright © 2007 O’Reilly & Associates, Inc. All rights reserved.