Received-SPF: Pass (protection.outlook.com: domain of mit.edu designates
 18.9.1.100 as permitted sender) receiver=protection.outlook.com;
 client-ip=18.9.1.100; helo=mail.exchange.mit.edu;
Authentication-Results-Original: spf=pass (sender IP is 18.9.28.11)
 smtp.mailfrom=mit.edu; mit.edu; dkim=none (message not signed)
 header.d=none;mit.edu; dmarc=bestguesspass action=none
 header.from=mit.edu;compauth=pass reason=109
Received-SPF: Pass (protection.outlook.com: domain of mit.edu designates
 18.9.28.11 as permitted sender) receiver=protection.outlook.com;
 client-ip=18.9.28.11; helo=outgoing.mit.edu;
Subject: Re: 119100524000153 NegoEx alerts
To: Edgar Olougouna <edgaro@microsoft.com>
CC: "lukeh@padl.com" <lukeh@padl.com>, support
	<support@mail.support.microsoft.com>
References: <BL0PR2101MB09316491570FDAF40165ADD3C5990@BL0PR2101MB0931.namprd21.prod.outlook.com>
 <SN6PR2101MB13427C92A81157D0561D61F8DB9B0@SN6PR2101MB1342.namprd21.prod.outlook.com>
 <c4cfee07-88ac-1475-e019-05b407bc23eb@mit.edu>
 <SN6PR2101MB134210D8EF69D0218411549CDB930@SN6PR2101MB1342.namprd21.prod.outlook.com>
 <SN6PR2101MB13421BCBC309907BA38E3932DB6C0@SN6PR2101MB1342.namprd21.prod.outlook.com>
 <SN6PR2101MB134294FB1A85E7AF4424C829DB6B0@SN6PR2101MB1342.namprd21.prod.outlook.com>
