Microsoft Open Specifications Support Team Blog

SMB 2 and SMB 3 security in Windows 10: the anatomy of signing and cryptographic keys

Edgar A Olougouna — Fri, 26 May 2017 05:11:50 GMT

Signing is an integral security feature in SMB2 since its inception. Encryption starts in SMB3 as an important security enhancement. This article reviews the security evolution of the authenticated session as well as computation of keys used in SMB 2.x through 3.1.1 dialects. It provides test vectors for key computation in SMB 3.0 and SMB 3.1.1. The samples illustrate the multichannel scenario and include step-by-step key calculation with pre-authentication integrity. Finally, the article highlights why Kerberos should be preferred over NTLMv2 whenever possible.

Table of Contents

Introduction 2 Windows versions and chronology of dialects in MS-SMB2 3

Deprecating SMB1 3 Dialects in Windows 10 v1703 implementation of MS-SMB2 4 Chronology of crypto algorithms in MS-SMB2 5

Security considerations in SMB2 and SMB3 5

Key consideration 5 SessionKey 5 NTLM SessionKey 5 Kerberos SessionKey 6 GSS_GetMIC() and GSS_Wrap() or their Ex() extensions 7

MS-SMB2 message integrity 7

Signed session 7 Secure dialect negotiation in SMB 3.0.x 8 Pre-authentication integrity in SMB 3.1.1 8

Keys in SMB 2.x through 3.1.1 8

Dialects 2.0.2 and 2.1 8 Dialects 3.x 8 Dialects 3.0 and 3.0.2 9 Dialect 3.1.1 9

SMB 3.x key derivation function 9

Parameters for Dialects 3.0 and 3.0.2 cryptographic keys 10 Parameters for Dialect 3.1.1 cryptographic keys 10 SMB 3.x Session binding 10 SMB 3.1.1 Session binding and pre-authentication integrity 11

Signing algorithms 11

Signing in dialects 2.0.2 and 2.1 11 Signing in dialects 3.0, 3.0.2, 3.1.1 11

When is the message signed? 12

Signing negotiation 12 Signing configuration 12 Requiring signing 13 Signing the message 13 Which SigningKey is used? 13

When is the message encrypted in SMB 3.x? 14

Encryption negotiation in SMB 3.0 14 Encryption in SMB 3.0: A protocol perspective 14 Encryption negotiation in SMB 3.1.1 14 SMB 3.1.1 Encryption in Windows 10 14 Encryption configuration summary 14 Built-in signing in SMB 3.x encryption 15

Conclusion 15 Appendix: Key derivation examples 16

Key derivation example for SMB 3.0 multichannel 16 Key derivation example for SMB 3.1.1 multichannel 17 NTLMv2 SessionKey calculation example 32

References 38

Introduction

The security model in MS-SMB2 relies upon authenticating the client-user identity before accessing a share on the server. Once the user is authenticated, the server may mandate message signing or encryption. The server also controls access to the share based on which users, groups, or claims are authorized to have various levels of access. This blog does not discuss authorization model. This article focuses on how MS-SMB2 achieves message integrity and confidentially for the authenticated user. We elaborate on the link as well as the distinction between the GSS-authenticated user session and the SMB2 session. SMB2 message integrity ensures that packets are not tampered or replayed while in-flight. Signing has always been part of the SMB2 protocol since its beginning in dialect 2.0.2 (Windows Vista). SMB 3.0 (Windows 8) adds a new signing algorithm and key calculation. Confidentiality provides secure data access over untrusted networks by preventing data inspection. SMB 3.0 introduces end-to-end encryption built in the protocol. In SMB 3.1.1 (Windows 10), the encryption algorithm can be negotiated, and the cryptographic key computation is enhanced with pre-authentication integrity. This article provides a tutorial regarding SMB2 and SMB3 security features:

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

When a new Windows version introduces a new SMB dialect, all previous dialects are mostly available for backward compatibility with older versions. Although SMBv1 dialect is still around, it is on the way of being gradually phased out.

Deprecating SMB1

We have been asking the world to stop using the legacy SMBv1. Recently, US-CERT issued a security bulletin advising to disable SMBv1 and move to SMB 2.x or preferably SMB 3.x. Windows XP and Windows 2003 have SMBv1 only. As you are probably aware, Windows XP support ended on April 8, 2014. Windows Server 2003 extended support ended on July 14, 2015. These non-serviced operating systems still command some footprint and everybody has not migrated yet from Windows XP and Windows Server 2003. It will take an industry effort to overcome some of the challenges on the deprecation path. These challenges include old printers, scanners and NAS devices. How to enable and disable SMBv1, SMBv2, and SMBv3 in Windows and Windows Server https://support.microsoft.com/en-us/help/2696547/how-to-enable-and-disable-smbv1-smbv2-and-smbv3-in-windows-and-windows-server The Deprecation of SMB1 – You should be planning to get rid of this old SMB1 dialect https://blogs.technet.microsoft.com/josebda/2015/04/21/the-deprecation-of-smb1-you-should-be-planning-to-get-rid-of-this-old-smb-dialect/ https://blogs.technet.microsoft.com/filecab/2016/09/16/stop-using-smb1/ [US-CERT] SMB Security Best Practices https://www.us-cert.gov/ncas/current-activity/2017/01/16/SMB-Security-Best-Practices Features Removed or Deprecated in Windows Server 2012 R2 https://technet.microsoft.com/en-us/library/dn303411.aspx

Dialects in Windows 10 v1703 implementation of MS-SMB2

In the following table, as in the rest of this article, we are only focusing on SMB protocols version 2 and 3 specified in MS-SMB2. Client ---- server ---- dialect --------------------------------------------- Vista --- 2008 --- 2.0.2 7 --- 2008 R2 --- 2.1 8 --- 2012 --- 3.0 8.1 --- 2012 R2 --- 3.0.2 10 --- 2016 --- 3.1.1 For a general discussion on SMB dialects in Windows 8.1 and Server 2012 R2, we encourage the reader to consult the following blog.

https://blogs.technet.microsoft.com/josebda/2013/10/02/windows-server-2012-r2-which-version-of-the-smb-protocol-smb-1-0-smb-2-0-smb-2-1-smb-3-0-or-smb-3-02-are-you-using/ Windows 10 v1703 sends SMB2 Negotiate with supported dialects: 2.0.2, 2.1, 3.0, 3.0.2, 3.1.1 (i.e. Dialects array on the wire: 02 02 10 02 00 03 02 03 11 03). Windows Server 2016 responds with dialect revision: 3.1.1 (i.e. network bytes 11 03), whereas Windows 2012 R2 responds with dialect revision: 3.0.2 (i.e. 02 03), and so on for other versions. The dialect is negotiated along with supported capabilities between the client and server (e.g. signing, encryption) among the capabilities defined in the scope of that dialect. SMB2 Negotiate is however unsigned since it occurs prior to authentication. This poses the problem of a man-in-the-middle (MITM) downgrading the dialect or tampering with the capabilities. SMB 3.0 attempted to solve this issue with a post-authentication validation of the Negotiate. SMB 3.1.1 integrated pre-authentication integrity into all the keys derived for the protocol.

Chronology of crypto algorithms in MS-SMB2

Dialect --- Key derivation --- Signing --- Encryption --------------------------------------------------------------------------------------------------------------------------------- 2.0.2 --- GSS-API SessionKey --- HMAC-SHA256 --- N/A 2.1 --- GSS-API SessionKey --- HMAC-SHA256 --- N/A 3.0 --- GSS-API SessionKey & KDF [SP800-108] --- AES-128-CMAC --- AES-128-CCM 3.0.2 --- GSS-API SessionKey & KDF [SP800-108] --- AES-128-CMAC --- AES-128-CCM 3.1.1 --- SHA-512 & GSS-API SessionKey & KDF [SP800-108] --- AES-128-CMAC --- AES-128-CCM and AES-128-GCM Ref: GSS-API [RFC2743]; KDF [SP800-108]; SHA-512 [FIPS180-4]; HMAC-SHA256 [FIPS180-2] and [RFC2104]; AES-128-CMAC [RFC4493]; AES-CCM and AES-GCM [RFC5084]

Security considerations in SMB2 and SMB3

Key consideration

All cryptographic keys used in SMB 2.x and 3.x are derived from the SessionKey. Therefore, the security of SMB 2/3 signing and encryption relies in part on the session key. This key must be unique, kept secret, and genuinely impossible to guess. The server should choose an authentication mechanism that provides unique and randomly generated session keys to ensure the security of the signing key, encryption key, and decryption key.

SessionKey

