Improvements for AP-REP validation

[petrsnd]

Summary of changes:

• Expose ServiceTicketSessionKey and ClientSubSessionKey in ApplicationSessionContext while preserving existing functionality
• Try to decrypt AP-REP with all keys before failing
• Remove sequence number validation on decrypted AP-REP

What's the problem?

We are unable to implement a simple WinRM (HTTP/SOAP) connection setup using GSS-API Krb5 while simulating the WinRM protocol with Kerberos authentication. When selecting the Kerberos authentication option for Enter-PSSession, PowerShell uses Kerberos directly, not SPNEGO.

This change is to have Kerberos.NET make all keys available via the ApplicationSessionContext to validate GSS-API tokens. The observed behavior that we are following is that the AP-REP is validated with the service ticket session key, and then GSS Wrap/Unwrap uses the subkey returned from the server.

• Bugfix
• New Feature

What's the solution?

ApplicationSessionContext needs to keep track of sub session keys as well and try multiple options before giving up, in order to accommodate applications that may misbehave relative to common expectations and specifications.

ApplicationSessionContext should not try to validate that the sequence numbers match.

• Includes unit tests
• Requires manual test

The code in #398 can be used to manually test.

What issue is this related to, if any?

The issue is described in #398.

[SteveSyfuhs]

Sorry for not getting to this sooner. The build is back in place and things are moving again. I'm happy with this change. Is it ready to be completed?

[petrsnd]

Thanks for responding @SteveSyfuhs

I am ready to merge the code, but the DecryptedKrbApRep_Validate_Sequence unit test will fail unless we make a change.

Currently, the test is really only testing that sequence number validation is included in DecryptedKrbApRep.Validate(), but the validation logic doesn't match what we are seeing on the wire. Nor does it match what I read in RFC 1964.

The sequence number validation in the current unit test code is just comparing the sequence number values as generated by the local static method CreateResponseMessage(). The value that normally comes from the ApplicationSessionContext is always null and the value passed into creation method is always 123.

In practice, we have observed that the sequence numbers in the WinRM use case do not match. RFC 1934 1.1.1 says that the sequence numbers should be included in the AP-REQ Authenticator:

For purposes of this specification, the authenticator shall include the optional sequence number, and the checksum field shall be used to convey channel binding, service flags, and optional delegation information.

and that they will be returned and can be validated, but only in the context of previously received data (RFC 1934 1.2.1.2):

Replay detection can be performed using state information retained on received sequence numbers, interpreted in conjunction
with the security context on which they arrive.

The sender should increment its sequence number by one after sending (RFC 1934 1.2.1.2), but the spec doesn't say the sender and receiver should match. We have used this code against a current WinRM implementation, and it only works if we remove the current sequence number validation requirement.

For these reasons, I suggest we just delete the current sequence number validation code along with the unit test that requires it. I'll add a commit to make that change, and you can merge if you agree. Or, we can do something different if you prefer.

[SteveSyfuhs]

Yep, agree. Sequence number is slightly more annoying in practice than as implemented here.

[SteveSyfuhs]

Actually small change I made after this got merged. Sequence number does need some level of validation, but it's only checked when explicitly requested instead, plus with specific rules now.