This blog talks about site-aware DFS referral introduced in Windows Server 2012. Extended DFS referrals provide remote client computers with optimal DFS referrals when the computers connect to the corporate network by using DirectAccess. This blog also describes how to configure a Window 8 client to issue extended DFS referral request for testing a SMB 3 server implementation.

Feature summary

Windows Server 2012 added extended DFS referral which enables the support of site awareness for Direct Access clients on Windows 8.

When a user on Windows 8 connects to Windows Server 2012 based DFS namespaces over Direct Access, the client receives referrals to the namespace servers and folder targets that are closest to their location.

In Windows 7, a remote computer (e.g. connected over Direct Access) whose IP address is outside of the sites specified in Active Directory would receive DFS referrals in a random order (from Windows Server 2008 R2 namespace server), including servers in distant sites. This may cause network latency and increased bandwidth usage.

In Windows 8, Direct Access was enhanced with site awareness. When accessing a DFS namespace over a Direct Access connection, the client provides a site name in the DFS referral request to Windows Server 2012 namespace server. The server uses the site name to order the referrals so that the client can get to the closest site available.

The extended DFS referral is sent using the new control code FSCTL_DFS_GET_REFERRALS_EX [MS-SMB2].  It is important to note that if an SMB 3.x server is DFS capable, it must support extended DFS referral. All Windows-based SMB 3.x servers (2012 and 2012 R2) support this new FSCTL.

Windows 8 implementation-specific triggers

A Windows-based DFS client decides to use FSCTL_DFS_GET_REFERRALS_EX if the computer is connected over Direct Access and the negotiated SMB dialect is 3.0 or above.

The extended referral provisioning is done on Windows 8/8.1 by Direct Access configuration.
The DFS client detects that the client is connected over Direct Access if UseDcLocatorSiteName != 0. Direct Access also provisions the SiteName configuration. Recall that the value of the SiteName entry takes precedence over the value of DynamicSiteName (which is dynamically set by Netlogon service; the site that the computer belongs to can be determined with DsGetSiteName API call). 

The following instructions may be practical for testing an SMB 3 server implementation with extended DFS referral. The key is to get the client issue the new FSCTL by setting the configuration that Direct Access would have provisioned.
When a Windows client requests for site-aware referrals, the server should not fail with the request, even with STATUS_NOT_SUPPORTED, otherwise the client will not be able to access the SMB 3 share, because there is no fallback mechanism from FSCTL_DFS_GET_REFERRALS_EX to FSCTL_DFS_GET_REFERRALS.

Windows-based extended DFS referrals testing

In my testing environment, I have a configuration similar to the following.

DC01 is running Windows Server 2012 in this site MS-SMB_Internal.
DFS Management \ Namespaces
SiteName MS-SMB_Internal
Namespace \\contoso.com\ShareVolume1, Add folder Share1 with target \\dc01\FileShare2

On the Windows 8 client:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Dfsc\Parameters
UseDcLocatorSiteName = 1
This indicates to the DFS client that the client is connected over “Direct Access”.
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters
SiteName MS-SMB_Internal
(SiteName is a string)
NOTE: If the SiteName is not configured, the client will issue FSCTL_DFS_GET_REFERRALS.
Restart Workstation service, and accept to restart Netlogon and Dfs Namespace services.

With the proper configuration, the client will send site-aware referral requests when asking for DFS referrals over SMB 3 connections.

— Site-aware DFS referral request example —

- SMB2: C   IOCTL (0xb), FID=0xFFFFFFFFFFFFFFFF FSCTL_DFS_GET_REFERRALS_EX,
  – CIoCtl:
     StructureSize: 57 (0x39)
     Reserved: 0 (0x0)
     CtlCode: FSCTL_DFS_GET_REFERRALS_EX
   + FileId: Persistent: 0xFFFFFFFFFFFFFFFF, Volatile: 0xFFFFFFFFFFFFFFFF
     InputOffset: 120 (0x78)
     InputCount: 97 (0x61)
     MaxInputResponse: 0 (0x0)
     OutputOffset: 120 (0x78)
     OutputCount: 0 (0x0)
     MaxOutputResponse: 4096 (0x1000)
     Flags: (00000000000000000000000000000001) FSCTL request
     Reserved2: 0 (0x0)
   – ReqGetDFSReferralEx:
      MaxReferralLevel: 4 (0x4)
    – RequestFlags: 1 (0x1)
       SiteName: (……………1) – SiteName present: The SiteName bit MUST be set to 1 if the packet contains the site name of the client.
       Unused:   (000000000000000.) – Unused
      RequestDataLength: 88 (0x58)
    – RequestData:
       RequestFileNameLength: 52 (0x34)
       RequestFileName: \contoso.com\ShareVolume1
       SiteNameLength: 32 (0x20)
       SiteName: MS-SMB_Internal
    padding: Binary Large Object (1 Bytes)

— Response example —

- SMB2: R   IOCTL (0xb) FSCTL_DFS_GET_REFERRALS_EX,
  – RIoCtl:
     StructureSize: 49 (0x31)
     Reserved: 0 (0x0)
     CtlCode: FSCTL_DFS_GET_REFERRALS_EX
   + FileId: Persistent: 0xFFFFFFFFFFFFFFFF, Volatile: 0xFFFFFFFFFFFFFFFF
     InputOffset: 112 (0x70)
     InputCount: 0 (0x0)
     OutputOffset: 112 (0x70)
     OutputCount: 184 (0xB8)
     Flags: 0 (0x0)
     Reserved2: 0 (0x0)
   – RespGetDFSReferral:
      PathConsumed: 50 bytes
      NumberOfReferrals: 1 (0x1)
    + ReferralHeaderFlags: 3 (0x3)
    – ReferralEntries: Version:4
     – ReferralV4: Index:1 TTL:300 Seconds
        VersionNumber: 0x4, MUST be set to 0x4
        Size: 34 (0x22)
        ServerType: Root targets returned
      + ReferralEntryFlags: 4 (0x4)
        TimeToLive: 300 Seconds
        DfsPathOffset: 34 (0x22) Offset:0xD4
        DfsAlternatePathOffset: 86 (0x56) Offset:0x108
        NetworkAddressOffset: 138 (0x8A) Offset:0x13C
        ServiceSiteGuid: {00000000-0000-0000-0000-000000000000} 
       DfsPath: Index:1 \contoso.com\ShareVolume1
       DfsAlternatePath: Index:1 \contoso.com\ShareVolume1
       TargetPath: Index:1 \DC01\ShareVolume1 

References

What’s New in DFS Namespaces and DFS Replication in Windows Server 2012
http://technet.microsoft.com/en-us/library/dn270370.aspx

How DFS Works
http://technet.microsoft.com/en-us/library/cc782417(v=WS.10).aspx

[MS-DFSC]: Distributed File System (DFS): Referral Protocol
http://msdn.microsoft.com/en-us/library/cc226982.aspx
[MS-CIFS]: Common Internet File System (CIFS) Protocol
http://msdn.microsoft.com/en-us/library/ee442092.aspx
[MS-SMB2]: Server Message Block (SMB) Protocol Versions 2 and 3
http://msdn.microsoft.com/en-us/library/cc246482.aspx
DirectAccess
http://technet.microsoft.com/en-us/windows/directaccess.aspx
SiteName
http://technet.microsoft.com/en-us/library/cc937923.aspx
DynamicSiteName
http://technet.microsoft.com/en-us/library/cc960209.aspx

Summary

This Blog will use the sample Heap-on-Node (HN) from section 3.8 of MS-PST and walk through the process of how to read a property from it. The current version of the MS-PST open specification document can be found here: http://msdn.microsoft.com/en-us/library/ff385210(office.12).aspx

Introduction

First, it’s important to understand that there are several layers and structures involved here. A basic understanding of the NDB and LTP layers is extremely helpful, but not required.

The construction of the Heap-on-Node can be summarized as follows:

1. The Block is a Heap-on-Node.
2. The BTree-on-Heap is built on top of the Heap-on-Node.
3. The Property Context is built on top of the BTree-on-Heap.

The HNHDR

First, we will take a look at the HNHDR which is the first 12 bytes of the block.

Figure 1: The HNHDR.

For now, we really only care about 2 of the properties here. The first 2 bytes which is the ibHnpm property with a value of 0x00EC. This is the offset from the beginning of the block to the beginning of the HNPAGEMAP. The 4th byte is the bClientSig with a value of 0xBC. This tells us that this block contains a Property Context which is built on top of a BTree-on-Heap. This will be important later.

The HNPAGEMAP

Looking at the offset in the Block specified by the ibHnpm property, it’s not possible to know the length of the HNPAGEMAP until you read the first property, cAlloc, which in this case is 0x0008. This tells us that the rgibAlloc table will contain 9 (8 + 1) entries. Each entry is a 2 byte WORD value. So, the length of the rgibAlloc table is 18 (9 * 2) bytes in length. Add the 2 bytes each for cAlloc and cFree and you get the total length of the HNPAGEMAP which is 22 bytes. Reading all 22 bytes we have the following.

Figure 2: The HNPAGEMAP.

Starting at the 5th byte, read the next 18 bytes as a series of 2-byte values to get a list of the offsets for the starting location of each allocation in the block. The 9th offset is a place holder that tells an application where the next allocation should start, it is not an allocation that contains data.

1. 0x000C
2. 0x0014
3. 0x006C
4. 0x007C
5. 0x008C
6. 0x00A4
7. 0x00BC
8. 0x00D4
9. 0x00EC

The first allocation starting at offset 0x000C will be the BTHHEADER which is 8 bytes in length.

The BTHHEADER

Figure 3: The BTHHEADER.

We care about 3 values from the BTHHEADER; cbKey, cbEnt, and hidRoot.

It’s VERY important to understand that the hidRoot is a HID structure that should be read as 2 separate 2-byte values and NOT as a single 4-byte value.

The combination of the cbKey and cbEnt tells us how long each PC BTH Record will be. Remember back when we looked at the HNHDR and the bClientSig value was 0xBC (bTypePC)? That’s how we know that the records will be PC BTH Records. In this case, each record will be 8 bytes in length.

Locating The hidRoot

The hidRoot is worth spending a little bit more time talking about. The current version of the MS-PST document (v2.1, 2/10/2014) is missing some vital information for working with HID structures. The current version of the documentation was valid for older versions of Outlook, however the current version of Outlook handles this structure differently. The exact version of Outlook that first handled it this way is not known.

Looking at the hidRoot we know that the hidBlockIndex is 0x0000 which means that the heap item is contained in the same block we are currently looking at. The hidIndex has a value of 0x0040 which seems strange because it’s supposed to be the 1-based index to the heap item where we can look to start reading some PC BTH Records. Since this BTree-on-Heap node only contains 8 allocations, it couldn’t possibly be the 64th allocation.

In order to get the correct allocation index we need to bit shift the hidIndex 5 places to the right. This will result in a value of 0x0002. Therefore, the PC BTH Records begin at the second allocation. This information should be included in a future release of the documentation and is vital in obtaining the correct hidIndex value.

Reading The PC BTH Records

We now have enough information to read the collection of PC BTH Records from the second allocation. First, in order to determine the length of the 2nd allocation we subtract the offset of the 3rd allocation from the offset of the 2nd. 0x6C – 0x14 = 0x58 (88 bytes).

Figure 4: The PC BTH Records.

We also know that each PC BTH Record is 8 bytes. Dividing 88 bytes by 8 bytes each gives us 11 records.

• 34 0E 02 01 A0 00 00 00
• 38 0E 03 00 00 00 00 00
• F9 0F 02 01 60 00 00 00
• 01 30 1F 00 80 00 00 00
• DF 35 03 00 89 00 00 00
• E0 35 02 01 C0 00 00 00
• E3 35 02 01 00 01 00 00
• E7 35 02 01 E0 00 00 00
• 33 66 0B 00 01 00 00 00
• FA 66 03 00 0D 00 0E 00
• FF 67 03 00 00 00 00 00

Each PC BTH Record starts with a 2-byte wPropId and a 2-byte wPropType. The list of possible wPropType values can be found in MS-OXCDATA section 2.11.1 and MS-OXPROPS contains the Master Property List which is probably the best place to look for Property ID values. However, you will also find Property ID values scattered throughout other documents where those properties are used.

Getting The Property

We will use the 4th PC BTH Record for demonstration purposes because we can easily look up what the Property ID and type is. The wPropId is 0x3001 and the wPropType is 0x001F. Searching in MS-OXPROPS we find that it belongs to the PidTagDisplayName property and that the type is PtypString. According to MS-OXCDATA section 2.11.1 the PtypString is “Variable size; a string of Unicode characters in UTF-16LE format encoding with terminating null character (0x0000).”

Now that we know what the property and the type is we can go retrieve it. The 3rd property of the PC BTH Record is the dwValueHnid which can represent a few different things. Refer to MS-PST section 2.3.3.3 on how to determine what the type of data stored in it. In this case, it’s a HID structure. Reading the hidIndex value of 0x0080 and bitshifting it 5 places to the right (like we did for the hidRoot earlier) we get an index value of 0x0004. That means that the string value that belongs to the PidTagDisplayName is stored in the 4th allocation of this block. Looking back at the list of offsets from the HNPAGEMAP we can see that the 4th allocation starts at offset 0x007C and is 0x10 (16 bytes) in length.

Figure 5: pidTagDisplayName.

This represents the string “UNICODE1″. Unfortunately, this block does not contain any other meaningful properties that we can look up in MS-OXPROPS, but if there were you would follow the same process.

Figure 6: Complete Heap-On-Node Property Context Block.

Pre-authentication integrity is one of the new SMB 3.1.1 security improvements in Windows 10 and Windows Server 2016 TP2 (technical preview 2). It improves protection from a man-in-the-middle (MITM) attacker in tampering with SMB2’s connection establishment and authentication messages. This new feature supersedes “secure dialect negotiation” introduced in SMB 3.0, which only protected against MITM attempt to downgrade the initially negotiated dialect and capabilities. This blog also provides test vectors for SMB 3.1.1 pre-authentication integrity.  

Summary

Pre-authentication integrity is a mandatory feature in SMB 3.1.1. It protects against any tampering with SMB2’s Negotiate and Session Setup messages by leveraging cryptographic hashing. The resulting hash is used as input to derive the session’s cryptographic keys, including its signing key. This enables the client and server to mutually trust the connection and session properties.

Overview

Signing has been a feature in SMB2 protocol since its inception. In the first two dialects 2.0.2, and 2.1, signing is effectively applied to message exchange once authentication is completed. Prior to SMB 3.0, there was no tampering protection to messages before authentication completion. SMB 3.0 “negotiate validation” provides some interesting but limited protection; the negotiate validation occurs after the session setup.
SMB 3.1.1 provides end-to-end integrity of pre-authentication messages. The session’s cryptographic keys are derived based on a hash of pre-authentication messages:
• This allows the client and server to validate signature or decryption of subsequent authenticated messages.
• The final session setup response is always signed, and as a result the client would fail signature validation in case of pre-authentication message tampering.
• The client must either sign or encrypt the Tree Connect request. This confirms to the server that both mutually derived the same keys, and validates there was no pre-authentication message tampering.
Please note that for guest and anonymous sessions, there is no protection since no keys can be derived.  

Pre-auth integrity hash

Pre-authentication is the exchange of negotiate and session setup messages until the session’s cryptographic keys can be derived, which is the point where authentication is completed.
Let’s take the example of an n-leg GSS-API authentication, pre-authentication integrity hash will consist of these SMB2 messages:
• Negotiate request,
• Negotiate response,
• Session setup request (leg-1),
• Session setup response (leg-1),
• . . .
• Session setup request (leg-n),
The processing of Session setup request (leg-n) results in an authentication “completed” state. The server then calculates the session’s signing key. The key derivation takes one of its inputs as the cumulative hash of Negotiate request through Session setup request (leg-n).
Pre-auth-integrity-hash (x) = PreauthIntegrityHash (Concatenate (Pre-auth-integrity-hash (x-1), pre-auth-message (x)))
Where:
x = 1, …, 2n + 1,
Pre-auth-integrity-hash (0) = zeros,
pre-auth-message (1) = Negotiate request,
. . .
pre-auth-message (2n + 1) = Session setup request (leg-n).
For SMB 3.1.1, the PreauthIntegrityHash function is SHA-512, the standard specified in [FIPS180-4].
The hash value used as input for key derivation is:
Session.PreauthIntegrityHashValue = Pre-auth-integrity-hash (2n + 1)
Note that the final session setup response is not part of the integrity hash calculation.
• Session setup response(leg-n)
However, this session setup response is signed (for SMB 3.1.1, AES-128-CMAC with SigningKey), allowing the client to verify the signature, and authenticate the source of the data. A successful signature verification, of a subsequent message (e.g. TreeConnect), validates that the client and server computed the same PreauthIntegrityHashValue and derived the same key.
NOTE: Since the hash is cumulative and there is no validation until the final step, implementers could approach the PreauthIntegrityHashValue calculation in many ways. One could choose to compute the temporary hash at each step, i.e. message sent or received. Another way is to calculate the temporary hash on a pair of request and response at a time except for the final session setup leg. Yet, another approach is to iterate through a number requests and responses at once. It all depends on whether the design can temporarily hold vectors of requests and responses. This should be a design consideration in case the implementation intends to handle applications where sessions will be very short lived, or on a server with a high volume of authenticated sessions. 

Pre-auth integrity capability negotiate context

If the client includes 0x0311 in the SMB2 NEGOTIATE’s Dialects array (i.e. the client supports SMB 3.1.1), it must add the SMB2_PREAUTH_INTEGRITY_CAPABILITIES negotiate context, as specified in MS-SMB2.
If the server selects SMB 3.1.1 dialect, it must convey the selected integrity hash algorithm by including a SMB2_PREAUTH_INTEGRITY_CAPABILITIES negotiate context in the NEGOTIATE response.
The pre-authentication integrity negotiate context has the same format in the Negotiate request and response, except that the response context must have a HashAlgorithmCount set to 1. In Windows 10, the pre-authentication integrity hash algorithm is SHA-512.
Note that Windows 10 and Windows Server 2016 TP2 use 32 bytes of randomly generated Salt. The salt value and its length are implementation-dependent, and as a result, it is recommended to use a secure PRNG to prevent from dictionary attacks.

SigningKey derivation

The signing key is derived as specified in [MS-SMB2]:
SigningKey = SMB3KDF (SessionKey, “SMBSigningKey\0″, Session.PreauthIntegrityHashValue)
SMB3KDF() is defined as the key derivation function (KDF) in Counter Mode, as specified in [SP800-108] section 5.1, with ‘r’ value of 32 and ‘L’ value of 128, and HMAC-SHA256 as the PRF.
SigningKey is the leftmost L bits of KDF result.
The SessionKey is the key derivation key. It set to the first 16 bytes of the cryptographic key queried from the GSS protocol (e.g. Kerberos [MS-KILE], or NTLM [MS-NLMP]) for this authenticated context. If the cryptographic key is less than 16 bytes, it is right-padded with zero bytes. Extracting the session key from GSS-API is implementation-dependent. In SSPI (Microsoft’s implementation of GSS-API), the session key is extracted by using QueryContextAttributes with SECPKG_ATTR_SESSION_KEY.
In NTLM, the SessionKey is the ExportedSessionKey returned when QueryContextAttributes is called with SECPKG_ATTR_SESSION_KEY. ExportedSessionKey is described in MS-NLMP.
In Kerberos [RFC4120], the SessionKey returned for QueryContextAttributes call with SECPKG_ATTR_SESSION_KEY is either the sub-session key (subkey) if it was negotiated during KRB_AP_REQ/KRB_AP_REP exchange, or the session key from the ticket if no subkey was negotiated.
The label is “SMBSigningKey\0”.
The context is Session.PreauthIntegrityHashValue.
Session.PreauthIntegrityHashValue is calculated as outlined earlier.

Proxy and traffic accelerator

Pre-authentication integrity might hinder solutions that rely on modifying SMB2 packets. For example, a so-called WAN accelerator needs to accept negotiate contexts. Any change to the pre-authentication packets would require to be transparent to the client (Kerberos constraint delegation, authentication token). On one hand, the client and device in the middle must derive the same keys. One the other hand, the device and server must arrive at the same keys once the authenticated context is completed.
This should not be seen as an issue. If the device was able to decode traffic, it is because it somehow has access to the user’s secret password or is allowed to act on behalf on the user. This is typically enabled through participating in a domain, or performing constraint delegation. 

Windows 10 RequireSecureNegotiate interop with SMB 3.0.x down-level servers

