[krbdev.mit.edu #8851] NegoEx

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

[krbdev.mit.edu #8851] NegoEx

Jeffrey Arbuckle via RT

Thu Nov 21 22:52:18 2019: Request 8851 was acted upon.
 Transaction: Ticket created by [hidden email]
       Queue: krb5
     Subject: NegoEx
       Owner: Nobody
  Requestors: [hidden email]
      Status: open
 Ticket <URL: https://krbdev.mit.edu/rt/Ticket/Display.html?id=8851 >


draft-zhu-negoex describes the NegoEx protocol. I am attaching a conversation
with Microsoft dochelp where some of the protocol details are clarified.

In this conversation, it appears to be stated that endpoints will continue
sending a VERIFY message along with each AP_REQUEST or CHALLENGE, but
empirically this does not seem to be the case, so our implementation will stop
at one VERIFY message from each endpoint under normal circumstances.



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 <[hidden email]>
Sent: Friday, October 4, 2019 10:18 PM
To: Interoperability Documentation Help <[hidden email]>
Cc: [hidden email]
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%7Csrenaden%40microsoft.com%7Cf82adc0b8f1a49a0486708d7493a4df5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637058387075198756&amp;sdata=PJgjKyGtWSyO%2BYhcqFQzab%2BQjBMJ3ZeACRMjeNsmWWY%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.

Is there any Microsoft documentation of NegoEx, apart from
https://tools.ietf.org/html/draft-zhu-negoex-04 ?

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.

Greg,

I will be researching this and will follow-up soon.

Regards,
Edgar

-----Original Message-----
From: Sreekanth Nadendla <[hidden email]>
Sent: Friday, October 4, 2019 10:21 PM
To: Greg Hudson <[hidden email]>
Cc: [hidden email]; support <[hidden email]>
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 <[hidden email]>
Sent: Friday, October 4, 2019 10:18 PM
To: Interoperability Documentation Help <[hidden email]>
Cc: [hidden email]
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%7C845e994f88d84184960208d7494310d3%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637058424704003544&amp;sdata=ure2%2F6CCUKQc98C68tQMFTjdJkbUPl6%2FYKGQdUfZvFk%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.

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 <[hidden email]>
Sent: Tuesday, October 15, 2019 9:41 AM
To: Edgar Olougouna <[hidden email]>
Cc: [hidden email]; support <[hidden email]>
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 <[hidden email]>
> Sent: Friday, October 4, 2019 10:21 PM
> To: Greg Hudson <[hidden email]>
> Cc: [hidden email]; support <[hidden email]>
> 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 <[hidden email]>
> Sent: Friday, October 4, 2019 10:18 PM
> To: Interoperability Documentation Help <[hidden email]>
> Cc: [hidden email]
> 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.
>

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 <[hidden email]>
Cc: [hidden email]; support <[hidden email]>
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 <[hidden email]>
Sent: Tuesday, October 15, 2019 9:41 AM
To: Edgar Olougouna <[hidden email]>
Cc: [hidden email]; support <[hidden email]>
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 <[hidden email]>
> Sent: Friday, October 4, 2019 10:21 PM
> To: Greg Hudson <[hidden email]>
> Cc: [hidden email]; support <[hidden email]>
> 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 <[hidden email]>
> Sent: Friday, October 4, 2019 10:18 PM
> To: Interoperability Documentation Help <[hidden email]>
> Cc: [hidden email]
> 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.
>

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 <[hidden email]>
Cc: [hidden email]; support <[hidden email]>
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 <[hidden email]>
Cc: [hidden email]; support <[hidden email]>
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 <[hidden email]>
Sent: Tuesday, October 15, 2019 9:41 AM
To: Edgar Olougouna <[hidden email]>
Cc: [hidden email]; support <[hidden email]>
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 <[hidden email]>
> Sent: Friday, October 4, 2019 10:21 PM
> To: Greg Hudson <[hidden email]>
> Cc: [hidden email]; support <[hidden email]>
> 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 <[hidden email]>
> Sent: Friday, October 4, 2019 10:18 PM
> To: Interoperability Documentation Help <[hidden email]>
> Cc: [hidden email]
> 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.
>

Your observation is correct. The client will send another verify message as soon as a key is readily available. In theory, it could be the next leg, or a subsequent or final leg.

Thanks,
Edgar

-----Original Message-----
From: Greg Hudson <[hidden email]>
Sent: Wednesday, October 23, 2019 11:45 AM
To: Edgar Olougouna <[hidden email]>
Cc: [hidden email]; support <[hidden email]>
Subject: Re: 119100524000153 NegoEx alerts

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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdata
> tracker.ietf.org%2Fdoc%2Fdraft-zhu-negoex%2F&amp;data=02%7C01%7Cedgaro
> %40microsoft.com%7Ca53c37453ca142e878f208d757cff067%7C72f988bf86f141af
> 91ab2d7cd011db47%7C1%7C0%7C637074422918709990&amp;sdata=5zyt%2FEnuDix3
> vs%2F5ffOS3H8zY4pRenpAvLGxNlP19W8%3D&amp;reserved=0
>
> Regards,
> Edgar
>
> -----Original Message-----
> From: Edgar Olougouna
> Sent: Friday, October 18, 2019 2:59 PM
> To: Greg Hudson <[hidden email]>
> Cc: [hidden email]; support <[hidden email]>
> 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 <[hidden email]>
> Cc: [hidden email]; support <[hidden email]>
> 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 <[hidden email]>
> Sent: Tuesday, October 15, 2019 9:41 AM
> To: Edgar Olougouna <[hidden email]>
> Cc: [hidden email]; support <[hidden email]>
> 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 <[hidden email]>
>> Sent: Friday, October 4, 2019 10:21 PM
>> To: Greg Hudson <[hidden email]>
>> Cc: [hidden email]; support <[hidden email]>
>> 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 <[hidden email]>
>> Sent: Friday, October 4, 2019 10:18 PM
>> To: Interoperability Documentation Help <[hidden email]>
>> Cc: [hidden email]
>> 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%7Ca53c37453ca142e878f208d757cff067%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637074422918709990&amp;sdata=yqfGxtUVLqykUJv4bQdny85zI94TPB50PF%2BWasrTiDk%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.
>>

Thanks. I will engage folks internally to evaluate how we can update the draft or assess any other possibility of documentation.

Cheers,

Edgar

 

From: Luke Howard <[hidden email]>
Sent: Wednesday, October 23, 2019 8:14 PM
To: Greg Hudson <[hidden email]>
Cc: Edgar Olougouna <[hidden email]>; support <[hidden email]>
Subject: Re: 119100524000153 NegoEx alerts

 

 

On 24 Oct 2019, at 2:44 am, Greg Hudson <[hidden email]> wrote:

 

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.)

 

Yes, from Windows 8, it’s not possible for an SSP to advertise as both SPNEGO and NegoEx, and also there are some limitations to advertising it under SPNEGO (you need to place it in front of NTLM for example). So it can be useful from an interop perspective.

 

Cheers,

Luke



_______________________________________________
krb5-bugs mailing list
[hidden email]
https://mailman.mit.edu/mailman/listinfo/krb5-bugs