From: Greg Hudson <ghudson@mit.edu>
Openpgp: preference=signencrypt
Autocrypt: addr=ghudson@mit.edu; keydata=
 xsFNBFLMQYIBEADZLNv8Jpeo2d4XSLE+k6m1VD2iOyX66wErZKaQpYrGB/leWKfz8l6c3pWd
 iVUnCoyxKlhRuGVArszdh2wUSRgHnMl86JC/vIdawdOdbnlTVfOJTiP3EfycsMUUDG6GckLY
 e+xxo7sM/bpXpGkbIWc0Ec/vbQt67eeW2En1AqL+ezJdVN9XL8icH2Hu6HlqxGgleC5H0yAi
 kM4yvNjo5z2M/Dr/x63bLcIdKkSRPzd0OaBg2g0Yh651eYpPu0e1Gi6785ZBjV4bnv3K5oLo
 5XsiHIZ60maHWTEyMO/byw4aS2cCWIovXurvz699KSF83B296+xhsFhhz4+kbQgXvJt4kIoI
 pdpX6xbIkeVlc+FuUbyE8MUGveA3TFHXZ4+0f2tvTekey/62FOeXnrqc4NsBViir3zGTXAqC
 7PQTNnX/86jyW+9SnJo9XbSBB3NV0K5I2o1cDzqRPqy/4fsoq8SxQwRga0CSId1PzE9PUEUY
 V0FCldo9LvPsUK9YE7AuwC+bcQiVLah5TF+5Kk7yLSaRxzQ3fI5lcqk5UPUqMLa87cRBdnal
 niuHVg0u3W22RMPkWe2iPIYYdr4TQDzCkD2JXpXNaZ3KipVT5aqowwfPEt7b6ti0vjrOInij
 YzFmVNMGKYabwh2zxKWQQ8GO5mUVu09CSe33H4EW7pDP+zHr2wARAQABzR1HcmVnIEh1ZHNv
 biA8Z2h1ZHNvbkBtaXQuZWR1PsLBeAQTAQIAIgUCUsxBggIbAwYLCQgHAwIGFQgCCQoLBBYC
 AwECHgECF4AACgkQDLoIV1+Dct8dZBAA1Mtoq1RPuUQg6hL2qFjwTEXeonWq8czkQ1fNNzO9
 x8I3VLn5L6CmWeAmxRU1DD0qZ5HL24+Mwnvy/eazp4/CSgiPC52KfbNsnQtg/E+8ruFQVHA/
 3HZXuCT/Nz4s06N3fMZrJLCGNEHRD0S43kb2GGboVY3ykO3FbPJB/DxDqtIMqt6B1SZ87UAR
 CVsRc296X3TsF9BgoQ/n54XfYAzrACkuIH9biHmH6wB1eykCeuhkCsu5Zf/tlSXJCFiuhvS+
 CX2EbNKF+0MLcGAavSzbjTnQw3kv8unSgecbEQ7A8ibGx6Jwgnvy0gzu6w4prhR40pVYDcL+
 sKsmQg6jo/uPvGdEqHISFSK8FxGGAonaAwg0014bXLaPo2MckcZ+szcHA/z4vpTdB1vChexL
 omM5ZTeSJaFfeYsspv8sq6EL1x21c7A+ngCmB70/OZR6dcgf9/ILmcjBiYfJHYukXTIvGT6y
 QJbok19So8RJKUYjzzHDKBweg8x6HdIrdy7HTcLzsqY9PFGg7/YlbLlGQwYXhK1b4uBmWyE7
 I/402+57I1YpMYND7vsTmJuE13Gv5ZGhYn5pSzX9ZTWY13LgGymkWBXPxfefkHKTV9ROCGEL
 t7SV3Nf7ZsCGLRGmDT6oqLz75/IrhKEcHIfD4ct+QvIm6pvPNvikQMwPWSd52GazILLOwU0E
 UsxBggEQAKaz/wX8nsSUaivmwW4NVlbmTsErHUt9iNHm9CmieuoDv1o8qUqEV6RiONIs0q5Y
 +dcooazhHRNpjAST2rbQFBZebfpVRKYAGzHoZEQ6OV8Eao+NjAGazS8RuwIxpeZ36r3AyVhe
 TAIvIzwpQFDNKTIUNbXctHrZ157TlxDuKwZ3+Yw/bhQE5YGrSLm17wIMcY3UHiE1mO5X0ohR
 dDeTf93PignUUvWvRRQLyxRGsBLz/CCwmCJZeu/FjnDk8HkEbAlmFAJ+YZu9rQ40vU6Z40KY
 L5U9PIn0FdSxviK7mys+VbFYV6mXWXZN8dOkHuG6zSdmobE90G6ZzAPcI4cyql63N+kUOb3b
 hGI/Wvn6tUbWeIc8UvQGpYb0+eOKHQBNKUOq5RV98hZorZRCu2W2RzZSxiufyONvtonbUtYs
 BMdw+gqUpK0ir782lc3cKbj+X5iiyg3ZGvBmTU6FN/MiX6MnTyEwOScFboKe6vB8ZgwII85K
 n9qlSI3xH56JBXamMP0yqJf57q0WfP8V7lFtm8SmhU2NQyP3wRYDm2+bLTNCmRPJN2ZUgkTx
 c/Qjov8TeeiTfX9S3ea/GJOdgA1mQfSkmUoOWROnwDBbKGBXNzkkoJna8j/zWgo/mQ5gNdIu
 HXcIdDKbyyhVH3+DwxXYWyYP/pnIk3AVCss75dXcdStfABEBAAHCwV8EGAECAAkFAlLMQYIC
 GwwACgkQDLoIV1+Dct+oSA/9HyTkr+UQbaucXE9pP87yasObKCBxYhoeRjzBhgtYUtSDuH2o
 xl5M3wmTNOooQSa8R1ljhax9v02pqspIA9hyGjGjvZ6jPydDsANNcohdbMjCzXNdrCF5149w
 gbGQ07rkc5JNyajzxH4GE/BXclTzwTYAaHvYM5PEQLDhmubK3M/kBvjWpZxLAJAobMi/jVwQ
 cmai+N56X9Ht/FVIQlmCuXoMAE9ScVWFaq8JnCo9VZ0G045NcxdEoQXVUXb3E5cmZ0Ld9sUm
 SKSJKjYWjfE4c/8oylZuo9LDTwozBEp/jsASjL0g8F3QJsQUkFkKROd45xHcIkFulshS3xkG
 gMu6UduV2ypPz987f+0wdVwx+KYnmnUB83gxqVucFRxfZZXiUHUml4rJ7Ww2+//H9FFPfw9f
 aPMg7nLFm2T0to3pwgyisLH/aThzW3TY7CZ7gkvMDtbo9EHrN4Nl3onuOtOKQpIMbFVqX4YZ
 m6znSLuUiWDUd8rvQfz+4ndZKIFOG1YIKwQBV8tN1RYBGY9bhv2Wtt5X6SKIzkUhDdgeyzci
 MC1M3N0Pqoqrms7FdBKAd0BE7puhQ24U42APss+Ur6WyRZMQTKc41SZWfrWV30agytUVdtRu
 gxERw74qeGAz6o3if42vI6u30SR6OCLMMSobqKc7HQvJ2qv3Z6j9kt1zXiE=