When a Windows 10 negotiates SMB 2.x.x or 3.0.x with a down-level server (e.g. Windows 2008 / 2008, R2, Windows Server 2012 / 2012 R2), it will always send FSCTL_VALIDATE_NEGOTIATE_INFO to attempt performing dialect negotiation validation. Most, if not all, third party implementations comply to secure negotiate validation IOCTL, or lack thereof, to proper handling of an unsupported IOCTL. This makes unnecessary the need for a RequireSecureNegotiate workaround.
In a nutshell, the RequireSecureNegotiate registry setting has been removed in Windows 10 release. It is no longer allowed to disable secure negotiate from Windows 10 clients when connecting to down-level servers.
Down-level servers which do not support the FSCTL_VALIDATE_NEGOTIATE_INFO are mandated to sign the error response since the request is signed. Typical error codes are STATUS_NOT_SUPPORTED, STATUS_INVALID_DEVICE_REQUEST or STATUS_FILE_CLOSED.

Conclusion

While pre-authentication integrity protects the session establishment phase in SMB 3.1.1, enabling signing would generally offer integrity check at large and protect from an attacker tampering with any packet. Signing has a cost, but its benefit generally outweighs the performance effect. 

Appendix: Test vector for SMB 3.1.1 pre-authentication integrity

This sample data should be considered “as-is”. It should also be noted that
examples do not replace normative protocol specifications. The reference must
be [MS-SMB2].

Our test client negotiates SMB 3.1.1 and communicates with a Windows server
2016 TP2.

Here are examples of the major steps for pre-authentication integrity
computation:

Appendix A. Pre-authentication integrity and encryption negotiate contexts

Appendix A.1 Windows 10 with its supported negotiate contexts

Header.Command 0x0000 NEGOTIATE

Preauth integrity hash capabilities —

PreauthIntegrityCaps.HashAlgorithmCount 0x1

PreauthIntegrityCaps.SaltLength 0x20

PreauthIntegrityCaps.HashAlgorithms 0x0001

PreauthIntegrityCaps.Salt

FA49E6578F1F3A9F4CD3E9CC14A67AA884B3D05844E0E5A118225C15887F32FF

Encryption capabilites —

EncryptionCaps.CipherCount 0x2

EncryptionCaps.Ciphers[0] 0x0002

EncryptionCaps.Ciphers[1] 0x0001

Connection.PreauthIntegrityHashId 0x0001

NEGOTIATE Request

Preauth integrity hash —

Current

Connection.PreauthIntegrityHashValue

00000000000000000000000000000000000000000000000000000000000000000000000000000000

000000000000000000000000000000000000000000000000

Negotiate request packet

FE534D4240000100000000000000800000000000000000000100000000000000FFFE000000000000

00000000000000000000000000000000000000000000000024000500000000003F000000ECD86F32

6276024F9F7752B89BB33F3A70000000020000000202100200030203110300000100260000000000

010020000100FA49E6578F1F3A9F4CD3E9CC14A67AA884B3D05844E0E5A118225C15887F32FF0000

0200060000000000020002000100

Concatenate Connection.PreauthIntegrityHashValue and Negotiate request
packet

SHA-512 Input Hash Data

00000000000000000000000000000000000000000000000000000000000000000000000000000000

000000000000000000000000000000000000000000000000FE534D42400001000000000000008000

00000000000000000100000000000000FFFE00000000000000000000000000000000000000000000

000000000000000024000500000000003F000000ECD86F326276024F9F7752B89BB33F3A70000000

020000000202100200030203110300000100260000000000010020000100FA49E6578F1F3A9F4CD3

E9CC14A67AA884B3D05844E0E5A118225C15887F32FF00000200060000000000020002000100

New

Connection.PreauthIntegrityHashValue

DD94EFC5321BB618A2E208BA8920D2F422992526947A409B5037DE1E0FE8C7362B8C47122594CDE0

CE26AA9DFC8BCDBDE0621957672623351A7540F1E54A0426

NEGOTIATE Response

Updating Preauth integrity hash —

Current

Connection.PreauthIntegrityHashValue

DD94EFC5321BB618A2E208BA8920D2F422992526947A409B5037DE1E0FE8C7362B8C47122594CDE0

CE26AA9DFC8BCDBDE0621957672623351A7540F1E54A0426

Negotiate response packet

FE534D4240000100000000000000010001000000000000000100000000000000FFFE000000000000

000000000000000000000000000000000000000000000000410001001103020039CBCAF329714942

BDCE5D60F09AB3FB2F000000000080000000800000008000D8DAE5ADCBAED00109094AB095AED001

80004001C00100006082013C06062B0601050502A08201303082012CA01A3018060A2B0601040182

3702021E060A2B06010401823702020AA282010C048201084E45474F455854530100000000000000

60000000700000007C7CC0FD06D6362D02DDE1CF343BFE292900F49750B4AA97934D9C4296B26E51

FD370471B235E15A50DAE15BD5489C87000000000000000060000000010000000000000000000000

5C33530DEAF90D4DB2EC4AE3786EC3084E45474F4558545303000000010000004000000098000000

7C7CC0FD06D6362D02DDE1CF343BFE295C33530DEAF90D4DB2EC4AE3786EC3084000000058000000

3056A05430523027802530233121301F06035504031318546F6B656E205369676E696E6720507562

6C6963204B65793027802530233121301F06035504031318546F6B656E205369676E696E67205075

626C6963204B6579010026000000000001002000010060A3C3B95C3C7CCD51EC536648D9B3AC74C4

83CA5B65385A251117BEB30712E50000020004000000000001000200

Concatenate Connection.PreauthIntegrityHashValue and Negotiate response
packet

SHA-512 Input Hash Data

DD94EFC5321BB618A2E208BA8920D2F422992526947A409B5037DE1E0FE8C7362B8C47122594CDE0

CE26AA9DFC8BCDBDE0621957672623351A7540F1E54A0426FE534D42400001000000000000000100

01000000000000000100000000000000FFFE00000000000000000000000000000000000000000000

0000000000000000410001001103020039CBCAF329714942BDCE5D60F09AB3FB2F00000000008000

0000800000008000D8DAE5ADCBAED00109094AB095AED00180004001C00100006082013C06062B06

01050502A08201303082012CA01A3018060A2B06010401823702021E060A2B06010401823702020A

A282010C048201084E45474F45585453010000000000000060000000700000007C7CC0FD06D6362D

02DDE1CF343BFE292900F49750B4AA97934D9C4296B26E51FD370471B235E15A50DAE15BD5489C87

0000000000000000600000000100000000000000000000005C33530DEAF90D4DB2EC4AE3786EC308

4E45474F45585453030000000100000040000000980000007C7CC0FD06D6362D02DDE1CF343BFE29

5C33530DEAF90D4DB2EC4AE3786EC30840000000580000003056A05430523027802530233121301F

06035504031318546F6B656E205369676E696E67205075626C6963204B6579302780253023312130

1F06035504031318546F6B656E205369676E696E67205075626C6963204B65790100260000000000

01002000010060A3C3B95C3C7CCD51EC536648D9B3AC74C483CA5B65385A251117BEB30712E50000

020004000000000001000200

New

Connection.PreauthIntegrityHashValue

324BFA92A4F3A190E466EBEA08D9C110DC88BFED758D9846ECC6F541CC1D02AE3C94A79F36011E99

7E13F841B91B50957AD07B19C8E2539C0B23FDAE09D2C513

Add NEW SessionId 0x17592186044441 to Preauth Integrity hash table with
value

Connection.PreauthIntegrityHashValue

324BFA92A4F3A190E466EBEA08D9C110DC88BFED758D9846ECC6F541CC1D02AE3C94A79F36011E99

7E13F841B91B50957AD07B19C8E2539C0B23FDAE09D2C513

SESSION SETUP Request

PreauthSession.SessionId 0x17592186044441

Current

PreauthSession.PreauthIntegrityHashValue

324BFA92A4F3A190E466EBEA08D9C110DC88BFED758D9846ECC6F541CC1D02AE3C94A79F36011E99

7E13F841B91B50957AD07B19C8E2539C0B23FDAE09D2C513

SessionSetup request packet

FE534D4240000100000000000100800000000000000000000200000000000000FFFE000000000000

00000000000000000000000000000000000000000000000019000001010000000000000058004A00

0000000000000000604806062B0601050502A03E303CA00E300C060A2B06010401823702020AA22A

04284E544C4D5353500001000000978208E200000000000000000000000000000000060380250000

000F

Concatenate PreauthSession.PreauthIntegrityHashValue and Session Setup
request packet

SHA-512 Input Hash Data 

324BFA92A4F3A190E466EBEA08D9C110DC88BFED758D9846ECC6F541CC1D02AE3C94A79F36011E99

7E13F841B91B50957AD07B19C8E2539C0B23FDAE09D2C513FE534D42400001000000000001008000

00000000000000000200000000000000FFFE00000000000000000000000000000000000000000000

000000000000000019000001010000000000000058004A000000000000000000604806062B060105

0502A03E303CA00E300C060A2B06010401823702020AA22A04284E544C4D53535000010000009782

08E200000000000000000000000000000000060380250000000F

PreauthSession.PreauthIntegrityHashValue

AC0B0F2B9986257700365E416D142A6EDC96DF03594A19E52A15F6BD0D041CD5D432F8ED42C55E33

197A50C9EC00F1462B50C592211B1471A04B56088FDFD5F9

SESSION SETUP Response

 — STATUS_MORE_PROCESSING_REQUIRED
- Updating Preauth integrity hash —

PreauthSession.SessionId 0x17592186044441

Current

PreauthSession.PreauthIntegrityHashValue

AC0B0F2B9986257700365E416D142A6EDC96DF03594A19E52A15F6BD0D041CD5D432F8ED42C55E33

197A50C9EC00F1462B50C592211B1471A04B56088FDFD5F9

SessionSetup response packet

FE534D4240000100160000C00100010001000000000000000200000000000000FFFE000000000000

190000000010000000000000000000000000000000000000090000004800B300A181B03081ADA003

0A0101A10C060A2B06010401823702020AA281970481944E544C4D53535000020000000C000C0038

00000015828AE20D1D8BA31179D008000000000000000050005000440000000A0092270000000F53

005500540033003100310002000C0053005500540033003100310001000C00530055005400330031

00310004000C0053005500540033003100310003000C0053005500540033003100310007000800A1

A1F5ADCBAED00100000000

SessionSetup response header signature 0x00000000000000000000000000000000

Concatenate PreauthSession.PreauthIntegrityHashValue and Session Setup
response packet

SHA-512 Input Hash Data

AC0B0F2B9986257700365E416D142A6EDC96DF03594A19E52A15F6BD0D041CD5D432F8ED42C55E33

197A50C9EC00F1462B50C592211B1471A04B56088FDFD5F9FE534D4240000100160000C001000100

01000000000000000200000000000000FFFE00000000000019000000001000000000000000000000

0000000000000000090000004800B300A181B03081ADA0030A0101A10C060A2B0601040182370202

0AA281970481944E544C4D53535000020000000C000C003800000015828AE20D1D8BA31179D00800

0000000000000050005000440000000A0092270000000F53005500540033003100310002000C0053

005500540033003100310001000C0053005500540033003100310004000C00530055005400330031

00310003000C0053005500540033003100310007000800A1A1F5ADCBAED00100000000

PreauthSession.PreauthIntegrityHashValue

2729E3440DFDDD839E37193F6E8F20C20CEFB3469E453A70CD980EEC06B8835740A7376008563336

4C8989895ECE81BF102DEEB14D4B7D48AFA76901A7A38387

SESSION SETUP Request

PreauthSession.SessionId 0x17592186044441

Current

PreauthSession.PreauthIntegrityHashValue

2729E3440DFDDD839E37193F6E8F20C20CEFB3469E453A70CD980EEC06B8835740A7376008563336

4C8989895ECE81BF102DEEB14D4B7D48AFA76901A7A38387

SessionSetup request packet

FE534D4240000100000000000100800000000000000000000300000000000000FFFE000000000000

1900000000100000000000000000000000000000000000001900000101000000000000005800CF01

0000000000000000A18201CB308201C7A0030A0101A28201AA048201A64E544C4D53535000030000

001800180090000000EE00EE00A80000000C000C00580000001A001A0064000000120012007E0000

001000100096010000158288E2060380250000000FECAC77A5F385A8BF9C38C706EEEDDCD3530055

005400330031003100610064006D0069006E006900730074007200610074006F0072004400520049

0056004500520033003100310000000000000000000000000000000000000000000000000063078E

B639FE03E20A231C3AE3BF23080101000000000000A1A1F5ADCBAED001BC4AD05F223CC90F000000

0002000C0053005500540033003100310001000C0053005500540033003100310004000C00530055

00540033003100310003000C0053005500540033003100310007000800A1A1F5ADCBAED001060004

00020000000800300030000000000000000000000000300000B61FEFCAA857EA57BF1EDCEBF8974B

8E0EBA5A6DFD9D07A31D11B548F8C9D0CC0A00100000000000000000000000000000000000090016

0063006900660073002F005300550054003300310031000000000000000000000000003B9BDFF38F

5EE8F9663F11A0F4C03A78A31204100100000063775A9A5FD97F0600000000

Concatenate PreauthSession.PreauthIntegrityHashValue and Session Setup
request packet

SHA-512 Input Hash Data 

2729E3440DFDDD839E37193F6E8F20C20CEFB3469E453A70CD980EEC06B8835740A7376008563336

4C8989895ECE81BF102DEEB14D4B7D48AFA76901A7A38387FE534D42400001000000000001008000

00000000000000000300000000000000FFFE00000000000019000000001000000000000000000000

00000000000000001900000101000000000000005800CF010000000000000000A18201CB308201C7

A0030A0101A28201AA048201A64E544C4D53535000030000001800180090000000EE00EE00A80000

000C000C00580000001A001A0064000000120012007E0000001000100096010000158288E2060380

250000000FECAC77A5F385A8BF9C38C706EEEDDCD3530055005400330031003100610064006D0069

006E006900730074007200610074006F007200440052004900560045005200330031003100000000

00000000000000000000000000000000000000000063078EB639FE03E20A231C3AE3BF2308010100

0000000000A1A1F5ADCBAED001BC4AD05F223CC90F0000000002000C005300550054003300310031

0001000C0053005500540033003100310004000C0053005500540033003100310003000C00530055

00540033003100310007000800A1A1F5ADCBAED00106000400020000000800300030000000000000

000000000000300000B61FEFCAA857EA57BF1EDCEBF8974B8E0EBA5A6DFD9D07A31D11B548F8C9D0

CC0A001000000000000000000000000000000000000900160063006900660073002F005300550054

003300310031000000000000000000000000003B9BDFF38F5EE8F9663F11A0F4C03A78A312041001

00000063775A9A5FD97F0600000000

PreauthSession.PreauthIntegrityHashValue

0DD13628CC3ED218EF9DF9772D436D0887AB9814BFAE63A80AA845F36909DB7928622DDDAD522D97

51640A459762C5A9D6BB084CBB3CE6BDADEF5D5BCE3C6C01

SESSION SETUP Response

SessionId 0x17592186044441 COMPLETED

SessionSetup response packet

FE534D4240000100000000000100800009000000000000000300000000000000FFFE000000000000

1900000000100000EBE146DA120BA25FC3376A49DFE31BC10900000048001D00A11B3019A0030A01

00A3120410010000003B453CDC3524164200000000

SessionSetup response header signature 0xEBE146DA120BA25FC3376A49DFE31BC1

PreauthSession.PreauthIntegrityHashValue

0DD13628CC3ED218EF9DF9772D436D0887AB9814BFAE63A80AA845F36909DB7928622DDDAD522D97

51640A459762C5A9D6BB084CBB3CE6BDADEF5D5BCE3C6C01

Input cryptographicKey (SessionKey) 0x270E1BA896585EEB7AF3472D3B4C75A7

(queried from GSS authenticated context)

— Dialect 0x0311 —

preauthIntegrityHashValue

0DD13628CC3ED218EF9DF9772D436D0887AB9814BFAE63A80AA845F36909DB7928622DDDAD522D97

51640A459762C5A9D6BB084CBB3CE6BDADEF5D5BCE3C6C01

CypherId 0x0002

SessionKey 0x270E1BA896585EEB7AF3472D3B4C75A7

SigningKey 0x73FE7A9A77BEF0BDE49C650D8CCB5F76

Appendix A.2. Pre-authentication integrity and encryption (AES-CCM) negotiate contexts 

Header.Command 0x0000 NEGOTIATE

Preauth integrity hash capabilities —

PreauthIntegrityCaps.HashAlgorithmCount 0x1

PreauthIntegrityCaps.SaltLength 0x20

PreauthIntegrityCaps.HashAlgorithms 0x0001

PreauthIntegrityCaps.Salt

BE43C3C288C4D3992CD82559E382F0AACEB5A1D936A1BFF07AD1E0C18DB0CA86

Encryption capabilites —

EncryptionCaps.CipherCount 0x1

EncryptionCaps.Ciphers[0] 0x0001

Connection.PreauthIntegrityHashId 0x0001

NEGOTIATE Request

Preauth integrity hash —

Current

Connection.PreauthIntegrityHashValue

00000000000000000000000000000000000000000000000000000000000000000000000000000000

000000000000000000000000000000000000000000000000

Negotiate request packet

FE534D4240000100000000000000800000000000000000000100000000000000FFFE000000000000

00000000000000000000000000000000000000000000000024000500000000003F000000C318232F

0EDFFB4D99991F725DA93B3E70000000020000000202100200030203110300000100260000000000

010020000100BE43C3C288C4D3992CD82559E382F0AACEB5A1D936A1BFF07AD1E0C18DB0CA860000

020004000000000001000100

Concatenate Connection.PreauthIntegrityHashValue and Negotiate request
packet

SHA-512 Input Hash Data

00000000000000000000000000000000000000000000000000000000000000000000000000000000

000000000000000000000000000000000000000000000000FE534D42400001000000000000008000

00000000000000000100000000000000FFFE00000000000000000000000000000000000000000000

000000000000000024000500000000003F000000C318232F0EDFFB4D99991F725DA93B3E70000000

020000000202100200030203110300000100260000000000010020000100BE43C3C288C4D3992CD8

2559E382F0AACEB5A1D936A1BFF07AD1E0C18DB0CA860000020004000000000001000100

New

Connection.PreauthIntegrityHashValue

BD11D3C338C8F993B3C9CD75420F331FCBFD6A389ADCEA930593C14D5EFDA3E38F1B0320BD03AACC

78CEA25D9DEFD89324ECA8595F2DAE4C0E01FBEA4A54A428

NEGOTIATE Response

Updating Preauth integrity hash —

Current

Connection.PreauthIntegrityHashValue

BD11D3C338C8F993B3C9CD75420F331FCBFD6A389ADCEA930593C14D5EFDA3E38F1B0320BD03AACC

78CEA25D9DEFD89324ECA8595F2DAE4C0E01FBEA4A54A428

Negotiate response packet

FE534D4240000100000000000000010001000000000000000100000000000000FFFE000000000000

000000000000000000000000000000000000000000000000410001001103020039CBCAF329714942

BDCE5D60F09AB3FB2F000000000080000000800000008000CDCEA973CAAED00109094AB095AED001

80004001C00100006082013C06062B0601050502A08201303082012CA01A3018060A2B0601040182

3702021E060A2B06010401823702020AA282010C048201084E45474F455854530100000000000000

6000000070000000747CC0FD06D6362D02DDE1CF343BFE299B5A978ED39ECF7F343F2F72B151E5C2

F427966D191C624A19F30E0F7132F3D5000000000000000060000000010000000000000000000000

5C33530DEAF90D4DB2EC4AE3786EC3084E45474F4558545303000000010000004000000098000000

747CC0FD06D6362D02DDE1CF343BFE295C33530DEAF90D4DB2EC4AE3786EC3084000000058000000

3056A05430523027802530233121301F06035504031318546F6B656E205369676E696E6720507562

6C6963204B65793027802530233121301F06035504031318546F6B656E205369676E696E67205075

626C6963204B65790100260000000000010020000100ED81E13FE1C5E910AE1299BE60FCA6F54B09

42FA0FB2A92285A947C68AB988810000020004000000000001000100

Concatenate Connection.PreauthIntegrityHashValue and Negotiate response
packet

SHA-512 Input Hash Data

BD11D3C338C8F993B3C9CD75420F331FCBFD6A389ADCEA930593C14D5EFDA3E38F1B0320BD03AACC

