Problem - Kevin Tafuro

negotiate which version of the protocol is to be used, and perhaps negotiate which
cryptographic algorithms and key sizes are to be used.
In situations like this, there is the threat of a rollback attack, which occurs when an
attacker tampers with messages during establishment and tricks the parties into
negotiating an insecure set of parameters (such as an old, broken version of a protocol).
A good protocol for authentication and key exchange, such as PAX or SAX (see Recipe
8.15), ensures that there are no opportunities for rollback in the context of the
protocol. If you don’t have messages that come before the key exchange, and if you
immediately start using your encryption key after the exchange using an authenticated
encryption solution, you can do other kinds of negotiation (such as agreeing on
a protocol) and not have to worry about rollback.
If, on the other hand, you send messages before your key exchange, or you create
your own end-to-end protocol (neither is a solution we recommend), you will need
to protect against replay attacks on your own. To accomplish this, after connection
establishment, have each side MAC every message that it thinks took place during
the establishment. If the client sends its MAC first, and the server validates it, the
server should MAC not only the establishment messages but also the MAC value
sent by the client. Similarly, if the server sends the MAC first, the client should
include the server’s MAC in its response.
Our overall recommendation is not to introduce SSL-style configurability for your
cryptography. If, for example, you use PAX, the only real option possible in the
whole key exchange and authentication process is the size of the key that gets
exchanged. We recommend that you use that key in a strong predetermined authenticated
encryption scheme without negotiation. If you feel that you absolutely must
allow for algorithm negotiation, we recommend you have a highly conservative
default that you immediately start using after the key exchange, such as AES in CWC
mode with 256-bit keys, and allow for renegotiation.
As we discuss in Recipe 6.21, you should use a message counter along with a MAC
to thwart capture replay attacks. Message counters can also help determine when
messages arrive out of order or are dropped, if you always check that the message
number increases by exactly one (standard capture replay detection only checks to
make sure the message number always increases).
Note that if you’re using a “reliable” transport such as TCP, you will get modest prevention
against message reordering and dropped messages. TCP’s protection against
these problems is not cryptographically secure, however. A savvy attacker can still
launch such attacks in a manner that the TCP layer will not detect.
In some environments, message ordering and dropping aren’t a big deal. These are
the environments in which you would traditionally use an “unreliable” protocol such
as UDP. Generally, cryptographically strong protocols may be able to tolerate drops,
492 | Chapter 9: Networking
This is the Title of the Book, eMatter Edition
Copyright © 2007 O’Reilly & Associates, Inc. All rights reserved.