Message-ID: <4e18ba04-85be-ea47-faa3-84f1e2cb046f@mit.edu>
Date: Wed, 23 Oct 2019 11:44:44 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101
 Thunderbird/60.7.2
In-Reply-To: <SN6PR2101MB134294FB1A85E7AF4424C829DB6B0@SN6PR2101MB1342.namprd21.prod.outlook.com>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Microsoft-Antispam-Message-Info-Original:
 KZdjnY8/ygyfWkXWyDz00y9hBGifD8Ot91sbbxGmg1sJOvXfuNbCD7bIm7HK76Y/h9dZmMq2r//mBhDoG7VX5JViKLrC7FMcxide98jkUuCnjU/areVeQatAJ8aGuGs3fqXqCyJVy35gqYkchpgJtiYJEdh9/SGbi6SoHOK1TF3YcAluJznUXyvvdqZKMbByajSE4Q5V4fnM3Oh5L26WRsBd8KZrMjTw9TZVGB8qsNnKycWR5nEX21jKHl1thqtJUiH9ug8QGGN+AX4gyq4wjAJzmsJOHr7wxyXYPUi5rKMQpXOHICzKD7+D/w7Rpj93yZJc+UcTD0zA979UBG/50cmSGLgCT5xTggxZbEHB0tTe85Om2necepApMdqxjX33qrzkhdMgSca83rA2Ifh1I/yLNVby88w6y8O+adJ76itRe8iNwHj15oDUQqAs3lbYlA0NI+6LHziTQPL9C1c+rC2rQbePPX01B1KEnmD9nIkUAzFz3ryItoCc9gZ8cRqlb/+E18W0Cdiz6bsTtFRYYJkuPBq+a+PjVsPsRO78rWblUcfYV8l24cSCGBY1IvW1kqrmrMKjo9XQlezk9fT7xfHQJAZuMKxo+nXqEK9wcQT65dxNhdUok3drVHJ9jVeIEi8a6g0fcb2H6AdDVx/gLLX0T3q4xVLIdnUwyZLbBWJTk695w9IBeBnyIvWaL8Ju+XR74puekaKt28RZhcEN7VyUnZFBzTmZRmrmtq37eL9G4Xe4LdBPX82zdtDY6vh24zaKWlCbNg2HeEJKcpwFgM9n8zNXOxqoIgWnE1bJBYzUg1xIsmXkkhHL1a/4XCGg3tk6LxvIPgZBYZfl2IWYIlfG9tLwYAE/aIDpeIUFJp0=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR0102MB3573
X-OrganizationHeadersPreserved: DM5PR0102MB3573.prod.exchangelabs.com
X-CrossPremisesHeadersPromoted: oc11exhyb6.exchange.mit.edu
X-CrossPremisesHeadersFiltered: oc11exhyb6.exchange.mit.edu
X-OrganizationHeadersPreserved: oc11exhyb4.exchange.mit.edu
X-MS-Exchange-Organization-ExpirationStartTime: 23 Oct 2019 15:44:56.0821
 (UTC)
X-MS-Exchange-Organization-ExpirationStartTimeReason: OriginalSubmit
X-MS-Exchange-Organization-ExpirationInterval: 1:00:00:00.0000000
X-MS-Exchange-Organization-ExpirationIntervalReason: OriginalSubmit
X-MS-Exchange-Organization-Network-Message-Id:
 dc8ff991-01f3-4ffd-145d-08d757cff411
X-MS-Exchange-Organization-MessageDirectionality: Originating
X-MS-Exchange-Organization-SCL: -1
X-CrossPremisesHeadersPromoted:
 DM3NAM03FT015.eop-NAM03.prod.protection.outlook.com
X-CrossPremisesHeadersFiltered:
 DM3NAM03FT015.eop-NAM03.prod.protection.outlook.com
X-MS-Exchange-Transport-CrossTenantHeadersStripped:
 DM3NAM03FT015.eop-NAM03.prod.protection.outlook.com
X-Forefront-Antispam-Report: CIP:18.9.1.100;IPV:NLI;CTRY:US;EFV:NLI;;SKIP:1;
X-MS-Exchange-Organization-AuthSource:
 CO1NAM03FT037.eop-NAM03.prod.protection.outlook.com