78CEA25D9DEFD89324ECA8595F2DAE4C0E01FBEA4A54A428FE534D42400001000000000000000100

01000000000000000100000000000000FFFE00000000000000000000000000000000000000000000

0000000000000000410001001103020039CBCAF329714942BDCE5D60F09AB3FB2F00000000008000

0000800000008000CDCEA973CAAED00109094AB095AED00180004001C00100006082013C06062B06

01050502A08201303082012CA01A3018060A2B06010401823702021E060A2B06010401823702020A

A282010C048201084E45474F4558545301000000000000006000000070000000747CC0FD06D6362D

02DDE1CF343BFE299B5A978ED39ECF7F343F2F72B151E5C2F427966D191C624A19F30E0F7132F3D5

0000000000000000600000000100000000000000000000005C33530DEAF90D4DB2EC4AE3786EC308

4E45474F4558545303000000010000004000000098000000747CC0FD06D6362D02DDE1CF343BFE29

5C33530DEAF90D4DB2EC4AE3786EC30840000000580000003056A05430523027802530233121301F

06035504031318546F6B656E205369676E696E67205075626C6963204B6579302780253023312130

1F06035504031318546F6B656E205369676E696E67205075626C6963204B65790100260000000000

010020000100ED81E13FE1C5E910AE1299BE60FCA6F54B0942FA0FB2A92285A947C68AB988810000

020004000000000001000100

New

Connection.PreauthIntegrityHashValue

7744458C12FB7387C68B767ED06E8A684BB0AA1F4E49E6C195B55CB47138F2BCDD9489EC5CF10FEE

04EF5192817EE3D6694F34965D33C177F296F915452B929B

Add NEW SessionId 0x17592186044425 to Preauth Integrity hash table with
value

Connection.PreauthIntegrityHashValue

7744458C12FB7387C68B767ED06E8A684BB0AA1F4E49E6C195B55CB47138F2BCDD9489EC5CF10FEE

04EF5192817EE3D6694F34965D33C177F296F915452B929B

SESSION SETUP Request

PreauthSession.SessionId 0x17592186044425

Current

PreauthSession.PreauthIntegrityHashValue

7744458C12FB7387C68B767ED06E8A684BB0AA1F4E49E6C195B55CB47138F2BCDD9489EC5CF10FEE

04EF5192817EE3D6694F34965D33C177F296F915452B929B

SessionSetup request packet

FE534D4240000100000000000100800000000000000000000200000000000000FFFE000000000000

00000000000000000000000000000000000000000000000019000001010000000000000058004A00

0000000000000000604806062B0601050502A03E303CA00E300C060A2B06010401823702020AA22A

04284E544C4D5353500001000000978208E200000000000000000000000000000000060380250000

000F

Concatenate PreauthSession.PreauthIntegrityHashValue and Session Setup
request packet

SHA-512 Input Hash Data 

7744458C12FB7387C68B767ED06E8A684BB0AA1F4E49E6C195B55CB47138F2BCDD9489EC5CF10FEE

04EF5192817EE3D6694F34965D33C177F296F915452B929BFE534D42400001000000000001008000

00000000000000000200000000000000FFFE00000000000000000000000000000000000000000000

000000000000000019000001010000000000000058004A000000000000000000604806062B060105

0502A03E303CA00E300C060A2B06010401823702020AA22A04284E544C4D53535000010000009782

08E200000000000000000000000000000000060380250000000F

PreauthSession.PreauthIntegrityHashValue

983C28E03CE2F30CA2CF648C95D489DD16E51E027A4A9F7C05A1F9E888AF289C112C77C8A77ACEB1

2EEC19DD6BD550C2303233B11A08F70609D4484D7CDEC58C

SESSION SETUP Response

 — STATUS_MORE_PROCESSING_REQUIRED
- Updating Preauth integrity hash —

PreauthSession.SessionId 0x17592186044425

Current

PreauthSession.PreauthIntegrityHashValue

983C28E03CE2F30CA2CF648C95D489DD16E51E027A4A9F7C05A1F9E888AF289C112C77C8A77ACEB1

2EEC19DD6BD550C2303233B11A08F70609D4484D7CDEC58C

SessionSetup response packet

FE534D4240000100160000C00100010001000000000000000200000000000000FFFE000000000000

090000000010000000000000000000000000000000000000090000004800B300A181B03081ADA003

0A0101A10C060A2B06010401823702020AA281970481944E544C4D53535000020000000C000C0038

00000015828AE2395571B0B34E928C000000000000000050005000440000000A0092270000000F53

005500540033003100310002000C0053005500540033003100310001000C00530055005400330031

00310004000C0053005500540033003100310003000C0053005500540033003100310007000800CC

2FBB73CAAED00100000000

SessionSetup response header signature 0x00000000000000000000000000000000

Concatenate PreauthSession.PreauthIntegrityHashValue and Session Setup
response packet

SHA-512 Input Hash Data

983C28E03CE2F30CA2CF648C95D489DD16E51E027A4A9F7C05A1F9E888AF289C112C77C8A77ACEB1

2EEC19DD6BD550C2303233B11A08F70609D4484D7CDEC58CFE534D4240000100160000C001000100

01000000000000000200000000000000FFFE00000000000009000000001000000000000000000000

0000000000000000090000004800B300A181B03081ADA0030A0101A10C060A2B0601040182370202

0AA281970481944E544C4D53535000020000000C000C003800000015828AE2395571B0B34E928C00

0000000000000050005000440000000A0092270000000F53005500540033003100310002000C0053

005500540033003100310001000C0053005500540033003100310004000C00530055005400330031

00310003000C0053005500540033003100310007000800CC2FBB73CAAED00100000000

PreauthSession.PreauthIntegrityHashValue

C9CA587360D51A1DA5E61E208391B6E5C1846ADC5E5C961614A3A533DE3943E6314C8AE9DE7CDBD1

7E4068ED21F97DEBE879F13724CF3FF21B2C86D99BA59B87

SESSION SETUP Request

PreauthSession.SessionId 0x17592186044425

Current

PreauthSession.PreauthIntegrityHashValue

C9CA587360D51A1DA5E61E208391B6E5C1846ADC5E5C961614A3A533DE3943E6314C8AE9DE7CDBD1

7E4068ED21F97DEBE879F13724CF3FF21B2C86D99BA59B87

SessionSetup request packet

FE534D4240000100000000000100800000000000000000000300000000000000FFFE000000000000

0900000000100000000000000000000000000000000000001900000101000000000000005800CF01

0000000000000000A18201CB308201C7A0030A0101A28201AA048201A64E544C4D53535000030000

001800180090000000EE00EE00A80000000C000C00580000001A001A0064000000120012007E0000

001000100096010000158288E2060380250000000F308F9AF7839280D351E663E84AD3957F530055

005400330031003100610064006D0069006E006900730074007200610074006F0072004400520049

005600450052003300310031000000000000000000000000000000000000000000000000001EAF5A

8F20782DD3B7DFC1562EBFE9240101000000000000CC2FBB73CAAED0012B6C3234196EE8BF000000

0002000C0053005500540033003100310001000C0053005500540033003100310004000C00530055

00540033003100310003000C0053005500540033003100310007000800CC2FBB73CAAED001060004

00020000000800300030000000000000000000000000300000B61FEFCAA857EA57BF1EDCEBF8974B

8E0EBA5A6DFD9D07A31D11B548F8C9D0CC0A00100000000000000000000000000000000000090016

0063006900660073002F00530055005400330031003100000000000000000000000000AEF242481A

FBFB82BEDBE68A4F5742F2A3120410010000007FEE0708D69AD22600000000

Concatenate PreauthSession.PreauthIntegrityHashValue and Session Setup
request packet

SHA-512 Input Hash Data 

C9CA587360D51A1DA5E61E208391B6E5C1846ADC5E5C961614A3A533DE3943E6314C8AE9DE7CDBD1

7E4068ED21F97DEBE879F13724CF3FF21B2C86D99BA59B87FE534D42400001000000000001008000

00000000000000000300000000000000FFFE00000000000009000000001000000000000000000000

00000000000000001900000101000000000000005800CF010000000000000000A18201CB308201C7

A0030A0101A28201AA048201A64E544C4D53535000030000001800180090000000EE00EE00A80000

000C000C00580000001A001A0064000000120012007E0000001000100096010000158288E2060380

250000000F308F9AF7839280D351E663E84AD3957F530055005400330031003100610064006D0069

006E006900730074007200610074006F007200440052004900560045005200330031003100000000

0000000000000000000000000000000000000000001EAF5A8F20782DD3B7DFC1562EBFE924010100

0000000000CC2FBB73CAAED0012B6C3234196EE8BF0000000002000C005300550054003300310031

0001000C0053005500540033003100310004000C0053005500540033003100310003000C00530055

00540033003100310007000800CC2FBB73CAAED00106000400020000000800300030000000000000

000000000000300000B61FEFCAA857EA57BF1EDCEBF8974B8E0EBA5A6DFD9D07A31D11B548F8C9D0

CC0A001000000000000000000000000000000000000900160063006900660073002F005300550054

00330031003100000000000000000000000000AEF242481AFBFB82BEDBE68A4F5742F2A312041001

0000007FEE0708D69AD22600000000

PreauthSession.PreauthIntegrityHashValue

BD57317658D28E7599C2491165F5D6FB36AD0AD65833774A6684D07F83EF2EBAB8726C1D76704AF3

25285A70FCBAD053F39EF4C031AE67C56006C50C6D349EC6

SESSION SETUP Response

SessionId 0x17592186044425 COMPLETED

SessionSetup response packet

FE534D4240000100000000000100800009000000000000000300000000000000FFFE000000000000

090000000010000021AC4DB12F2F6431207BA653FB805C290900000048001D00A11B3019A0030A01

00A312041001000000F19063CADAA8BE2100000000

SessionSetup response header signature 0x21AC4DB12F2F6431207BA653FB805C29

PreauthSession.PreauthIntegrityHashValue

BD57317658D28E7599C2491165F5D6FB36AD0AD65833774A6684D07F83EF2EBAB8726C1D76704AF3

25285A70FCBAD053F39EF4C031AE67C56006C50C6D349EC6

Input cryptographicKey (SessionKey) 0xFD67875E7DF37605F5A9D226991A8782

(queried from GSS authenticated context)

— Dialect 0x0311 —

preauthIntegrityHashValue

BD57317658D28E7599C2491165F5D6FB36AD0AD65833774A6684D07F83EF2EBAB8726C1D76704AF3

25285A70FCBAD053F39EF4C031AE67C56006C50C6D349EC6

CypherId 0x0001

SessionKey 0xFD67875E7DF37605F5A9D226991A8782

SigningKey 0xD9AE56D84460F692E15673D7AC357904

Appendix B. Pre-authentication integrity negotiate context only

Header.Command 0x0000 NEGOTIATE

Preauth integrity hash —

PreauthIntegrityCaps.HashAlgorithmCount 0x1

PreauthIntegrityCaps.SaltLength 0x20

PreauthIntegrityCaps.HashAlgorithms 0x0001

PreauthIntegrityCaps.Salt

E2D024DB75ED67B6323EDB6BD24FC4C97ECD893481CE1BEFDBD1DE3D09DF9DB5

Connection.PreauthIntegrityHashId 0x0001

NEGOTIATE Request

Preauth integrity hash —

Current

Connection.PreauthIntegrityHashValue

00000000000000000000000000000000000000000000000000000000000000000000000000000000

000000000000000000000000000000000000000000000000

Negotiate request packet

FE534D4240000100000000000000800000000000000000000100000000000000FFFE000000000000

00000000000000000000000000000000000000000000000024000500000000003F0000004C3DB6FB

51377A45AB915E5700F9D91B70000000010000000202100200030203110300000100260000000000

010020000100E2D024DB75ED67B6323EDB6BD24FC4C97ECD893481CE1BEFDBD1DE3D09DF9DB5

Concatenate Connection.PreauthIntegrityHashValue and Negotiate request
packet

SHA-512 Input Hash Data

00000000000000000000000000000000000000000000000000000000000000000000000000000000

000000000000000000000000000000000000000000000000FE534D42400001000000000000008000

00000000000000000100000000000000FFFE00000000000000000000000000000000000000000000

000000000000000024000500000000003F0000004C3DB6FB51377A45AB915E5700F9D91B70000000

010000000202100200030203110300000100260000000000010020000100E2D024DB75ED67B6323E

DB6BD24FC4C97ECD893481CE1BEFDBD1DE3D09DF9DB5

New

Connection.PreauthIntegrityHashValue

EF7D572595297374B39788024797DAA020D66D3DF9D3A893CF2CA0442AEE16C6C154F1BC185CAF3F

660139347B9C4CA231161CA8A16073F058B5422045DE7C65

NEGOTIATE Response

Updating Preauth integrity hash —

Current

Connection.PreauthIntegrityHashValue

EF7D572595297374B39788024797DAA020D66D3DF9D3A893CF2CA0442AEE16C6C154F1BC185CAF3F

660139347B9C4CA231161CA8A16073F058B5422045DE7C65

Negotiate response packet

FE534D4240000100000000000000010001000000000000000100000000000000FFFE000000000000

00000000000000000000000000000000000000000000000041000100110301001DE6C96123D11C40

9509F58B06CEB6E52F000000000080000000800000008000ECAC634232B1D001112265502BB1D001

80004001C00100006082013C06062B0601050502A08201303082012CA01A3018060A2B0601040182

3702021E060A2B06010401823702020AA282010C048201084E45474F455854530100000000000000

6000000070000000E396D6D84D7EBFC97CE3BD8B1761B727F0DDDDFF536372E805A6CD3A8CCC5C0F

54F850C98DF6C8C9F7A88AE1FF70590A000000000000000060000000010000000000000000000000

5C33530DEAF90D4DB2EC4AE3786EC3084E45474F4558545303000000010000004000000098000000

E396D6D84D7EBFC97CE3BD8B1761B7275C33530DEAF90D4DB2EC4AE3786EC3084000000058000000

3056A05430523027802530233121301F06035504031318546F6B656E205369676E696E6720507562

6C6963204B65793027802530233121301F06035504031318546F6B656E205369676E696E67205075

626C6963204B657901002600000000000100200001003208BCEB8827C388303D3E51E2D90F710898

D12B04522B5D871A0C031FC7B7B5

Concatenate Connection.PreauthIntegrityHashValue and Negotiate response
packet

SHA-512 Input Hash Data

EF7D572595297374B39788024797DAA020D66D3DF9D3A893CF2CA0442AEE16C6C154F1BC185CAF3F

660139347B9C4CA231161CA8A16073F058B5422045DE7C65FE534D42400001000000000000000100

01000000000000000100000000000000FFFE00000000000000000000000000000000000000000000

000000000000000041000100110301001DE6C96123D11C409509F58B06CEB6E52F00000000008000

0000800000008000ECAC634232B1D001112265502BB1D00180004001C00100006082013C06062B06

01050502A08201303082012CA01A3018060A2B06010401823702021E060A2B06010401823702020A

A282010C048201084E45474F4558545301000000000000006000000070000000E396D6D84D7EBFC9

7CE3BD8B1761B727F0DDDDFF536372E805A6CD3A8CCC5C0F54F850C98DF6C8C9F7A88AE1FF70590A

0000000000000000600000000100000000000000000000005C33530DEAF90D4DB2EC4AE3786EC308

4E45474F4558545303000000010000004000000098000000E396D6D84D7EBFC97CE3BD8B1761B727

5C33530DEAF90D4DB2EC4AE3786EC30840000000580000003056A05430523027802530233121301F

06035504031318546F6B656E205369676E696E67205075626C6963204B6579302780253023312130

1F06035504031318546F6B656E205369676E696E67205075626C6963204B65790100260000000000

0100200001003208BCEB8827C388303D3E51E2D90F710898D12B04522B5D871A0C031FC7B7B5

New

Connection.PreauthIntegrityHashValue

7ECC09ACEC6034FF40F8B0C9F6662C95E2532E6F54D29E922138A65D592FD58FA437712034CD2542

55EAA10BB823507EFCF1654195512A8445D9DE2609F47741

Add NEW SessionId 0x30786325577741 to Preauth Integrity hash table with
value

Connection.PreauthIntegrityHashValue

7ECC09ACEC6034FF40F8B0C9F6662C95E2532E6F54D29E922138A65D592FD58FA437712034CD2542

55EAA10BB823507EFCF1654195512A8445D9DE2609F47741

SESSION SETUP Request

PreauthSession.SessionId 0x30786325577741

Current

PreauthSession.PreauthIntegrityHashValue

7ECC09ACEC6034FF40F8B0C9F6662C95E2532E6F54D29E922138A65D592FD58FA437712034CD2542

55EAA10BB823507EFCF1654195512A8445D9DE2609F47741

SessionSetup request packet

FE534D4240000100000000000100800000000000000000000200000000000000FFFE000000000000

00000000000000000000000000000000000000000000000019000001010000000000000058004A00

0000000000000000604806062B0601050502A03E303CA00E300C060A2B06010401823702020AA22A

04284E544C4D5353500001000000978208E200000000000000000000000000000000060380250000

000F

Concatenate PreauthSession.PreauthIntegrityHashValue and Session Setup
request packet

SHA-512 Input Hash Data 

7ECC09ACEC6034FF40F8B0C9F6662C95E2532E6F54D29E922138A65D592FD58FA437712034CD2542

55EAA10BB823507EFCF1654195512A8445D9DE2609F47741FE534D42400001000000000001008000

00000000000000000200000000000000FFFE00000000000000000000000000000000000000000000

000000000000000019000001010000000000000058004A000000000000000000604806062B060105

0502A03E303CA00E300C060A2B06010401823702020AA22A04284E544C4D53535000010000009782

08E200000000000000000000000000000000060380250000000F

PreauthSession.PreauthIntegrityHashValue

96D0F138CFE59B45465B2241727FADE2F74E5F6E4F88392C53A6DDC8E03B9BA5D7405FD37963906B

D7256648BDD43537A3A29C2CD0FE4FE5FE18E124EAD0B663

SESSION SETUP Response

 — STATUS_MORE_PROCESSING_REQUIRED
- Updating Preauth integrity hash —

PreauthSession.SessionId 0x30786325577741

Current

PreauthSession.PreauthIntegrityHashValue

96D0F138CFE59B45465B2241727FADE2F74E5F6E4F88392C53A6DDC8E03B9BA5D7405FD37963906B

D7256648BDD43537A3A29C2CD0FE4FE5FE18E124EAD0B663

SessionSetup response packet

FE534D4240000100160000C00100010001000000000000000200000000000000FFFE000000000000

0D000000001C000000000000000000000000000000000000090000004800B300A181B03081ADA003

0A0101A10C060A2B06010401823702020AA281970481944E544C4D53535000020000000C000C0038

00000015828AE2CBB1D86ED8A26BBE000000000000000050005000440000000A0092270000000F53

005500540033003100310002000C0053005500540033003100310001000C00530055005400330031

00310004000C0053005500540033003100310003000C005300550054003300310031000700080083

C4744232B1D00100000000

SessionSetup response header signature 0x00000000000000000000000000000000

Concatenate PreauthSession.PreauthIntegrityHashValue and Session Setup
response packet

SHA-512 Input Hash Data

96D0F138CFE59B45465B2241727FADE2F74E5F6E4F88392C53A6DDC8E03B9BA5D7405FD37963906B

D7256648BDD43537A3A29C2CD0FE4FE5FE18E124EAD0B663FE534D4240000100160000C001000100

01000000000000000200000000000000FFFE0000000000000D000000001C00000000000000000000

0000000000000000090000004800B300A181B03081ADA0030A0101A10C060A2B0601040182370202

0AA281970481944E544C4D53535000020000000C000C003800000015828AE2CBB1D86ED8A26BBE00

0000000000000050005000440000000A0092270000000F53005500540033003100310002000C0053

005500540033003100310001000C0053005500540033003100310004000C00530055005400330031

00310003000C005300550054003300310031000700080083C4744232B1D00100000000

PreauthSession.PreauthIntegrityHashValue

F2243F95EEF00B4218D5A00DFBDAB515B9CC1F7C5F8DA99AAFBAFB72EB9424F6845C79A94EC5796C

9D69402D103EDD72805ACB38CF62E7DA3BE94B3BED3EE8FC

SESSION SETUP Request

PreauthSession.SessionId 0x30786325577741

Current

PreauthSession.PreauthIntegrityHashValue

F2243F95EEF00B4218D5A00DFBDAB515B9CC1F7C5F8DA99AAFBAFB72EB9424F6845C79A94EC5796C

