1 // Copyright 2017 The Chromium Authors 2 // Use of this source code is governed by a BSD-style license that can be 3 // found in the LICENSE file. 4 5 // This file contains common input and result values use to verify the NTLM 6 // implementation. They are defined in [MS-NLMP] Section 4.2 [1]. 7 // 8 // [MS-NLMP] has no test data for Extended Protection for Authentication (EPA). 9 // Test vectors related to EPA (aka Channel Binding) have been taken from 10 // a Microsoft blog post [2]. 11 // 12 // [1] https://msdn.microsoft.com/en-us/library/cc236621.aspx 13 // [2] https://blogs.msdn.microsoft.com/openspecification/2013/03/26/ntlm-and- 14 // channel-binding-hash-aka-extended-protection-for-authentication/ 15 16 #ifndef NET_NTLM_NTLM_TEST_DATA_H_ 17 #define NET_NTLM_NTLM_TEST_DATA_H_ 18 19 #include "net/ntlm/ntlm_constants.h" 20 21 namespace net::ntlm::test { 22 23 // Common input values defined in [MS-NLMP] Section 4.2.1. 24 inline constexpr char16_t kPassword[] = {'P', 'a', 's', 's', 'w', 25 'o', 'r', 'd', '\0'}; 26 inline constexpr char16_t kNtlmDomain[] = {'D', 'o', 'm', 'a', 'i', 'n', '\0'}; 27 inline constexpr uint8_t kNtlmDomainRaw[] = {'D', 0x00, 'o', 0x00, 'm', 0x00, 28 'a', 0x00, 'i', 0x00, 'n', 0x00}; 29 inline constexpr char16_t kUser[] = {'U', 's', 'e', 'r', '\0'}; 30 inline constexpr char16_t kDomainUserCombined[] = { 31 'D', 'o', 'm', 'a', 'i', 'n', '\\', 'U', 's', 'e', 'r', '\0'}; 32 inline constexpr char16_t kHostname[] = {'C', 'O', 'M', 'P', 'U', 33 'T', 'E', 'R', '\0'}; 34 inline constexpr char16_t kServer[] = {'S', 'e', 'r', 'v', 'e', 'r', '\0'}; 35 inline constexpr uint8_t kServerRaw[] = {'S', 0x00, 'e', 0x00, 'r', 0x00, 36 'v', 0x00, 'e', 0x00, 'r', 0x00}; 37 38 // ASCII Versions of the above strings. 39 inline constexpr char kNtlmDomainAscii[] = "Domain"; 40 inline constexpr char kUserAscii[] = "User"; 41 inline constexpr char kHostnameAscii[] = "COMPUTER"; 42 43 // Test data obtained from [2]. 44 inline constexpr uint8_t kChannelBindings[] = { 45 't', 'l', 's', '-', 's', 'e', 'r', 'v', 'e', 'r', '-', 46 'e', 'n', 'd', '-', 'p', 'o', 'i', 'n', 't', ':', 0xea, 47 0x05, 0xfe, 0xfe, 0xcc, 0x6b, 0x0b, 0xd5, 0x71, 0xdb, 0xbc, 0x5b, 48 0xaa, 0x3e, 0xd4, 0x53, 0x86, 0xd0, 0x44, 0x68, 0x35, 0xf7, 0xb7, 49 0x4c, 0x85, 0x62, 0x1b, 0x99, 0x83, 0x47, 0x5f, 0x95, '\0'}; 50 51 inline constexpr char kNtlmSpn[] = {'H', 'T', 'T', 'P', '/', 'S', 52 'e', 'r', 'v', 'e', 'r', '\0'}; 53 inline constexpr uint8_t kNtlmSpnRaw[] = { 54 'H', 0x00, 'T', 0x00, 'T', 0x00, 'P', 0x00, '/', 0x00, 'S', 55 0x00, 'e', 0x00, 'r', 0x00, 'v', 0x00, 'e', 0x00, 'r', 0x00}; 56 57 // Input value defined in [MS-NLMP] Section 4.2.1. 58 inline constexpr uint64_t kServerTimestamp = 0; 59 60 // Arbitrary value for client timestamp. The spec does not provide test data 61 // or scenarios involving the client timestamp. The relevant thing is that it 62 // is not equal to |kServerTimestamp| so it can be determined which timestamp 63 // is within the message. 64 // Tue, 23 May 2017 20:13:07 +0000 65 inline constexpr uint64_t kClientTimestamp = 131400439870000000; 66 67 // Challenge vectors defined in [MS-NLMP] Section 4.2.1. 68 inline constexpr uint8_t kServerChallenge[kChallengeLen] = { 69 0x01, 0x23, 0x45, 0x67, 0x89, 0xab, 0xcd, 0xef}; 70 inline constexpr uint8_t kClientChallenge[kChallengeLen] = { 71 0xaa, 0xaa, 0xaa, 0xaa, 0xaa, 0xaa, 0xaa, 0xaa}; 72 73 // Test input defined in [MS-NLMP] Section 4.2.3.3. 74 inline constexpr uint8_t kChallengeMsgV1[] = { 75 0x4e, 0x54, 0x4c, 0x4d, 0x53, 0x53, 0x50, 0x00, 0x02, 0x00, 0x00, 0x00, 76 0x0c, 0x00, 0x0c, 0x00, 0x38, 0x00, 0x00, 0x00, 0x33, 0x82, 0x0a, 0x82, 77 0x01, 0x23, 0x45, 0x67, 0x89, 0xab, 0xcd, 0xef, 0x00, 0x00, 0x00, 0x00, 78 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 79 0x06, 0x00, 0x70, 0x17, 0x00, 0x00, 0x00, 0x0f, 0x53, 0x00, 0x65, 0x00, 80 0x72, 0x00, 0x76, 0x00, 0x65, 0x00, 0x72, 0x00}; 81 82 // Test input defined in [MS-NLMP] Section 4.2.4.3. 83 inline constexpr uint8_t kChallengeMsgFromSpecV2[] = { 84 0x4e, 0x54, 0x4c, 0x4d, 0x53, 0x53, 0x50, 0x00, 0x02, 0x00, 0x00, 0x00, 85 0x0c, 0x00, 0x0c, 0x00, 0x38, 0x00, 0x00, 0x00, 0x33, 0x82, 0x8a, 0xe2, 86 0x01, 0x23, 0x45, 0x67, 0x89, 0xab, 0xcd, 0xef, 0x00, 0x00, 0x00, 0x00, 87 0x00, 0x00, 0x00, 0x00, 0x24, 0x00, 0x24, 0x00, 0x44, 0x00, 0x00, 0x00, 88 0x06, 0x00, 0x70, 0x17, 0x00, 0x00, 0x00, 0x0f, 0x53, 0x00, 0x65, 0x00, 89 0x72, 0x00, 0x76, 0x00, 0x65, 0x00, 0x72, 0x00, 0x02, 0x00, 0x0c, 0x00, 90 0x44, 0x00, 0x6f, 0x00, 0x6d, 0x00, 0x61, 0x00, 0x69, 0x00, 0x6e, 0x00, 91 0x01, 0x00, 0x0c, 0x00, 0x53, 0x00, 0x65, 0x00, 0x72, 0x00, 0x76, 0x00, 92 0x65, 0x00, 0x72, 0x00, 0x00, 0x00, 0x00, 0x00, 93 }; 94 95 // A minimal challenge message for tests. For NTLMv1 this implementation only 96 // reads the smallest required version of the message (32 bytes). Some 97 // servers may still send messages this small. The only relevant flags 98 // that affect behavior are that both NTLMSSP_NEGOTIATE_UNICODE and 99 // NTLMSSP_NEGOTIATE_EXTENDED_SESSIONSECURITY are set. 100 // 101 // [0-7] - "NTLMSSP\0" (Signature) 102 // [9-11] - |MessageType::kChallenge| (Message Type = 0x00000002) 103 // [12-19] - |SecBuf(kNegotiateMessageLen, 0)| (Target Name - Not Used) 104 // [20-23] - |kNegotiateMessageFlags| (Flags = 0x00088207) 105 // [24-31] - |kServerChallenge| (Server Challenge) 106 // 107 // See [MS-NLMP] Section 2.2.2.2 for more information about the Challenge 108 // message. 109 inline constexpr uint8_t kMinChallengeMessage[kChallengeHeaderLen] = { 110 'N', 'T', 'L', 'M', 'S', 'S', 'P', '\0', 0x02, 0x00, 0x00, 111 0x00, 0x00, 0x00, 0x00, 0x00, 0x20, 0x00, 0x00, 0x00, 0x07, 0x82, 112 0x08, 0x00, 0x01, 0x23, 0x45, 0x67, 0x89, 0xab, 0xcd, 0xef}; 113 114 // The same message as |kMinChallengeMessage| but with the 115 // NTLMSSP_NEGOTIATE_UNICODE flag cleared. 116 inline constexpr uint8_t kMinChallengeMessageNoUnicode[kChallengeHeaderLen] = { 117 'N', 'T', 'L', 'M', 'S', 'S', 'P', '\0', 0x02, 0x00, 0x00, 118 0x00, 0x00, 0x00, 0x00, 0x00, 0x20, 0x00, 0x00, 0x00, 0x06, 0x82, 119 0x08, 0x00, 0x01, 0x23, 0x45, 0x67, 0x89, 0xab, 0xcd, 0xef}; 120 121 // The same message as |kMinChallengeMessage| but with the 122 // NTLMSSP_NEGOTIATE_EXTENDED_SESSIONSECURITY flag cleared. 123 inline constexpr uint8_t kMinChallengeMessageNoSS[kChallengeHeaderLen] = { 124 'N', 'T', 'L', 'M', 'S', 'S', 'P', '\0', 0x02, 0x00, 0x00, 125 0x00, 0x00, 0x00, 0x00, 0x00, 0x20, 0x00, 0x00, 0x00, 0x07, 0x82, 126 0x00, 0x00, 0x01, 0x23, 0x45, 0x67, 0x89, 0xab, 0xcd, 0xef}; 127 128 // Test result value for NTOWFv1() defined in [MS-NLMP] Section 4.2.2.1.2. 129 inline constexpr uint8_t kExpectedNtlmHashV1[kNtlmHashLen] = { 130 0xa4, 0xf4, 0x9c, 0x40, 0x65, 0x10, 0xbd, 0xca, 131 0xb6, 0x82, 0x4e, 0xe7, 0xc3, 0x0f, 0xd8, 0x52}; 132 133 // Test result value for NTOWFv2() defined in [MS-NLMP] Section 4.2.4.1.1. 134 inline constexpr uint8_t kExpectedNtlmHashV2[kNtlmHashLen] = { 135 0x0c, 0x86, 0x8a, 0x40, 0x3b, 0xfd, 0x7a, 0x93, 136 0xa3, 0x00, 0x1e, 0xf2, 0x2e, 0xf0, 0x2e, 0x3f}; 137 138 // Test result value defined in [MS-NLMP] Section 4.2.2.1. 139 inline constexpr uint8_t kExpectedNtlmResponseV1[kResponseLenV1] = { 140 0x67, 0xc4, 0x30, 0x11, 0xf3, 0x02, 0x98, 0xa2, 0xad, 0x35, 0xec, 0xe6, 141 0x4f, 0x16, 0x33, 0x1c, 0x44, 0xbd, 0xbe, 0xd9, 0x27, 0x84, 0x1f, 0x94}; 142 143 // Test result value defined in [MS-NLMP] Section 4.2.3.2.2. 144 inline constexpr uint8_t kExpectedNtlmResponseWithV1SS[kResponseLenV1] = { 145 0x75, 0x37, 0xf8, 0x03, 0xae, 0x36, 0x71, 0x28, 0xca, 0x45, 0x82, 0x04, 146 0xbd, 0xe7, 0xca, 0xf8, 0x1e, 0x97, 0xed, 0x26, 0x83, 0x26, 0x72, 0x32}; 147 148 // Test result value defined in [MS-NLMP] Section 4.2.3.2.1. 149 inline constexpr uint8_t kExpectedLmResponseWithV1SS[kResponseLenV1] = { 150 0xaa, 0xaa, 0xaa, 0xaa, 0xaa, 0xaa, 0xaa, 0xaa, 0x00, 0x00, 0x00, 0x00, 151 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00}; 152 153 // Test result value defined in [MS-NLMP] Section 4.2.4.1.3. 154 // 155 // "temp" is defined in Section 3.3.2 and is part of the data to be hashed 156 // to generate the NTLMv2 Proof. It is composed of 3 parts; 157 // 158 // 1) [0-27] A fixed length part in the first 28 (|kProofInputLenV2|) bytes 159 // which in this implementation is generated by |GenerateProofInputV2|. 160 // 161 // 2) [28-63] A variable length part which the spec calls "ServerName" but 162 // defines as the AV Pairs (aka Target Information) from the Authenticate 163 // message. See |kExpectedTargetInfoFromSpecV2| for more information. 164 // 165 // 3) [64-68] 4 zero bytes. 166 // 167 // NOTE: The timestamp (bytes [8-15]) should not actually be 0 here. In order 168 // to use the test data from the spec some lower level tests do generate this 169 // value. The target info sent by the server does not contain a timestamp 170 // AvPair, and section 3.1.5.1.2 states that the client should populate the 171 // timestamp with the servers timestamp if it exists, otherwise with the 172 // client's local time. For end to end tests the alternate value 173 // |kExpectedTempWithClientTimestampV2| below is used for end to end tests. 174 // Having different test data for the server and client time allows testing 175 // the logic more correctly. 176 inline constexpr uint8_t kExpectedTempFromSpecV2[] = { 177 0x01, 0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 178 0x00, 0x00, 0x00, 0x00, 0xaa, 0xaa, 0xaa, 0xaa, 0xaa, 0xaa, 0xaa, 0xaa, 179 0x00, 0x00, 0x00, 0x00, 0x02, 0x00, 0x0c, 0x00, 0x44, 0x00, 0x6f, 0x00, 180 0x6d, 0x00, 0x61, 0x00, 0x69, 0x00, 0x6e, 0x00, 0x01, 0x00, 0x0c, 0x00, 181 0x53, 0x00, 0x65, 0x00, 0x72, 0x00, 0x76, 0x00, 0x65, 0x00, 0x72, 0x00, 182 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00}; 183 184 // This value is the same as |kExpectedTempFromSpecV2| but with the timestamp 185 // field at bytes [8-15] populated with |kClientTimestamp|. 186 inline constexpr uint8_t kExpectedTempWithClientTimestampV2[] = { 187 0x01, 0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x80, 0x0b, 0xc8, 0xfd, 188 0x00, 0xd4, 0xd2, 0x01, 0xaa, 0xaa, 0xaa, 0xaa, 0xaa, 0xaa, 0xaa, 0xaa, 189 0x00, 0x00, 0x00, 0x00, 0x02, 0x00, 0x0c, 0x00, 0x44, 0x00, 0x6f, 0x00, 190 0x6d, 0x00, 0x61, 0x00, 0x69, 0x00, 0x6e, 0x00, 0x01, 0x00, 0x0c, 0x00, 191 0x53, 0x00, 0x65, 0x00, 0x72, 0x00, 0x76, 0x00, 0x65, 0x00, 0x72, 0x00, 192 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00}; 193 194 // Test result value defined (indirectly) in [MS-NLMP] Section 4.2.4. 195 // 196 // This is part 2 (bytes [28-63]) of |kExpectedTempFromSpecV2|. Additional 197 // notes; 198 // 199 // a) The spec defines the AV Pairs to be in the opposite order to which they 200 // actually appear in the output in Section 4.2.4.1.3. 201 // 202 // b) The implicit presence of a terminating AV Pair is not mentioned. 203 // 204 // c) Section 4.2.4 does not show the byte sequences of the AV Pair Headers. 205 // 206 // NOTE: The real implementation in default settings would not have such a 207 // simple set of AV Pairs since a flags field to indicate the presence of a 208 // MIC, and a channel bindings field would also have been added. 209 inline constexpr uint8_t kExpectedTargetInfoFromSpecV2[] = { 210 0x02, 0x00, 0x0c, 0x00, 0x44, 0x00, 0x6f, 0x00, 0x6d, 0x00, 0x61, 0x00, 211 0x69, 0x00, 0x6e, 0x00, 0x01, 0x00, 0x0c, 0x00, 0x53, 0x00, 0x65, 0x00, 212 0x72, 0x00, 0x76, 0x00, 0x65, 0x00, 0x72, 0x00, 0x00, 0x00, 0x00, 0x00}; 213 214 // This target info is to test the behavior when a server timestamp is 215 // present. It is the same as |kExpectedTargetInfoFromSpecV2| but with 216 // an additional timestamp AvPair. 217 inline constexpr uint8_t kExpectedTargetInfoFromSpecPlusServerTimestampV2[] = { 218 0x02, 0x00, 0x0c, 0x00, 0x44, 0x00, 0x6f, 0x00, 0x6d, 0x00, 0x61, 0x00, 219 0x69, 0x00, 0x6e, 0x00, 0x01, 0x00, 0x0c, 0x00, 0x53, 0x00, 0x65, 0x00, 220 0x72, 0x00, 0x76, 0x00, 0x65, 0x00, 0x72, 0x00, 0x07, 0x00, 0x08, 0x00, 221 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00}; 222 223 // The target info after being updated by the client when the server sends 224 // |kExpectedTargetInfoFromSpecV2| in the challenge message with both EPA and 225 // MIC enabled. 226 // 227 // When MIC and EPA are enabled, 3 additional AvPairs are added. 228 // 1) A flags AVPair with the MIC_PRESENT bit set. 229 // 2) A channel bindings AVPair containing the channel bindings hash. 230 // 3) A target name AVPair containing the SPN of the server. 231 // 232 // AvPair 1 [0-1] |TargetInfoAvId::kDomainName| Av ID = 0x0002 233 // AvPair 1 [2-3] |len(kNtlmDomainRaw)| Av Length = 0x000c 234 // AvPair 1 [4-15] |kNtlmDomainRaw| Av Payload = L"Domain" 235 // 236 // AvPair 2 [16-17] |TargetInfoAvId::kServerName| Av ID = 0x0001 237 // AvPair 2 [18-19] |len(kServerRaw)| Av Length = 0x000c 238 // AvPair 2 [20-31] |kServerRaw| Av Payload = L"Server" 239 // 240 // AvPair 3 [32-33] |TargetInfoAvId::kFlags| Av ID = 0x0006 241 // AvPair 3 [34-35] |sizeof(uint32_t)| Av Length = 0x0004 242 // AvPair 3 [36-39] |TargetInfoAvFlags::kMicPresent| Av Payload = 0x00000002 243 // 244 // AvPair 4 [40-41] |TargetInfoAvId::kChannelBindings| Av ID = 0x000a 245 // AvPair 4 [42-43] |kChannelBindingsHashLen| Av Length = 0x0010 246 // AvPair 4 [44-59] |kExpectedChannelBindingHashV2| Av Payload 247 // 248 // AvPair 5 [60-61] |TargetInfoAvId::kTargetName| Av ID = 0x0009 249 // AvPair 5 [62-63] |len(kNtlmSpnRaw)| Av Length = 0x0016 250 // AvPair 5 [64-85] |kNtlmSpnRaw| Av Payload = 251 // L"HTTP/Server" 252 // 253 // AvPair 6 [86-87] |TargetInfoAvId::kEol| Av ID = 0x0000 254 // AvPair 6 [88-89] Av Length = 0x0000 255 inline constexpr uint8_t kExpectedTargetInfoSpecResponseV2[] = { 256 0x02, 0x00, 0x0c, 0x00, 'D', 0x00, 'o', 0x00, 'm', 0x00, 'a', 0x00, 257 'i', 0x00, 'n', 0x00, 0x01, 0x00, 0x0c, 0x00, 'S', 0x00, 'e', 0x00, 258 'r', 0x00, 'v', 0x00, 'e', 0x00, 'r', 0x00, 0x06, 0x00, 0x04, 0x00, 259 0x02, 0x00, 0x00, 0x00, 0x0a, 0x00, 0x10, 0x00, 0x65, 0x86, 0xE9, 0x9D, 260 0x81, 0xC2, 0xFC, 0x98, 0x4E, 0x47, 0x17, 0x2F, 0xD4, 0xDD, 0x03, 0x10, 261 0x09, 0x00, 0x16, 0x00, 'H', 0x00, 'T', 0x00, 'T', 0x00, 'P', 0x00, 262 '/', 0x00, 'S', 0x00, 'e', 0x00, 'r', 0x00, 'v', 0x00, 'e', 0x00, 263 'r', 0x00, 0x00, 0x00, 0x00, 0x00}; 264 265 // Test result value defined in [MS-NLMP] Section 4.2.4.2.2. 266 inline constexpr uint8_t kExpectedProofFromSpecV2[kNtlmProofLenV2] = { 267 0x68, 0xcd, 0x0a, 0xb8, 0x51, 0xe5, 0x1c, 0x96, 268 0xaa, 0xbc, 0x92, 0x7b, 0xeb, 0xef, 0x6a, 0x1c}; 269 270 // The value of the NTLMv2 proof when |kExpectedTargetInfoSpecResponseV2| is 271 // the updated target info in the Authenticate message. 272 inline constexpr uint8_t kExpectedProofSpecResponseV2[kNtlmProofLenV2] = { 273 0x01, 0x0c, 0x0b, 0xd1, 0x4e, 0xf7, 0xa2, 0x96, 274 0x89, 0xc0, 0xc1, 0x9c, 0xea, 0xe8, 0xb7, 0xdf}; 275 276 // The value of the NTLMv2 proof when |kExpectedTargetInfoSpecResponseV2| is 277 // the updated target info, and |kClientTimestamp| is correctly set in the 278 // Authenticate message. 279 constexpr uint8_t 280 kExpectedProofSpecResponseWithClientTimestampV2[kNtlmProofLenV2] = { 281 0x8c, 0x02, 0x60, 0xdb, 0xef, 0x69, 0x06, 0x62, 282 0xaf, 0x9c, 0x42, 0xd5, 0x07, 0x82, 0xd2, 0xed}; 283 284 // Test result data obtained from [2]. 285 inline constexpr uint8_t 286 kExpectedChannelBindingHashV2[kChannelBindingsHashLen] = { 287 0x65, 0x86, 0xE9, 0x9D, 0x81, 0xC2, 0xFC, 0x98, 288 0x4E, 0x47, 0x17, 0x2F, 0xD4, 0xDD, 0x03, 0x10}; 289 290 // Test result value defined in [MS-NLMP] Section 4.2.4.1.2. 291 inline constexpr uint8_t kExpectedSessionBaseKeyFromSpecV2[kSessionKeyLenV2] = { 292 0x8d, 0xe4, 0x0c, 0xca, 0xdb, 0xc1, 0x4a, 0x82, 293 0xf1, 0x5c, 0xb0, 0xad, 0x0d, 0xe9, 0x5c, 0xa3}; 294 295 // The session base key when the proof is 296 // |kExpectedProofSpecResponseWithClientTimestampV2|. 297 constexpr uint8_t 298 kExpectedSessionBaseKeyWithClientTimestampV2[kSessionKeyLenV2] = { 299 0x62, 0x3d, 0xbd, 0x07, 0x1b, 0xe7, 0xa5, 0x30, 300 0xb6, 0xa9, 0x5c, 0x2e, 0xb4, 0x98, 0x24, 0x70}; 301 302 // The Message Integrity Check (MIC) using 303 // |kExpectedSessionBaseKeyWithClientTimestampV2| over the following 3 304 // messages; |kExpectedNegotiateMsg|, |kChallengeMsgFromSpecV2|, and 305 // |kExpectedAuthenticateMsgSpecResponseV2|. 306 // The MIC field in |kExpectedAuthenticateMsgSpecResponseV2| is set to all 307 // zeros while calculating the hash. 308 inline constexpr uint8_t kExpectedMicV2[kMicLenV2] = { 309 0xf7, 0x36, 0x16, 0x33, 0xf0, 0xad, 0x9b, 0xdf, 310 0x4a, 0x7c, 0x42, 0x1b, 0xc6, 0xb8, 0x24, 0xa3}; 311 312 // Expected negotiate message from this implementation. 313 // [0-7] - "NTLMSSP\0" (Signature) 314 // [9-11] - |MessageType::kNegotiate| (Message Type = 0x00000001) 315 // [12-15] - |kNegotiateMessageFlags| (Flags = 0x00088207) 316 // [16-23] - |SecBuf(kNegotiateMessageLen, 0)| (Domain) 317 // [24-32] - |SecBuf(kNegotiateMessageLen, 0)| (Workstation) 318 // 319 // NOTE: Message does not include Version field. Since 320 // NTLMSSP_NEGOTIATE_VERSION is never sent, it is not required, and the server 321 // won't try to read it. The field is currently omitted for test compatibility 322 // with the existing implementation. When NTLMv2 is implemented this field 323 // will be present for both NTLMv1 and NTLMv2, however it will always be set to 324 // all zeros. The version field is only used for debugging and only defines 325 // a mapping to Windows operating systems. 326 // 327 // Similarly both Domain and Workstation fields are are not strictly required 328 // either (though are included here) since neither 329 // NTLMSSP_NEGOTIATE_OEM_WORKSTATION_SUPPLIED nor 330 // NTLMSSP_NEGOTIATE_OEM_DOMAIN_SUPPLIED are ever sent. A compliant server 331 // should never read past the 16th byte in this message. 332 // 333 // See [MS-NLMP] Section 2.2.2.5 for more detail on flags and 2.2.2.1 for the 334 // Negotiate message in general. 335 inline constexpr uint8_t kExpectedNegotiateMsg[kNegotiateMessageLen] = { 336 'N', 'T', 'L', 'M', 'S', 'S', 'P', '\0', 0x01, 0x00, 0x00, 337 0x00, 0x07, 0x82, 0x08, 0x00, 0x00, 0x00, 0x00, 0x00, 0x20, 0x00, 338 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x20, 0x00, 0x00, 0x00}; 339 340 // Expected V1 Authenticate message from this implementation when sent 341 // |kChallengeMsgV1| as the challenge. 342 // 343 // [0-7] - "NTLMSSP\0" (Signature) 344 // [9-11] - |MessageType::kAuthenticate| (Message Type = 0x00000003) 345 // [12-19] - |SecBuf(64, kResponseLenV1)| (LM Response) 346 // [20-27] - |SecBuf(88, kResponseLenV1)| (NTLM Response) 347 // [28-35] - |SecBuf(112, 12)| (Target Name = L"Domain") 348 // [36-43] - |SecBuf(124, 8)| (User = L"User") 349 // [44-51] - |SecBuf(132, 16)| (Workstation = L"COMPUTER") 350 // [52-59] - |SecBuf(64, 0)| (Session Key (empty)) 351 // [60-63] - 0x00088203 (Flags) 352 // [64-87] - |EXPECTED_V1_WITH_SS_LM_RESPONSE| (LM Response Payload) 353 // [88-111] - |EXPECTED_V1_WITH_SS_NTLM_RESPONSE| (NTLM Response Payload) 354 // [112-123]- L"Domain" (Target Name Payload) 355 // [124-132]- L"User" (User Payload) 356 // [132-147]- L"COMPUTER" (Workstation Payload) 357 // 358 // NOTE: This is not identical to the message in [MS-NLMP] Section 4.2.2.3 for 359 // several reasons. 360 // 361 // 1) The flags are different because this implementation does not support 362 // the flags related to version, key exchange, signing and sealing. These 363 // flags are not relevant to implementing the NTLM scheme in HTTP. 364 // 2) Since key exchange is not required nor supported, the session base key 365 // payload is not required nor present. 366 // 3) The specification allows payloads to be in any order. This (and the 367 // prior) implementation uses a different payload order than the example. 368 // 4) The version field is Windows specific and there is no provision for 369 // non-Windows OS information. This message does not include a version field. 370 inline constexpr uint8_t kExpectedAuthenticateMsgSpecResponseV1[] = { 371 'N', 'T', 'L', 'M', 'S', 'S', 'P', '\0', 0x03, 0x00, 0x00, 0x00, 372 0x18, 0x00, 0x18, 0x00, 0x40, 0x00, 0x00, 0x00, 0x18, 0x00, 0x18, 0x00, 373 0x58, 0x00, 0x00, 0x00, 0x0c, 0x00, 0x0c, 0x00, 0x70, 0x00, 0x00, 0x00, 374 0x08, 0x00, 0x08, 0x00, 0x7c, 0x00, 0x00, 0x00, 0x10, 0x00, 0x10, 0x00, 375 0x84, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x40, 0x00, 0x00, 0x00, 376 0x03, 0x82, 0x08, 0x00, 0xaa, 0xaa, 0xaa, 0xaa, 0xaa, 0xaa, 0xaa, 0xaa, 377 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 378 0x00, 0x00, 0x00, 0x00, 0x75, 0x37, 0xf8, 0x03, 0xae, 0x36, 0x71, 0x28, 379 0xca, 0x45, 0x82, 0x04, 0xbd, 0xe7, 0xca, 0xf8, 0x1e, 0x97, 0xed, 0x26, 380 0x83, 0x26, 0x72, 0x32, 'D', 0x00, 'o', 0x00, 'm', 0x00, 'a', 0x00, 381 'i', 0x00, 'n', 0x00, 'U', 0x00, 's', 0x00, 'e', 0x00, 'r', 0x00, 382 'C', 0x00, 'O', 0x00, 'M', 0x00, 'P', 0x00, 'U', 0x00, 'T', 0x00, 383 'E', 0x00, 'R', 0x00, 384 }; 385 386 // Expected V2 Authenticate message from this implementation when sent 387 // |kChallengeMsgFromSpecV2| as the challenge using default features. 388 // 389 // [0-7] - "NTLMSSP\0" (Signature) 390 // [9-11] - |MessageType::kAuthenticate| (Message Type = 0x00000003) 391 // [12-19] - |SecBuf(88, kResponseLenV1)| (LM Response) 392 // [20-27] - |SecBuf(112, 138)| (NTLM Response) 393 // [28-35] - |SecBuf(250, 12)| (Target Name = L"Domain") 394 // [36-43] - |SecBuf(262, 8)| (User = L"User") 395 // [44-51] - |SecBuf(270, 16)| (Workstation = L"COMPUTER") 396 // [52-59] - |SecBuf(88, 0)| (Session Key (empty)) 397 // [60-63] - 0x00088203 (Flags) 398 // [64-71] - All zero (Version) 399 // [72-87] - |kExpectedMicV2| (MIC) 400 // [88-111] - All zero (LM Response Payload) 401 // [112-249]-------------------------------------- (NTLM Response Payload) 402 // [112-127]-|kExpectedProofSpecResponseWithClientTimestampV2| 403 // (NTLMv2 Proof) 404 // [128-155]-|kExpectedTempWithClientTimestampV2[0-27]| 405 // (Proof Input) 406 // [156-245]-|kExpectedTargetInfoSpecResponseV2| (Updated target info) 407 // [246-249]-0x00000000 (Reserved - zeros) 408 // ----------------------------------------------------------------------- 409 // [250-261]- L"Domain" (Target Name Payload) 410 // [262-269]- L"User" (User Payload) 411 // [270-285]- L"COMPUTER" (Workstation Payload) 412 // 413 // NOTE: This is not identical to the message in [MS-NLMP] Section TODO(X) for 414 // several reasons. 415 // 416 // 1) The flags are different because this implementation does not support 417 // the flags related to version, key exchange, signing and sealing. These 418 // flags are not relevant to implementing the NTLM scheme in HTTP. 419 // 2) Since key exchange is not required nor supported, the session base key 420 // payload is not required nor present. 421 // 3) The specification allows payloads to be in any order. This (and the 422 // prior) implementation uses a different payload order than the example. 423 // 4) The version field is Windows specific and there is no provision for a 424 // non-Windows OS information. This message does not include a version field. 425 // 5) The example in the spec does not use Extended Protection for 426 // Authentication (EPA). This message includes an extra AV Pair containing 427 // the hashed channel bindings. 428 // 6) The example in the spec does not use Message Integrity Check (MIC). 429 // The optional field is not present, nor is the flags AV Pair that indicates 430 // it's presence. 431 // 7) Since the server does not provide a timestamp, the client should 432 // provide one. 433 inline constexpr uint8_t kExpectedAuthenticateMsgSpecResponseV2[] = { 434 'N', 'T', 'L', 'M', 'S', 'S', 'P', '\0', 0x03, 0x00, 0x00, 0x00, 435 0x18, 0x00, 0x18, 0x00, 0x58, 0x00, 0x00, 0x00, 0x8a, 0x00, 0x8a, 0x00, 436 0x70, 0x00, 0x00, 0x00, 0x0c, 0x00, 0x0c, 0x00, 0xfa, 0x00, 0x00, 0x00, 437 0x08, 0x00, 0x08, 0x00, 0x06, 0x01, 0x00, 0x00, 0x10, 0x00, 0x10, 0x00, 438 0x0e, 0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x58, 0x00, 0x00, 0x00, 439 0x03, 0x82, 0x08, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 440 0xf7, 0x36, 0x16, 0x33, 0xf0, 0xad, 0x9b, 0xdf, 0x4a, 0x7c, 0x42, 0x1b, 441 0xc6, 0xb8, 0x24, 0xa3, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 442 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 443 0x00, 0x00, 0x00, 0x00, 0x8c, 0x02, 0x60, 0xdb, 0xef, 0x69, 0x06, 0x62, 444 0xaf, 0x9c, 0x42, 0xd5, 0x07, 0x82, 0xd2, 0xed, 0x01, 0x01, 0x00, 0x00, 445 0x00, 0x00, 0x00, 0x00, 0x80, 0x0b, 0xc8, 0xfd, 0x00, 0xd4, 0xd2, 0x01, 446 0xaa, 0xaa, 0xaa, 0xaa, 0xaa, 0xaa, 0xaa, 0xaa, 0x00, 0x00, 0x00, 0x00, 447 0x02, 0x00, 0x0c, 0x00, 'D', 0x00, 'o', 0x00, 'm', 0x00, 'a', 0x00, 448 'i', 0x00, 'n', 0x00, 0x01, 0x00, 0x0c, 0x00, 'S', 0x00, 'e', 0x00, 449 'r', 0x00, 'v', 0x00, 'e', 0x00, 'r', 0x00, 0x06, 0x00, 0x04, 0x00, 450 0x02, 0x00, 0x00, 0x00, 0x0a, 0x00, 0x10, 0x00, 0x65, 0x86, 0xE9, 0x9D, 451 0x81, 0xC2, 0xFC, 0x98, 0x4E, 0x47, 0x17, 0x2F, 0xD4, 0xDD, 0x03, 0x10, 452 0x09, 0x00, 0x16, 0x00, 'H', 0x00, 'T', 0x00, 'T', 0x00, 'P', 0x00, 453 '/', 0x00, 'S', 0x00, 'e', 0x00, 'r', 0x00, 'v', 0x00, 'e', 0x00, 454 'r', 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 'D', 0x00, 455 'o', 0x00, 'm', 0x00, 'a', 0x00, 'i', 0x00, 'n', 0x00, 'U', 0x00, 456 's', 0x00, 'e', 0x00, 'r', 0x00, 'C', 0x00, 'O', 0x00, 'M', 0x00, 457 'P', 0x00, 'U', 0x00, 'T', 0x00, 'E', 0x00, 'R', 0x00, 458 }; 459 460 // Expected V2 Authenticate message from this implementation when sent 461 // |kChallengeMsgV1| as the challenge using default features. This scenario 462 // can occur because some older implementations (Windows 2003 and earlier), 463 // do not send NTLMSSP_NEGOTIATE_TARGET_INFO, nor a Target Info payload in 464 // the challenge message. 465 // 466 // [0-7] - "NTLMSSP\0" (Signature) 467 // [9-11] - |MessageType::kAuthenticate| (Message Type = 0x00000003) 468 // [12-19] - |SecBuf(88, kResponseLenV1)| (LM Response) 469 // [20-27] - |SecBuf(112, 106)| (NTLM Response) 470 // [28-35] - |SecBuf(218, 12)| (Target Name = L"Domain") 471 // [36-43] - |SecBuf(230, 8)| (User = L"User") 472 // [44-51] - |SecBuf(238, 16)| (Workstation = L"COMPUTER") 473 // [52-59] - |SecBuf(88, 0)| (Session Key (empty)) 474 // [60-63] - 0x00088203 (Flags) 475 // [64-71] - All zero (Version) 476 // [72-87] - (MIC) 477 // [88-111] - All zero (LM Response Payload) 478 // [112-217]-------------------------------------- (NTLM Response Payload) 479 // [112-127]- (NTLMv2 Proof) 480 // [128-155]-|kExpectedTempWithClientTimestampV2[0-27]| 481 // (Proof Input) 482 // [156-213]-|kExpectedTargetInfoSpecResponseV2[32-89]| 483 // (Updated target info) 484 // [214-217]-0x00000000 (Reserved - zeros) 485 // ----------------------------------------------------------------------- 486 // [218-229]- L"Domain" (Target Name Payload) 487 // [230-237]- L"User" (User Payload) 488 // [238-253]- L"COMPUTER" (Workstation Payload) 489 // 490 // NOTE: This is message is almost the same as 491 // |kExpectedAuthenticateMsgSpecResponseV2| with the following changes. 492 // 1) The target info within the NTLM response is missing the first 32 493 // bytes, which represent the 2 AvPairs that the server does not send in 494 // this case. 495 // 2) The NTLM Response security buffer length is reduced by 32 and therefore 496 // all subsequent security buffer offsets are reduced by 32. 497 // 3) The NTLMv2 Proof is different since the different target info changes 498 // the hash. 499 // 4) As with the NTLMv2 Proof, the MIC is different because the message is 500 // different. 501 inline constexpr uint8_t kExpectedAuthenticateMsgToOldV1ChallegeV2[] = { 502 'N', 'T', 'L', 'M', 'S', 'S', 'P', '\0', 0x03, 0x00, 0x00, 0x00, 503 0x18, 0x00, 0x18, 0x00, 0x58, 0x00, 0x00, 0x00, 0x6a, 0x00, 0x6a, 0x00, 504 0x70, 0x00, 0x00, 0x00, 0x0c, 0x00, 0x0c, 0x00, 0xda, 0x00, 0x00, 0x00, 505 0x08, 0x00, 0x08, 0x00, 0xe6, 0x00, 0x00, 0x00, 0x10, 0x00, 0x10, 0x00, 506 0xee, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x58, 0x00, 0x00, 0x00, 507 0x03, 0x82, 0x08, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 508 0x31, 0x37, 0xd6, 0x9e, 0x5c, 0xc8, 0x7d, 0x7a, 0x9f, 0x7c, 0xf4, 0x1a, 509 0x5a, 0x19, 0xdc, 0x25, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 510 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 511 0x00, 0x00, 0x00, 0x00, 0xbe, 0xd9, 0xa9, 0x42, 0x20, 0xc2, 0x25, 0x2b, 512 0x91, 0x6e, 0x9c, 0xe3, 0x9d, 0x97, 0x3a, 0x2d, 0x01, 0x01, 0x00, 0x00, 513 0x00, 0x00, 0x00, 0x00, 0x80, 0x0b, 0xc8, 0xfd, 0x00, 0xd4, 0xd2, 0x01, 514 0xaa, 0xaa, 0xaa, 0xaa, 0xaa, 0xaa, 0xaa, 0xaa, 0x00, 0x00, 0x00, 0x00, 515 0x06, 0x00, 0x04, 0x00, 0x02, 0x00, 0x00, 0x00, 0x0a, 0x00, 0x10, 0x00, 516 0x65, 0x86, 0xE9, 0x9D, 0x81, 0xC2, 0xFC, 0x98, 0x4E, 0x47, 0x17, 0x2F, 517 0xD4, 0xDD, 0x03, 0x10, 0x09, 0x00, 0x16, 0x00, 'H', 0x00, 'T', 0x00, 518 'T', 0x00, 'P', 0x00, '/', 0x00, 'S', 0x00, 'e', 0x00, 'r', 0x00, 519 'v', 0x00, 'e', 0x00, 'r', 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 520 0x00, 0x00, 'D', 0x00, 'o', 0x00, 'm', 0x00, 'a', 0x00, 'i', 0x00, 521 'n', 0x00, 'U', 0x00, 's', 0x00, 'e', 0x00, 'r', 0x00, 'C', 0x00, 522 'O', 0x00, 'M', 0x00, 'P', 0x00, 'U', 0x00, 'T', 0x00, 'E', 0x00, 523 'R', 0x00, 524 }; 525 526 // Expected V2 Authenticate message from this implementation when sent 527 // |kChallengeMsgFromSpecV2|, no channel bindings exist, and the remote 528 // server is named 'server' (with lowercase 's'). All the test data from the 529 // spec uses 'Server' with an uppercase 'S'. Chrome lower cases the hostname 530 // so this result vector is needed for an end to end test in 531 // |HttpNetworkTransactionUnitTest|. 532 // 533 // The response is the same as |kExpectedAuthenticateMsgSpecResponseV2| with 534 // the following differences. 535 // 536 // [72-87] - The MIC (hash of all messages) is different because the 537 // message is different. 538 // [112-127] - The cryptographic proof is different due to the changed 539 // AvPairs below, which are inputs to the hash. 540 // [225]- The 's' in the SPN AvPair is lowercase. 541 // [200-215] - The channel binding AvPair in the target info is all zero. See 542 // |kExpectedTargetInfoSpecResponseV2| for more information. 543 inline constexpr uint8_t kExpectedAuthenticateMsgEmptyChannelBindingsV2[] = { 544 'N', 'T', 'L', 'M', 'S', 'S', 'P', '\0', 0x03, 0x00, 0x00, 0x00, 545 0x18, 0x00, 0x18, 0x00, 0x58, 0x00, 0x00, 0x00, 0x8a, 0x00, 0x8a, 0x00, 546 0x70, 0x00, 0x00, 0x00, 0x0c, 0x00, 0x0c, 0x00, 0xfa, 0x00, 0x00, 0x00, 547 0x08, 0x00, 0x08, 0x00, 0x06, 0x01, 0x00, 0x00, 0x10, 0x00, 0x10, 0x00, 548 0x0e, 0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x58, 0x00, 0x00, 0x00, 549 0x03, 0x82, 0x08, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 550 0xa7, 0x37, 0x50, 0x69, 0x59, 0xfe, 0xea, 0x74, 0xaa, 0x77, 0xa1, 0xc0, 551 0x5b, 0xe2, 0x39, 0xa2, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 552 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 553 0x00, 0x00, 0x00, 0x00, 0xfe, 0x4d, 0xec, 0x67, 0xcf, 0x4d, 0xbd, 0xf8, 554 0xc7, 0xa7, 0x80, 0x89, 0xb1, 0xc5, 0x46, 0xa7, 0x01, 0x01, 0x00, 0x00, 555 0x00, 0x00, 0x00, 0x00, 0x80, 0x0b, 0xc8, 0xfd, 0x00, 0xd4, 0xd2, 0x01, 556 0xaa, 0xaa, 0xaa, 0xaa, 0xaa, 0xaa, 0xaa, 0xaa, 0x00, 0x00, 0x00, 0x00, 557 0x02, 0x00, 0x0c, 0x00, 'D', 0x00, 'o', 0x00, 'm', 0x00, 'a', 0x00, 558 'i', 0x00, 'n', 0x00, 0x01, 0x00, 0x0c, 0x00, 'S', 0x00, 'e', 0x00, 559 'r', 0x00, 'v', 0x00, 'e', 0x00, 'r', 0x00, 0x06, 0x00, 0x04, 0x00, 560 0x02, 0x00, 0x00, 0x00, 0x0a, 0x00, 0x10, 0x00, 0x00, 0x00, 0x00, 0x00, 561 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 562 0x09, 0x00, 0x16, 0x00, 'H', 0x00, 'T', 0x00, 'T', 0x00, 'P', 0x00, 563 '/', 0x00, 's', 0x00, 'e', 0x00, 'r', 0x00, 'v', 0x00, 'e', 0x00, 564 'r', 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 'D', 0x00, 565 'o', 0x00, 'm', 0x00, 'a', 0x00, 'i', 0x00, 'n', 0x00, 'U', 0x00, 566 's', 0x00, 'e', 0x00, 'r', 0x00, 'C', 0x00, 'O', 0x00, 'M', 0x00, 567 'P', 0x00, 'U', 0x00, 'T', 0x00, 'E', 0x00, 'R', 0x00, 568 }; 569 570 } // namespace net::ntlm::test 571 572 #endif // NET_NTLM_NTLM_TEST_DATA_H_ 573