The SessionKey is set to the first 16 bytes of the cryptographic key queried from the GSS protocol (e.g. Kerberos [MS-KILE], 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.

NTLM SessionKey

In NTLM security provider, the SessionKey is the ExportedSessionKey described in MS-NLMP. NTLM is a challenge response protocol and its session key is based on password hashing that relies on weak cryptography.

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.

Despite its weakness, NTLM remains a widely-used authentication mechanism in non-domain environments. Auditing and restricting NTLM usage guide https://technet.microsoft.com/en-us/library/jj865674.aspx See the following blog post for a discussion NTLM keys.

https://blogs.msdn.microsoft.com/openspecification/2010/04/19/ntlm-keys-and-sundry-stuff/ Note: Extended protection for authentication exists for NTLM over TLS. This binds the TLS session to the NTLM session. Unfortunately, SMB2 does use extended protection authentication because there is no outer authenticated session. NTLM and Channel Binding Hash (aka Extended Protection for Authentication) https://blogs.msdn.microsoft.com/openspecification/2013/03/26/ntlm-and-channel-binding-hash-aka-extended-protection-for-authentication/

Kerberos SessionKey

In Kerberos [RFC4120] security provider, the SessionKey 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. When the KDC issues a service ticket, it generates a random session key. Rather than using a pseudo-random number generator (PRNG), the session key should use a truly random number generator, such as one based on measurements of random physical phenomena. See [RFC4086] for an in-depth discussion of randomness. For the subkey, it is also strongly encouraged that any key derived by an application for subsequent use include the full key entropy derived from the KDC-generated session key carried in the ticket. The KDC issues tickets with the strongest encryption type (etype) to protect the session key. The etype is based on configuration of what the KDC enforces and what client and server principals can support (AES256_HMAC_SHA1, AES128_HMAC_SHA1, RC4_HMAC_MD5, DES_CBC_MD5, DES_CBC_CRC).

https://blogs.msdn.microsoft.com/openspecification/2010/11/17/encryption-type-selection-in-kerberos-exchanges/

https://blogs.msdn.microsoft.com/openspecification/2011/05/30/windows-configurations-for-kerberos-supported-encryption-type/ https://blogs.technet.microsoft.com/petergu/2013/04/14/interpreting-the-supportedencryptiontypes-registry-key/. Beyond the etype, the security of the Kerberos SessionKey is substantially strengthened if all preceding Kerberos exchanges ([RFC4120] or [MS-KILE]) that lead to the service ticket have reinforced protection. For instance, the authentication service may leverage public key cryptography to protect the initial authentication (PKInit), as specified in [RFC4556], [MS-PKCA], e.g. for smart card authentication. In its basic form, the security of the Kerberos authentication service depends on the strength of the password used to protect it.

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

Signing in SMB2 and SMB3 uses their respective algorithms HMAC-SHA256 and AES-128-CMAC. SMB2/3 signing does not use GSS-API GSS_GetMIC() or GSS_GetMICEx(). Likewise, SMB 3.x encryption uses its own encryption algorithms, i.e. AES-128-CCM and AES-128-GCM as introduced earlier in this article. GSS-API GSS_Wrap() or GSS_WrapEx() are not pertinent for SMB3 encryption. The GSS-API keys should not be confused with SMB2/3 keys, though the latter are derived from the session key. In case of NTLM authentication, NTLM has his own signing and sealing keys, which serve for GSS_GetMICEx(), GSS_VerifyMICEx(), GSS_WrapEX(), GSS_UnwrapEX(). The same remarks apply for Kerberos GSS-API keys, and Kerberos GSS functions.

MS-SMB2 message integrity

SMB2 message integrity manifests on a signed session where signed packets flow from client to server. What happens to message integrity until the session is established?

Signed session

On a signed session, every signed packet includes a signature that the receiver can validate. Unlike SMB1 signing which uses MD5 [RFC1321] as hashing algorithm, SMB2 uses a better hashing for signing. SMB 2.02 and SMB 2.1 use HMAC SHA-256, whereas SMB 3.0 upgrades to AES-128-CMAC for its signing. Before signing can happen, the client and server need to negotiate signing; and the client needs authenticate first to have a SessionKey from which a SigningKey is derived (more details on this later). SMB 2.x did not have a mechanism to detect MITM downgrading of negotiated capabilities.

Secure dialect negotiation in SMB 3.0.x

Dialect 3.0 implements secure dialect negotiation (SMB 3.0, 3.02) to protect against security-downgrade attacks. When SMB 3.0 is negotiated, the client must send a mandatory signed request to validate the Negotiate information. The validation occurs post-authentication and after the Tree Connect exchange. https://blogs.msdn.com/b/openspecification/archive/2012/06/28/smb3-secure-dialect-negotiation.aspx SMB 3.1.1 introduces pre-authentication integrity which supersedes the SMB 3.0.x secure dialect negotiation.

Pre-authentication integrity in SMB 3.1.1

SMB 3.1.1 pre-authentication integrity enhances protection against security-downgrade attacks by verifying the integrity of all messages preceding the session establishment. This mandatory feature protects against any tampering with Negotiate and Session Setup messages by leveraging cryptographic hashing SHA-512 [FIPS180-4]. Pre-authentication integrity also integrates a salt transmitted on the wire as part of the hash calculation. In Windows implementation, the pre-auth-integrity negotiate context has a salt of 32 bytes. The salt is randomly generated (e.g. PRNG) and not reused, otherwise it would allow surface attacks. https://blogs.msdn.microsoft.com/openspecification/2015/08/11/smb-3-1-1-pre-authentication-integrity-in-windows-10/

Keys in SMB 2.x through 3.1.1

Dialects 2.0.2 and 2.1

Prior to SMB 3.0, the 16-bytes SessionKey was the primary key. SigningKey: Session.SigningKey is the same as Session.SessionKey. Application’s session key for an authenticated context: the client returns Session.SessionKey.

Dialects 3.x

In SMB 3.x, two new keys are added to serve for encryption. The application’s session key for an authenticated context has become a key on its own. The SMB 3.x keys have the following properties:

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.

Upon authentication, SigningKey, and ApplicationKey are calculated. If encryption is supported (even if not negotiated), EncryptionKey and DecryptionKey are computed. All these keys are derived using the SP800-108 key derivation function (KDF) (see more details

later in this article). SessionKey is the key derivation key (KDK), a parameter to the KDF.

Dialects 3.0 and 3.0.2

Apart from the KDK input, i.e. SessionKey, the other parameters to the KDF are constants defined for each type of key. (more details in subsequent Sections).

Dialect 3.1.1

SessionKey remains the KDF’s KDK. The context parameter is no longer a constant, instead it is PreauthIntegrityHashValue (see blog “SMB 3.1.1 Pre-authentication Integrity”). The remaining parameters to the KDF are constant, but they differ from the constants used in SMB 3.0.x key derivation. (see specifics in subsequent Sections).

SMB 3.x key derivation function

Ko = SMB3KDF (Ki, Label, Context) 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. Ki – The SessionKey is the key derivation key (KDK), used as an input to the KDF, for SMB 3.x. Label – the purpose of this derived key, encoded as string and length for SMB 3.x. Context – the context information of this derived key, encoded as string and length for SMB 3.x. L – An integer that specifies the length of the derived keying material Ko, L is 128 bits for SMB 3.x cryptographic keys. Note that L is a constant since all SMB 3.x keys are 16 bytes in length. Ko – Keying material output from the KDF, a binary string of length L, where Ko is the leftmost L bits of KDF result.

Parameters for Dialects 3.0 and 3.0.2 cryptographic keys

Label and context are constants for each type of cryptographic key.

SigningKey = SMB3KDF ( SessionKey, "SMB2AESCMAC\0", "SmbSign\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

A new label is defined for each type of cryptographic key. The context is Session.PreauthIntegrityHashValue, as described in the “SMB 3.1.1 pre-authentication integrity” blog.

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

SMB2_SESSION_FLAG_BINDING bit is set in the Flags field of the Session Setup request. For session binding to multiple connections (multichannel), the server needs to call GSS_Accept_sec_context for each additional channel. This requires creating a new-temporary security context to have a SessionKey and derive a SigningKey for the binding channel. Note that the session binding request must be signed with the master session’s SigningKey, as described later in this article. However, EncryptionKey, DecryptionKey, and ApplicationKey remain the same from the main channel, i.e. remain the same for all related channels.

SMB 3.1.1 Session binding and pre-authentication integrity

If this is a master or binding session setup and the dialect is 3.1.1 or higher, we allocate and initialize the session's pre-authentication integrity hash value starting with the connection's pre-authentication integrity hash. We always start with the pre-authentication hash resulting from processing Negotiate on that connection. The client side logic is summarized below. Set Session.PreauthIntegrityHashValue to Connection.PreauthIntegrityHashValue. Update Session.PreauthIntegrityHashValue with the SessionSetup request. if it's STATUS_MORE_PROCESSING_REQUIRED, update Session.PreauthIntegrityHashValue with the response, and process subsequent session setup exchange leg. if it's STATUS_SUCCESS, use Session.PreauthIntegrityHashValue to generate cryptographic keys, then verify the signature of the SessionSetup response. For the server side, the logic is similar except that we use Session.PreauthIntegrityHashValue when SMB2_SESSION_FLAG_BINDING is NOT set, and PreauthSession.PreauthIntegrityHashValue when SMB2_SESSION_FLAG_BINDING is set. This is important because there is no guarantee in which order session bindings will be processed. That way, each session setup processing is isolated from the other, but all use the connection's pre-authentication hash as the starting point.

Signing algorithms

For a signed message, the sender sets the Signature field and the SMB2_FLAGS_SIGNED bit in the Flags field of the SMB2 header. The sender calculates the signature as follows.

Signing in dialects 2.0.2 and 2.1

The signer computes a 32-byte hash by using HMAC-SHA256 over the entire message, beginning with the SMB2 header with the signature field zeroed, and using the provided SigningKey. The HMAC-SHA256 hash is specified in [FIPS180-2] and [RFC2104] The signature is the first 16-bytes of the hash.

Signing in dialects 3.0, 3.0.2, 3.1.1

The signer computes the 16-byte signature by using AES-128-CMAC over the entire message, beginning with the SMB2 header with the signature field zeroed, and using the SigningKey provided. The AES-128-CMAC is specified in [RFC4493]. For dialect 3.x family, the server must sign the final SessionSetup Response. This excludes guest and anonymous sessions since there is no SigningKey available in those types of contexts. Signing of the final SMB 3.x SessionSetup Response:

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.

For Dialect SMB 3.x, the session binding request is signed with the master session’s SigningKey.

When is the message signed?

Signing negotiation

The client and server negotiate signing by using the SecurityMode field in the SMB2 Negotiate request and response exchange. The client also communicates the SecurityMode in the SessionSetup Request. SMB2_NEGOTIATE_SIGNING_ENABLED (0x0001) SMB2_NEGOTIATE_SIGNING_REQUIRED (0x0002) Windows SMB 2/3 clients always set SMB2_NEGOTIATE_SIGNING_ENABLED flag in the negotiate request and Windows-based servers set it likewise in the response since they all support signing. MS-SMB2 require all SMB 2/3 servers to implement signing, regardless of whether they set the SMB2_NEGOTIATE_SIGNING_ENABLED flag.

Signing configuration

By default, Windows client and server have the following settings. Get-SmbClientConfiguration | fl EnableSecuritySignature,RequireSecuritySignature EnableSecuritySignature : True RequireSecuritySignature : False The corresponding registry keys on the client are under HKLM\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters Get-SmbServerConfiguration | fl EnableSecuritySignature,RequireSecuritySignature EnableSecuritySignature : False RequireSecuritySignature : False The corresponding registry keys on the server are under HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters For additional details on signing configuration and effective behavior, please consult the following blog: The Basics of SMB Signing (covering both SMB1 and SMB2) https://blogs.technet.microsoft.com/josebda/2010/12/01/the-basics-of-smb-signing-covering-both-smb1-and-smb2/

Requiring signing

The session will have Session.SigningRequired = TRUE if one the following conditions is met:

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

NOTE: Signing cannot be required for guest or anonymous sessions as they do not have proper security context.

Signing the message

To sign a message, the first two prerequisites are:

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.

If those two prerequisites are met, the sender signs the message under these specific conditions:

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.

There is one notable exception to the “Session.SigningRequired is equal to TRUE” prerequisite. Irrespective of Session.SigningRequired, FSCTL_VALIDATE_NEGOTIATE_INFO should always be signed. Note that if Session.EncryptData is equal to TRUE, the server would not need to verify the signature of FSCTL_VALIDATE_NEGOTIATE_INFO message (see Section “Built-in signing in SMB 3.x encryption”).

Which SigningKey is used?

With SMB 2.x, the signing key is Session.SessionKey. With SMB 3.x, the notions of multichannel and session binding introduce new rules for whichever of Session.SessionKey or Channel.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?

A detailed discussion is provided in the blogs mentioned in the following sub-sections.

Encryption negotiation in SMB 3.0

SMB 3.0.x client and server advertise encryption support via the SMB2_GLOBAL_CAP_ENCRYPTION capability flag during the NEGOTIATE. If encryption is enforced on the whole server, each session enables encryption by setting SMB2_SESSION_FLAG_ENCRYPT_DATA in the SessionFlags of SessionSetup response. For a per-share enabled encryption, ShareFlags of TreeConnect response includes SMB2_SHAREFLAG_ENCRYPT_DATA. SMB 3.0 and SMB 3.0.2 support only the encryption algorithm AES-128-CCM.

Encryption in SMB 3.0: A protocol perspective

https://blogs.msdn.com/b/openspecification/archive/2012/10/05/encryption-in-smb-3-0-a-protocol-perspective.aspx

Encryption negotiation in SMB 3.1.1

SMB 3.1.1 client and server negotiate encryption support by exchanging supported cipher IDs 0x0002 (AES-128-GCM) and 0x0001 (AES-128-CCM) in SMB2_ENCRYPTION_CAPABILITIES negotiate context in the NEGOTIATE request and response.

SMB 3.1.1 Encryption in Windows 10

https://blogs.msdn.microsoft.com/openspecification/2015/09/09/smb-3-1-1-encryption-in-windows-10/

Encryption configuration summary

As discussed in the abovementioned blogs, the configuration items that affect encryption on Windows 8 / Windows Server 2012 and onward are: Global level encryption on the server: Set-SmbServerConfiguration -EncryptData <0|1> If enabled, SessionSetup.Response.SessionFlags includes SMB2_SESSION_FLAG_ENCRYPT_DATA. Share level encryption: New-SmbShare -Name -Path -EncryptData 1 Set-SmbShare -Name -EncryptData <0|1> If enabled, TreeConnect.Response.ShareFlags sets SMB2_SHAREFLAG_ENCRYPT_DATA. Server-wide encryption has precedence over share level encryption. If global encryption is enabled, you cannot selectively disable encryption for certain shares. Keep in mind that a dynamic change of the share’s EncryptData property would mean different encryption experience if existing TreeIds prior to the change remain connected. New TreeId connections after the change would reflect the new value of the share’s EncryptData property. Thus, when the administrator reconfigures Share.EncryptData, is it recommended to force disconnection of all current connections to allow clients to pick the new configuration. Unencrypted access: Set-SmbServerConfiguration -RejectUnencryptedAccess <0|1> This is for down-level clients. See discussion on security impact in Section “Unencrypted Access: RejectUnencryptedAccess” of blog entry “SMB 3.1.1 Encryption in Windows 10”.

Built-in signing in SMB 3.x encryption

Integrity (message authentication) is built into the algorithms used for encryption in SMB 3.x, i.e. AES-128-CCM and AES-128-GCM. These encryption algorithms incorporate the benefit of a message authentication code. Successful decryption means that SMB3 crypto processing has checked the integrity of the encrypted message. The receiver does not need to validate the signature of the inner SMB2 message itself. In general, signing the SMB2 message before encrypting it would be a waste of CPU cycles without any additional security. SMB 3.x encryption supplants regular signing: it does not and should not turn off message signing. When SMB 3.x encryption is in use, we do not need regular signing. However, “RejectUnencryptedAccess set to FALSE” should not disable signing, i.e. does not mean bypass RequireMessageSigning. A message that is not encrypted shall be subject to the rules of regular signing.

Conclusion

We have discussed the anatomy of signing and cryptographic keys used in MS-SMB2 protocol for all dialects supported by Windows 10. These keys – directly or indirectly – support the following security features: In SMB 2.0.2 and 2.1 dialects:

Message integrity across an authenticated session.

In SMB 3.0 dialect:

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

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].

Key derivation example for SMB 3.0 multichannel

--- Master session (first channel) ---

Input cryptographicKey 0x7CD451825D0450D235424E44BA6E78CC (queried from GSS authenticated context)

--- Dialect 0x0300 --- SessionKey 0x7CD451825D0450D235424E44BA6E78CC SigningKey 0x0B7E9C5CAC36C0F6EA9AB275298CEDCE EncryptionKey 0xFAD27796665B313EBB578F388632B4F7 DecryptionKey 0xB0F0427F7CEB416D1D9DCC0CD4F99447 ApplicationKey 0xBB23A4575AA26C721AF525AF15A87B4F

--- Second channel (session binding) ---

Input cryptographicKey 0x4E01A2B313BCF660CC250BEF021AEDE6 (queried from GSS authenticated context) Alternate channel: generate Channel.SigningKey. Alternate channel: Copy encryption/decryption keys from main channel

--- Dialect 0x0300 --- SessionKey 0x4E01A2B313BCF660CC250BEF021AEDE6 SigningKey 0xBA1A17DBBFEC349BCA105563D598952F EncryptionKey 0xFAD27796665B313EBB578F388632B4F7 DecryptionKey 0xB0F0427F7CEB416D1D9DCC0CD4F99447 ApplicationKey 0xBB23A4575AA26C721AF525AF15A87B4F

Key derivation example for SMB 3.1.1 multichannel

--- Master session (first channel) ---

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 0x100000000019 to Preauth Integrity hash table with value Connection.PreauthIntegrityHashValue 324BFA92A4F3A190E466EBEA08D9C110DC88BFED758D9846ECC6F541CC1D02AE3C94A79F36011E99 7E13F841B91B50957AD07B19C8E2539C0B23FDAE09D2C513

SESSION SETUP Request PreauthSession.SessionId 0x100000000019 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 0x100000000019 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 0x100000000019 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 0x100000000019 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 EncryptionKey 0x629BCBC54422A0F572B97F45989B6073 DecryptionKey 0xE2AF0DCEFAC68DA71A0DFBD0D1350D74 ApplicationKey 0x6D7AD7954E9EC61E907B4D473DC178FF

--- second channel (session binding) ----

Header.Command 0x0000 NEGOTIATE

Preauth integrity hash capabilities --- PreauthIntegrityCaps.HashAlgorithmCount 0x1 PreauthIntegrityCaps.SaltLength 0x20 PreauthIntegrityCaps.HashAlgorithms 0x0001 PreauthIntegrityCaps.Salt 3E38B8B81A9AFB172278056F4898FD09A1B9976A49B2D771161FCD4D40DF7D7D

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 00000000000000000000000000000000000000000000000024000500010000003F000000ECD86F32 6276024F9F7752B89BB33F3A70000000020000000202100200030203110300000100260000000000 0100200001003E38B8B81A9AFB172278056F4898FD09A1B9976A49B2D771161FCD4D40DF7D7D0000 0200060000000000020002000100 Concatenate Connection.PreauthIntegrityHashValue and Negotiate request packet SHA-512 Input Hash Data 00000000000000000000000000000000000000000000000000000000000000000000000000000000 000000000000000000000000000000000000000000000000FE534D42400001000000000000008000 00000000000000000100000000000000FFFE00000000000000000000000000000000000000000000 000000000000000024000500010000003F000000ECD86F326276024F9F7752B89BB33F3A70000000 0200000002021002000302031103000001002600000000000100200001003E38B8B81A9AFB172278 056F4898FD09A1B9976A49B2D771161FCD4D40DF7D7D00000200060000000000020002000100 New Connection.PreauthIntegrityHashValue F035C2B2BAB116E0DCF6A74E26670604D1BF6DDA065913AF7C30E93C1F025AC3CE2DD44D4DE26524 A785E5D8E06AF0BE1C74296FEF05B045C3793A12B32C49DF

NEGOTIATE Response

Updating Preauth integrity hash --- Current Connection.PreauthIntegrityHashValue F035C2B2BAB116E0DCF6A74E26670604D1BF6DDA065913AF7C30E93C1F025AC3CE2DD44D4DE26524 A785E5D8E06AF0BE1C74296FEF05B045C3793A12B32C49DF Negotiate response packet FE534D4240000100000000000000010001000000000000000100000000000000FFFE000000000000 000000000000000000000000000000000000000000000000410001001103020039CBCAF329714942 BDCE5D60F09AB3FB2F000000000080000000800000008000A76533AECBAED00109094AB095AED001 80004001C00100006082013C06062B0601050502A08201303082012CA01A3018060A2B0601040182 3702021E060A2B06010401823702020AA282010C048201084E45474F455854530100000000000000 60000000700000007E7CC0FD06D6362D02DDE1CF343BFE29172BA8482F8B7BE4DBA9F69A8DEBBA83 36E453F3EE58983492F66354ED01A5BE000000000000000060000000010000000000000000000000 5C33530DEAF90D4DB2EC4AE3786EC3084E45474F4558545303000000010000004000000098000000 7E7CC0FD06D6362D02DDE1CF343BFE295C33530DEAF90D4DB2EC4AE3786EC3084000000058000000 3056A05430523027802530233121301F06035504031318546F6B656E205369676E696E6720507562 6C6963204B65793027802530233121301F06035504031318546F6B656E205369676E696E67205075 626C6963204B657901002600000000000100200001002521FE7288989F816EE6D3D6C55921FBEF2C C239789E83B8A0EC29E8D84EBAB80000020004000000000001000200 Concatenate Connection.PreauthIntegrityHashValue and Negotiate response packet SHA-512 Input Hash Data F035C2B2BAB116E0DCF6A74E26670604D1BF6DDA065913AF7C30E93C1F025AC3CE2DD44D4DE26524 A785E5D8E06AF0BE1C74296FEF05B045C3793A12B32C49DFFE534D42400001000000000000000100 01000000000000000100000000000000FFFE00000000000000000000000000000000000000000000 0000000000000000410001001103020039CBCAF329714942BDCE5D60F09AB3FB2F00000000008000 0000800000008000A76533AECBAED00109094AB095AED00180004001C00100006082013C06062B06 01050502A08201303082012CA01A3018060A2B06010401823702021E060A2B06010401823702020A A282010C048201084E45474F45585453010000000000000060000000700000007E7CC0FD06D6362D 02DDE1CF343BFE29172BA8482F8B7BE4DBA9F69A8DEBBA8336E453F3EE58983492F66354ED01A5BE 0000000000000000600000000100000000000000000000005C33530DEAF90D4DB2EC4AE3786EC308 4E45474F45585453030000000100000040000000980000007E7CC0FD06D6362D02DDE1CF343BFE29 5C33530DEAF90D4DB2EC4AE3786EC30840000000580000003056A05430523027802530233121301F 06035504031318546F6B656E205369676E696E67205075626C6963204B6579302780253023312130 1F06035504031318546F6B656E205369676E696E67205075626C6963204B65790100260000000000 0100200001002521FE7288989F816EE6D3D6C55921FBEF2CC239789E83B8A0EC29E8D84EBAB80000 020004000000000001000200 New Connection.PreauthIntegrityHashValue E267AB1AA0403082AA2A9FEB0224AF3EA92E53CAA50A893A9635F0659F93591F81391737E68DB0C9 AD878C56449C36A6895EBCF435A7D97072C7B596B8AF3817

Add NEW SessionId 0x100000000019 to Preauth Integrity hash table with value Connection.PreauthIntegrityHashValue E267AB1AA0403082AA2A9FEB0224AF3EA92E53CAA50A893A9635F0659F93591F81391737E68DB0C9 AD878C56449C36A6895EBCF435A7D97072C7B596B8AF3817

SESSION SETUP Request PreauthSession.SessionId 0x100000000019 Current PreauthSession.PreauthIntegrityHashValue E267AB1AA0403082AA2A9FEB0224AF3EA92E53CAA50A893A9635F0659F93591F81391737E68DB0C9 AD878C56449C36A6895EBCF435A7D97072C7B596B8AF3817 SessionSetup request packet FE534D4240000100000000000100800008000000000000000200000000000000FFFE000000000000 190000000010000068BD0C58F613CE1334B1EB51C68D39EA19000101010000000000000058004A00 0000000000000000604806062B0601050502A03E303CA00E300C060A2B06010401823702020AA22A 04284E544C4D5353500001000000978208E200000000000000000000000000000000060380250000 000F Concatenate PreauthSession.PreauthIntegrityHashValue and Session Setup request packet SHA-512 Input Hash Data E267AB1AA0403082AA2A9FEB0224AF3EA92E53CAA50A893A9635F0659F93591F81391737E68DB0C9 AD878C56449C36A6895EBCF435A7D97072C7B596B8AF3817FE534D42400001000000000001008000 08000000000000000200000000000000FFFE000000000000190000000010000068BD0C58F613CE13 34B1EB51C68D39EA19000101010000000000000058004A000000000000000000604806062B060105 0502A03E303CA00E300C060A2B06010401823702020AA22A04284E544C4D53535000010000009782 08E200000000000000000000000000000000060380250000000F PreauthSession.PreauthIntegrityHashValue 8346469934A59E951A3F2DA7FA4C2C29F0F6B13A6B0951D4CD5279F8D40FD84FF98157937613C6BE 9514582E44344B1710DD5BFCE3BB023D28C6EA512E0ADEBD

SESSION SETUP Response

--- STATUS_MORE_PROCESSING_REQUIRED - Updating Preauth integrity hash --- PreauthSession.SessionId 0x100000000019 Current PreauthSession.PreauthIntegrityHashValue 8346469934A59E951A3F2DA7FA4C2C29F0F6B13A6B0951D4CD5279F8D40FD84FF98157937613C6BE 9514582E44344B1710DD5BFCE3BB023D28C6EA512E0ADEBD SessionSetup response packet FE534D4240000100160000C00100010009000000000000000200000000000000FFFE000000000000 1900000000100000014A71CAE724995E612430E2BE87578C090000004800B300A181B03081ADA003 0A0101A10C060A2B06010401823702020AA281970481944E544C4D53535000020000000C000C0038 00000015828AE23823DA68E32D2FE1000000000000000050005000440000000A0092270000000F53 005500540033003100310002000C0053005500540033003100310001000C00530055005400330031 00310004000C0053005500540033003100310003000C005300550054003300310031000700080041 3B42AECBAED00100000000 SessionSetup response header signature 0x014A71CAE724995E612430E2BE87578C Concatenate PreauthSession.PreauthIntegrityHashValue and Session Setup response packet SHA-512 Input Hash Data 8346469934A59E951A3F2DA7FA4C2C29F0F6B13A6B0951D4CD5279F8D40FD84FF98157937613C6BE 9514582E44344B1710DD5BFCE3BB023D28C6EA512E0ADEBDFE534D4240000100160000C001000100 09000000000000000200000000000000FFFE0000000000001900000000100000014A71CAE724995E 612430E2BE87578C090000004800B300A181B03081ADA0030A0101A10C060A2B0601040182370202 0AA281970481944E544C4D53535000020000000C000C003800000015828AE23823DA68E32D2FE100 0000000000000050005000440000000A0092270000000F53005500540033003100310002000C0053 005500540033003100310001000C0053005500540033003100310004000C00530055005400330031 00310003000C0053005500540033003100310007000800413B42AECBAED00100000000 PreauthSession.PreauthIntegrityHashValue 6DAD1BA61CAF5FDFBB46D995463FF5780F7248D692E70CE87D8B58B2FBEFD438937E1BCBEC3676F2 6F7EE374E169F8AFB17671FB9A47AB88EE2C079DB2B2C7D3

SESSION SETUP Request PreauthSession.SessionId 0x100000000019 Current PreauthSession.PreauthIntegrityHashValue 6DAD1BA61CAF5FDFBB46D995463FF5780F7248D692E70CE87D8B58B2FBEFD438937E1BCBEC3676F2 6F7EE374E169F8AFB17671FB9A47AB88EE2C079DB2B2C7D3 SessionSetup request packet FE534D4240000100000000000100800008000000000000000300000000000000FFFE000000000000 19000000001000003CA64529ACAE57B26DCEC17B14E477D71900010101000000000000005800CF01 0000000000000000A18201CB308201C7A0030A0101A28201AA048201A64E544C4D53535000030000 001800180090000000EE00EE00A80000000C000C00580000001A001A0064000000120012007E0000 001000100096010000158288E2060380250000000FED00E0F3D901F7B77E98071474F83009530055 005400330031003100610064006D0069006E006900730074007200610074006F0072004400520049 00560045005200330031003100000000000000000000000000000000000000000000000000A46794 DA5D2033965D5339E1A675B79B0101000000000000413B42AECBAED0018E4D343661BA6A75000000 0002000C0053005500540033003100310001000C0053005500540033003100310004000C00530055 00540033003100310003000C0053005500540033003100310007000800413B42AECBAED001060004 00020000000800300030000000000000000000000000300000B61FEFCAA857EA57BF1EDCEBF8974B 8E0EBA5A6DFD9D07A31D11B548F8C9D0CC0A00100000000000000000000000000000000000090016 0063006900660073002F00530055005400330031003100000000000000000000000000C8C61D67CE 697693891336917655DDD3A3120410010000005122F070A7314A9B00000000 Concatenate PreauthSession.PreauthIntegrityHashValue and Session Setup request packet SHA-512 Input Hash Data 6DAD1BA61CAF5FDFBB46D995463FF5780F7248D692E70CE87D8B58B2FBEFD438937E1BCBEC3676F2 6F7EE374E169F8AFB17671FB9A47AB88EE2C079DB2B2C7D3FE534D42400001000000000001008000 08000000000000000300000000000000FFFE00000000000019000000001000003CA64529ACAE57B2 6DCEC17B14E477D71900010101000000000000005800CF010000000000000000A18201CB308201C7 A0030A0101A28201AA048201A64E544C4D53535000030000001800180090000000EE00EE00A80000 000C000C00580000001A001A0064000000120012007E0000001000100096010000158288E2060380 250000000FED00E0F3D901F7B77E98071474F83009530055005400330031003100610064006D0069 006E006900730074007200610074006F007200440052004900560045005200330031003100000000 000000000000000000000000000000000000000000A46794DA5D2033965D5339E1A675B79B010100 0000000000413B42AECBAED0018E4D343661BA6A750000000002000C005300550054003300310031 0001000C0053005500540033003100310004000C0053005500540033003100310003000C00530055 00540033003100310007000800413B42AECBAED00106000400020000000800300030000000000000 000000000000300000B61FEFCAA857EA57BF1EDCEBF8974B8E0EBA5A6DFD9D07A31D11B548F8C9D0 CC0A001000000000000000000000000000000000000900160063006900660073002F005300550054 00330031003100000000000000000000000000C8C61D67CE697693891336917655DDD3A312041001 0000005122F070A7314A9B00000000 PreauthSession.PreauthIntegrityHashValue EA3BF912B11CBFEC5B1889E8209614218687F82FA5294521AD3063425E49E88A10BD022124CE2512 3BC9111F52D9566BA88BF46344E6063DC5E3FF0389026F6C

SESSION SETUP Response SessionId 0x100000000019 COMPLETED SessionSetup response packet FE534D4240000100000000000100800009000000000000000300000000000000FFFE000000000000 19000000001000008D604217FFBACF40635BF9D8729921500900000048001D00A11B3019A0030A01 00A312041001000000CFB046FC5D368E2200000000 SessionSetup response header signature 0x8D604217FFBACF40635BF9D872992150 PreauthSession.PreauthIntegrityHashValue EA3BF912B11CBFEC5B1889E8209614218687F82FA5294521AD3063425E49E88A10BD022124CE2512 3BC9111F52D9566BA88BF46344E6063DC5E3FF0389026F6C

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

Alternate channel: generate Channel.SigningKey. Alternate channel: Copy encryption/decryption keys from main channel

--- Dialect 0x0311 --- preauthIntegrityHashValue EA3BF912B11CBFEC5B1889E8209614218687F82FA5294521AD3063425E49E88A10BD022124CE2512 3BC9111F52D9566BA88BF46344E6063DC5E3FF0389026F6C CypherId 0x0002 SessionKey 0x84B9DBB730116A8FA6E9889555C265F9 SigningKey 0xC962BCA1A9DD1697B030644199705431 EncryptionKey 0x629BCBC54422A0F572B97F45989B6073 DecryptionKey 0xE2AF0DCEFAC68DA71A0DFBD0D1350D74 ApplicationKey 0x6D7AD7954E9EC61E907B4D473DC178FF

NTLMv2 SessionKey calculation example

These steps show how the SessionKey is calculated for the master session used in the SMB 3.1.1 multichannel example. These steps show that with the knowledge of the password and a packet sniff, one can derive the NTLM SessionKey. The steps follow MS-NLMP, compute NTLMv2 SessionKey, and verify that it matches the ExportedSessionKey. Recall the cryptographicKey (SessionKey) 0x270E1BA896585EEB7AF3472D3B4C75A7 (queried from GSS authenticated context)

Inputs ==========

ChallengeMessage.ServerChallenge

- ResponseToken: NTLM CHALLENGE MESSAGE - NLMP: NTLM CHALLENGE MESSAGE Signature: NTLMSSP MessageType: Challenge Message (0x00000002) + TargetNameFields: Length: 12, Offset: 56 + NegotiateFlags: 0xE28A8215 (NTLM v2, 128-bit encryption, Always Sign) + ServerChallenge: 0D1D8BA31179D008 Reserved: Binary Large Object (8 Bytes) + TargetInfoFields: Length: 80, Offset: 68 + Version: Windows 10.0 Build 10130 NLMPv15 TargetNameString: SUT311 - AvPairs: 6 pairs + AvPair: SUT311 (Server NetBIOS domain name) + AvPair: SUT311 (Server NetBIOS computer name) + AvPair: SUT311 (The FQDN (2) of the domain.) + AvPair: SUT311 (The fully qualified domain name (FQDN (1)) of the computer.) + AvPair: 10:18:21 PM 6/24/2015 (Server local time) + AvPair: NULL

ChallengeMessage.ServerChallenge = "0D 1D 8B A3 11 79 D0 08 "

From the NtChallengeResponse, the Response needs to match the calculated NTProofStr . NtChallengeResponse = ConcatenationOf(NTProofStr, temp)

- ResponseToken: NTLM AUTHENTICATE MESSAGE Version:NTLM v2, Domain: SUT311, User: administrator, Workstation: DRIVER311 - NLMP: NTLM AUTHENTICATE MESSAGE Version:NTLM v2, Domain: SUT311, User: administrator, Workstation: DRIVER311 Signature: NTLMSSP MessageType: Authenticate Message (0x00000003) + LmChallengeResponseFields: Length: 24, Offset: 144 + NtChallengeResponseFields: Length: 238, Offset: 168 + DomainNameFields: Length: 12, Offset: 88 + UserNameFields: Length: 26, Offset: 100 + WorkstationFields: Length: 18, Offset: 126 + EncryptedRandomSessionKeyFields: Length: 16, Offset: 406 + NegotiateFlags: 0xE2888215 (NTLM v2, 128-bit encryption, Always Sign) + Version: Windows 6.3 Build 9600 NLMPv15 + MessageIntegrityCheck: ECAC77A5F385A8BF9C38C706EEEDDCD3 DomainNameString: SUT311 UserNameString: administrator WorkstationString: DRIVER311 + LmChallengeResponseStruct: 000000000000000000000000000000000000000000000000 - NTLMV2ChallengeResponse: 63078EB639FE03E20A231C3AE3BF2308 + Response: 63078EB639FE03E20A231C3AE3BF2308 ResponseVersion: 1 (0x1) HiResponseVersion: 1 (0x1) + Z1: Time: 06/24/2015, 22:18:21.389456 UTC + ClientChallenge: BC4AD05F223CC90F + Z2: - AvPairs: 10 pairs + AvPair: SUT311 (Server NetBIOS domain name) + AvPair: SUT311 (Server NetBIOS computer name) + AvPair: SUT311 (The FQDN (2) of the domain.) + AvPair: SUT311 (The fully qualified domain name (FQDN (1)) of the computer.) + AvPair: 10:18:21 PM 6/24/2015 (Server local time) + AvPair: 0x2 (Server configuration) + AvPair: 0x3000 (Token restrictions) + AvPair: 0x3000 (A channel bindings hash) + AvPair: cifs/SUT311 (The SPN of the target server) + AvPair: NULL Padding: Binary Large Object (8 Bytes) + SessionKeyString: 3B9BDFF38F5EE8F9663F11A0F4C03A78 + Tag3: + OctetStringHeader: + MechListMic: Version: 1

Based on NtChallengeResponseFields: Length: 238, Offset: 168, extract the bytes: AuthenticateMessage: Ntlmv2ChallengeResponse 63 07 8E B6 39 FE 03 E2 0A 23 1C 3A E3 BF 23 08 01 01 00 00 00 00 00 00 A1 A1 F5 AD CB AE D0 01 BC 4A D0 5F 22 3C C9 0F 00 00 00 00 02 00 0C 00 53 00 55 00 54 00 33 00 31 00 31 00 01 00 0C 00 53 00 55 00 54 00 33 00 31 00 31 00 04 00 0C 00 53 00 55 00 54 00 33 00 31 00 31 00 03 00 0C 00 53 00 55 00 54 00 33 00 31 00 31 00 07 00 08 00 A1 A1 F5 AD CB AE D0 01 06 00 04 00 02 00 00 00 08 00 30 00 30 00 00 00 00 00 00 00 00 00 00 00 00 30 00 00 B6 1F EF CA A8 57 EA 57 BF 1E DC EB F8 97 4B 8E 0E BA 5A 6D FD 9D 07 A3 1D 11 B5 48 F8 C9 D0 CC 0A 00 10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 09 00 16 00 63 00 69 00 66 00 73 00 2F 00 53 00 55 00 54 00 33 00 31 00 31 00 00 00 00 00 00 00 00 00 00 00 00 00

AuthenticateMessage: Ntlmv2ChallengeResponse.Response: 63 07 8E B6 39 FE 03 E2 0A 23 1C 3A E3 BF 23 08 ( or for future reference 63078EB639FE03E20A231C3AE3BF2308 )

From Ntlmv2ChallengeResponse of AuthenticateMessage, strip off the Response field: temp = 01 01 00 00 00 00 00 00 A1 A1 F5 AD CB AE D0 01 BC 4A D0 5F 22 3C C9 0F 00 00 00 00 02 00 0C 00 53 00 55 00 54 00 33 00 31 00 31 00 01 00 0C 00 53 00 55 00 54 00 33 00 31 00 31 00 04 00 0C 00 53 00 55 00 54 00 33 00 31 00 31 00 03 00 0C 00 53 00 55 00 54 00 33 00 31 00 31 00 07 00 08 00 A1 A1 F5 AD CB AE D0 01 06 00 04 00 02 00 00 00 08 00 30 00 30 00 00 00 00 00 00 00 00 00 00 00 00 30 00 00 B6 1F EF CA A8 57 EA 57 BF 1E DC EB F8 97 4B 8E 0E BA 5A 6D FD 9D 07 A3 1D 11 B5 48 F8 C9 D0 CC 0A 00 10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 09 00 16 00 63 00 69 00 66 00 73 00 2F 00 53 00 55 00 54 00 33 00 31 00 31 00 00 00 00 00 00 00 00 00 00 00 00 00

AuthenticateMessage.SessionKeyString EncryptedRandomSessionKey = 3B 9B DF F3 8F 5E E8 F9 66 3F 11 A0 F4 C0 3A 78

Supply all parameters to the key calculation algorithm defined in MS-NLMP. Passwd = Password01! Username = ADMINISTRATOR Domain = SUT311

=== key calculation steps: [MS-NLMP] 3.3.2 NTLM v2 Authentication

UNICODE(Passwd)) = FFFE500061007300730077006F0072006400300031002100 NtHash = MD4(UNICODE(Passwd)) = 7C4FE5EADA682714A036E39378362BAB UUserDom = UNICODE(ConcatenationOf( Uppercase(User), UserDom ) ) UUserDom = UNICODE(ADMINISTRATORSUT311) = FFFE410044004D0049004E004900530054005200410054004F00520053005500540033003100 3100 NTOWFv2(Passwd, User, UserDom) = HMAC_MD5(NtHash, UUserDom) = AEE3959B44A815F1EB28C9511B4F533B ResponseKeyNT = NTOWFv2 = AEE3959B44A815F1EB28C9511B4F533B temp = ConcatenationOf(Responserversion, HiResponserversion, Z(6), Time, ClientChallenge, Z(4), ServerName, Z(4)) temp = 0101000000000000A1A1F5ADCBAED001BC4AD05F223CC90F0000000002000C00530055005400 33003100310001000C0053005500540033003100310004000C005300550054003300310031000 3000C0053005500540033003100310007000800A1A1F5ADCBAED001060004000200000008003 00030000000000000000000000000300000B61FEFCAA857EA57BF1EDCEBF8974B8E0EBA5A6DF D9D07A31D11B548F8C9D0CC0A001000000000000000000000000000000000000900160063006 900660073002F00530055005400330031003100000000000000000000000000 CHALLENGE_MESSAGE.ServerChallenge = 0D1D8BA31179D008 NTProofStr = HMAC_MD5(ResponseKeyNT, ConcatenationOf(CHALLENGE_MESSAGE.ServerChallenge, temp)

NTProofStr = 63078EB639FE03E20A231C3AE3BF2308 SessionBaseKey = HMAC_MD5(ResponseKeyNT, NTProofStr) NTLMv2 KeyExchangeKey = SessionBaseKey KeyExchangeKey= B4CF22566926B1C069ACD80E4D73C814

Because NTLMSSP_NEGOTIATE_KEY_EXCH AND (NTLMSSP_NEGOTIATE_SIGN OR NTLMSSP_NEGOTIATE_SEAL): ExportedSessionKey = RC4.Encrypt(KeyExchangeKey, AUTHENTICATE_MESSAGE.EncryptedRandomSessionKey)

ExportedSessionKey = 270E1BA896585EEB7AF3472D3B4C75A7 (this matches the key queried from GSS-API)

For completeness, we also show here the computation of the remaining NTLM keys. Note those keys have no use in SMB2/3.

Check SIGNKEY() algorithm in MS-NLMP for specific details.

Because we have NTLMSSP_NEGOTIATE_EXTENDED_SESSIONSECURITY flag set: Client Signing key = MD5(ConcatenationOf(ExportedSessionKey, "session key to client-to-server signing key magic constant")) Server Signing key = MD5(ConcatenationOf(ExportedSessionKey, "session key to server-to-client signing key magic constant"))

Server Signing key = E1BD8B416B0B709D295E12F2CF18E6C5 Client Signing key = D43F36C44BCE0630250A09EA0C2E8C2C

Check SEALKEY() algorithm in MS-NLMP for specific details.

Because NTLMSSP_NEGOTIATE_EXTENDED_SESSIONSECURITY flag is set and NTLMSSP_NEGOTIATE_128 is set: Client Sealing Key = MD5(ConcatenationOf(ExportedSessionKey, "session key to client-to-server sealing key magic constant")) Server Sealing Key = MD5(ConcatenationOf(ExportedSessionKey, "session key to server-to-client sealing key magic constant"))

Server Sealing Key = B0F5A0B32C81FF34A878E1409B3B0EF2 Client Sealing Key = 31E5557D99BE13F1B2665C7C7C52CE70

References

[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, https://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, https://www.ietf.org/rfc/rfc5084.txt [FIPS180-4] FIPS PUBS, "Secure Hash Standards (SHS)", March 2012, https://csrc.nist.gov/publications/fips/fips180-4/fips-180-4.pdf [RFC4493]. The AES-CMAC Algorithm, https://www.ietf.org/rfc/rfc4493.txt Windows Server 2012 R2: Which version of the SMB protocol (SMB 1.0, SMB 2.0, SMB 2.1, SMB 3.0 or SMB 3.02) are you using?

https://blogs.technet.microsoft.com/josebda/2013/10/02/windows-server-2012-r2-which-version-of-the-smb-protocol-smb-1-0-smb-2-0-smb-2-1-smb-3-0-or-smb-3-02-are-you-using/ The Basics of SMB Signing (covering both SMB1 and SMB2) https://blogs.technet.microsoft.com/josebda/2010/12/01/the-basics-of-smb-signing-covering-both-smb1-and-smb2/

How Kerberos user-to-user authentication works?

Edgar A Olougouna — Wed, 24 May 2017 19:17:36 GMT

The Kerberos user-to-user (U2U) authentication mechanism enables a client to authenticate to a service that is not in possession of the long-term secret key. U2U allows one principal to authenticate using a ticket encrypted with the session key from a TGT issued to another principal. This article discusses the messages involved in the mechanism. It illustrates various scenarios and applicability settings. It finally provides samples of packet exchanges.

Table of Contents

Preamble 2 Glossary 2 Refresher: Basic Kerberos authentication 2

The Authentication Service Exchange 2 The Ticket-Granting Service Exchange 3 The Client / Application Server Exchange 3

User-to-User Authentication Exchange 3

User-to-User Mechanism 3 User-to-User GSS-API messages 4 User-to-User tickets are not cached 5

How is U2U authentication initiated? 5

Deliberate client awareness 5 U2U via KDC policy 5 U2U via server policy 5

U2U illustrations 5

Deliberate Kerberos U2U from client: CredSSP in Remote Desktop Session 5 Kerberos U2U: Enabling SSO with NTLM for smart card sign-in 6 Kerberos U2U via KDC policy: Offering Remote Assistance 6

Conclusion 7

Appendix 1. Related Kerberos Error codes 7 Appendix 2. Steps of standard CredSSP’s Kerberos U2U from client 8 Appendix 3. Steps of Kerberos U2U via KDC policy in Offering Remote Assistance 24 References 48

Preamble

This article is not about Public Key Cryptography Based User-to-User (PKU2U). PKU2U is used in homegroup environments to authenticate peers by leveraging local certificates between peer computers. This article is not about Service for User and Constrained Delegation, both referred to as S4U [MS-SFU]. S4U enables an application service to obtain a Kerberos service ticket on behalf of a user (S4U2Self, S4U2Proxy). We assume the reader is familiar with Kerberos authentication [RFC4120] and GSS-API concepts [RFC2743]. We start the article with a terse overview of basic Kerberos authentication before elaborating on U2U.

Glossary

API – Application Program Interface AP – Application server AS – Authentication service GSS – Generic Security Service KDC - Key distribution center PAC – Privilege Account Certificate SPN - Service Principal Name SPNEGO - Simple and Protected GSSAPI Negotiation Mechanism TGT - Ticket granting ticket TGS - Ticket granting service U2U – User-to-user

Refresher: Basic Kerberos authentication

In its classic form, the Kerberos protocol supports authentication between a client and an application server. It consists of three main message exchanges.

The Authentication Service Exchange

The AS exchange consists of KRB_AS_REQ and KRB_AS_REP. In the KRB_AS_REQ, the client requests a TGT from the KDC’s Authentication Service (AS). In the KRB_AS_REP, the AS returns the TGT, which is the user's initial ticket meant only for use by the TGS. The TGT includes a session key that the client can use to encrypt communication with the TGS. The TGT is encrypted with a key only known by the KDC (the KDC key is shared by all KDCs in the realm). Thus, the TGT is opaque to all entities except the KDC itself. The TGT has a short validity time (typically 10 hours). The encrypted part of AS exchange uses the key that the client shares with the KDC.

The Ticket-Granting Service Exchange

The TGS exchange involves KRB_TGS_REQ and KRB_TGS_REP. The client requests the TGS to issue a service ticket for the target service. In the KRB_TGS_REQ, the client presents the TGT, an authenticator, and identifies the target service by its SPN. The TGS validates the TGT and the authenticator. It then issues a service ticket. It encrypts the ticket with the long-term key that is shared by the KDC and the target service. The ticket includes the client's identity and a copy of the session key. The TGS encrypts the client's copy of the session key with the key that the KDC shares with the client.

The Client / Application Server Exchange

To authenticate to the server, the client composes KRB_AP_REQ and sends the service ticket along with a new authenticator to the target server. The server decrypts the ticket with its long-term key and validates the authenticator. In Windows, the service also creates an access token based on the user’s PAC. Optionally, the client might have requested mutual authentication with the target server. If so, the target server retrieves the client’s timestamp from the authenticator, encrypts it with the session key, and returns it to the client as part of the KRB_AP_REP.

User-to-User Authentication Exchange

U2U authentication provides a method to perform authentication when the verifier does not have access to the service’s long-term key. The basic form of Kerberos authentication is not suitable for peer-to-peer authentication. The U2U variant of Kerberos enables authentication of such peers. The idea is to obtain a TGS ticket encrypted with the session key from another TGT issued to another user, instead of the long-term server key that would have not be accessible in the acceptor’s context. The following sections summarize the user-to-user authentication sequence.

User-to-User Mechanism

The OID for user-to-user mechanism is: 1.2.840.113554.1.2.2.3

It is a child OID of GSSAPI Kerberos OID 1.2.840.113554.1.2.2.

The U2U mech-type extends the conventional Kerberos GSS-API protocol and adds a round trip with the server to retrieve the TGT from the service.

User-to-User GSS-API messages

In the GSS-API encapsulated message exchange for U2U Kerberos, the request token has an innerContextToken with a 2-octet TOK_ID field containing 04 00 (KERB-TGT-REQUEST) followed by the message: KERB-TGT-REQUEST ::= SEQUENCE { pvno[0] INTEGER, msg-type[1] INTEGER, server-name[2] PrincipalName OPTIONAL, realm[3] Realm OPTIONAL All fields are defined in the Kerberos RFC4120 and informational RFC draft for U2U [U2UDraft]. msg-type is KRB_TGT_REQ (16).

The response message is a KERB_TGT_REPLY token which has an innerContextToken with a 2-octet TOK_ID field containing 04 01 (KERB-TGT-REPLY) followed by the message as follows: KERB-TGT-REPLY ::= SEQUENCE { pvno[0] INTEGER, msg-type[1] INTEGER, ticket[2] Ticket } msg-type is KRB_TGT_REP (17). The ticket contains the TGT for the service.

Upon receipt of the service TGT, the client initiator can now request the KDC to issue a service ticket by using a KERB-TGS-REQ with the KDC-Options ENC-TKT-IN-SKEY and the service TGT in the additional-tickets of the KDC-REQ-BODY.

Because ENC-TKT-IN-SKEY option is present in the KRB_KDC_REQ, the Sname may be absent. However, the Sname for U2U ticket is typically set to the principal name (i.e. user name) whose TGT the server supplied to the client. If Sname is absent, the KDC will use the name from the client in the additional ticket.

The TGS honors the request and issues the ticket (KERB-TGS-REP). It encrypts the ticket with the session key of the TGT in the additional ticket.

The client finally continues with the AP exchange. In the KERB-AP-REQ, the client sets USE-SESSION-KEY flag in the AP-Options to indicate to the server that U2U authentication is in use, and that the service ticket is encrypted in the session key from the server's TGT rather than in the server's long-term key.

User-to-User tickets are not cached

U2U service tickets are not cacheable. A U2U ticket is only usable to one instance of a client application. On the other hand, to cache a ticket, it must be valid to all instances of the service that share that SPN. Multiple authentications that share a cacheable service ticket will likewise share a session key.

How is U2U authentication initiated?

The Kerberos protocol does not specify the client’s trigger to U2U authentication. It is in the application protocol sequence that the client obtains the server’s TGT. Once this pre-requisite is fulfilled, the client can initiate user-to-user authentication as previously described. U2U is often used in cases where SPNEGO starts Kerberos and then fails either with KDC_ERR_MUST_USE_USER2USER from the KDC or with KRB_AP_ERR_USER_TO_USER_REQUIRED from the server.

Deliberate client awareness

When the client is aware that the application server requires user-to-user authentication, it will explicitly request U2U mechanism in the first call to GSS_Init_Sec_Context.

U2U via KDC policy

The KDC may implement a policy on user accounts to reject conventional service ticket requests. When a KERB_TGS_REQ that does not include a second ticket with an ENC_TKT_IN_SKEY KDC Option, the KDC will respond with KDC_ERR_MUST_USE_USER2USER (0x1B).

U2U via server policy

When a client sends a conventional KRB_AP_REQ and the service requires U2U authentication, the server will respond with KRB_AP_ERR_USER_TO_USER_REQUIRED (0x45). The server may provide its TGT in the data of the error message.

U2U illustrations

Deliberate Kerberos U2U from client: CredSSP in Remote Desktop Session

For Kerberos under CredSSP, the client chooses to do U2U on its own without a prior error about U2U being required. The client initiates U2U because CredSSP calls InitializeSecurityContext with the ISC_REQ_USE_SESSION_KEY flag. That flag requires a new session key, which Kerberos honors by doing U2U. When one observes network packets of Windows-based CredSPP, the Kerberos exchanges start with a conventional TGS ticket request, which is unexpected. This conventional TGS exchange could be explained by the fact that the code that forces to transition to U2U is emulating the reception of the user-to-user required error, and thus after the point where we get the normal ticket. That initial TGS preceding the first CredSSP TSRequest is a useless ticket retrieval. Indeed, that ticket is not presented in the TSRequest. Instead the client deliberately decides to send a U2U inside an SPNEGO token of the TSRequest. CredSSP resorts to U2U mechanism because U2U service tickets are not cacheable. When CredSSP uses U2U, it gets a unique session key to encrypt credentials and this remains private to the process instance. Had that connection used Kerberos without U2U, then the session key used to protect the credentials would have been available to any process running as the user that shares the user’s ticket cache. Note that the SPNEGO token of the first CSSP TSRequest has UserToUserMechanism in the MechToken = InitialContextToken{ThisMech: UserToUserMechanism (1.2.840.113554.1.2.2.3) . . .} Even though the MechTypes list contains: MechTypes: {MsKerberosToken (1.2.840.48018.1.2.2); KerberosToken (1.2.840.113554.1.2.2); Negoex (1.3.6.1.4.1.311.2.2.30); NLMP (1.3.6.1.4.1.311.2.2.10)} Here, the MechType is not really being negotiated. In the appendix, we provide illustrative packets of the exchange. The outer TLS session of the CredSSP packets has been decrypted.

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

Kerberos U2U helps to provide single-sign-on (SSO) with NTLM for a smart card sign-in. When the user logs in a client with a smartcard, Kerberos U2U enables SSO to network services that require NTLM. One such scenario is a remote desktop connection to a non-domain-joined server where the client needs to delegate its credentials to the server which is not capable of Kerberos authentication. The client uses Kerberos U2U to retrieve the NTOWF hash of the user’s password. It starts with a PKINIT exchange of KERB_AS_REQ / KERB_AS_REP with AS-PK-REQ / AS-PK-REP as specified in [MS-PKCA]. By using the PIN to unlock the smartcard, the client reads the principal name and certificate, then signs the AS-REQ which the KDC will validate before issuing the TGT. The client then retrieves a U2U TGS with the user name as Sname. In the U2U TGS’s KDC-REQ-BODY, the client uses the ENC-TKT-IN-SKEY option and supplies its TGT in the additional tickets. This allows to decrypt the resulting PAC (with the session key) and get the NTOWF in NTLM_SUPPLEMENTAL_CREDENTIAL. The encrypted NTOWF is part of the PAC and thus gets propagated to service tickets that the user acquires, but only the system to which the user logs on interactively can decrypt it. This allows a user that logs on with a smartcard to acquire credentials necessary to access resources that require NTLM. Note that the encrypted NTOWF in the PAC is not due to U2U. The client uses Kerberos U2U because a U2U ticket is un-cacheable. The session key remains privy to that process instance. When another authentication is needed, there is a separate ticket request.

Kerberos U2U via KDC policy: Offering Remote Assistance

This example illustrates U2U authentication with the trigger via KDC policy. It uses the scenario of an Expert providing an unsolicited Remote Assistance (RA) to a Novice. The Expert initiates the RA offer with “msra /offerRA ” command. To establish the RA session to the host identified by the Novice-FQDN, the Expert needs to obtain a Kerberos ticket to the user account of the Novice. First, the Expert’s computer tries to obtain a Kerberos ticket for the user account on the Novice's computer. The user account does not have any service principal name (SPN) that is registered. Thus, the KDC service on the DC returns the error KDC_S_PRINCIPAL_UNKNOWN. The extended error information conveys the client should fall back to U2U authentication (the KDC reply indicates KDC_ERR_MUST_USE_USER2USER in its extended error information). The Expert computer sends the U2U token to the Novice’s computer and obtain the user’s TGT. In this scenario, this U2U token exchange happens as part of the MSRPC Bind because the RA session goes over DCOM (MSRPC). The Expert computer uses an SPN with "RestrictedKrbHost" service class because it has the server name but not the identity of the service. This SPN is meant to authenticate with the server and not the service. Afterwards, it proceeds U2U authentication exchange, as previously described. In the appendix, we show an example of parsed packets of the exchange.

Conclusion

In this article, we discussed how Kerberos user-to-user authentication works. It is often an unspoken extension to Kerberos. We described the message exchange and provided examples of applications. The appendixes provide samples of U2U authentication exchanges.

Appendix 1. Related Kerberos Error codes

Error code, Error macro, Description

0x6, KDC_ERR_C_PRINCIPAL_UNKNOWN, Client not found in Kerberos database 0x7, KDC_ERR_S_PRINCIPAL_UNKNOWN, Server not found in Kerberos database 0x1B, KDC_ERR_MUST_USE_USER2USER, Server principal valid for user2user only 0x45, KRB_AP_ERR_USER_TO_USER_REQUIRED, User-to-user authorization is required A network packet capture generally shows the error codes in KERB-ERROR responses. To further diagnose, the Kerberos Event log can be useful, notably when there is extended error information. For diagnostic purpose, you can set the following registry to enable Kerberos events. This should not be left enabled on live production, otherwise it will fill up unnecessary disk space. https://support.microsoft.com/en-us/help/262177/how-to-enable-kerberos-event-logging HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters Registry Value: LogLevel Value Type: REG_DWORD Value Data: 0x1

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

This client’s TGT will be used later during U2U TGS.

KerberosV5 KerberosV5:AS Request Cname: Administrator Realm: contoso4 Sname: krbtgt/contoso4 KerberosV5 KerberosV5:KRB_ERROR - KDC_ERR_PREAUTH_REQUIRED (25) KerberosV5 KerberosV5:AS Request Cname: Administrator Realm: contoso4 Sname: krbtgt/contoso4 KerberosV5 KerberosV5:AS Response Ticket[Realm: CONTOSO4.COM, Sname: krbtgt/CONTOSO4.COM]

The following TGS ticket (to Sname: TERMSRV/sut01tp4.contoso4.com) will not be used, although it is retrieved.

KerberosV5 KerberosV5:TGS Request Realm: CONTOSO4.COM Sname: TERMSRV/sut01tp4.contoso4.com KerberosV5 KerberosV5:TGS Response Cname: Administrator

The client initiates U2U.

CSSP CredSSP:TSRequest, Version: 3

TLSSSLData: Transport Layer Security (TLS) Payload Data + TLS: TLS Rec Layer-1 SSL Application Data - Cssp: CredSSP - TsRequest: + SequenceHeader: + Tag0: + Version: 3 + Tag1: - NegoTokens: + SequenceOfHeader: + SequenceHeader: + Tag0: + AsnOctetStringHeader: - NegoToken: - InitialContextToken: + ApplicationHeader: + ThisMech: SpnegoToken (1.3.6.1.5.5.2) - InnerContextToken: 0x1 - SpnegoToken: 0x1 + ChoiceTag: - NegTokenInit: + SequenceHeader: + Tag0: - MechTypes: Prefer MsKerberosToken (1.2.840.48018.1.2.2) + SequenceHeader: + MechType: MsKerberosToken (1.2.840.48018.1.2.2) + MechType: KerberosToken (1.2.840.113554.1.2.2) + MechType: Negoex (1.3.6.1.4.1.311.2.2.30) + MechType: NLMP (1.3.6.1.4.1.311.2.2.10) + Tag2: + OctetStringHeader: - MechToken: unused (0) - MsKerberosToken: unused (0) - KerberosInitToken: + ApplicationHeader: + ThisMech: UserToUserMechanism (1.2.840.113554.1.2.2.3) - InnerContextToken: unused (0) - KerberosToken: unused (0) TokId: 0x400 - UsertoUserSessionReq: KRB_TGT_REQ (0x10) + SequenceHeader: + Tag0: + pvno: 5 + Tag1: + MessageType: 16 + Tag2: + ServerName: TERMSRV/sut01tp4.contoso4.com

the client receives the TGT form the server.

CSSP CredSSP:TSRequest, Version: 3

TLSSSLData: Transport Layer Security (TLS) Payload Data + TLS: TLS Rec Layer-1 SSL Application Data - Cssp: CredSSP - TsRequest: + SequenceHeader: + Tag0: + Version: 3 + Tag1: - NegoTokens: + SequenceOfHeader: + SequenceHeader: + Tag0: + AsnOctetStringHeader: - NegoToken: - NegotiationToken: + ChoiceTag: - NegTokenResp: + SequenceHeader: + Tag0: + NegState: accept-incomplete (1) + Tag1: + SupportedMech: MsKerberosToken (1.2.840.48018.1.2.2) + Tag2: + OctetStringHeader: - ResponseToken: unused (0) - MsKerberosToken: unused (0) - KerberosInitToken: + ApplicationHeader: + ThisMech: UserToUserMechanism (1.2.840.113554.1.2.2.3) - InnerContextToken: unused (0) - KerberosToken: unused (0) TokId: 0x401 - UsertoUserSessionRep: KRB_TGT_REP (0x11) + SequenceHeader: + Tag0: + pvno: 5 + Tag1: + MessageType: 17 + Tag2: - Ticket: Realm: CONTOSO4.COM, Sname: krbtgt/CONTOSO4.COM + ApplicationTag: + SequenceHeader: + Tag0: + TktVno: 5 + Tag1: + Realm: CONTOSO4.COM + Tag2: 0x1 + Sname: krbtgt/CONTOSO4.COM + Tag3: 0x1 - EncPart: + SequenceHeader: + Tag0: + EType: aes256-cts-hmac-sha1-96 (18) + Tag1: + KvNo: 2 + Tag2: + Cipher: h:Ì°a---------------12Bz"?Uâ*sä‘:ñ‹?ç;†·8µFnDê1@È\wÐV8–ÄÔ÷uÊdÈvqÙÜ0 ---------------/¤<Ï¼»¢þkÎgÈmíXeðoôfòWòùÝ?$5.---------------´äŒ^´ÛÝïcJõ@ûdY’.®?`Ä×53+iw˜ ¿ÞFv´&q'`™Íü…01W PÎø.ºOç3|+g`"CRaØ]#\ÊñÞ(xªþ›•â¸ôå±¡MŠå.05HÓö“¶ZÆQ†·&-------------------------------------------------------------¾}7^a•çúÅ£Ù.´sÕL†ÖãR1---------------œ{íºÄ/)\" Lò[áqœU

The client requests service ticket for U2U authentication.

KerberosV5 KerberosV5:TGS Request Realm: CONTOSO4.COM Sname: TERMSRV/sut01tp4.contoso4.com

- Kerberos: TGS Request Realm: CONTOSO4.COM Sname: TERMSRV/sut01tp4.contoso4.com + Length: Length = 2674 - TgsReq: Kerberos TGS Request + ApplicationTag: - KdcReq: KRB_TGS_REQ (12) + SequenceHeader: + Tag1: + Pvno: 5 + Tag2: + MsgType: KRB_TGS_REQ (12) + Tag3: - PaData: + SequenceOfHeader: - PaData: PA-TGS-REQ (1) + SequenceHeader: + Tag1: + PaDataType: PA-TGS-REQ (1) + Tag2: + OctetStringHeader: - KrbApReq: KRB_AP_REQ (14) + ApplicationTag: + SequenceHeader: + Tag0: + PvNo: 5 + Tag1: + MsgType: KRB_AP_REQ (14) + Tag2: 0x1 + ApOptions: + Tag3: - Ticket: Realm: CONTOSO4.COM, Sname: krbtgt/CONTOSO4.COM + ApplicationTag: + SequenceHeader: + Tag0: + TktVno: 5 + Tag1: + Realm: CONTOSO4.COM + Tag2: 0x1 + Sname: krbtgt/CONTOSO4.COM + Tag3: 0x1 - EncPart: + SequenceHeader: + Tag0: + EType: aes256-cts-hmac-sha1-96 (18) + Tag1: + KvNo: 2 + Tag2: + Cipher: ¯++ä¨OQòåc ¦¹ÿÑãIªã<»Xðë.`¾bÌÎØI?N¦ÛIXzCXaº´Æ}±?Õ6 ›D£ðiñËÕ?ÉeÕ?J0W¬šÚDÚù ¸aŠNxDÉ»’ÓQŠh øË˜öÕ¡¼wÊ?$æŒªya}|^líà@—ÎëÚ÷.\ê¯z™Ÿðîö¢N‡Ù†¥¦2l QÑ=úG²R¨Mj/lÕ¾éŒL

KerberosV5 KerberosV5:TGS Response Cname: Administrator

- Kerberos: TGS Response Cname: Administrator + Length: Length = 1638 - TgsRep: Kerberos TGS Response + ApplicationTag: - KdcRep: KRB_TGS_REP (13) + SequenceHeader: + Tag0: + PvNo: 5 + Tag1: + MsgType: KRB_TGS_REP (13) + Tag3: + Crealm: CONTOSO4.COM + Tag4: + Cname: Administrator + Tag5: - Ticket: Realm: CONTOSO4.COM, Sname: TERMSRV/sut01tp4.contoso4.com + ApplicationTag: + SequenceHeader: + Tag0: + TktVno: 5 + Tag1: + Realm: CONTOSO4.COM + Tag2: 0x1 + Sname: TERMSRV/sut01tp4.contoso4.com + Tag3: 0x1 - EncPart: + SequenceHeader: + Tag0: + EType: aes256-cts-hmac-sha1-96 (18) + Tag2: + Cipher: [¼ˆÀfÙ÷&v.'æÿÒ~”´Ñ95D³3›Ø‹éæD@OÆæÆþ@œ¹oÙÁ}&&MáÛ`? ‘oh¼õÎýƒíˆû---------------÷68”öR®˜ÏïV‹?ö5¾_ú>´I4˜ ?ØDÏ‡Éš&”ù«yaøýª·mv?ïa%ß À + Tag6: + EncPart:

CSSP CredSSP:TSRequest, Version: 3

TLSSSLData: Transport Layer Security (TLS) Payload Data + TLS: TLS Rec Layer-1 SSL Application Data - Cssp: CredSSP - TsRequest: + SequenceHeader: + Tag0: + Version: 3 + Tag1: - NegoTokens: + SequenceOfHeader: + SequenceHeader: + Tag0: + AsnOctetStringHeader: - NegoToken: - NegotiationToken: + ChoiceTag: - NegTokenResp: + SequenceHeader: + Tag0: + NegState: accept-incomplete (1) + Tag2: + OctetStringHeader: - ResponseToken: unused (0) - KerberosToken: unused (0) - KerberosInitToken: + ApplicationHeader: + ThisMech: UserToUserMechanism (1.2.840.113554.1.2.2.3) - InnerContextToken: unused (0) - KerberosToken: unused (0) TokId: Krb5ApReq (0x100) - ApReq: KRB_AP_REQ (14) + ApplicationTag: + SequenceHeader: + Tag0: + PvNo: 5 + Tag1: + MsgType: KRB_AP_REQ (14) + Tag2: 0x1 - ApOptions: + KerberosFlagsHeader: + Padding: - KrbFlags: 0x60000000 Reserved: (0...............................) UseSessionKey: (.1..............................) MutualRequired: (..1.............................) Unused: (...00000000000000000000000000000) + Tag3: - Ticket: Realm: CONTOSO4.COM, Sname: TERMSRV/sut01tp4.contoso4.com + ApplicationTag: + SequenceHeader: + Tag0: + TktVno: 5 + Tag1: + Realm: CONTOSO4.COM + Tag2: 0x1 + Sname: TERMSRV/sut01tp4.contoso4.com + Tag3: 0x1 - EncPart: + SequenceHeader: + Tag0: + EType: aes256-cts-hmac-sha1-96 (18) + Tag2: + Cipher: [¼ˆÀfÙ÷&v.'æÿÒ~”´Ñ95D³3›Ø‹éæD@OÆæÆþ@œ¹oÙÁ}&&MáÛ`? ‘oh¼õÎýƒíˆû---------------÷68”öR®˜ÏïV‹?ö5¾_ú>´I4˜ ?ØDÏ‡Éš&”ù«yaøýª·mv?ïa%ß À + Tag4: + Authenticator:

CSSP CredSSP:TSRequest, Version: 3

TLSSSLData: Transport Layer Security (TLS) Payload Data + TLS: TLS Rec Layer-1 SSL Application Data - Cssp: CredSSP - TsRequest: + SequenceHeader: + Tag0: + Version: 3 + Tag3: + PubKeyAuth: Encrypted

CSSP CredSSP:TSRequest, Version: 3

TLSSSLData: Transport Layer Security (TLS) Payload Data + TLS: TLS Rec Layer-1 SSL Application Data - Cssp: CredSSP - TsRequest: + SequenceHeader: + Tag0: + Version: 3 + Tag2: + AuthInfo: Encrypted

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

KerberosV5:AS Request Cname: myuser01 Realm: CONTOSO.COM Sname: krbtgt/CONTOSO.COM KerberosV5:KRB_ERROR - KDC_ERR_PREAUTH_REQUIRED (25) KerberosV5:AS Request Cname: myuser01 Realm: CONTOSO.COM Sname: krbtgt/CONTOSO.COM KerberosV5:AS Response Ticket[Realm: CONTOSO.COM, Sname: krbtgt/CONTOSO.COM] KerberosV5:TGS Request Realm: CONTOSO.COM Sname: RestrictedKrbHost/sut2016rs1.contoso.com KerberosV5:TGS Response Cname: myuser01 . . . KerberosV5:TGS Request Realm: CONTOSO.COM Sname: krbtgt/CONTOSO KerberosV5:TGS Response Cname: myuser01

KerberosV5:TGS Request Realm: CONTOSO.COM Sname: Administrator

- Kerberos: TGS Request Realm: CONTOSO.COM Sname: Administrator + Length: Length = 1542 - TgsReq: Kerberos TGS Request + ApplicationTag: - KdcReq: KRB_TGS_REQ (12) + SequenceHeader: + Tag1: + Pvno: 5 + Tag2: + MsgType: KRB_TGS_REQ (12) + Tag3: - PaData: + SequenceOfHeader: - PaData: PA-TGS-REQ (1) + SequenceHeader: + Tag1: + PaDataType: PA-TGS-REQ (1) + Tag2: + OctetStringHeader: - KrbApReq: KRB_AP_REQ (14) + ApplicationTag: + SequenceHeader: + Tag0: + PvNo: 5 + Tag1: + MsgType: KRB_AP_REQ (14) + Tag2: 0x1 + ApOptions: + Tag3: + Ticket: Realm: CONTOSO.COM, Sname: krbtgt/CONTOSO.COM + Tag4: + Authenticator: + Tag4: - ReqBody: + SequenceHeader: + Tag0: + KdcOptions: 0x40810000 + Tag2: 0x1 + Realm: CONTOSO.COM + Tag3: + Sname: Administrator + Tag5: 0x1 + Till: 09/13/2037 02:48:05 UTC + Tag7: + Nonce: 1167598226 (0x45982292) + Tag8: + Etype: + TagA: + EncAuthorizationData:

KerberosV5:KRB_ERROR - KDC_ERR_S_PRINCIPAL_UNKNOWN (7)

- Kerberos: KRB_ERROR - KDC_ERR_S_PRINCIPAL_UNKNOWN (7) + Length: Length = 105 - KrbError: KRB_ERROR (30) + ApplicationTag: + SequenceHeader: + Tag0: + PvNo: 5 + Tag1: + MsgType: KRB_ERROR (30) + Tag4: + Stime: 04/08/2017 06:06:33 UTC + Tag5: + SuSec: 429948 + Tag6: + ErrorCode: KDC_ERR_S_PRINCIPAL_UNKNOWN (7) + Tag9: + Realm: CONTOSO.COM + TagA: + Sname: Administrator + TagC: - EData: - EData: 0 0 ---------------?¡------------------------------------------------------------ + AsnOctetStringHeader: OctetStream: 04 0D 30 0B 30 09 A0 03 02 01 80 A1 02 04 00

In the Kerberos error message, the extended error data has Error Code: 0x1b KDC_ERR_MUST_USE_USER2USER

The Kerberos event log entry looks like the following: - - 3 0 2 0 0 0x80000000000000 8201 System client2016rs1.contoso.com - 6:6:33.0000 4/8/2017 Z 0x1b Unknown Error CONTOSO.COM Administrator Administrator@CONTOSO.COM 9 11b8 300B3009A003020180A1020400

the client sends UsertoUserSessionReq: KRB_TGT_REQ (0x10) to the server.

- MSRPC: c/o Bind: unknown UUID{00000001-0000-0000-C000-000000000046} Call=0x2 Assoc Grp=0x0 Xmit=0x16D0 Recv=0x16D0 - Bind: {00000001-0000-0000-C000-000000000046} unknown RpcVers: 5 (0x5) RpcVersMinor: 0 (0x0) PType: 0x0B - Bind + PfcFlags: 7 (0x7) + PackedDrep: 0x10 FragLength: 304 (0x130) AuthLength: 136 (0x88) CallId: 2 (0x2) MaxXmitFrag: 5840 (0x16D0) MaxRecvFrag: 5840 (0x16D0) AssocGroupId: 0 (0x0) + PContextElem: - AuthVerifier: 0x1 AuthType: RPC_C_AUTHN_GSS_NEGOTIATE - The Simple and Protected GSS-API Negotiation (SPNEGO) mechanism selects either NT LAN Manager (NTLM) or Kerberos authentication. AuthLevel: dce_c_authn_level_pkt_integrity - This level offers the dce_c_authn_level_pkt services plus per-PDU modification and deletion detection. AuthPadLength: 0 (0x0) AuthReserved: 0 (0x0) AuthContextId: 0 (0x0) - AuthValue: - GssApi: - InitialContextToken: + ApplicationHeader: + ThisMech: SpnegoToken (1.3.6.1.5.5.2) - InnerContextToken: 0x1 - SpnegoToken: 0x1 + ChoiceTag: - NegTokenInit: + SequenceHeader: + Tag0: - MechTypes: Prefer MsKerberosToken (1.2.840.48018.1.2.2) + SequenceHeader: + MechType: MsKerberosToken (1.2.840.48018.1.2.2) + MechType: KerberosToken (1.2.840.113554.1.2.2) + MechType: Negoex (1.3.6.1.4.1.311.2.2.30) + MechType: NLMP (1.3.6.1.4.1.311.2.2.10) + Tag2: + OctetStringHeader: - MechToken: unused (0) - MsKerberosToken: unused (0) - KerberosInitToken: + ApplicationHeader: + ThisMech: UserToUserMechanism (1.2.840.113554.1.2.2.3) - InnerContextToken: unused (0) - KerberosToken: unused (0) TokId: 0x400 - UsertoUserSessionReq: KRB_TGT_REQ (0x10) + SequenceHeader: + Tag0: + pvno: 5 + Tag1: + MessageType: 16 + Tag2: + ServerName: Administrator + Tag3: + Realm: CONTOSO

The server requests TGT for the user from the KDC.

KerberosV5:AS Request Cname: Administrator Realm: CONTOSO.COM Sname: krbtgt/CONTOSO.COM KerberosV5:KRB_ERROR - KDC_ERR_PREAUTH_REQUIRED (25)

KerberosV5:AS Request Cname: Administrator Realm: CONTOSO.COM Sname: krbtgt/CONTOSO.COM

- Kerberos: AS Request Cname: Administrator Realm: CONTOSO.COM Sname: krbtgt/CONTOSO.COM + Length: Length = 312 - AsReq: Kerberos AS Request + ApplicationTag: - KdcReq: KRB_AS_REQ (10) + SequenceHeader: + Tag1: + Pvno: 5 + Tag2: + MsgType: KRB_AS_REQ (10) + Tag3: + PaData: + Tag4: - ReqBody: + SequenceHeader: + Tag0: + KdcOptions: 0x40810010 + Tag1: + Cname: Administrator + Tag2: 0x1 + Realm: CONTOSO.COM + Tag3: + Sname: krbtgt/CONTOSO.COM + Tag5: 0x1 + Till: 09/13/2037 02:48:05 UTC + Tag6: + Rtime: 09/13/2037 02:48:05 UTC + Tag7: + Nonce: 1118221639 (0x42A6B547) + Tag8: + Etype: + Tag9: - Addresses: + SequenceOfHeader: - Address: SUT2016RS1 + SequenceHeader: + Tag0: + AddrType: Netbios address (20) + Tag1: + Address: SUT2016RS1

KerberosV5:AS Response Ticket[Realm: CONTOSO.COM, Sname: krbtgt/CONTOSO.COM]

- Kerberos: AS Response Ticket[Realm: CONTOSO.COM, Sname: krbtgt/CONTOSO.COM] + Length: Length = 1583 - AsRep: Kerberos AS Response + ApplicationTag: - KdcRep: KRB_AS_REP (11) + SequenceHeader: + Tag0: + PvNo: 5 + Tag1: + MsgType: KRB_AS_REP (11) + Tag2: + Padata: + Tag3: + Crealm: CONTOSO.COM + Tag4: + Cname: Administrator + Tag5: + Ticket: Realm: CONTOSO.COM, Sname: krbtgt/CONTOSO.COM + Tag6: + EncPart:

the client receives UsertoUserSessionRep: KRB_TGT_REP (0x11) from the server

- MSRPC: c/o Bind Ack: unknown UUID{00000001-0000-0000-C000-000000000046} Call=0x2 Assoc Grp=0x55A4AC30 Xmit=0x16D0 Recv=0x16D0 - BindAck: RpcVers: 5 (0x5) RpcVersMinor: 0 (0x0) PType: 0x0C - Bind Ack + PfcFlags: 7 (0x7) + PackedDrep: 0x10 FragLength: 1303 (0x517) AuthLength: 1187 (0x4A3) CallId: 2 (0x2) MaxXmitFrag: 5840 (0x16D0) MaxRecvFrag: 5840 (0x16D0) AssocGroupId: 1436855344 (0x55A4AC30) + SecAddr: 54390 Pad2: 0x1 + PResultList: - AuthVerifier: AuthType: RPC_C_AUTHN_GSS_NEGOTIATE - The Simple and Protected GSS-API Negotiation (SPNEGO) mechanism selects either NT LAN Manager (NTLM) or Kerberos authentication. AuthLevel: dce_c_authn_level_pkt_integrity - This level offers the dce_c_authn_level_pkt services plus per-PDU modification and deletion detection. AuthPadLength: 0 (0x0) AuthReserved: 0 (0x0) AuthContextId: 0 (0x0) - AuthValue: - GssApi: - NegotiationToken: + ChoiceTag: - NegTokenResp: + SequenceHeader: + Tag0: + NegState: accept-incomplete (1) + Tag1: + SupportedMech: MsKerberosToken (1.2.840.48018.1.2.2) + Tag2: + OctetStringHeader: - ResponseToken: unused (0) - MsKerberosToken: unused (0) - KerberosInitToken: + ApplicationHeader: + ThisMech: UserToUserMechanism (1.2.840.113554.1.2.2.3) - InnerContextToken: unused (0) - KerberosToken: unused (0) TokId: 0x401 - UsertoUserSessionRep: KRB_TGT_REP (0x11) + SequenceHeader: + Tag0: + pvno: 5 + Tag1: + MessageType: 17 + Tag2: - Ticket: Realm: CONTOSO.COM, Sname: krbtgt/CONTOSO.COM + ApplicationTag: + SequenceHeader: + Tag0: + TktVno: 5 + Tag1: + Realm: CONTOSO.COM + Tag2: 0x1 + Sname: krbtgt/CONTOSO.COM + Tag3: 0x1 + EncPart:

The client request TGS from the KDC for the service's user.

KerberosV5:TGS Request Realm: CONTOSO.COM Sname: Administrator

- Kerberos: TGS Request Realm: CONTOSO.COM Sname: Administrator + Length: Length = 2692 - TgsReq: Kerberos TGS Request + ApplicationTag: - KdcReq: KRB_TGS_REQ (12) + SequenceHeader: + Tag1: + Pvno: 5 + Tag2: + MsgType: KRB_TGS_REQ (12) + Tag3: - PaData: + SequenceOfHeader: - PaData: PA-TGS-REQ (1) + SequenceHeader: + Tag1: + PaDataType: PA-TGS-REQ (1) + Tag2: + OctetStringHeader: - KrbApReq: KRB_AP_REQ (14) + ApplicationTag: + SequenceHeader: + Tag0: + PvNo: 5 + Tag1: + MsgType: KRB_AP_REQ (14) + Tag2: 0x1 + ApOptions: + Tag3: + Ticket: Realm: CONTOSO.COM, Sname: krbtgt/CONTOSO.COM + Tag4: + Authenticator: + PaData: PA-PAC-OPTIONS (167) + Tag4: - ReqBody: + SequenceHeader: + Tag0: - KdcOptions: 0x40810008 + KerberosFlagsHeader: + Padding: - KrbFlags: 0x40810008 Reserved: (0...............................) Forwardable: (.1..............................) Ticket to be issued is to have its FORWARDABLE flag set Forwarded: (..0.............................) This is not a request for forwarding Proxiable: (...0............................) Ticket to be issued is not to have its PROXIABLE flag set Proxy: (....0...........................) This is not a request for a proxy AllowPostDate: (.....0..........................) Ticket to be issued is not to have its MAY_POSTDATE flag set PostDated: (......0.........................) This is not a request for a postdated ticket Unused7: (.......0........................) Renewable: (........1.......................) Ticket to be issued is to have its RENEWABLE flag set Unused9: (.........0......................) Unused10: (..........0.....................) OptHardwareAuth: (...........0....................) Unused12: (............0...................) Unused13: (.............0..................) CnameInAddlTkt: (..............0.................) This is not a request for S4U2proxy functionality Canonicalize: (...............1................) Unused16: (................0000000000......) DisableTransitedCheck: (..........................0.....) Checking of the transited field is enabled RenewableOk: (...........................0....) Renewable ticket is not acceptable EncTktInSkey: (............................1...) Indicates that the ticket for the end server is to be encrypted in the session key from the additional TGT provided Unused29: (.............................0..) Renew: (..............................0.) Present request is not for a renewal Validate: (...............................0) Request is not to validate a postdated ticket + Tag2: 0x1 + Realm: CONTOSO.COM + Tag3: + Sname: Administrator + Tag5: 0x1 + Till: 09/13/2037 02:48:05 UTC + Tag7: + Nonce: 1181218830 (0x4667F80E) + Tag8: + Etype: + TagA: + EncAuthorizationData: + TagB: - AdditionalTickets: + SequenceOfHeader: - Ticket: Realm: CONTOSO.COM, Sname: krbtgt/CONTOSO.COM + ApplicationTag: + SequenceHeader: + Tag0: + TktVno: 5 + Tag1: + Realm: CONTOSO.COM + Tag2: 0x1 + Sname: krbtgt/CONTOSO.COM + Tag3: 0x1 + EncPart:

KerberosV5:TGS Response Cname: myuser01

- Kerberos: TGS Response Cname: myuser01 + Length: Length = 1528 - TgsRep: Kerberos TGS Response + ApplicationTag: - KdcRep: KRB_TGS_REP (13) + SequenceHeader: + Tag0: + PvNo: 5 + Tag1: + MsgType: KRB_TGS_REP (13) + Tag3: + Crealm: CONTOSO.COM + Tag4: + Cname: myuser01 + Tag5: - Ticket: Realm: CONTOSO.COM, Sname: Administrator + ApplicationTag: + SequenceHeader: + Tag0: + TktVno: 5 + Tag1: + Realm: CONTOSO.COM + Tag2: 0x1 + Sname: Administrator + Tag3: 0x1 - EncPart: + SequenceHeader: + Tag0: + EType: aes256-cts-hmac-sha1-96 (18) + Tag2: + Cipher: ©lELY³’Ç·ÝÁò·¸@»^_”@}?WSÀ|hÖ÷FÃrÑ«g†á†ü%º÷ ¢$ÌÿSÖŸ?×íEïB£_†¤tólëÄU + Tag6: - EncPart: + SequenceHeader: + Tag0: + EType: aes256-cts-hmac-sha1-96 (18) + Tag2: + Cipher: À{ÙcBØP}½§WcæT%3×„·îç”mù×v-=Y¹A%1Âšãˆr_·âh

the client does the AP exchange of Kerberos token with the server, and indicates in the APOptions USE-SESSION-KEY flag that the ticket is encrypted with the session key from the server's TGT.

- MSRPC: c/o Alter Cont: unknown UUID{00000001-0000-0000-C000-000000000046} Call=0x2 - AlterContext: RpcVers: 5 (0x5) RpcVersMinor: 0 (0x0) PType: 0x0E - Alter Context + PfcFlags: 7 (0x7) + PackedDrep: 0x10 FragLength: 1659 (0x67B) AuthLength: 1579 (0x62B) CallId: 2 (0x2) MaxXmitFrag: ignored MaxRecvFrag: ignored AssocGroupId: ignored + PContextElem: - AuthVerifier: 0x1 AuthType: RPC_C_AUTHN_GSS_NEGOTIATE - The Simple and Protected GSS-API Negotiation (SPNEGO) mechanism selects either NT LAN Manager (NTLM) or Kerberos authentication. AuthLevel: dce_c_authn_level_pkt_integrity - This level offers the dce_c_authn_level_pkt services plus per-PDU modification and deletion detection. AuthPadLength: 0 (0x0) AuthReserved: 0 (0x0) AuthContextId: 0 (0x0) - AuthValue: - GssApi: - NegotiationToken: + ChoiceTag: - NegTokenResp: + SequenceHeader: + Tag0: + NegState: accept-incomplete (1) + Tag2: + OctetStringHeader: - ResponseToken: unused (0) - KerberosToken: unused (0) - Kerberos: AP Request Ticket[Realm: CONTOSO.COM, Sname: Administrator] - ApReq: KRB_AP_REQ (14) + ApplicationTag: + SequenceHeader: + Tag0: + PvNo: 5 + Tag1: + MsgType: KRB_AP_REQ (14) + Tag2: 0x1 - ApOptions: + KerberosFlagsHeader: + Padding: - KrbFlags: 0x60000000 Reserved: (0...............................) UseSessionKey: (.1..............................) MutualRequired: (..1.............................) Unused: (...00000000000000000000000000000) + Tag3: - Ticket: Realm: CONTOSO.COM, Sname: Administrator + ApplicationTag: + SequenceHeader: + Tag0: + TktVno: 5 + Tag1: + Realm: CONTOSO.COM + Tag2: 0x1 + Sname: Administrator + Tag3: 0x1 - EncPart: + SequenceHeader: + Tag0: + EType: aes256-cts-hmac-sha1-96 (18) + Tag2: + Cipher: ©lELY³’Ç·ÝÁò·¸@»^_”@}?WSÀ|hÖ÷FÃrÑ«g†á†ü%º÷ ¢$ÌÿSÖŸ?×íEïB£_†¤tólëÄU + Tag4: + Authenticator:

Because MUTUAL-REQUIRED flag was set in AP-Options, the server includes KRB-AP-REP in its response.

- MSRPC: c/o Alter Cont Resp: unknown UUID{00000001-0000-0000-C000-000000000046} Call=0x2 Assoc Grp=0x55A4AC30 Xmit=0x16D0 Recv=0x16D0 - AlterContextResponse: RpcVers: 5 (0x5) RpcVersMinor: 0 (0x0) PType: 0x0F - Alter Context Resp + PfcFlags: 7 (0x7) + PackedDrep: 0x10 FragLength: 216 (0xD8) AuthLength: 152 (0x98) CallId: 2 (0x2) MaxXmitFrag: ignored MaxRecvFrag: ignored AssocGroupId: ignored + SecAddr: + Pad2: 0x1 + PResultList: - AuthVerifier: AuthType: RPC_C_AUTHN_GSS_NEGOTIATE - The Simple and Protected GSS-API Negotiation (SPNEGO) mechanism selects either NT LAN Manager (NTLM) or Kerberos authentication. AuthLevel: dce_c_authn_level_pkt_integrity - This level offers the dce_c_authn_level_pkt services plus per-PDU modification and deletion detection. AuthPadLength: 0 (0x0) AuthReserved: 0 (0x0) AuthContextId: 0 (0x0) - AuthValue: - GssApi: - NegotiationToken: + ChoiceTag: - NegTokenResp: + SequenceHeader: + Tag0: + NegState: accept-incomplete (1) + Tag2: + OctetStringHeader: - ResponseToken: KRB_AP_REP (15) - KerberosToken: KRB_AP_REP (15) - Kerberos: AP Response - ApRep: KRB_AP_REP (15) + ApplicationTag: + SequenceHeader: + Tag0: + PvNo: 5 + Tag1: + MsgType: KRB_AP_REP (15) + Tag2: 0x1 - AuthorizationData: + SequenceHeader: + Tag0: + EType: rc4-hmac (23) + Tag2: + Cipher: Uàs5˜3(,S ¥Ç×Ñ•Kìd/aò---------------Ã/}¦Œ«—ƒm–„Fzº4@¬q1[«u,OCÿ¦ÇŠ}µ˜?D¸j¹šÚÜ|!»[ç¤|/öon‡ˆ=i+ï†(šPpãúN….¼wÈ†‚™vºÉWõ

- MSRPC: c/o Alter Cont: unknown UUID{00000001-0000-0000-C000-000000000046} Call=0x2 - AlterContext: RpcVers: 5 (0x5) RpcVersMinor: 0 (0x0) PType: 0x0E - Alter Context + PfcFlags: 7 (0x7) + PackedDrep: 0x10 FragLength: 216 (0xD8) AuthLength: 136 (0x88) CallId: 2 (0x2) MaxXmitFrag: ignored MaxRecvFrag: ignored AssocGroupId: ignored + PContextElem: - AuthVerifier: 0x1 AuthType: RPC_C_AUTHN_GSS_NEGOTIATE - The Simple and Protected GSS-API Negotiation (SPNEGO) mechanism selects either NT LAN Manager (NTLM) or Kerberos authentication. AuthLevel: dce_c_authn_level_pkt_integrity - This level offers the dce_c_authn_level_pkt services plus per-PDU modification and deletion detection. AuthPadLength: 0 (0x0) AuthReserved: 0 (0x0) AuthContextId: 0 (0x0) - AuthValue: - GssApi: - NegotiationToken: + ChoiceTag: - NegTokenResp: + SequenceHeader: + Tag0: + NegState: accept-incomplete (1) + Tag2: + OctetStringHeader: - ResponseToken: KRB_AP_REP (15) - KerberosToken: KRB_AP_REP (15) - Kerberos: AP Response - ApRep: KRB_AP_REP (15) + ApplicationTag: + SequenceHeader: + Tag0: + PvNo: 5 + Tag1: + MsgType: KRB_AP_REP (15) + Tag2: 0x1 - AuthorizationData: + SequenceHeader: + Tag0: + EType: rc4-hmac (23) + Tag2: + Cipher: ówûdf__ÇßMk†¦;N”ß³“ºãu:ïýVwhû™F0ÔuDš>©×¤‡Ÿ7@Pü¤º8MÚÜ 4H + Tag3: + OctetStringHeader: - MechListMic: KRB_AP_REP (15) - KerberosToken: KRB_AP_REP (15) TokId: GSS_GetMIC (0x404) - Krb5GssV2GetMic: + Flags: 4 (0x4) Filler: Binary Large Object (5 Bytes) SndSeq: 1181218827 (0x4667F80B) SgnCksum: Binary Large Object (12 Bytes)

- MSRPC: c/o Alter Cont Resp: unknown UUID{00000001-0000-0000-C000-000000000046} Call=0x2 Assoc Grp=0x55A4AC30 Xmit=0x16D0 Recv=0x16D0 - AlterContextResponse: RpcVers: 5 (0x5) RpcVersMinor: 0 (0x0) PType: 0x0F - Alter Context Resp + PfcFlags: 7 (0x7) + PackedDrep: 0x10 FragLength: 105 (0x69) AuthLength: 41 (0x29) CallId: 2 (0x2) MaxXmitFrag: ignored MaxRecvFrag: ignored AssocGroupId: ignored + SecAddr: + Pad2: 0x1 + PResultList: - AuthVerifier: AuthType: RPC_C_AUTHN_GSS_NEGOTIATE - The Simple and Protected GSS-API Negotiation (SPNEGO) mechanism selects either NT LAN Manager (NTLM) or Kerberos authentication. AuthLevel: dce_c_authn_level_pkt_integrity - This level offers the dce_c_authn_level_pkt services plus per-PDU modification and deletion detection. AuthPadLength: 0 (0x0) AuthReserved: 0 (0x0) AuthContextId: 0 (0x0) - AuthValue: - GssApi: - NegotiationToken: + ChoiceTag: - NegTokenResp: + SequenceHeader: + Tag0: + NegState: accept-completed (0) + Tag3: + OctetStringHeader: - MechListMic: unused (0) - KerberosToken: unused (0) TokId: GSS_GetMIC (0x404) - Krb5GssV2GetMic: + Flags: 5 (0x5) Filler: Binary Large Object (5 Bytes) SndSeq: 1096155632 (0x415601F0) SgnCksum: Binary Large Object (12 Bytes)

References

[RFC4120] The Kerberos Network Authentication Service (V5) https://tools.ietf.org/rfc/rfc4120.txt [U2UDraft] User to User Kerberos Authentication using GSS-API https://tools.ietf.org/html/draft-swift-win2k-krb-user2user-03 [RFC2743] "Generic Security Service Application Program Interface Version 2, Update 1" https://tools.ietf.org/rfc/rfc2743.txt [MS-CSSP]: Credential Security Support Provider (CredSSP) Protocol https://msdn.microsoft.com/en-us/library/cc226764.aspx [MS-SPNG]: Simple and Protected GSS-API Negotiation Mechanism (SPNEGO) Extension https://msdn.microsoft.com/en-us/library/cc247021.aspx [MS-RA]: Remote Assistance Protocol https://msdn.microsoft.com/en-us/library/cc240013.aspx [MS-PKCA]: Public Key Cryptography for Initial Authentication (PKINIT) in Kerberos Protocol https://msdn.microsoft.com/en-us/library/cc238455.aspx [PKU2U] Introducing PKU2U in Windows https://technet.microsoft.com/en-us/library/dd560634(v=ws.10).aspx [MS-SFU]: Kerberos Protocol Extensions: Service for User and Constrained Delegation Protocol https://msdn.microsoft.com/en-us/library/cc246071.aspx

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

Tom Jebo — Tue, 23 Feb 2016 11:51:00 GMT

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:

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
Provide the Key from the previous Shared Secret Request (not included in this explanation)
Set the Key Type to TEXT
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 (https://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 (https://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

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

OpenXML Styles 101 - Understanding Table Style Conditional Formatting

JCurry — Fri, 06 Nov 2015 10:16:00 GMT

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.

https://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 (10x8). 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:firstColumn="1"
w:lastColumn="0" w:noHBand="0" w:noVBand="1"/>

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

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.

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







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.

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.

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.

OpenXML Styles 101 - Creating Custom Styles and Understanding Style Inheritance

JCurry — Wed, 16 Sep 2015 12:00:00 GMT

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.

https://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

Paragraph 1

Paragraph 2

Paragraph 3

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

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

0

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

document.xml

Paragraph 1

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

And assign the new style to the second paragraph…

document.xml

Paragraph 2

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

And apply it to the third paragraph…

document.xml

Paragraph 3

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.

MS-OXCFXICS - How to parse the FastTransfer Stream

JCurry — Wed, 16 Sep 2015 11:59:00 GMT

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:

The stream consists of elements.
Each element is either a marker or a propValue.

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.

propValues are either fixed or variable length.

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.

If it's fixed length, read the next x number of bytes as indicated by the type.
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.

SMB 3.1.1 Encryption in Windows 10

Edgar A Olougouna — Wed, 09 Sep 2015 13:04:00 GMT

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 -EncryptData <0|1> Share level encryption enabled at creation: New-SmbShare -Name -Path -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 https://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 https://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 https://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 https://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, https://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, https://www.ietf.org/rfc/rfc5084.txt SMB3 Secure Dialect Negotiation https://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 https://blogs.technet.com/b/josebda/archive/2014/08/11/smb3-powershell-changes-in-windows-server-2012-r2-smb1-can-now-be-completely-removed.aspx

SMB 3.1.1 Pre-authentication integrity in Windows 10

Edgar A Olougouna — Tue, 11 Aug 2015 13:15:00 GMT

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

https://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

https://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, https://csrc.nist.gov/publications/nistpubs/800-108/sp800-108.pdf

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

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

MS-PST - Parsing a Heap-on-Node Property Context Block

JCurry — Fri, 30 May 2014 12:12:00 GMT

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: https://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:

The Block is a Heap-on-Node.
The BTree-on-Heap is built on top of the Heap-on-Node.
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.

0x000C
0x0014
0x006C
0x007C
0x008C
0x00A4
0x00BC
0x00D4
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.

cbKey	0x02
cbEnt	0x06
hidRoot	0x0040, 0x0000

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.

Extended DFS referral for SMB 3

Edgar A Olougouna — Fri, 21 Feb 2014 09:40:00 GMT

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
https://technet.microsoft.com/en-us/library/dn270370.aspx

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

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