9D69402D103EDD72805ACB38CF62E7DA3BE94B3BED3EE8FC

SessionSetup request packet

FE534D4240000100000000000100800000000000000000000300000000000000FFFE000000000000

0D000000001C0000000000000000000000000000000000001900000101000000000000005800CF01

0000000000000000A18201CB308201C7A0030A0101A28201AA048201A64E544C4D53535000030000

001800180090000000EE00EE00A80000000C000C00580000001A001A0064000000120012007E0000

001000100096010000158288E2060380250000000F268C28C948C2E1EF3A481C34A7100C97530055

005400330031003100610064006D0069006E006900730074007200610074006F0072004400520049

0056004500520033003100310000000000000000000000000000000000000000000000000030EF61

6190C8A662E721E2F8EDC40E98010100000000000083C4744232B1D001A529012472765972000000

0002000C0053005500540033003100310001000C0053005500540033003100310004000C00530055

00540033003100310003000C005300550054003300310031000700080083C4744232B1D001060004

000200000008003000300000000000000000000000003000009B52C033A82790F6F74C0E851E924C

504FDC52EF290D80D5322FBE536429D6D50A00100000000000000000000000000000000000090016

0063006900660073002F005300550054003300310031000000000000000000000000008A393FC3E9

D7FFD7CDE5BECCBF864F29A31204100100000071B9DE9A4248980D00000000

Concatenate PreauthSession.PreauthIntegrityHashValue and Session Setup
request packet

SHA-512 Input Hash Data 

F2243F95EEF00B4218D5A00DFBDAB515B9CC1F7C5F8DA99AAFBAFB72EB9424F6845C79A94EC5796C

9D69402D103EDD72805ACB38CF62E7DA3BE94B3BED3EE8FCFE534D42400001000000000001008000

00000000000000000300000000000000FFFE0000000000000D000000001C00000000000000000000

00000000000000001900000101000000000000005800CF010000000000000000A18201CB308201C7

A0030A0101A28201AA048201A64E544C4D53535000030000001800180090000000EE00EE00A80000

000C000C00580000001A001A0064000000120012007E0000001000100096010000158288E2060380

250000000F268C28C948C2E1EF3A481C34A7100C97530055005400330031003100610064006D0069

006E006900730074007200610074006F007200440052004900560045005200330031003100000000

00000000000000000000000000000000000000000030EF616190C8A662E721E2F8EDC40E98010100

000000000083C4744232B1D001A5290124727659720000000002000C005300550054003300310031

0001000C0053005500540033003100310004000C0053005500540033003100310003000C00530055

0054003300310031000700080083C4744232B1D00106000400020000000800300030000000000000

0000000000003000009B52C033A82790F6F74C0E851E924C504FDC52EF290D80D5322FBE536429D6

D50A001000000000000000000000000000000000000900160063006900660073002F005300550054

003300310031000000000000000000000000008A393FC3E9D7FFD7CDE5BECCBF864F29A312041001

00000071B9DE9A4248980D00000000

PreauthSession.PreauthIntegrityHashValue

CB3320852ED35231F1087E6A4828C129384F7041005FF76543B46B1590574300B376771109C29903

D0A5E6EB124A3BCA8DD9CF0FBF2EF60F2FED746A70CE0533

SESSION SETUP Response

SessionId 0x30786325577741 COMPLETED

SessionSetup response packet

FE534D4240000100000000000100800009000000000000000300000000000000FFFE000000000000

0D000000001C0000BCE812303D9BCD5D3295EF0572553AEB0900000048001D00A11B3019A0030A01

00A31204100100000017DD19D27E10A55D00000000

SessionSetup response header signature 0xBCE812303D9BCD5D3295EF0572553AEB

PreauthSession.PreauthIntegrityHashValue

CB3320852ED35231F1087E6A4828C129384F7041005FF76543B46B1590574300B376771109C29903

D0A5E6EB124A3BCA8DD9CF0FBF2EF60F2FED746A70CE0533

Input cryptographicKey (SessionKey) 0xA8B3FCB8C96884BA9126132AE5B076AF

(queried from GSS authenticated context)

— Dialect 0x0311 —

preauthIntegrityHashValue

CB3320852ED35231F1087E6A4828C129384F7041005FF76543B46B1590574300B376771109C29903

D0A5E6EB124A3BCA8DD9CF0FBF2EF60F2FED746A70CE0533

SessionKey 0xA8B3FCB8C96884BA9126132AE5B076AF

SigningKey 0x5756AC382298721282D4D9F61CF1195F

[References]

[MS-SMB2]: Server Message Block (SMB) Protocol Versions 2
and 3 Specification

SMB3 Secure Dialect Negotiation

http://blogs.msdn.com/b/openspecification/archive/2012/06/28/smb3-secure-dialect-negotiation.aspx

What’s new in SMB 3.1.1 in the Windows Server 2016 Technical
Preview 2

http://blogs.technet.com/b/josebda/archive/2015/05/05/what-s-new-in-smb-3-1-1-in-the-windows-server-technical-preview-2.aspx

[SP800-108] National Institute of Standards and Technology.
“Special Publication 800-108, Recommendation for Key Derivation Using
Pseudorandom Functions”, October 2009, http://csrc.nist.gov/publications/nistpubs/800-108/sp800-108.pdf

[FIPS180-4] FIPS PUBS, “Secure Hash Standards
(SHS)”, March 2012, http://csrc.nist.gov/publications/fips/fips180-4/fips-180-4.pdf

[RFC4493]. The AES-CMAC Algorithm, http://www.ietf.org/rfc/rfc4493.txt

SMB 3 encryption offers data packet confidentiality and prevents an attacker from both tampering with and eavesdropping on any data packet. Encryption has been enhanced in SMB 3.1.1. The cipher can now be negotiated during connection establishment. In addition to AES-128-CCM for SMB 3.0.x compatibility, Windows 10 (and Windows Server 2016) added AES-128-GCM in SMB 3.1.1. The GCM mode offers a significant performance gain. Both ciphers [RFC5084] provide authenticated encryption, i.e. message integrity (signing). This blog takes a protocol walk on the enhancement and provides sample test vectors.
NOTE: This is written based on Windows 10, and Windows Server 2016 Technical Preview 3.

Encryption capability negotiate context

• SMB 3.1.1 client and server negotiate encryption support via SMB2_ENCRYPTION_CAPABILITIES negotiate context in the NEGOTIATE request and response. 
• The client advertises its list of supported cipher IDs in the order of most preferred encryption algorithm. Windows 10 implements cipher IDs 0x0002 (AES-128-GCM) and 0x0001 (AES-128-CCM). 
• If the client sends 3.0.x in the dialect array and supports encryption, it must advertise the SMB2_GLOBAL_CAP_ENCRYPTION capability flag as well since it does not know yet what dialect the server supports.
• If the server selects dialect 3.1.1 and supports encryption, it responds with the encryption negotiate context. SMB2_GLOBAL_CAP_ENCRYPTION capability flag should not be set because it is valid for the SMB 3.0 and 3.0.2 dialects.
• The encryption capability negotiate context has the same format in the Negotiate request and response, except that the response context must have CipherCount set to 1, and the cipher ID that conveys the server’s selection.

Multichannel encryption 

• Session binding (multichannel) requires that all channels bound to a given session negotiate the same encryption cipher as the master session’s connection.
• As in SMB 3.0.x, all SMB 3.1.1 channels (primary and alternate) bound to a given master session share the same encryption and decryption keys.
• The cipher ID is kept consistent as multichannel traffic can be spread across channels.

Server-wide or per-share encryption

• For a global level encryption, SessionSetup_response.SessionFlags includes SMB2_SESSION_FLAG_ENCRYPT_DATA. Encryption is enforced on the whole server.
• For a per-share level encryption, TreeConnect_response.ShareFlags includes SMB2_SHAREFLAG_ENCRYPT_DATA.
• If server-wide encryption is configured, share level encryption will not have any effect. This means, when global encryption is enabled, you cannot selectively disable encryption for certain shares.
• Encryption enforcement can be bypassed if “unencrypted access” is allowed. See RejectUnencryptedAccess.

Configuration

PowerShell cmdlets can be used to configure encryption on both Windows 10 and Windows Server 2016:

Global level encryption on the server:
Set-SmbServerConfiguration -EncryptData <0|1>

Share level encryption:
Set-SmbShare -Name <share name> -EncryptData <0|1>
Share level encryption enabled at creation:
New-SmbShare -Name <share name> -Path <pathname> -EncryptData 1

Unencrypted access:
Set-SmbServerConfiguration -RejectUnencryptedAccess <0|1>
See notes in Section “Unencrypted access”.

Encryption keys

Upon successful SessionSetup (Session.EncryptData), or successful TreeConnect (Share.EncryptData), the server and client generate EncryptionKey and DecryptionKey as specified in [MS-SMB2].
The key derivation in SMB 3.1.1 uses the same function as in SMB 3.0.x with new labels and context as follows. The context Session.PreauthIntegrityHashValue is derived from pre-authentication integrity hashing. The respective labels are shown in the following key formulas.

• EncryptionKey (Client) = DecryptionKey (Server) = SMB3KDF (SessionKey, “SMBC2ScipherKey\0″, Session.PreauthIntegrityHashValue)
• DecryptionKey (Client) = EncryptionKey (Server) = SMB3KDF ( SessionKey, “SMBS2CCipherKey\0″, Session.PreauthIntegrityHashValue)

Note that SMB3KDF() and the calculation of Session.PreauthIntegrityHashValue are described in the blog post:
SMB 3.1.1 Pre-authentication integrity in Windows 10
http://blogs.msdn.com/b/openspecification/archive/2015/08/11/smb-3-1-1-pre-authentication-integrity-in-windows-10.aspx

Transformed message

A transformed message consists of a transform_header followed by its encrypted SMB2 message.
A transform_header has the same size and most of the same fields as defined for dialect 3.0.x with two specific changes for dialect 3.1.1:
ProtocolId (4 bytes):  0xFD534D42 (in network order)
Signature (16 bytes):  Signature of the encrypted message.
Nonce (16 bytes):  An implementation-specific value unique for this encrypted message.
OriginalMessageSize (4 bytes):  The size in bytes of the SMB2 message.
Reserved (2 bytes):  Set to zeros and ignored.
Flags (2 bytes): This field indicates how the SMB2 message was transformed.
SessionId (8 bytes):  Uniquely identifies the established session for the command.

The two changes to the transform_header for SMB 3.1.1 are as follows:

Nonce (16 bytes) field: If CipherId is AES-128-GCM, the nonce used for encryption is the leftmost 12 bytes of the Nonce field, AES128GCM_Nonce (12 bytes), and the remaining 4 bytes are reserved. If CipherId is AES-128-CCM, the nonce used for encryption is the leftmost 11 bytes of the Nonce field, AES128CCM_Nonce (11 bytes), and the remaining 5 bytes are reserved.

Flags (2 bytes): this field repurposes the EncryptionAlgorithm (2 bytes) field used in SMB 3.0.x. When Flags’ value is set to 0x0001, it indicates that the message is encrypted using the negotiated cipher ID.

Encrypting the message

The sender encrypts the message with these specifics:
- The encryption algorithm specified by Connection.CipherId (AES-GCM or AES-CCM) is called with the following inputs:
- AES key: Session.EncryptionKey.
- AES-nonce or IV: AES128CCM_Nonce for AES-CCM, AES128GCM_Nonce for AES-GCM.
- Plaintext: The SMB2 message including the header and the payload.
- The optional authenticated data (AAD):  The SMB2 transform_header excluding the ProtocolId and Signature fields; these are the 32 bytes starting from the Nonce field.

The AES-CCM or AES-GCM outputs are:
- Ciphertext: the encrypted SMB2 message
- Message authentication code: the Signature field of the transform_header.

The sender appends the encrypted SMB2 message to the transform_header and sends it to the receiver.

Decrypting the message

The message is decrypted using:
- The encryption algorithm specified by Connection.CipherId.
- The Session.DecryptionKey of the Session that corresponds to the SessionId in the transform_header.
- The AAD passed to the algorithm is the transform_header excluding the ProtocolId and Signature fields.
- The nonce passed to the algorithm is based on CipherId as previously described.

The signature returned by the decryption algorithm is then verified against the Signature in the transform_header.

Encryption clauses

The encryption clauses are generally the same as for SMB 3.0.x. See the blog post at:
Encryption in SMB 3.0: A protocol perspective
http://blogs.msdn.com/b/openspecification/archive/2012/10/05/encryption-in-smb-3-0-a-protocol-perspective.aspx

Unencrypted Access: RejectUnencryptedAccess

Set-SmbServerConfiguration -RejectUnencryptedAccess <0|1>
The behavior is mainly unchanged in Windows Server 2016. The default value of RejectUnencryptedAccess is TRUE. When encryption is required (per share or server wide), the server returns ACCESS_DENIED for an unencrypted access attempt. A value of FALSE allows access from clients which do not support encryption or are not encryption-capable (e.g. SMB 1, SMB2 dialects 2.02, 2.1, SMB 3.x without encryption).
This configuration item is meant for a transition phase to support down-level clients which use older dialects (SMB 2.1 or earlier) by literally “allowing any unencrypted access” whenever the deployment scenario requires.
Note that if RejectUnencryptedAccess is disabled (FALSE), it opens the possibility for a man-in-the-middle (MITM) attacker to prevent the connection from negotiating encryption. If SMB 3.x is negotiated, the Windows 10 client will leverage negotiate validation or pre-authentication integrity to verify the properties of the connection with the server. In SMB 2.x.x, the encryption feature is not available even if the Windows 10 client still performs secure negotiate validation.
However, setting RejectUnencryptedAccess to FALSE makes it un-detectible if the MITM downgrades the connection’s dialect to SMB1, thus preventing encryption negotiation and allowing “clear text” eavesdropping. 
As a result, it is recommended to disable SMB1 on the client as soon as it is no longer needed.

Conclusion

Encryption is a very important feature whenever data confidentiality is required. This is the case when transferring high business impact data over untrusted networks. The addition of encryption negotiate context in SMB 3.1.1 is an enhancement that would interest many implementers. It also makes the feature extensible as new cryptographic ciphers become available and adopted. Some benchmark testing showed that AES-128-GCM provides as much as two times performance improvement over AES-128-CCM, while providing authenticated encryption at the same time.

Appendix A. Test vector for SMB 3.1.1 encryption

This sample data should be considered “as-is”. It should also be noted that examples do not replace normative protocol specifications. The authoritative reference is [MS-SMB2].

The test client negotiates SMB 3.1.1 and communicates with a Windows 2016 server. It opens a file and WRITEs the following content. It then READs back the file.
This is the content written and read:
Smb3 encryption testing
Hex value:
536D623320656E6372797074696F6E2074657374696E67

These outputs show pre-authentication integrity phase for key derivation, then the encryption and decryption of the WRITE and READ commands.
The decrypted content is verified to be same at the end of the SMB2 READ response.

Appendix A.1 Test vector with AES-GCM

 — Key derivation —

Header.Command 0x0000 NEGOTIATE

Preauth integrity hash —
PreauthIntegrityCaps.HashAlgorithmCount 0x1
PreauthIntegrityCaps.SaltLength 0x20
PreauthIntegrityCaps.HashAlgorithms 0x0001
PreauthIntegrityCaps.Salt
D1709D7196E1BD0B6EBF95213D76553435763514392649FD6F216ED8BF269CD8

Encryption capabilites —
EncryptionCaps.CipherCount 0x2
EncryptionCaps.Ciphers[0] 0x0002
EncryptionCaps.Ciphers[1] 0x0001

Connection.PreauthIntegrityHashId 0x0001

NEGOTIATE Request

Preauth integrity hash —
Current
Connection.PreauthIntegrityHashValue
00000000000000000000000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000
Negotiate request packet
FE534D4240000100000000000000010000000000000000000000000000000000FFFE000000000000
0000000000000000000000000000000000000000000000002400050001000000660000004F0D7FA0
09F5B246B2EF62551D7D7C0970000000020000000202100200030203110300000100260000000000
010020000100D1709D7196E1BD0B6EBF95213D76553435763514392649FD6F216ED8BF269CD80000
0200060000000000020002000100
Concatenate Connection.PreauthIntegrityHashValue and Negotiate request packet
SHA-512 Input Hash Data
00000000000000000000000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000FE534D42400001000000000000000100
00000000000000000000000000000000FFFE00000000000000000000000000000000000000000000
00000000000000002400050001000000660000004F0D7FA009F5B246B2EF62551D7D7C0970000000
020000000202100200030203110300000100260000000000010020000100D1709D7196E1BD0B6EBF
95213D76553435763514392649FD6F216ED8BF269CD800000200060000000000020002000100
New
Connection.PreauthIntegrityHashValue
550442DAF311412870AD9E58E602B0312D61328D6B1AC28F22AF46D6EA581F23A9BFABE0CC041197
6BF3F9DA23D3433352CB48CF00B8659BC1A3695E1B1A52A8

NEGOTIATE Response

Updating Preauth integrity hash —
Current
Connection.PreauthIntegrityHashValue
550442DAF311412870AD9E58E602B0312D61328D6B1AC28F22AF46D6EA581F23A9BFABE0CC041197
6BF3F9DA23D3433352CB48CF00B8659BC1A3695E1B1A52A8
Negotiate response packet
FE534D4240000100000000000000010001000000000000000000000000000000FFFE000000000000
000000000000000000000000000000000000000000000000410001001103020039CBCAF329714942
BDCE5D60F09AB3FB27000000000080000000800000008000D1168E69CDAED00109094AB095AED001
80004001C00100006082013C06062B0601050502A08201303082012CA01A3018060A2B0601040182
3702021E060A2B06010401823702020AA282010C048201084E45474F455854530100000000000000
6000000070000000807CC0FD06D6362D02DDE1CF343BFE29C16AA4EA4741FB0EF645DC5C5D3C3E6A
8DE5D0BAEF7A06DC070076174356EDA0000000000000000060000000010000000000000000000000
5C33530DEAF90D4DB2EC4AE3786EC3084E45474F4558545303000000010000004000000098000000
807CC0FD06D6362D02DDE1CF343BFE295C33530DEAF90D4DB2EC4AE3786EC3084000000058000000
3056A05430523027802530233121301F06035504031318546F6B656E205369676E696E6720507562
6C6963204B65793027802530233121301F06035504031318546F6B656E205369676E696E67205075
626C6963204B65790100260000000000010020000100B51C002C28941192737A08344B05CE90786E
EC146D99CDB60AE44E5A86127D270000020004000000000001000200
Concatenate Connection.PreauthIntegrityHashValue and Negotiate response packet
SHA-512 Input Hash Data
550442DAF311412870AD9E58E602B0312D61328D6B1AC28F22AF46D6EA581F23A9BFABE0CC041197
6BF3F9DA23D3433352CB48CF00B8659BC1A3695E1B1A52A8FE534D42400001000000000000000100
01000000000000000000000000000000FFFE00000000000000000000000000000000000000000000
0000000000000000410001001103020039CBCAF329714942BDCE5D60F09AB3FB2700000000008000
0000800000008000D1168E69CDAED00109094AB095AED00180004001C00100006082013C06062B06
01050502A08201303082012CA01A3018060A2B06010401823702021E060A2B06010401823702020A
A282010C048201084E45474F4558545301000000000000006000000070000000807CC0FD06D6362D
02DDE1CF343BFE29C16AA4EA4741FB0EF645DC5C5D3C3E6A8DE5D0BAEF7A06DC070076174356EDA0
0000000000000000600000000100000000000000000000005C33530DEAF90D4DB2EC4AE3786EC308
4E45474F4558545303000000010000004000000098000000807CC0FD06D6362D02DDE1CF343BFE29
5C33530DEAF90D4DB2EC4AE3786EC30840000000580000003056A05430523027802530233121301F
06035504031318546F6B656E205369676E696E67205075626C6963204B6579302780253023312130
1F06035504031318546F6B656E205369676E696E67205075626C6963204B65790100260000000000
010020000100B51C002C28941192737A08344B05CE90786EEC146D99CDB60AE44E5A86127D270000
020004000000000001000200
New
Connection.PreauthIntegrityHashValue
ABE4DA6E875F6FB05033AF04DCC38C92888B4E13D1EAB7AA05CADE142064974CB3EAB0782600549B
A27207AA213B0D190B9950FA36D45BE32A888BFEE8389B74

Add NEW SessionId 0x100000000025 to Preauth Integrity hash table with value
Connection.PreauthIntegrityHashValue
ABE4DA6E875F6FB05033AF04DCC38C92888B4E13D1EAB7AA05CADE142064974CB3EAB0782600549B
A27207AA213B0D190B9950FA36D45BE32A888BFEE8389B74

