2B or not 2B, that is the question. Dave Challener, During TCG TSS Working Group discussion of decrypt/encrypt sessions
Chapter 13 briefly touched on decrypt and encrypt sessions. As you may remember, these are per-command session modifiers. This chapter describes these two session modifiers in detail: what they do, practical uses of them, some limitations on them, how to set them up, and some code examples.
What Do Encrypt/Decrypt Sessions Do?
In a nutshell, decrypt and encrypt sessions protect secrets being transmitted over an insecure medium. A caller, to protect the confidentiality of data, can encrypt it with a command encryption key known only to the caller and the TPM. The encryption key is determined, in part, by the parameters used to start the session (more on that later).
A decrypt session then informs the TPM that the first parameter is encrypted. This means after receiving the parameter, the TPM must decrypt it—hence the name, decrypt session. For a response, an encrypt session indicates that the TPM has encrypted the first response parameter before returning it to the caller, which is why it's called an encrypt session. After receiving the encrypted response parameter, the caller uses the response decryption key to decrypt the data.
Two different symmetric-key modes can be used for decrypt and encrypt sessions: XOR and CFB. CFB mode offers stronger encryption but requires that the TPM and the caller both have access to a hashing algorithm and an encryption algorithm. XOR requires only a hashing algorithm and is the right choice for very small code size, but it is less secure.
Practical Use Cases
So, what are these symmetric key modes good for? The quick answer is that there are many ways to use them; just look in Part 3 of the TPM 2.0 specification for every command that has a TPM2B as a first command and/or first response parameter. All of those parameters are possible candidates to be encrypted.
A small sampling of common use cases are as follows:
• Tpm2_Create: The first command parameter to this command, inSensitive, is a structure which contains the password (called userAuth in the structure description) in one of its fields. This should probably be sent to the TPM encrypted, which would require that the session be set up as a decrypt session. 
• Confidential data being written to or read from TPM NV indexes. Suppose you want to use the TPM NV indexes to save password information or personal credit card information. Encrypting
this data before sending it to or receiving it from the TPM helps protect it.
• Use of decrypt and encrypt sessions becomes even more important when communicating with a remote TPM over the network. Suppose you want to store keys on a remote server and recover them from client machines. Sending these in the clear over the network is obviously insecure. SSL sessions can remedy the network snooping vulnerability, but the keys are still in the clear in multiple software layers on the client and server machines. Encrypt and decrypt sessions can vastly reduce the attack surface.
-  There's an interesting wrinkle related to the first response parameter from Tpm2_Create: even though this parameter is a TPM2B and could be encrypted by setting the session as an encrypt session, it's always encrypted by the TPM. Encrypting it again would seem to be of little value.