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