SESSION SETUP Request
PreauthSession.SessionId 0x100000000025
Current
PreauthSession.PreauthIntegrityHashValue
ABE4DA6E875F6FB05033AF04DCC38C92888B4E13D1EAB7AA05CADE142064974CB3EAB0782600549B
A27207AA213B0D190B9950FA36D45BE32A888BFEE8389B74
SessionSetup request packet
FE534D4240000100000000000100800000000000000000000100000000000000FFFE000000000000
00000000000000000000000000000000000000000000000019000001010000000000000058004A00
0000000000000000604806062B0601050502A03E303CA00E300C060A2B06010401823702020AA22A
04284E544C4D5353500001000000978208E200000000000000000000000000000000060380250000
000F
Concatenate PreauthSession.PreauthIntegrityHashValue and Session Setup request packet
SHA-512 Input Hash Data 
ABE4DA6E875F6FB05033AF04DCC38C92888B4E13D1EAB7AA05CADE142064974CB3EAB0782600549B
A27207AA213B0D190B9950FA36D45BE32A888BFEE8389B74FE534D42400001000000000001008000
00000000000000000100000000000000FFFE00000000000000000000000000000000000000000000
000000000000000019000001010000000000000058004A000000000000000000604806062B060105
0502A03E303CA00E300C060A2B06010401823702020AA22A04284E544C4D53535000010000009782
08E200000000000000000000000000000000060380250000000F
PreauthSession.PreauthIntegrityHashValue
A5E8AB87E2ADB8FA5F4545D20F1FD2019D66CCD0F4DFD1F762F1DFC8DCB15B98D0BD1F1450F6A0AF
C70F80B353C2D959217681949CF22DF35F31257A281C6A80

SESSION SETUP Response

 — STATUS_MORE_PROCESSING_REQUIRED – Updating Preauth integrity hash —
PreauthSession.SessionId 0x100000000025
Current
PreauthSession.PreauthIntegrityHashValue
A5E8AB87E2ADB8FA5F4545D20F1FD2019D66CCD0F4DFD1F762F1DFC8DCB15B98D0BD1F1450F6A0AF
C70F80B353C2D959217681949CF22DF35F31257A281C6A80
SessionSetup response packet
FE534D4240000100160000C00100010001000000000000000100000000000000FFFE000000000000
250000000010000000000000000000000000000000000000090000004800B300A181B03081ADA003
0A0101A10C060A2B06010401823702020AA281970481944E544C4D53535000020000000C000C0038
00000015828AE25FC0CB7F886E93D6000000000000000050005000440000000A0092270000000F53
005500540033003100310002000C0053005500540033003100310001000C00530055005400330031
00310004000C0053005500540033003100310003000C005300550054003300310031000700080024
8D5C6CCDAED00100000000
SessionSetup response header signature 0x00000000000000000000000000000000
Concatenate PreauthSession.PreauthIntegrityHashValue and Session Setup response packet
SHA-512 Input Hash Data
A5E8AB87E2ADB8FA5F4545D20F1FD2019D66CCD0F4DFD1F762F1DFC8DCB15B98D0BD1F1450F6A0AF
C70F80B353C2D959217681949CF22DF35F31257A281C6A80FE534D4240000100160000C001000100
01000000000000000100000000000000FFFE00000000000025000000001000000000000000000000
0000000000000000090000004800B300A181B03081ADA0030A0101A10C060A2B0601040182370202
0AA281970481944E544C4D53535000020000000C000C003800000015828AE25FC0CB7F886E93D600
0000000000000050005000440000000A0092270000000F53005500540033003100310002000C0053
005500540033003100310001000C0053005500540033003100310004000C00530055005400330031
00310003000C0053005500540033003100310007000800248D5C6CCDAED00100000000
PreauthSession.PreauthIntegrityHashValue
9A095455244172898902B0FBDF5FEFAFD8435BB66A47EB55CB7542732A423F58B12B3ED698BEF387
8D8A346FD9F5CC882DA37AAF2A939290E98B935FC72B3944

SESSION SETUP Request
PreauthSession.SessionId 0x100000000025
Current
PreauthSession.PreauthIntegrityHashValue
9A095455244172898902B0FBDF5FEFAFD8435BB66A47EB55CB7542732A423F58B12B3ED698BEF387
8D8A346FD9F5CC882DA37AAF2A939290E98B935FC72B3944
SessionSetup request packet
FE534D4240000100000000000100800000000000000000000200000000000000FFFE000000000000
2500000000100000000000000000000000000000000000001900000101000000000000005800CF01
0000000000000000A18201CB308201C7A0030A0101A28201AA048201A64E544C4D53535000030000
001800180090000000EE00EE00A80000000C000C00580000001A001A0064000000120012007E0000
001000100096010000158288E2060380250000000FA5E34268EF143BE5816251D02C564E9B530055
005400330031003100610064006D0069006E006900730074007200610074006F0072004400520049
005600450052003300310031000000000000000000000000000000000000000000000000002C263D
A5C2D54785E8EDA0552472D3A30101000000000000248D5C6CCDAED001BEA7A53E2DC098EB000000
0002000C0053005500540033003100310001000C0053005500540033003100310004000C00530055
00540033003100310003000C0053005500540033003100310007000800248D5C6CCDAED001060004
00020000000800300030000000000000000000000000300000B61FEFCAA857EA57BF1EDCEBF8974B
8E0EBA5A6DFD9D07A31D11B548F8C9D0CC0A00100000000000000000000000000000000000090016
0063006900660073002F00530055005400330031003100000000000000000000000000133FA6EA15
4880BB44576C6E2490BDE7A31204100100000067890BD408F5680D00000000
Concatenate PreauthSession.PreauthIntegrityHashValue and Session Setup request packet
SHA-512 Input Hash Data 
9A095455244172898902B0FBDF5FEFAFD8435BB66A47EB55CB7542732A423F58B12B3ED698BEF387
8D8A346FD9F5CC882DA37AAF2A939290E98B935FC72B3944FE534D42400001000000000001008000
00000000000000000200000000000000FFFE00000000000025000000001000000000000000000000
00000000000000001900000101000000000000005800CF010000000000000000A18201CB308201C7
A0030A0101A28201AA048201A64E544C4D53535000030000001800180090000000EE00EE00A80000
000C000C00580000001A001A0064000000120012007E0000001000100096010000158288E2060380
250000000FA5E34268EF143BE5816251D02C564E9B530055005400330031003100610064006D0069
006E006900730074007200610074006F007200440052004900560045005200330031003100000000
0000000000000000000000000000000000000000002C263DA5C2D54785E8EDA0552472D3A3010100
0000000000248D5C6CCDAED001BEA7A53E2DC098EB0000000002000C005300550054003300310031
0001000C0053005500540033003100310004000C0053005500540033003100310003000C00530055
00540033003100310007000800248D5C6CCDAED00106000400020000000800300030000000000000
000000000000300000B61FEFCAA857EA57BF1EDCEBF8974B8E0EBA5A6DFD9D07A31D11B548F8C9D0
CC0A001000000000000000000000000000000000000900160063006900660073002F005300550054
00330031003100000000000000000000000000133FA6EA154880BB44576C6E2490BDE7A312041001
00000067890BD408F5680D00000000
PreauthSession.PreauthIntegrityHashValue
B23F3CBFD69487D9832B79B1594A367CDD950909B774C3A4C412B4FCEA9EDDDBA7DB256BA2EA30E9
77F11F9B113247578E0E915C6D2A513B8F2FCA5707DC8770

SESSION SETUP Response
SessionId 0x100000000025 COMPLETED
SessionSetup response packet
FE534D4240000100000000000100800009000000000000000200000000000000FFFE000000000000
25000000001000006B85A4519A0F3EEA35BA946DD3AFE6B80900000048001D00A11B3019A0030A01
00A3120410010000003932A87523AB660100000000
SessionSetup response header signature 0x6B85A4519A0F3EEA35BA946DD3AFE6B8
PreauthSession.PreauthIntegrityHashValue
B23F3CBFD69487D9832B79B1594A367CDD950909B774C3A4C412B4FCEA9EDDDBA7DB256BA2EA30E9
77F11F9B113247578E0E915C6D2A513B8F2FCA5707DC8770

Input cryptographicKey (SessionKey) 0x419FDDF34C1E001909D362AE7FB6AF79
(queried from GSS authenticated context)

— Dialect 0x0311 —
preauthIntegrityHashValue
B23F3CBFD69487D9832B79B1594A367CDD950909B774C3A4C412B4FCEA9EDDDBA7DB256BA2EA30E9
77F11F9B113247578E0E915C6D2A513B8F2FCA5707DC8770
CypherId 0x0002
SessionKey 0x419FDDF34C1E001909D362AE7FB6AF79
SigningKey 0x8765949DFEAEE105CE9118B45BE988F0
EncryptionKey 0xA2F5E80E5D59103034F32E52F698E5EC
DecryptionKey 0x748C50868C90F302962A5C35F5F9A8BF
ApplicationKey 0x099D610789FBE82055B313601C3E8CC4

— Encryption —

SessionId 0x100000000025
SessionKey 0x419FDDF34C1E001909D362AE7FB6AF79
SigningKey 0x8765949DFEAEE105CE9118B45BE988F0
EncryptionKey 0xA2F5E80E5D59103034F32E52F698E5EC
DecryptionKey 0x748C50868C90F302962A5C35F5F9A8BF
ApplicationKey 0x099D610789FBE82055B313601C3E8CC4
Header.Command 0x0009 WRITE

Encryption of the request —

Key 0xA2F5E80E5D59103034F32E52F698E5EC

Nonce Length 0xc
AES-128-GCM nonce 0xC7D6822D269CAF48904C664C

SMB2 packet
FE534D4240000100000000000900010008000000000000000500000000000000FFFE000001000000
25000000001000000000000000000000000000000000000031007000170000000000000000000000
0600000004000000010000000400000000000000000000007000000000000000536D623320656E63
72797074696F6E2074657374696E67
transform_header.ProtocolId 0x424d53fd
transform_header.Signature 0xBD73D97D2BC9001BCAFAC0FDFF5FEEBC
transform_header.Nonce 0xC7D6822D269CAF48904C664C00000000
transform_header.OriginalMessageSize 0x87
transform_header.Reserved 0x0
transform_header.Flags 0x0001
transform_header.SessionId 0x100000000025
Encrypted message
6ECDD2A7AFC7B47763057A041B8FD4DAFFE990B70C9E09D36C084E02D14EF247F8BDE38ACF6256F8
B1D3B56F77FBDEB312FEA5E92CBCC1ED8FB2EBBFAA75E49A4A394BB44576545567C24D4C014D47C9
FBDFDAFD2C4F9B72F8D256452620A299F48E29E53D6B61D1C13A19E91AF013F00D17E3ABC2FC3D36
C8C1B6B93973253852DBD442E46EE8

Transformed message
FD534D42BD73D97D2BC9001BCAFAC0FDFF5FEEBCC7D6822D269CAF48904C664C0000000087000000
0000010025000000001000006ECDD2A7AFC7B47763057A041B8FD4DAFFE990B70C9E09D36C084E02
D14EF247F8BDE38ACF6256F8B1D3B56F77FBDEB312FEA5E92CBCC1ED8FB2EBBFAA75E49A4A394BB4
4576545567C24D4C014D47C9FBDFDAFD2C4F9B72F8D256452620A299F48E29E53D6B61D1C13A19E9
1AF013F00D17E3ABC2FC3D36C8C1B6B93973253852DBD442E46EE8

Decryption of the response —

Transformed message
FD534D42ACBE1CB7ED343ADF1725EF144D90D4B0E06831DD2E8EB7B4000000000000000050000000
00000100250000000010000026BBBF949983A6C1C796559D0F2C510CB651D1F7B6AC8DED32A2A0B8
F2D793A815C6F6B848D69767A215841A42D400AE6DDB5F0B44173A014973321FDD7950DA6179159B
82E03C9E18A050FF0EA1C967
transform_header.ProtocolId 0x424d53fd
transform_header.Signature 0xACBE1CB7ED343ADF1725EF144D90D4B0
transform_header.Nonce 0xE06831DD2E8EB7B40000000000000000
transform_header.OriginalMessageSize 0x50
transform_header.Reserved 0x0
transform_header.Flags 0x0001
transform_header.SessionId 0x100000000025

Key 0x748C50868C90F302962A5C35F5F9A8BF

Nonce Length 0xc
AES-128-GCM nonce 0xE06831DD2E8EB7B400000000
Decrypted SMB2 packet
FE534D4240000100000000000900010001000000000000000500000000000000FFFE000001000000
25000000001000000000000000000000000000000000000011000000170000000000000000000000
Header.Command 0x0008 READ

Encryption of the request —

Key 0xA2F5E80E5D59103034F32E52F698E5EC

Nonce Length 0xc
AES-128-GCM nonce 0xD7AA8C6D36859243B715E0A6

SMB2 packet
FE534D4240000100000000000800010008000000000000000600000000000000FFFE000001000000
25000000001000000000000000000000000000000000000031000000170000000000000000000000
060000000400000001000000040000000000000000000000000000000000000000
transform_header.ProtocolId 0x424d53fd
transform_header.Signature 0x6DAC0B6FD85A3ED42BB917DA38FE0386
transform_header.Nonce 0xD7AA8C6D36859243B715E0A600000000
transform_header.OriginalMessageSize 0x71
transform_header.Reserved 0x0
transform_header.Flags 0x0001
transform_header.SessionId 0x100000000025
Encrypted message
88A47BF09CA3C3141CDD7306BE9D9475AB24FCCB833D77461C041F8FB983D0C188F0729272B31D9D
3D0DC6B687C069EEE0CC8EACA2C536D019ACC9E185D1EB630E0FCB793EEECEB06D82A1D77706E700
DBEBFB4FEB54D7AD2D97E7288804F90757FE4D08D6A84A3FF433E7451E768E4699

Transformed message
FD534D426DAC0B6FD85A3ED42BB917DA38FE0386D7AA8C6D36859243B715E0A60000000071000000
00000100250000000010000088A47BF09CA3C3141CDD7306BE9D9475AB24FCCB833D77461C041F8F
B983D0C188F0729272B31D9D3D0DC6B687C069EEE0CC8EACA2C536D019ACC9E185D1EB630E0FCB79
3EEECEB06D82A1D77706E700DBEBFB4FEB54D7AD2D97E7288804F90757FE4D08D6A84A3FF433E745
1E768E4699

Decryption of the response —

Transformed message
FD534D427F714B3B9D8FA1198584E71C2BAA1CB6E16831DD2E8EB7B4000000000000000067000000
000001002500000000100000FECEDF4D03BB11A6CC5D8A53BE33D6D8701986342B4197D306E16F9C
BB218E92F7F8281F51CE68BB85A20D87DE90EBBF80538066D1C37513C0A58D70936D537B624F5500
202A612B6CD30D448A82791A0B2E049ED512AFAEFB06E98AB3D6F931D7D50DB2DBD36A
transform_header.ProtocolId 0x424d53fd
transform_header.Signature 0x7F714B3B9D8FA1198584E71C2BAA1CB6
transform_header.Nonce 0xE16831DD2E8EB7B40000000000000000
transform_header.OriginalMessageSize 0x67
transform_header.Reserved 0x0
transform_header.Flags 0x0001
transform_header.SessionId 0x100000000025

Key 0x748C50868C90F302962A5C35F5F9A8BF

Nonce Length 0xc
AES-128-GCM nonce 0xE16831DD2E8EB7B400000000
Decrypted SMB2 packet
FE534D4240000100000000000800010001000000000000000600000000000000FFFE000001000000
25000000001000000000000000000000000000000000000011005000170000000000000000000000
536D623320656E6372797074696F6E2074657374696E67 

Appendix A.2 Test vector with AES-CCM

— Key derivation —

Header.Command 0x0000 NEGOTIATE

Preauth integrity hash —
PreauthIntegrityCaps.HashAlgorithmCount 0x1
PreauthIntegrityCaps.SaltLength 0x20
PreauthIntegrityCaps.HashAlgorithms 0x0001
PreauthIntegrityCaps.Salt
1A05A92392E1554C072AE7B186EE7DC02CB90BEF2E639CCC94B7A9DC7B393442

Encryption capabilites —
EncryptionCaps.CipherCount 0x2
EncryptionCaps.Ciphers[0] 0x0001
EncryptionCaps.Ciphers[1] 0x0002

Connection.PreauthIntegrityHashId 0x0001

NEGOTIATE Request

Preauth integrity hash —
Current
Connection.PreauthIntegrityHashValue
00000000000000000000000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000
Negotiate request packet
FE534D4240000100000000000000010000000000000000000000000000000000FFFE000000000000
00000000000000000000000000000000000000000000000024000500010000006600000078EA16AC
6877C34A95F7160F73EA377270000000020000000202100200030203110300000100260000000000
0100200001001A05A92392E1554C072AE7B186EE7DC02CB90BEF2E639CCC94B7A9DC7B3934420000
0200060000000000020001000200
Concatenate Connection.PreauthIntegrityHashValue and Negotiate request packet
SHA-512 Input Hash Data
00000000000000000000000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000FE534D42400001000000000000000100
00000000000000000000000000000000FFFE00000000000000000000000000000000000000000000
000000000000000024000500010000006600000078EA16AC6877C34A95F7160F73EA377270000000
0200000002021002000302031103000001002600000000000100200001001A05A92392E1554C072A
E7B186EE7DC02CB90BEF2E639CCC94B7A9DC7B39344200000200060000000000020001000200
New
Connection.PreauthIntegrityHashValue
A3A8A769FEA693B3D037406EF945E115D2B7A4A9318564D2CAAA4B1FE0EC36D8D92A4802619EDCF2
9E2410534D2D3749E71F76ADF5212F959210D291097A6355

NEGOTIATE Response

Updating Preauth integrity hash —
Current
Connection.PreauthIntegrityHashValue
A3A8A769FEA693B3D037406EF945E115D2B7A4A9318564D2CAAA4B1FE0EC36D8D92A4802619EDCF2
9E2410534D2D3749E71F76ADF5212F959210D291097A6355
Negotiate response packet
FE534D4240000100000000000000010001000000000000000000000000000000FFFE000000000000
000000000000000000000000000000000000000000000000410001001103020039CBCAF329714942
BDCE5D60F09AB3FB27000000000080000000800000008000D04C8443CCAED00109094AB095AED001
80004001C00100006082013C06062B0601050502A08201303082012CA01A3018060A2B0601040182
3702021E060A2B06010401823702020AA282010C048201084E45474F455854530100000000000000
60000000700000007F7CC0FD06D6362D02DDE1CF343BFE2973007DCF55CA793E082B7A257DEFE6E8
E18291ABF112C0599108C772F55CBB2A000000000000000060000000010000000000000000000000
5C33530DEAF90D4DB2EC4AE3786EC3084E45474F4558545303000000010000004000000098000000
7F7CC0FD06D6362D02DDE1CF343BFE295C33530DEAF90D4DB2EC4AE3786EC3084000000058000000
3056A05430523027802530233121301F06035504031318546F6B656E205369676E696E6720507562
6C6963204B65793027802530233121301F06035504031318546F6B656E205369676E696E67205075
626C6963204B6579010026000000000001002000010088AFA422ECC239CB16F30BA641AE4B6EE79F
5A4AF74FE18A301E9790515D07F70000020004000000000001000100
Concatenate Connection.PreauthIntegrityHashValue and Negotiate response packet
SHA-512 Input Hash Data
A3A8A769FEA693B3D037406EF945E115D2B7A4A9318564D2CAAA4B1FE0EC36D8D92A4802619EDCF2
9E2410534D2D3749E71F76ADF5212F959210D291097A6355FE534D42400001000000000000000100
01000000000000000000000000000000FFFE00000000000000000000000000000000000000000000
0000000000000000410001001103020039CBCAF329714942BDCE5D60F09AB3FB2700000000008000
0000800000008000D04C8443CCAED00109094AB095AED00180004001C00100006082013C06062B06
01050502A08201303082012CA01A3018060A2B06010401823702021E060A2B06010401823702020A
A282010C048201084E45474F45585453010000000000000060000000700000007F7CC0FD06D6362D
02DDE1CF343BFE2973007DCF55CA793E082B7A257DEFE6E8E18291ABF112C0599108C772F55CBB2A
0000000000000000600000000100000000000000000000005C33530DEAF90D4DB2EC4AE3786EC308
4E45474F45585453030000000100000040000000980000007F7CC0FD06D6362D02DDE1CF343BFE29
5C33530DEAF90D4DB2EC4AE3786EC30840000000580000003056A05430523027802530233121301F
06035504031318546F6B656E205369676E696E67205075626C6963204B6579302780253023312130
1F06035504031318546F6B656E205369676E696E67205075626C6963204B65790100260000000000
01002000010088AFA422ECC239CB16F30BA641AE4B6EE79F5A4AF74FE18A301E9790515D07F70000
020004000000000001000100
New
Connection.PreauthIntegrityHashValue
A21419AD43D5A4975326E07142734EADA33D0927738F3C1B05A65B003CCAAAE225B547045260356C
2014A21E0A3DFA9EF7B192C375BFFC5F5E766AC3261F0457