X-MS-Exchange-Organization-AuthAs: Anonymous
X-OriginatorOrg: exchange.mit.edu
X-MS-Office365-Filtering-Correlation-Id-Prvs:
 3c0a881d-b6c6-4f05-1556-08d757cff1b5
X-Microsoft-Antispam: BCL:0;
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Oct 2019 15:44:55.9180
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: dc8ff991-01f3-4ffd-145d-08d757cff411
X-MS-Exchange-CrossTenant-Id: 64afd9ba-0ecf-4acf-bc36-935f6235ba8b
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=64afd9ba-0ecf-4acf-bc36-935f6235ba8b;Ip=[18.9.1.100];Helo=[mail.exchange.mit.edu]
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR01MB4512
X-MS-Exchange-Transport-EndToEndLatency: 00:00:01.2377662
X-MS-Exchange-Processed-By-BccFoldering: 15.20.2367.016
X-Microsoft-Antispam-Mailbox-Delivery:
	ucf:0;jmr:0;ex:0;auth:0;dest:I;ENG:(750127)(520011016)(944506383)(944626516);
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?OXF4QkczZWp5TUNSaGxDaFRtL0dabkZKZEtTbDFaVVNrRkh5YmRrQlU2V2Fx?=
 =?utf-8?B?V1IxZ3dyTGFTNjFaRktrZDI3eVVxdTJVVkRxYXhia2YwbFM0bytzVmFPUmg1?=
 =?utf-8?B?ZHZoeHlaNjAvK2NSWjdQR0puZGxuWmxlT1pqMDVMVVZMbWVuR0l6WHhxbWdN?=
 =?utf-8?B?TnA0U01iUVB4dmhLZjlzQUxYSG9GTW5iU3V1ZHlqam9ZWkFKZlBOTFV0RVhl?=
 =?utf-8?B?ZUFjUlIvV1k3QmhNZVJnREZTa0RNOERTZEZ0OXpoN0JZdC94MThLZndFRmJE?=
 =?utf-8?B?TmFZb2FkaURBaTZna2tGZXNoeTZmR2E4S3ZOUXpIYzNYR1Nxd1lROTljeG9u?=
 =?utf-8?B?VTdjbmZrTUxFZk1pcmd4bW9URkFoYkhMWTVIZGxuTTFqdlhkRXhxcnB5cVZl?=
 =?utf-8?B?UVcvYk4xMm9ZSXpxUkE0MmdKRWtuZmlDYkYzd0xqNXNPRHlKaHc1RlN5WWdv?=
 =?utf-8?B?ZVQvNFFvb0xZMzVpY0JneXNsK1RSazNkZjdIaFhZZVFQemlJRnQ1dDAwSXZv?=
 =?utf-8?B?MHcrWnhuN3djajdKZDZhdWdGa1ZEYXZKbGlxbHhHZnV3Rk50RlB5QjEwY1B3?=
 =?utf-8?B?SUg3TWpTaVNOdjUrVStxOGlXbFh4VzhabzBNRTRWaW5hQWkzNWNHc3k3WHZv?=
 =?utf-8?B?VVhvbDlZUXNFd1FoOTlJKys0QUVLMTJxMzF4a2E2TWk3OFpER0JCdzRNQ1Fh?=
 =?utf-8?B?WVMrNGZ3d0VONU9nOFpSbUZ4QVI1R0hhMCtTKy9kY2FNYXROMm9EVWRyZ1da?=
 =?utf-8?B?dDlvOGRWeGlnNENtbm1XY04yR2ZVOWNCUlZPcVF5NWNnV2pZWjdBQTRNSDFV?=
 =?utf-8?B?a21mdmhVK1h5M2hEZUhYZlQvZkhLeWdoSDU4aWJvS09CTmk3MU14Z3l1eHU1?=
 =?utf-8?B?Mm9TK0Z3TVBZcUdKWkxQT21CM1d5dmFJa0xnSkc4ZStpb2o3MElmQ09tRlAz?=
 =?utf-8?B?OE94aFl1elVESDI5Zktzc2RwZHBIOFpGdnRpME1zejNDL2pROU1wU2VlOHRH?=
 =?utf-8?B?aStncmZhSHNSM1ozSEQwaFgranNYcjJOMndRK3V1bE9JcjJjMldoNERYVDlo?=
 =?utf-8?B?WURvVE1kSm9RWGZzTWZHSUp5dTF4NXh6ME4ySTU5bG1oUGs2aGl5UlhlbzNP?=
 =?utf-8?B?M0dabGNxV0ltUmMxM09yTDRDekN5NHBzaWZqblhIbnAwQkV6TU9Tc2V4RVlV?=
 =?utf-8?B?WWQrUlBrWDQ5dWI4bDNPb2FSYmdRV2owR2sxS0JDMUo4b1FWdnoyNVFlU3py?=
 =?utf-8?B?cjBab28zZHRlc2FKa0FKT1FBYWFwRC9TQVN1NndCZGVIRFN5c3ZBRXFDU2tn?=
 =?utf-8?B?bnc1U0V4Y3JBZU5iNmV1Ylcwb3ZzTVFVTmpTd2RkbW9idW1wVW9tY3pRUGFh?=
 =?utf-8?B?anI4M0dteVIrclhZaWRZZFRqTWJaU1NWMEh3NG5VTmw4ZGxNTlhNUWl4OUh4?=
 =?utf-8?B?djAvTFpzZW40TlduOWtuekxUYjExN0hRdWFFc2VlakZOZW9ZbkhObFBPbUpE?=
 =?utf-8?B?dkJ5WVc2Vmg3bVdCdDNmK2RMK21RZjVWMkFkUjZqbHQ0ekdlSHVIMHlyNmJR?=
 =?utf-8?B?dGZXQWVDdkFyR1dxUys0bnRmenNTN2MyYm8rKzhUSE9HZlR2UlozdTlqQ0hF?=
 =?utf-8?Q?LM2a32k0k7rdB75ajQHrk32xR9Gnt3Mwu+mrvdXg8BP8=3D?=
