3.4 Session Security Details

If it is negotiated, session security provides message integrity (signing) and message confidentiality (sealing). When NTLM v2 authentication is not negotiated, only one key is used for sealing. As a result, operations are performed in a half-duplex mode: the client sends a message and then waits for a server response. For information on how key exchange, signing, and sealing keys are generated, see KXKEY, SIGNKEY, and SEALKEY.

In connection-oriented mode, messages are assumed to be received in the order sent. The application or communications protocol is expected to guarantee this property. As a result, the client and server sealing keys are computed only once per session.

For the cases of ANONYMOUS user and Guest user login, there is no session security (see section 3.2.5.1.2).

Note In connectionless mode, messages can arrive out of order. Because of this, the sealing key MUST be reset for every message. Rekeying with the same sealing key for multiple messages would not maintain message security. Therefore, a per-message sealing key, SealingKey', is computed as the MD5 hash of the original sealing key and the message sequence number. The resulting SealingKey' value is used to reinitialize the key state structure prior to invoking the following SIGN, SEAL, and MAC algorithms. To compute the SealingKey' and initialize the key state structure identified by the Handle parameter, use the following:

 SealingKey' = MD5(ConcatenationOf(SealingKey, SequenceNumber))
 RC4Init(Handle, SealingKey')