Add NEW SessionId 0x100000000021 to Preauth Integrity hash table with value
Connection.PreauthIntegrityHashValue
A21419AD43D5A4975326E07142734EADA33D0927738F3C1B05A65B003CCAAAE225B547045260356C
2014A21E0A3DFA9EF7B192C375BFFC5F5E766AC3261F0457

SESSION SETUP Request
PreauthSession.SessionId 0x100000000021
Current
PreauthSession.PreauthIntegrityHashValue
A21419AD43D5A4975326E07142734EADA33D0927738F3C1B05A65B003CCAAAE225B547045260356C
2014A21E0A3DFA9EF7B192C375BFFC5F5E766AC3261F0457
SessionSetup request packet
FE534D4240000100000000000100800000000000000000000100000000000000FFFE000000000000
00000000000000000000000000000000000000000000000019000001010000000000000058004A00
0000000000000000604806062B0601050502A03E303CA00E300C060A2B06010401823702020AA22A
04284E544C4D5353500001000000978208E200000000000000000000000000000000060380250000
000F
Concatenate PreauthSession.PreauthIntegrityHashValue and Session Setup request packet
SHA-512 Input Hash Data 
A21419AD43D5A4975326E07142734EADA33D0927738F3C1B05A65B003CCAAAE225B547045260356C
2014A21E0A3DFA9EF7B192C375BFFC5F5E766AC3261F0457FE534D42400001000000000001008000
00000000000000000100000000000000FFFE00000000000000000000000000000000000000000000
000000000000000019000001010000000000000058004A000000000000000000604806062B060105
0502A03E303CA00E300C060A2B06010401823702020AA22A04284E544C4D53535000010000009782
08E200000000000000000000000000000000060380250000000F
PreauthSession.PreauthIntegrityHashValue
FD10D68FFBB5D94DD483DE14DC8AF92B4D2D8517A5D245FE091C93050AC56239B3B829F74CB25451
276248F12279DCC027C9B53841A67052A617C32C93CBA8C2

SESSION SETUP Response

 — STATUS_MORE_PROCESSING_REQUIRED – Updating Preauth integrity hash —
PreauthSession.SessionId 0x100000000021
Current
PreauthSession.PreauthIntegrityHashValue
FD10D68FFBB5D94DD483DE14DC8AF92B4D2D8517A5D245FE091C93050AC56239B3B829F74CB25451
276248F12279DCC027C9B53841A67052A617C32C93CBA8C2
SessionSetup response packet
FE534D4240000100160000C00100010001000000000000000100000000000000FFFE000000000000
210000000010000000000000000000000000000000000000090000004800B300A181B03081ADA003
0A0101A10C060A2B06010401823702020AA281970481944E544C4D53535000020000000C000C0038
00000015828AE29296836B33F712E0000000000000000050005000440000000A0092270000000F53
005500540033003100310002000C0053005500540033003100310001000C00530055005400330031
00310004000C0053005500540033003100310003000C005300550054003300310031000700080019
C69C43CCAED00100000000
SessionSetup response header signature 0x00000000000000000000000000000000
Concatenate PreauthSession.PreauthIntegrityHashValue and Session Setup response packet
SHA-512 Input Hash Data
FD10D68FFBB5D94DD483DE14DC8AF92B4D2D8517A5D245FE091C93050AC56239B3B829F74CB25451
276248F12279DCC027C9B53841A67052A617C32C93CBA8C2FE534D4240000100160000C001000100
01000000000000000100000000000000FFFE00000000000021000000001000000000000000000000
0000000000000000090000004800B300A181B03081ADA0030A0101A10C060A2B0601040182370202
0AA281970481944E544C4D53535000020000000C000C003800000015828AE29296836B33F712E000
0000000000000050005000440000000A0092270000000F53005500540033003100310002000C0053
005500540033003100310001000C0053005500540033003100310004000C00530055005400330031
00310003000C005300550054003300310031000700080019C69C43CCAED00100000000
PreauthSession.PreauthIntegrityHashValue
2AA0A0D736D4A3BE4A2FA06B20EEBF02635543C0310F72595ACEAF9893BBE647D9C753175215BB24
71DF365D4FC77AB8D168ECC91ABC02C4611D2AAC33181967

SESSION SETUP Request
PreauthSession.SessionId 0x100000000021
Current
PreauthSession.PreauthIntegrityHashValue
2AA0A0D736D4A3BE4A2FA06B20EEBF02635543C0310F72595ACEAF9893BBE647D9C753175215BB24
71DF365D4FC77AB8D168ECC91ABC02C4611D2AAC33181967
SessionSetup request packet
FE534D4240000100000000000100800000000000000000000200000000000000FFFE000000000000
2100000000100000000000000000000000000000000000001900000101000000000000005800CF01
0000000000000000A18201CB308201C7A0030A0101A28201AA048201A64E544C4D53535000030000
001800180090000000EE00EE00A80000000C000C00580000001A001A0064000000120012007E0000
001000100096010000158288E2060380250000000F3E492B87B2606D263031D0D12B6AD267530055
005400330031003100610064006D0069006E006900730074007200610074006F0072004400520049
005600450052003300310031000000000000000000000000000000000000000000000000009AEF57
4DBD2E8A323B017ED361EEA14B010100000000000019C69C43CCAED00176AC9CBD38378531000000
0002000C0053005500540033003100310001000C0053005500540033003100310004000C00530055
00540033003100310003000C005300550054003300310031000700080019C69C43CCAED001060004
00020000000800300030000000000000000000000000300000B61FEFCAA857EA57BF1EDCEBF8974B
8E0EBA5A6DFD9D07A31D11B548F8C9D0CC0A00100000000000000000000000000000000000090016
0063006900660073002F005300550054003300310031000000000000000000000000005E621187A7
5CC18E3982494ECC4793B7A3120410010000005C661B9E6BE0F1E500000000
Concatenate PreauthSession.PreauthIntegrityHashValue and Session Setup request packet
SHA-512 Input Hash Data 
2AA0A0D736D4A3BE4A2FA06B20EEBF02635543C0310F72595ACEAF9893BBE647D9C753175215BB24
71DF365D4FC77AB8D168ECC91ABC02C4611D2AAC33181967FE534D42400001000000000001008000
00000000000000000200000000000000FFFE00000000000021000000001000000000000000000000
00000000000000001900000101000000000000005800CF010000000000000000A18201CB308201C7
A0030A0101A28201AA048201A64E544C4D53535000030000001800180090000000EE00EE00A80000
000C000C00580000001A001A0064000000120012007E0000001000100096010000158288E2060380
250000000F3E492B87B2606D263031D0D12B6AD267530055005400330031003100610064006D0069
006E006900730074007200610074006F007200440052004900560045005200330031003100000000
0000000000000000000000000000000000000000009AEF574DBD2E8A323B017ED361EEA14B010100
000000000019C69C43CCAED00176AC9CBD383785310000000002000C005300550054003300310031
0001000C0053005500540033003100310004000C0053005500540033003100310003000C00530055
0054003300310031000700080019C69C43CCAED00106000400020000000800300030000000000000
000000000000300000B61FEFCAA857EA57BF1EDCEBF8974B8E0EBA5A6DFD9D07A31D11B548F8C9D0
CC0A001000000000000000000000000000000000000900160063006900660073002F005300550054
003300310031000000000000000000000000005E621187A75CC18E3982494ECC4793B7A312041001
0000005C661B9E6BE0F1E500000000
PreauthSession.PreauthIntegrityHashValue
DECF98A420718718F22090D3580FCC5E484BD310FA1268210C6E86335A8891E767F5BCD99FA5A785
9D665AD07A73EA94E1BCDB7CFA69A6962A28A244138340B1

SESSION SETUP Response
SessionId 0x100000000021 COMPLETED
SessionSetup response packet
FE534D4240000100000000000100800009000000000000000200000000000000FFFE000000000000
21000000001000003676196AEE8CA17E5D50A53642EF2BE40900000048001D00A11B3019A0030A01
00A3120410010000000F57444342A2717E00000000
SessionSetup response header signature 0x3676196AEE8CA17E5D50A53642EF2BE4
PreauthSession.PreauthIntegrityHashValue
DECF98A420718718F22090D3580FCC5E484BD310FA1268210C6E86335A8891E767F5BCD99FA5A785
9D665AD07A73EA94E1BCDB7CFA69A6962A28A244138340B1

Input cryptographicKey (SessionKey) 0x07B7F69C1E2581662DF6987E88F9E891
(queried from GSS authenticated context)

— Dialect 0x0311 —
preauthIntegrityHashValue
DECF98A420718718F22090D3580FCC5E484BD310FA1268210C6E86335A8891E767F5BCD99FA5A785
9D665AD07A73EA94E1BCDB7CFA69A6962A28A244138340B1
CypherId 0x0001
SessionKey 0x07B7F69C1E2581662DF6987E88F9E891
SigningKey 0x3DCC82C5795AE27F383242761078C59B
EncryptionKey 0xDFAAA31AAE40A2485D47AC4DF09FDA1D
DecryptionKey 0x95C544AEF6072680DA1CE49A68A97FA6
ApplicationKey 0x7A2F0F73EC2D530879B2913BBFCE242F

— Encryption —

SessionId 0x100000000021
SessionKey 0x07B7F69C1E2581662DF6987E88F9E891
SigningKey 0x3DCC82C5795AE27F383242761078C59B
EncryptionKey 0xDFAAA31AAE40A2485D47AC4DF09FDA1D
DecryptionKey 0x95C544AEF6072680DA1CE49A68A97FA6
ApplicationKey 0x7A2F0F73EC2D530879B2913BBFCE242F
Header.Command 0x0009 WRITE

Encryption of the request —

Key 0xDFAAA31AAE40A2485D47AC4DF09FDA1D

Nonce Length 0xb
AES-128-CCM nonce 0x9F6F1EAAD7E9F24AACD38F

SMB2 packet
FE534D4240000100000000000900010008000000000000000500000000000000FFFE000001000000
21000000001000000000000000000000000000000000000031007000170000000000000000000000
0500000004000000010000000400000000000000000000007000000000000000536D623320656E63
72797074696F6E2074657374696E67
transform_header.ProtocolId 0x424d53fd
transform_header.Signature 0xE89551D666DAB8993488F5A97103116C
transform_header.Nonce 0x9F6F1EAAD7E9F24AACD38F0000000000
transform_header.OriginalMessageSize 0x87
transform_header.Reserved 0x0
transform_header.Flags 0x0001
transform_header.SessionId 0x100000000021
Encrypted message
56A74778199A9D2B6E9C3A376FD88D27680694FED253A313BEB07381AE8689F973ACDB8D716E4477
803BCE53A92E1B81FA3E965AD9AF2C89C08CE66A344664453B8FC88118EDC9814CF58E92AA465E6E
FB09958A9FDAD96FBD55B36A710C30D5E7C64AD7B9449F9F17EDD024FE8BA79154F340A82740D1D5
180C69B0A2DE6A4BA893BD55D3210E

Transformed message
FD534D42E89551D666DAB8993488F5A97103116C9F6F1EAAD7E9F24AACD38F000000000087000000
00000100210000000010000056A74778199A9D2B6E9C3A376FD88D27680694FED253A313BEB07381
AE8689F973ACDB8D716E4477803BCE53A92E1B81FA3E965AD9AF2C89C08CE66A344664453B8FC881
18EDC9814CF58E92AA465E6EFB09958A9FDAD96FBD55B36A710C30D5E7C64AD7B9449F9F17EDD024
FE8BA79154F340A82740D1D5180C69B0A2DE6A4BA893BD55D3210E

Decryption of the response —

Transformed message
FD534D42DD33EC41A927DD51476FE887C2D3C136D96831DD2E8EB7B4000000000000000050000000
000001002100000000100000F783157E0F6F1C055D746753CA16D20C21088E2A67564E056C2F68A7
F14F226C3BD809B7A2D52E5FE4ECF49821BC6001733430CF174E2764B3CCB213AAD8BB9FBAF6C15E
13D9120965390E004A96A3F7
transform_header.ProtocolId 0x424d53fd
transform_header.Signature 0xDD33EC41A927DD51476FE887C2D3C136
transform_header.Nonce 0xD96831DD2E8EB7B40000000000000000
transform_header.OriginalMessageSize 0x50
transform_header.Reserved 0x0
transform_header.Flags 0x0001
transform_header.SessionId 0x100000000021

Key 0x95C544AEF6072680DA1CE49A68A97FA6

Nonce Length 0xb
AES-128-CCM nonce 0xD96831DD2E8EB7B4000000
Decrypted SMB2 packet
FE534D4240000100000000000900010001000000000000000500000000000000FFFE000001000000
21000000001000000000000000000000000000000000000011000000170000000000000000000000
Header.Command 0x0008 READ

Encryption of the request —

Key 0xDFAAA31AAE40A2485D47AC4DF09FDA1D

Nonce Length 0xb
AES-128-CCM nonce 0xA0F92E964EDC3049B86E19

SMB2 packet
FE534D4240000100000000000800010008000000000000000600000000000000FFFE000001000000
21000000001000000000000000000000000000000000000031000000170000000000000000000000
050000000400000001000000040000000000000000000000000000000000000000
transform_header.ProtocolId 0x424d53fd
transform_header.Signature 0x35BF9600C841F0CDA9BD1BC3727B7E36
transform_header.Nonce 0xA0F92E964EDC3049B86E190000000000
transform_header.OriginalMessageSize 0x71
transform_header.Reserved 0x0
transform_header.Flags 0x0001
transform_header.SessionId 0x100000000021
Encrypted message
C4CCD3EB483A0638E69C99E391E7F64BCC10D6BEE46FEEA258C4BCAF792CB5A6E69283924081806D
AB64827E9D14A5345D5221AB6DAFCB0E89FC2606B63D92163F4F6C93D1213D86ABF123B93EAD3AEF
9A3471EFD68A423A00A6E0064D9AE3C842EFFFAD236A3BF25D37F4CD054C97DE18

Transformed message
FD534D4235BF9600C841F0CDA9BD1BC3727B7E36A0F92E964EDC3049B86E19000000000071000000
000001002100000000100000C4CCD3EB483A0638E69C99E391E7F64BCC10D6BEE46FEEA258C4BCAF
792CB5A6E69283924081806DAB64827E9D14A5345D5221AB6DAFCB0E89FC2606B63D92163F4F6C93
D1213D86ABF123B93EAD3AEF9A3471EFD68A423A00A6E0064D9AE3C842EFFFAD236A3BF25D37F4CD
054C97DE18

Decryption of the response —

Transformed message
FD534D42E241A13C7E1EE42ECF1FD69F3B8668C6DA6831DD2E8EB7B4000000000000000067000000
00000100210000000010000015D67234FC8358D7BA1BF037ABC8EFD41A0A8F9BB04B16DEB1E85606
BD8C2770823FE6239A286CB3E3D5762ABBD53FD8DE11ED491FE905E146A8FFCE09414AB741103D63
7E28B19C6BA759B399DCC21FAE24CF2A455A13B215FC2857ABB513927F9F271D1C208B
transform_header.ProtocolId 0x424d53fd
transform_header.Signature 0xE241A13C7E1EE42ECF1FD69F3B8668C6
transform_header.Nonce 0xDA6831DD2E8EB7B40000000000000000
transform_header.OriginalMessageSize 0x67
transform_header.Reserved 0x0
transform_header.Flags 0x0001
transform_header.SessionId 0x100000000021

Key 0x95C544AEF6072680DA1CE49A68A97FA6

Nonce Length 0xb
AES-128-CCM nonce 0xDA6831DD2E8EB7B4000000
Decrypted SMB2 packet
FE534D4240000100000000000800010001000000000000000600000000000000FFFE000001000000
21000000001000000000000000000000000000000000000011005000170000000000000000000000
536D623320656E6372797074696F6E2074657374696E67 

Appendix B. How to disable SMB1 on Windows

 See [KB2696547] https://support.microsoft.com/en-us/kb/2696547

In Windows 8.1 / Server 2012 R2:
•To remove SMB1, use the following PowerShell cmdlet:
Remove-WindowsFeature FS-SMB1
•To add SMB1 feature:
Add-WindowsFeature FS-SMB1

Windows Client

•To disable SMBv1 on the SMB client, run the following commands:
sc.exe config lanmanworkstation depend= bowser/mrxsmb20/nsi
sc.exe config mrxsmb10 start= disabled

•To enable SMBv1 on the SMB client, run the following commands:
sc.exe config lanmanworkstation depend= bowser/mrxsmb10/mrxsmb20/nsi
sc.exe config mrxsmb10 start= auto

Windows Server

In Windows Server 2012 R2:
Get-SmbServerConfiguration | Select EnableSMB1Protocol, EnableSMB2Protocol
•To disable SMBv1 on the SMB server, run the following cmdlet:
Set-SmbServerConfiguration -EnableSMB1Protocol $false
•To enable SMBv1 on the SMB server, run the following cmdlet:
Set-SmbServerConfiguration -EnableSMB1Protocol $true

In older server versions:
•To disable SMBv1 on the SMB server, run the following cmdlet:
Set-ItemProperty -Path “HKLM:\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters” SMB1 -Type DWORD -Value 0 –Force
•To enable SMBv1 on the SMB server, run the following cmdlet:
Set-ItemProperty -Path “HKLM:\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters” SMB1 -Type DWORD -Value 1 –Force

[References]

Encryption in SMB 3.0: A protocol perspective
http://blogs.msdn.com/b/openspecification/archive/2012/10/05/encryption-in-smb-3-0-a-protocol-perspective.aspx

What’s new in SMB 3.1.1 in the Windows Server 2016 Technical Preview 2
http://blogs.technet.com/b/josebda/archive/2015/05/05/what-s-new-in-smb-3-1-1-in-the-windows-server-technical-preview-2.aspx

[MS-SMB2]: Server Message Block (SMB) Protocol Versions 2 and 3 Specification

https://msdn.microsoft.com/en-us/library/cc246482.aspx 

[SP800-108] National Institute of Standards and Technology. “Special Publication 800-108, Recommendation for Key Derivation Using Pseudorandom Functions”, October 2009, http://csrc.nist.gov/publications/nistpubs/800-108/sp800-108.pdf

[RFC5084] Housley, R., “Using AES-CCM and AES-GCM Authenticated Encryption in the Cryptographic Message Syntax (CMS)”, RFC 5084, November 2007, http://www.ietf.org/rfc/rfc5084.txt

SMB3 Secure Dialect Negotiation
http://blogs.msdn.com/b/openspecification/archive/2012/06/28/smb3-secure-dialect-negotiation.aspx

How to enable and disable SMBv1, SMBv2, and SMBv3 in Windows Vista, Windows Server 2008, Windows 7, Windows Server 2008 R2, Windows 8, and Windows Server 2012
https://support.microsoft.com/en-us/kb/2696547

SMB3 PowerShell changes in Windows Server 2012 R2: SMB1 can now be completely removed
http://blogs.technet.com/b/josebda/archive/2014/08/11/smb3-powershell-changes-in-windows-server-2012-r2-smb1-can-now-be-completely-removed.aspx

Note: This article was written using version 16.2 (10/30/2014) of the MS-OXCFXICS document as reference and all links contained in this article reference sections of that version of the document. The current version of the MS-OXCFXICS document can be found here: https://msdn.microsoft.com/en-us/library/cc463916(v=exchg.80).aspx

Resources:

• [MS-OXCFXICS] – Bulk Data Transfer Protocol

• [MS-OXPROPS] – Exchange Server Protocols Master Property List

• [MS-OXCDATA] – Data Structures

Introduction:
The FastTransfer Stream as described in MS-OXCFXICS section 2.2.4 and its related subsections can be an intimidating adversary if you are trying to implement a mail client or server that uses RPC as its primary method of communication (as opposed to ActiveSync or Exchange Web Services). The important thing to understand is that it is nothing more than a serialized collection of markers, properties, and values.