MIME-Version: 1.0

Thank you for describing how alerts appear to be used in the code.  I do
have a remaining point of confusion.  You wrote "It also sends the alert
to the client indicating that it doesn���t have a completed session
security, which causes the client to resend a verify message on the
later leg."  Wouldn't the client send another verify message anyway?  In
our other thread, I asked if (when the mech makes keys available early)
the exchange goes AP_REQUEST/VERIFY, CHALLENGE/VERIFY,
AP_REQUEST/VERIFY, CHALLENGE/VERIFY, or just AP_REQUEST/VERIFY,
CHALLENGE/VERIFY, AP_REQUEST, CHALLENGE, and you said the exchange ends
with AP_REQUEST/VERIFY, CHALLENGE/VERIFY, implying that endpoints
continue sending verify messages with each mech token.

I do not believe NegoEx currently has any adoption outside of
Microsoft's Kerberos implementation.  I am currently revising an
implementation of NegoEx which Luke wrote in 2011, with the hope of
including it in an upcoming MIT krb5 release.  The primary motivation is
to enable interoperation with pku2u and with third-party SSPs which have
been written for Windows.  (My vague understanding is that Windows makes
it complicated for SSPs to be advertised directly under SPNEGO, so they
tend to be negotiated via NegoEx.)

On 10/23/19 11:25 AM, Edgar Olougouna wrote:
> Greg,
> We cannot be entirely certain of the intended purpose of this alert message type, as the expired Internet Draft is the only document, I could find on this. And as you noticed, the document does not have any narrative text on the topic, nor any defined processing logic. 
> After conversing with some of our security developers, and reviewing the source code, it looks like the alert message happens if a NegoEx package on one peer thinks it���s done and has a session key while the other side disagrees. We are not entirely clear on whether this can happen with any authentication protocol we have under NegoEx.
> It appears the basic logic is that the client sends what it thinks is a final authentication message, and thinking that it is done it also sends the verify message.  The server, however, has some correctable error, such as a time skew, and replies to the client with an error asking the client to retry.  It also sends the alert to the client indicating that it doesn���t have a completed session security, which causes the client to resend a verify message on the later leg.
> The authors of this expired draft have all moved on to pasture new, albeit inside Microsoft. Some of our security developers do not have a glorious assessment of NegoEx design, it might be hard to get folks onboard to get any work done regarding the draft.
> In any case, out of curiosity, are you aware of any process to submit an amendment to an IETF internet draft? Would it be like creating a new version of the draft? 
> What is the real status of this NegoEx protocol in the field in general? I don���t know whether we have any data on the adoption of the NegoEx regarding how prevalent it is amongst non-Windows implementations of authentication packages.  
> Maybe you could start a conversation by emailing the authors of the draft and take it from there. The email addresses are available here: https://datatracker.ietf.org/doc/draft-zhu-negoex/
> 
> Regards,
> Edgar
> 
> -----Original Message-----
> From: Edgar Olougouna 
> Sent: Friday, October 18, 2019 2:59 PM
> To: Greg Hudson <ghudson@mit.edu>
> Cc: lukeh@padl.com; support <support@mail.support.microsoft.com>
> Subject: RE: 119100524000153 NegoEx alerts
> 
> Greg,
> I am still working on this. Thank you for your patience.
> 
> Regards,
> Edgar 
> 
> -----Original Message-----
> From: Edgar Olougouna 
> Sent: Tuesday, October 15, 2019 10:35 AM
> To: Greg Hudson <ghudson@mit.edu>
> Cc: lukeh@padl.com; support <support@mail.support.microsoft.com>
> Subject: RE: 119100524000153 NegoEx alerts
> 
> Greg,
> Thank you for these additional questions on VERIFY. I am investigating the ALERT related question as well. I will follow-up soon.
> 
> Regards,
> Edgar 
> 
> -----Original Message-----
> From: Greg Hudson <ghudson@mit.edu> 
> Sent: Tuesday, October 15, 2019 9:41 AM
> To: Edgar Olougouna <edgaro@microsoft.com>
> Cc: lukeh@padl.com; support <support@mail.support.microsoft.com>
> Subject: Re: 119100524000153 NegoEx alerts
> 
> I have some additional questions about NegoEx, pertaining to VERIFY messages.
> 
> * Can a VERIFY message be included in the first initiator NegoEx token, if the generation of the optimistic mech token makes a NegoEx key available?
> 
> * Can a VERIFY message be included the first acceptor NegoEx token, if the optimistic mech token is successfully accepted and makes a NegoEx key available?
> 
> * Once a VERIFY message is generated by either side, are additional VERIFY messages constructed as further NegoEx tokens are created, or is only one sent?  Does it matter if the first VERIFY message was generated for the optimistic mech, if a different mech winds up being negotiated?
> 
> Also, if the optimistic mech is one-legged (meaning, like krb5 without mutual auth, the whole mechanism protocol is just a single initiator token), how can the initiator determine on its second step whether its optimistic token was accepted or ignored by the acceptor?
> 
> On 10/7/19 1:17 PM, Edgar Olougouna wrote:
>> Greg,
>>
>> I will be researching this and will follow-up soon.
>>
>> Regards,
>> Edgar
>>
>> -----Original Message-----
>> From: Sreekanth Nadendla <srenaden@microsoft.com>
>> Sent: Friday, October 4, 2019 10:21 PM
>> To: Greg Hudson <ghudson@mit.edu>
>> Cc: lukeh@padl.com; support <support@mail.support.microsoft.com>
>> Subject: 119100524000153 NegoEx alerts
>>
>> Dochelp in Bcc
>> Casemail in Cc
>>
>> Hi Greg,
>> Thank you for your inquiry about Microsoft Open Specifications. We have created an incident for investigating this issue. One of the Open specifications team member will contact you shortly.
>>
>> Regards,
>> Sreekanth Nadendla
>> Microsoft Windows Open Specifications
>>
>> -----Original Message-----
>> From: Greg Hudson <ghudson@mit.edu>
>> Sent: Friday, October 4, 2019 10:18 PM
>> To: Interoperability Documentation Help <dochelp@microsoft.com>
>> Cc: lukeh@padl.com
>> Subject: NegoEx alerts
>>
>> Is there any Microsoft documentation of NegoEx, apart from
>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-zhu-negoex-04&amp;data=02%7C01%7Cedgaro%40microsoft.com%7Cb9ce8fcddf074754808408d7517dbf41%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637067472837783982&amp;sdata=jgUjKHRdmqXaqVumMPpYGCPeSnhEzxSvxXVcfUEmBeE%3D&amp;reserved=0 ?
>>
>> In that document, there are several definitions related to "alerts":
>>
>> * MESSAGE_TYPE_ALERT in the MESSAGE_TYPE enumeration
>> * The ALERT structure
>> * The ALERT_TYPE_PULSE define
>> * The ALERT_VERIFY_NO_KEY define
>> * The ALERT_PULSE structure
>> * The ALERT_VECTOR structure
>> * The ALERT_MESSAGE structure
>>
>> However, those definitions aren't used anywhere in the narrative text of the document; there are no references to "alert", "pulse", or "verify_no_key" outside of the definitions.  Does Microsoft's NegoEx implementation make any use of alerts, or are those definitions vestigial?
>>
>> Thanks.
>>