1

When performing a DTLS handshake using the SChannel SSPI in Windows 10 - for which there is no documentation - how should the application handle a SEC_I_MESSAGE_FRAGMENT result from AcceptSecurityContext (ASC) or InitializeSecurityContext (ISC)?

I understand that I am meant to send the recieved fragment to the other party and call ASC/ISC again to obtain the next fragment, but when I call ASC again, this time with an empty input SECBUFFER_TOKEN, I receive nothing in the output token buffer, and it returns SEC_I_MESSAGE_FRAGMENT - suggesting it is expecting input data.

Presumably I am not successfully indicating to ASC that I want it to give me the next fragment, so how do I do this?

I have created a standalone example that reproduces my issue in this GitHub gist: https://gist.github.com/haddoncd/381c5e9542e977ca238ff16229bd9a0e

I have also included in the gist example output from the program which shows in detail the inputs that lead to the issue: https://gist.github.com/haddoncd/381c5e9542e977ca238ff16229bd9a0e#file-example_output-txt

Haddon CD.
  • 158
  • 6
  • I suggest that you handle it as if you received a SEC_E_INCOMPLETE_MESSAGE, they look very similar. – SoronelHaetir May 10 '21 at 16:01
  • @SoronelHaetir - As I understand it, SEC_E_INCOMPLETE_MESSAGE is used to indicate that the input message was incomplete, and that more data must be read from the other party before continuing. The meaning of SEC_I_MESSAGE_FRAGMENT is almost the opposite - there's more data to be obtained from ASC/ISC without needing to read from the socket, because it has produced output that does not fit in a single datagram, and so has fragmented it, returning only the first fragment. – Haddon CD. May 10 '21 at 16:32

0 Answers0