Sample Data:
The following sample data is the first part of a much larger stream of bytes. However, for the purposes of this article, it contains enough different property types to give you a good idea of how it all works.

0x0000: | 03 00 12 40 02 01 E1 65 00 00 00 00 02 01 E0 65
0x0010: | 16 00 00 00 52 F6 85 EC 7D 43 2E 4A A9 60 34 50
0x0020: | 88 53 D9 0A 00 00 00 00 03 F5 40 00 08 30 00 D0
0x0030: | 9E A8 81 85 D0 01 02 01 E2 65 16 00 00 00 52 F6
0x0040: | 85 EC 7D 43 2E 4A A9 60 34 50 88 53 D9 0A 00 00
0x0050: | 00 00 20 7C 02 01 E3 65 17 00 00 00 16 52 F6 85
0x0060: | EC 7D 43 2E 4A A9 60 34 50 88 53 D9 0A 00 00 00
0x0070: | 00 20 7C 1F 00 01 30 0C 00 00 00 49 00 4E 00 42
0x0080: | 00 4F 00 58 00 00 00 14 00 49 67 01 00 00 00 00
0x0090: | 00 03 F4 03 00 39 66 FB 03 00 00 40 00 07 30 80
0x00A0: | 39 06 A8 81 85 D0 01 0B 00 F4 10 00 00

Breaking it Down:
The Lexical Structure of the FastTransfer Stream might look complicated at first but we can summarize it as follows:

1. The stream consists of elements. 
2. Each element is either a marker or a propValue. 
1. If the element matches an entry from the table in section 2.2.4.1.4, it’s a Marker. If not, it’s a propValue.
3. propValues are either fixed or variable length.
1. The first 2 bytes of the propValue represent the data type. Reference MS-OXCDATA section 2.11.1 to find out what type it is and whether it’s fixed or variable length.
1. If it’s fixed length, read the next x number of bytes as indicated by the type.
2. If it’s variable length, follow the description provided to correctly read the value.

Markers:
Markers are the easiest to understand and come in 2 types. They are either stand-alone, or consist of a pair of start and end markers. They are nothing more than a 4-byte value that tells you something about the properties that come after it in the stream (unless it’s an end marker). Taking a look at our example data stream from above let’s look at the first element and try to determine if it’s a marker or a propValue.

Element[0]:
0x0000: | 03 00 12 40 02 01 E1 65 00 00 00 00 02 01 E0 65

The value of the first element is 0x40120003 (remember that int32 type values are transmitted in little-endian format). From looking at the table in MS-OXCDATA section 2.2.4.1.4 we can see that this represents the IncrSyncChange Marker which “signifies the start of ICS information pertaining to the message.” That’s all there is to it. Moving on…

propValues:
If the element isn’t a Marker (the element value is NOT in the table in MS-OXCFXICS section 2.2.4.1.4), it’s a propValue. There are 2 types of propValues, fixed and variable length. The table in MS-OXCDATA section 2.11.1 contains all of the possible types. The list is fairly long so I will only talk about the ones that appear in our sample data. Let’s take a look at the first one…

Element[1]:
0x0000: | 03 00 12 40 02 01 E1 65 00 00 00 00 02 01 E0 65

The element value is 0x65E10102, which is not a Marker (check the table!), which means it’s a propValue. There are 2 things that you need to do with this. First, look up the type in MS-OXCDATA section 2.11.1. In this case, the type 0x0102 means that the property is a PtypBinary. According to the description, this type is “Variable size; a COUNT field followed by that many bytes.” The COUNT field is 4 bytes in length and should be read as an integer, which in this case is the value 0x00000000, or simply 0. This also means that this is the end of this propType. Because the COUNT value is 0, no bytes follow it that belong to this property. But what does the property represent? That’s the second thing to do, look up the Property ID in MS-OXPROPS. In this case, the Property ID 0x65E1 belongs to the PidTagParentSourceKey property (section 2.850).

Taking a look at the next element…

Element[2]:
0x0000: | 03 00 12 40 02 01 E1 65 00 00 00 00 02 01 E0 65
0x0010: | 16 00 00 00 52 F6 85 EC 7D 43 2E 4A A9 60 34 50
0x0020: | 88 53 D9 0A 00 00 00 00 03 F5 40 00 08 30 00 D0

You can probably tell by how many bytes I’ve highlighted above that there is definitely more going on with this next one. Following the same process as before, get the element (0x65E00201) which is a propValue. This is also a PtypBinary type so you know that the next thing you have to do is get the COUNT, which in this case is 0x00000016, or 22 in decimal format. This tells us that the next 22 bytes should be read as a byte array. That’s easy, but what does that data actually represent? Going into that much depth with each property would be beyond the scope of this article, but here’s a hint: Look up the Property ID (0x65E0) in MS-OXPROPS (PidTagSourceKey) and then check the defining reference (MS-OXCFXICS section 2.2.1.2.5).

Let’s parse a few more propValues…

Element[3]:
0x0020: | 88 53 D9 0A 00 00 00 00 03 F5 40 00 08 30 00 D0
0x0030: | 9E A8 81 85 D0 01 02 01 E2 65 16 00 00 00 52 F6

propValue: 0x30080040
Property type: 0x0040 – PtypTime
Property ID: 0x3008 – PidTagLastModificationTime
Value: 05/03/2015 09:15:12
Note: See MS-DTYP section 2.3.3 on how to interpret this type of value.

Element[4]:
0x0030: | 9E A8 81 85 D0 01 02 01 E2 65 16 00 00 00 52 F6
0x0040: | 85 EC 7D 43 2E 4A A9 60 34 50 88 53 D9 0A 00 00
0x0050: | 00 00 20 7C 02 01 E3 65 17 00 00 00 16 52 F6 85

propValue: 0x65E20102
Property type: 0x0102 – PtypBinary
Property ID: 0x65E2 – PidTagChangeKey
Value: See MS-OXCFXICS section 2.2.1.2.7

Element[5]:
0x0050: | 00 00 20 7C 02 01 E3 65 17 00 00 00 16 52 F6 85
0x0060: | EC 7D 43 2E 4A A9 60 34 50 88 53 D9 0A 00 00 00
0x0070: | 00 20 7C 1F 00 01 30 0C 00 00 00 49 00 4E 00 42

propValue: 0x65E30102
Property type: 0x0102 – PtypBinary
Property ID: 0x65E3 – PidTagPredecessorChangeList
Value: See MS-OXCFXICS section 2.2.1.2.8

Element[6]:
0x0070: | 00 20 7C 1F 00 01 30 0C 00 00 00 49 00 4E 00 42
0x0080: | 00 4F 00 58 00 00 00 14 00 49 67 01 00 00 00 00

propValue: 0x3001001F
Property type: 0x001F – PtypString
Property ID: 0x3001 – PidTagDisplayName
Value: “INBOX”
Note: Per MS-OXCDATA section 2.11.1 this “a string of Unicode characters in UTF-16LE format encoding with terminating null character (0x0000).”

Element[7]:
0x0080: | 00 4F 00 58 00 00 00 14 00 49 67 01 00 00 00 00
0x0090: | 00 03 F4 03 00 39 66 FB 03 00 00 40 00 07 30 80

propValue: 0x67490014
Property type: 0x0014 – PtypInteger64
Property ID: 0x6749 – PidTagParentFolderId
Value: -863846703525003263

Element[8]:
0x0090: | 00 03 F4 03 00 39 66 FB 03 00 00 40 00 07 30 80

propValue: 0x66390003
Property type: 0x0003 – PtypInteger32
Property ID: 0x6639 – PidTagRights
Value: 0x000003FB
Note: See MS-OXCPERM section 2.2.7 on how to interpret these flags.

Element[9]:
0x0090: | 00 03 F4 03 00 39 66 FB 03 00 00 40 00 07 30 80
0x00A0: | 39 06 A8 81 85 D0 01 0B 00 F4 10 00 00

propValue: 0x30070040
Property type: 0x0040 – PtypTime
Property ID: 0x3007 – PidTagCreationTime
Value: 05/03/2015 09:15:11
Note: See MS-DTYP section 2.3.3 on how to interpret this type of value.

Element[10]:
0x00A0: | 39 06 A8 81 85 D0 01 0B 00 F4 10 00 00

propValue: 0x10F4000B
Property type: 0x000B – PtypBoolean
Property ID: 0x3007 – PidTagAttributeHidden
Value: 0x0000 (False)
Note: If you look at the table in MS-OXCDATA section 2.11.1 you will see that the description for PtypBoolean states that it is “1 byte; restricted to 1 or 0.” However, you can see that I have 2 bytes highlighted. This is because PtypBoolean is serialized differently than is described there. This difference is described in MS-OXCFXICS in section 2.2.4.1.3 where it states that the PtypBoolean type is “2-bytes in FastTransfer streams, instead of 1-byte as specified in [MS-OXCDATA]. Using little-endian byte ordering, “01 00″ for TRUE and “00 00″ for FALSE.”

I hope this helps you to understand how the Fast Transfer stream is serialized. Even though we only looked at a few of the elements in this stream, it should give you a good idea on how to proceed to parse a complete FastTransfer stream.

Introduction
This will be the first in a series of articles on various OpenXML topics. This article provides an expanded description of how Style Inheritance works. We will be using an example created in Microsoft Word 2016 and then manually modifying the package contents.

By simply reading through this blog you should be able to grasp how to manually create your own custom styles and how to build more complex styles using Style Inheritance. However, nothing beats getting some actual hands-on experience. I highly encourage you to perform the steps as they are presented here and experiment on your own.

Resources
This article will refer exclusively to information contained in ISO/IEC 29500-1. The latest version, as of this article’s release date, was published in September of 2012 and can be downloaded from the following location.

http://standards.iso.org/ittf/PubliclyAvailableStandards/index.html

Getting Started
We will start by creating a very simple document that contains three paragraphs. The actual contents of the paragraphs isn’t very important, but it makes it easier to identify each one in the XML if they are numbered on some way.

Figure 1: Three paragraphs in the default style.

Save the document and then rename the file with a .zip extension.

Note: It is assumed that you already understand that the .DOCX, .XLSX, and .PPTX file formats are actually special .ZIP packages that contain all of the XML files used to construct the document. ISO/IEC 29500-1 section 9 contains a summary of the package format. ISO/IEC 29500-2 deals exclusively with the Open Packaging Conventions (OPC) format.

Examining the Package Contents
Once you have renamed the file to have a .zip extension, go ahead and extract the contents. Open the folder and then examine the contents of the “word” folder. The contents should look similar to this.

Figure 2: The contents of the “word” folder.

The two files that we will be working with are document.xml and styles.xml. Go ahead and open the document.xml and styles.xml files in a basic text editor. The first thing you will notice is that the contents are one big blob of text without any kind of formatting unless you are using an application that was designed specifically for editing XML files. There are a few different ways to fix this, but if you are a Visual Studio user you can use the Edit -> Advanced -> Format Document command.

The section of the document.xml file that we will be working with is in the middle that has our three paragraphs.

document.xml
<w:p w:rsidR=”00BA6E33″ w:rsidRDefault=”009A7F68″>
   <w:r>
      <w:t>Paragraph 1</w:t>
   </w:r>
</w:p>
<w:p w:rsidR=”009A7F68″ w:rsidRDefault=”009A7F68″>
   <w:r>
      <w:t>Paragraph 2</w:t>
   </w:r>
</w:p>
<w:p w:rsidR=”009A7F68″ w:rsidRDefault=”009A7F68″>
   <w:r>
      <w:t>Paragraph 3</w:t>
   </w:r>
   <w:bookmarkStart w:id=”0″ w:name=”_GoBack”/>
   <w:bookmarkEnd w:id=”0″/>
</w:p>

There isn’t anything in the styles.xml file that we really care about right now. The only thing worth taking note of is the “Normal” style near the bottom of the file.

styles.xml
<w:style w:type=”paragraph” w:default=”1″ w:styleId=”Normal”>
   <w:name w:val=”Normal”/>
   <w:qFormat/>
</w:style>

Creating a New Style
Additional details on the style element can be found in ISO/IEC 29500-1 section 17.7.4.17. For now, we will create a very simple style that is based on the Normal style, sets it to be Bold, and increases the font size.

styles.xml
<w:style w:type=”paragraph” w:styleId=”MyCustomStyle1″>
   <w:name w:val=”My Custom Style 1″/>
   <w:basedOn w:val=”Normal”/>
   <w:rPr>
      <w:sz w:val=”32″/>
      <w:b w:val=”true”/>0
   </w:rPr>
</w:style>

Next, we will assign this style to the first paragraph of our document.

document.xml
<w:p w:rsidR=”00BA6E33″ w:rsidRDefault=”009A7F68″>
   <w:pPr>
      <w:pStyle w:val=”MyCustomStyle1″/>
   </w:pPr>
   <w:r>
      <w:t>Paragraph 1</w:t>
   </w:r>
</w:p>

After you make those changes and save the files you will need to update the package contents. It’s important to understand that you can’t just re-zip the main folder and put a .docx extension on it. It will be missing all of the metadata. The best way to update the package contents is to overwrite the existing files in the original .zip package with the updated ones and then rename back to the .docx extension. After you do that and open the file it Word it should look like this.

Figure 3: MyCustomStyle1 applied to the first paragraph.

Inheriting From a Custom Style
For the second paragraph lets create a new style that inherits from the one used in the first paragraph. We will add a new element and change an existing one to demonstrate how the style at the leaf level overrides the style(s) further up the inheritance tree.

styles.xml
<w:style w:type=”paragraph” w:styleId=”MyCustomStyle2″>
   <w:name w:val=”My Custom Style 2″/>
   <w:basedOn w:val=”MyCustomStyle1″/>
   <w:rPr>
      <w:b w:val=”false”/>
      <w:color w:val=”FF0000″/>
   </w:rPr>
</w:style>

And assign the new style to the second paragraph…

document.xml
<w:p w:rsidR=”009A7F68″ w:rsidRDefault=”009A7F68″>
   <w:pPr>
      <w:pStyle w:val=”MyCustomStyle2″/>
   </w:pPr>
   <w:r>
      <w:t>Paragraph 2</w:t>
   </w:r>
</w:p>

Update the package contents again and let’s take a look at the result.

Figure 4: MyCustomStyle2 applied to the second paragraph

As you can see the text in the second paragraph is still 16pt in size which was inherited from MyCustomStyle1, is no longer bold, and is now red.

Overwriting Everything
Regardless of what is inherited from previous styles in the tree, it is possible to simply overwrite everything. There is no real practical use for this. Creating a new style that doesn’t inherit from another style is probably a better choice and will give the same results, but we are doing this for demonstration purposes. Here is a third style that inherits from the second style that overwrites each property set previously.

styles.xml
<w:style w:type=”paragraph” w:styleId=”MyCustomStyle3″>
   <w:name w:val=”My Custom Style 3″/>
   <w:basedOn w:val=”MyCustomStyle2″/>
   <w:rPr>
      <w:sz w:val=”64″/>
      <w:b w:val=”true”/>
      <w:color w:val=”0000FF”/>
   </w:rPr>
</w:style>

And apply it to the third paragraph…

document.xml
<w:p w:rsidR=”009A7F68″ w:rsidRDefault=”009A7F68″>
   <w:pPr>
      <w:pStyle w:val=”MyCustomStyle3″/>
   </w:pPr>
   <w:r>
      <w:t>Paragraph 3</w:t>
   </w:r>
   <w:bookmarkStart w:id=”0″ w:name=”_GoBack”/>
   <w:bookmarkEnd w:id=”0″/>
</w:p>

And take a look at the result.

Figure 5: MyCustomStyle3 applied to the third paragraph.

As you can see the font size is now set to 32pt, bold has been turned on again, and the text is blue.

Summary
Thank you for taking the time to read through this article. This was a simple introduction to how Style Inheritance works in Open XML. I hope that this was useful for you and answered any questions that you may have had on the subject. In future articles we will dig deeper into styles and explore other topics such as the Style Hierarchy, Linked Styles, and more.

I encourage you to send you feedback or questions regarding this article, or any other Open XML related topics to Microsoft Interoperability Support at dochelp@microsoft.com or posted on the Office XML, ODF, and Binary File Formats forum on MSDN.

Introduction
This is the second in a series of articles covering various OpenXML topics. This article provides an example of creating some simple table styles that use conditional formatting, the pitfalls that you would probably encounter, and how to get the results you’re expecting. We will be using an example created in Microsoft Word 2016 and then manually modifying the package contents. 

By simply reading through this blog you should be able to grasp how to manually create your own custom table styles with conditional formatting. However, nothing beats getting some actual hands-on experience. I highly encourage you to perform the steps as they are presented here and experiment on your own.

Resources
This article will refer to information contained in ISO/IEC 29500-1 and a few other documents as necessary. The latest version of ISO/IEC 29500-1, as of this article’s release date, was published in September of 2012 and can be downloaded from the following location.

http://standards.iso.org/ittf/PubliclyAvailableStandards/index.html

Getting Started
We will start by creating a very simple document that contains a table. Use the Insert -> Table ribbon button and select the maximum size table from the UI (10×8). You don’t have to make the table this large if you don’t want to, but I find that having more rows and columns makes it easier to see the changes that we will be making. Your document should look something like this.

Figure 1: A new document containing an empty table.

Save the document and then rename the file with a .zip extension.

Note: It is assumed that you already understand that the .DOCX, .XLSX, and .PPTX file formats are actually special .ZIP packages that contain all of the XML files used to construct the document. ISO/IEC 29500-1 section 9 contains a summary of the package format. ISO/IEC 29500-2 deals exclusively with the Open Packaging Conventions (OPC) format.

Examining the Package Contents
Once you have renamed the file to have a .zip extension, go ahead and extract the contents. Open the folder and then examine the contents of the “word” folder. The contents should look similar to this.

Figure 2: The contents of the “word” folder.

The two files that we will be working with are document.xml and styles.xml. Go ahead and open the document.xml and styles.xml files in a basic text editor. The first thing you will notice is that the contents are one big blob of text without any kind of formatting unless you are using an application that was designed specifically for editing XML files. There are a few different ways to fix this, but if you are a Visual Studio user you can use the Edit -> Advanced -> Format Document command.

We will only be concerned with a few lines from the document.xml file. We won’t be doing anything to it right away so you just need to locate them for now.

document.xml
   <w:tblPr>
      <w:tblStyle w:val=”TableGrid”/>
      <w:tblW w:w=”0″ w:type=”auto”/>
      <w:tblLook w:val=”04A0″ w:firstRow=”1″ w:lastRow=”0″ w:firstColumn=”1″
                 w:lastColumn=”0″ w:noHBand=”0″ w:noVBand=”1″/>
   </w:tblPr>

Most of the work we will be doing is going to be in the styles.xml file. We will be making changes to the built-in TableGrid style. Currently, the style does not have any conditional formatting specified. We will add that in the next section.

styles.xml
   <w:style w:type=”table” w:styleId=”TableGrid”>
      <w:name w:val=”Table Grid”/>
      <w:basedOn w:val=”TableNormal”/>
      <w:uiPriority w:val=”39″/>
      <w:rsid w:val=”00131252″/>
      <w:pPr>
         <w:spacing w:after=”0″ w:line=”240″ w:lineRule=”auto”/>
      </w:pPr>
      <w:tblPr>
         <w:tblBorders>
            <w:top w:val=”single” w:sz=”4″ w:space=”0″ w:color=”auto”/>
            <w:left w:val=”single” w:sz=”4″ w:space=”0″ w:color=”auto”/>
            <w:bottom w:val=”single” w:sz=”4″ w:space=”0″ w:color=”auto”/>
            <w:right w:val=”single” w:sz=”4″ w:space=”0″ w:color=”auto”/>
            <w:insideH w:val=”single” w:sz=”4″ w:space=”0″ w:color=”auto”/>
            <w:insideV w:val=”single” w:sz=”4″ w:space=”0″ w:color=”auto”/>
         </w:tblBorders>
      </w:tblPr>
   </w:style>

Note: If you have read my previous article, Creating Custom Styles and Understanding Style Inheritance, you may have noticed that the TableGrid style is based on the TableNormal style. However, we will not be making any changes to the TableNormal style and we are not concerned with any of the settings from it. You may still want to take a look it in order to understand the entire style that is being applied to the table though.

