mirror/naiveproxy
1
0
Fork 0
mirror of https://github.com/klzgrad/naiveproxy.git synced 2024-12-01 01:36:09 +03:00
Code Issues Projects Releases Wiki Activity
e4396ddd79
naiveproxy/net/ntlm/ntlm_test_data.h
klzgrad e45b4af2be Import chromium-68.0.3440.106
2018-08-11 05:35:24 +00:00

576 lines
32 KiB
C++
Raw Blame History

// 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_
Reference in New Issue View Git Blame Copy Permalink