Hi Tom, > It's an advisory payload, and can be used to direct the connection appropriately > by load balancers, servers hosting multiple names, and the like. It's basically the > same servername that will be presented later in SMB2_TREE_CONNECT, only it's > available early, prior to any SMB3 processing. Other possible uses are for logging > and diagnosis. Ok, I think it should be explicitly stated, otherwise it's a bit confusing, if it's completely missing from 3.3.5.4 Receiving an SMB2 NEGOTIATE Request. > It has no actual function in the SMB3 protocol, so apart from defining the payload > it's not a matter for the MS-SMB2 document. We would hope, however, that clients > will include the context when sending SMB2_NEGOTIATE. This might be an information leak if client or server require encryption, as the unc in the tree connect is encrypted and the negotiate value isn't. On the other side it's likely that the target principal name is already visible in a kerberos ticket or the NTLMSSP MsvAvTargetName. metze
Attachment:
signature.asc
Description: OpenPGP digital signature