Table Styles and Row Banding
ISO/IEC 29500-1 section 17.7.6 and its related subsections contain the majority of the information that you need to know in order to be able to create table styles that use conditional formatting for things such as row and column banding. The element that you use to define the type of conditional formatting being applied is the tblStylePr element (section 17.7.6.6). For example, if we add the following to the TableGrid style it should add a shaded background to the odd numbered rows.

<w:tblStylePr w:type=”band1Horz”>
   <w:tcPr>
      <w:shd w:val=”clear” w:color=”auto” w:fill=”AAAAAA” />
   </w:tcPr>
</w:tblStylePr>

Note: Add this block of XML either right after the rsid element or after the pPr element block. If you add it after the tblPr element block that contains the tblBorders it won’t show up correctly.

If you’re following along and implementing this as you’re reading through this article you are now probably wondering why the row banding doesn’t seem to be working. I’ve intentionally left something out to illustrate a very important point when working with the ISO/IEC 29500 specification, which is that the Office products don’t always behave according to the spec.

The issue here deals with tblStyleRowBandSize which is described in section 17.7.6.7. This element allows you specify how many rows will be grouped into a single band when conditional formatting is applied. If you look at the TableGrid style you’ll notice that this element is not defined, and per the spec “If this element is omitted, then the default number of rows in a single row band shall be assumed to be 1.” So, it shouldn’t be a problem, right? Unfortunately, that’s not the case here.

The lesson to learn from this is the following: When you encounter behavior that differs from, or seems to contradict the specification, it’s probably because Word/Excel/PowerPoint is doing something different, which is exactly what is happening here.

The document to look at that describes these differences is MS-OI29500. Section 2.1, Normative Variations, contains almost 2,000 sections with information about how the Office implementations differ from what is described in ISO/IEC 29500. In this case, section 2.1.251 contains notes about how Word treats the tblStyleRowBandSize element and the first 2 items are what we care about.

a. The standard says the default for tblStyleRowBandSize is 1.
     Word uses 0 as the default for tblStyleRowBandSize.

b. The standard does not specify the meaning if tblStyleRowBandSize is set to 0.
             If tblStyleRowBandSize is set to 0, Word does not apply any banded row conditional formatting.

That should be self-explanatory. But if you’re still not sure, it means that we need to add the tblStyleRowBandSize element to our style and give it a value of 1 or greater. Just to be safe, we should go ahead and add the tblStyleColBandSize element as well since it behaves exactly the same way. Once you add those the complete style should look similar to the following.

styles.xml
   <w:style w:type=”table” w:styleId=”TableGrid”>
      <w:name w:val=”Table Grid”/>
      <w:basedOn w:val=”TableNormal”/>
      <w:uiPriority w:val=”39″/>
      <w:rsid w:val=”00131252″/>
      <w:tblStyleRowBandSize w:val=”1″/>
      <w:tblStyleColBandSize w:val=”1″/>
      <w:tblStylePr w:type=”band1Horz”>
         <w:tcPr>
            <w:shd w:val=”clear” w:color=”auto” w:fill=”AAAAAA” />
         </w:tcPr>
      </w:tblStylePr>
      <w:pPr>
         <w:spacing w:after=”0″ w:line=”240″ w:lineRule=”auto”/>
      </w:pPr>
      <w:tblPr>
         <w:tblBorders>
            <w:top w:val=”single” w:sz=”4″ w:space=”0″ w:color=”auto”/>
            <w:left w:val=”single” w:sz=”4″ w:space=”0″ w:color=”auto”/>
            <w:bottom w:val=”single” w:sz=”4″ w:space=”0″ w:color=”auto”/>
            <w:right w:val=”single” w:sz=”4″ w:space=”0″ w:color=”auto”/>
            <w:insideH w:val=”single” w:sz=”4″ w:space=”0″ w:color=”auto”/>
            <w:insideV w:val=”single” w:sz=”4″ w:space=”0″ w:color=”auto”/>
         </w:tblBorders>
      </w:tblPr>
   </w:style>

Now when you open the document in Word it should look something like this.

Figure 3: A table with odd row banding applied.

Column Banding
In addition to row banding you can add column bands as well. It works almost exactly the same way as row banding in that you just need to add a tblStylePr element with the right type and that’s almost all there is to it. Let’s add odd column banding and set it to a slightly lighter shade of gray.

<w:tblStylePr w:type=”band1Vert”>
   <w:tcPr>
      <w:shd w:val=”clear” w:color=”auto” w:fill=”CCCCCC” />
   </w:tcPr>
</w:tblStylePr>

Once again, if you’re following along and testing each change we make you’re probably wondering why the column banding isn’t showing up. This is where we need to go back and look at the line from the document.xml file that looked like this.

<w:tblLook w:val=”04A0″ w:firstRow=”1″ w:lastRow=”0″ w:firstColumn=”1″ w:lastColumn=”0″ w:noHBand=”0″ w:noVBand=”1″/>

The details about this element are in section 17.4.55. But if you examine the values for the different attributes in the line above the problem should jump out at you. The noVBand attribute is set to 1, or true. This means that “the vertical banding conditional formatting shall not be applied to the table.” The fix should be equally as obvious, setting noVBand to 0 (similar to noHBand) tells word to apply any conditional formatting for columns. The table should now look like this.

Figure 4: A table with both row and column banding applied.

One Last Thing
The last issue may not be obvious and it’s likely that most people would never notice or even care, but it’s something that you should be aware of. Did you notice how the column banding is overwriting the row banding? Regardless of whether or not that was the behavior you we’re expecting, that’s the result. But why? If we take a look at the description of how the different conditional formatting options are applied (section 17.7.6.6) we see that is tells us the following:

When specified, these conditional formats shall be applied in the following order (therefore subsequent formats override properties on previous formats):

• Whole table
• Banded columns, even column banding
• Banded rows, even row banding
• First row, last row
• First column, last column
• Top left, top right, bottom left, bottom right

The problem should be a little more clear at this point. According to the specification, row banding should be applied after column banding. So why do we see the opposite behavior? This is another one of those cases where Word behaves differently from the spec. As we did previously, we should look in MS-OI29500 to see if has anything to say about this, and it does. Section 2.1.250 is the entry for the tblStylePr element and it states the following:

a. The standard specifies the precedence order in which conditional formatting should be applied.
     When specified, Office applies conditional formats in the following order (therefore subsequent formats override properties on previous formats):

• Whole table
• Banded rows, even row banding
• Banded columns, even column banding
• First column, last column
• First row, last row
• Top left, top right, bottom left, bottom right

As you can see, Word actually applies the column banding after the row banding which is why the table looks the way it does.

Summary
Thank you for taking the time to read through this article. I hope that you found it useful and that it may have answered a few questions you had on table styles or how conditional formatting works. 

I encourage you to send any feedback or questions regarding this article, or any other Open XML related topics to Microsoft Interoperability Support at dochelp@microsoft.com or post on the Office XML, ODF, and Binary File Formats forum on MSDN.

Verifying STUN Message Integrity for Lync and Skype for Business ICE Traffic

Recently there have been some inquiries about how to verify the integrity of messages in STUN protocol conversations when used by Lync and Skype for Business.  In this blog post, I will describe a common scenario based on a recent customer inquiry and explain how it was resolved.

Background

Interactive Connectivity Establishment (ICE)¹ is a protocol that allows endpoints to create a media based connection across multiple networks where NAT is used.  ICE makes use of STUN² (Simple Traversal of UDP through NAT) and TURN³ (Traversal Using Relay NAT), two solutions to finding the internal addresses of remote endpoints when NAT is involved. Also useful in this discussion is the fact that the Open
Specifications include Microsoft’s extensions to ICE, namely the [MS-ICE], [MS-ICE2] and [MS-ICE2BWM] documents. We will reference [MS-ICE2]⁴ in this discussion.

Scenario

In this scenario, two Lync endpoints have established a connection via the ICE protocol and are in the process of connectivity checks per STUN. As part of the Binding Request message, an attribute is included called the MESSAGE-INTEGRITY. This contains an HMAC-SHA1⁵ hash of the message called an HMAC.

In the network trace for this scenario, the STUN Binding Requests are being sent, having already shared the temporary username and password in previous Shared Secret Request.

Figure 1 MESSAGE-INTEGRITY Attribute

The calculation of the MESSAGE-INTEGRITY attribute is described in section 10.2.8 of the referenced STUN RFC. The HMAC-SHA1represents a hash of the message up to but not including the MESSAGE-INTEGRITY attribute itself.

To manually test this out, you can compute an HMAC using the jsSHA⁶ tool. Following the description in STUN 10.2.8, an overview of the steps:

1. Copy the message data from your network analysis tool as a hex stream from the beginning of the STUN Binding Request message to just before the MESSAGE-INTEGRITY attribute. Insert this into the “Input Text:” field of the HMAC Demo section in the jsSHA tool. Remember to pad the text with 0’s to make up the 64-byte multiple length. Set the Input Type to HEX
2. Provide the Key from the previous Shared Secret Request (not included in this explanation)
3. Set the Key Type to TEXT
4. SHA Variant should be SHA-1 and Output Type should be HEX

The resulting Output Hash field will update automatically and should match the value in the MESSAGE-INTEGRITY attribute.

In the above shown packet in figure 1, the text used to compute the HMAC is:

0x0000 000100542112A442

0x0008 BEEBD6F17710B6A1

0x0010 B6A92CBD0006000C

0x0018 764F614D3A667641

0x0020 7300000000240004

0x0028 6EFFFEFF80290008

0x0030 000000000001E6E4

0x0038 8054000431000000

0x0040 8070000400000002 <= stop just before the MESSAGE-INTEGRITY attribute

0x0048 0000000000000000 <= added 56 bytes of 0’s from here to the end

0x0050 0000000000000000

0x0058 0000000000000000

0x0060 0000000000000000

0x0068 0000000000000000

0x0070 0000000000000000

0x0078 0000000000000000

The total length of this is 0x80 hex or 128 bytes. The key from the Shared Secret Request for this conversation was:

ydYldnHIRgbOUr1MYUGy4t0g

Given this data and the steps above, you can even verify the resulting HMAC yourself by using the jsSHA tool. What you should see as a result is: 

b87d4d8d56fc76794667aacae3593e58e1dbfe97

which matches the one in your trace.

However, in the customer scenario, for them it wasn’t matching.

Problem and Resolution

The problem in this scenario was that the MESSAGE-INTEGRITY HMAC hash value was not comparing correctly with the value computed using the shared key and message data.

The customer in this scenario was following the newer STUN draft RFC (http://tools.ietf.org/html/draft-ietf-behave-rfc3489bis-08#section-14.4) which adds some verbiage to the message integrity validation process, specifically:

“Based on the rules above, the hash includes the length field from the STUN message header.  This length indicates the length of the entire message, including the MESSAGE-INTEGRITY attribute itself.  Consequently, the MESSAGE-INTEGRITY attribute MUST be inserted into the message (with dummy content) prior to the computation of the integrity check.  Once the computation is performed, the value of the attribute can be filled in.  This ensures the length has the correct value when the hash is performed.  Similarly, when validating the MESSAGE-INTEGRITY, the length field should be adjusted to point to the end of the MESSAGE-INTEGRITY attribute prior to calculating the HMAC.  Such adjustment is necessary when attributes, such as FINTERPRINT, appear after MESSAGE-INTEGRITY.”

This is not in the old (obsoleted) STUN RFC (http://tools.ietf.org/html/draft-ietf-behave-rfc3489bis-02#section-10.2.8). The problem is that the Lync processing is using the older RFC for the MESSAGE-INTEGRITY attribute and doesn’t include specifically the modification of the length in the message header before calculating the HMAC. The [MS-ICE2] open specification does reference the correct STUN RFC (i.e. the old one) in 2.2.2 but references (indirectly via ICE/NAT RFC¹ ) the newer one in 3.1.4.8.2.4 where it speaks directly about calculating the MESSAGE-INTEGRITY attribute.  

So, the only change to make to get the correct result, was to stop modifying the length field in the message header before calculating the HMAC.

The main take away from this exercise is that Lync uses the original STUN RFC for MESSAGE-INTEGRITY.  It’s important to take note of the references provided in the Microsoft Open Specifications when parsing or coding to a protocol that is used by a Microsoft product. In this case [MS-ICE2] was misleading as it referred to the older STUN in 2.2.2 and the newer one (indirectly) in 3.1.4.8.2.4.

References

1. ICE: http://tools.ietf.org/html/draft-ietf-mmusic-ice-19
2. STUN: http://tools.ietf.org/html/draft-ietf-behave-rfc3489bis-02
3. New STUN: http://tools.ietf.org/html/draft-ietf-behave-rfc3489bis-08
4. TURN: http://tools.ietf.org/html/draft-rosenberg-midcom-turn-08
5. [MS-ICE2]: https://msdn.microsoft.com/en-us/library/dd907518(v=office.12).aspx
6. HMAC-SHA1: http://tools.ietf.org/html/rfc2104

User-to-User Mechanism

User-to-User GSS-API messages

U2U via KDC policy

U2U via server policy

U2U illustrations

Deliberate Kerberos U2U from client: CredSSP in Remote Desktop Session

Kerberos U2U: Enabling SSO with NTLM for smart card sign-in

Kerberos U2U via KDC policy: Offering Remote Assistance

Conclusion

Appendix 1. Related Kerberos Error codes

Appendix 2. Steps of standard CredSSP’s Kerberos U2U from client

Appendix 3. Steps of Kerberos U2U via KDC policy in Offering Remote Assistance

References

Introduction

• Security considerations in the specification.
• Signing and encryption operations.
• Algorithms used for each security feature for a given dialect.
• Keys in SMB2 and SMB3 protocols.
• Specifics of key derivation in SMB 3.0.x and 3.1.1.
• Illustration of key calculation steps for multichannel.
• Illustration of the (out-of-favor yet) popular NTLMv2 session key calculation.

Windows versions and chronology of dialects in MS-SMB2

Deprecating SMB1

Dialects in Windows 10 v1703 implementation of MS-SMB2

Chronology of crypto algorithms in MS-SMB2

Security considerations in SMB2 and SMB3

Key consideration

SessionKey

NTLM SessionKey

• NTLM does not support any modern cryptographic methods, such as AES or SHA-256. Its key derivation from the password is based on MD4 [RFC1320], DES [FIPS46-2], HMAC_MD5, and RC4.
• NTLM does not use any salt. It is possible to observe a network packet trace and produce the same key if the attacker knows password, as shown in the appendix by an example of NTLMv2 session key calculation.
• NTLM does not offer mutual authentication between client and server. The is no so such flag in the protocol.
• The password length and complexity should be chosen carefully to mitigate brute force attacks.
• At a minimum, NTLMv2 should be used, and auditing should be in place.

Kerberos SessionKey

GSS_GetMIC() and GSS_Wrap() or their Ex() extensions

MS-SMB2 message integrity

Signed session

Secure dialect negotiation in SMB 3.0.x

Pre-authentication integrity in SMB 3.1.1

Keys in SMB 2.x through 3.1.1

Dialects 2.0.2 and 2.1

Dialects 3.x

• Key size: 128-bit i.e. 16 bytes each.
• Session.SigningKey: Key used for signing the SMB2 messages on this session.
• Channel.SigningKey: Key used for signing the SMB2 messages on this channel when session binding is used for multiple channels.
  o If the session is setup with SMB2_SESSION_FLAG_BINDING, Channel.SigningKey must be generated. Both master session and binding session must be from the same security principal, i.e. same security identifier (SID).
  o If SMB2_SESSION_FLAG_BINDING is not set, Channel.SigningKey is set to Session.SigningKey. Note that two security principals can still multiplex separate channels on the same connection.
• Session.ApplicationKey: Key mainly queried by higher-layer applications. An example is SAMR protocol over named pipe SMB2 transport [MS-SAMR]. ApplicationKey is generated for non-binding sessions.
• Session.EncryptionKey: Key used by the sender for encrypting messages. There is one encryption key for all sessions bound to a master session. This enables to send encrypted messages on any channel.
• Session.DecryptionKey: Key used by the receiver for decrypting messages. Likewise, the decryption key is the same for all sessions bound to a master session. If a decrypted message contains compounded related SMB2 messages, these later must all belong to the same SessionId.

Dialects 3.0 and 3.0.2

Dialect 3.1.1

SMB 3.x key derivation function

Parameters for Dialects 3.0 and 3.0.2 cryptographic keys

• SigningKey = SMB3KDF ( SessionKey, “SMB2AESCMAC\0”, “Smbign\0”)
• ApplicationKey = SMB3KDF (SessionKey, “SMB2APP\0”, “SmbRpc\0”)
• EncryptionKey (Client) = DecryptionKey (Server) =  SMB3KDF (SessionKey, “SMB2AESCCM\0”, “ServerIn \0”)
• EncryptionKey (Server) = DecryptionKey (Client) = SMB3KDF (SessionKey, “SMB2AESCCM\0”, “ServerOut\0”)

Parameters for Dialect 3.1.1 cryptographic keys

• SigningKey = SMB3KDF (SessionKey, “SMBSigningKey\0”, Session.PreauthIntegrityHashValue)
• ApplicationKey = SMB3KDF (SessionKey, “SMBAppKey\0”, Session.PreauthIntegrityHashValue)
• EncryptionKey (Client) = DecryptionKey (Server) = SMB3KDF (SessionKey, “SMBC2ScipherKey\0”, Session.PreauthIntegrityHashValue)
• DecryptionKey (Client) = EncryptionKey (Server) = SMB3KDF (SessionKey, “SMBS2CCipherKey\0”, Session.PreauthIntegrityHashValue)

SMB 3.x Session binding

SMB 3.1.1 Session binding and pre-authentication integrity

Signing algorithms

Signing in dialects 2.0.2 and 2.1

Signing in dialects 3.0, 3.0.2, 3.1.1

• Connection.Dialect belongs to the 3.x dialect family:
• If SMB2_SESSION_FLAG_BINDING is set in the SessionSetup, use Channel.SigningKey.
• Otherwise, use Session.SigningKey.

When is the message signed?

Signing negotiation

Signing configuration

Requiring signing

• Signing has been required by negotiation.
• The server configuration requires message signing.
• The SessionSetup requires signing.

Signing the message

• Existence of the signing key: SessionId field has a non-zero value, otherwise there would be no possible signing key. The exception is a guest or anonymous session, which does not have a signing key even there’s a SessionId.
• Signing requirement: SessionId requires signing, i.e. its Session.SigningRequired is equal to TRUE as outlined previously.

• It’s a TREE_CONNECT or the message belongs to an un-encrypted TreeId, i.e. its TreeConnect.EncryptData is equal to FALSE. If we are not encrypting, we begin to sign messages as soon the session is established, i.e. the signing key is available and the session requires signing.
• Connection.Dialect is “3.1.1”, and it’s a TREE_CONNECT and SessionId is not an encrypted session, i.e. its Session.EncryptData is equal to FALSE. If 3.1.1 dialect is negotiated, the protocol requires signing or encrypting all TREE_CONNECT sent in non-guest, non-anonymous sessions. When the whole session is not encrypted, we always sign the TREE_CONNECT since all SMB2/3 servers support signing.

Which SigningKey is used?

• For SessionSetup request, the signing key is Session.SessionKey. For instance, the signing key for session setup request for session binding (SMB2_SESSION_FLAG_BINDING) is Session.SessionKey.
• For session set up response, if the status code is NOT equal to STATUS_SUCCESS, the signing key is Session.SessionKey. If the session setup response has STATUS_SUCCESS, the signing key is Channel.SigningKey.
• For any other command, the signing key is Channel.SigningKey. Note that the session can be multiplexed on multiple channels across multiple connections. Since, each channel has their signing key, the sender looks up the Channel in Session.ChannelList that matches the same connection.

When is the message encrypted in SMB 3.x?

Encryption negotiation in SMB 3.0

Encryption in SMB 3.0: A protocol perspective

Encryption negotiation in SMB 3.1.1

SMB 3.1.1 Encryption in Windows 10

Encryption configuration summary

Built-in signing in SMB 3.x encryption

Conclusion

• Message integrity across an authenticated session.

• Message integrity (with a stronger algorithm) across an authenticated session.
• Encryption of traffic between client and server.
• Session binding to multiple connections (multichannel).
• Validation of negotiated information.

In SMB 3.1.1 dialect:

• All the above 3.0 dialect security features, except the validation of negotiated information.
• Negotiation of encryption and integrity algorithms.
• Protection of negotiation and session establishment.

Appendix: Key derivation examples

Key derivation example for SMB 3.0 multichannel

Key derivation example for SMB 3.1.1 multichannel

NTLMv2 SessionKey calculation example

References