GSSAPI support

[DMHP]

Hi antiduh, I'm following this in the github. In kerberos we have some steps like 1. Client requesting the TGT from KDC 2. Client getting the TGT 3.Client requesting SGT from KDC by using TGT, to access specific service 4. Client getting the SGT 5. Send SGT to resource server 6. Access the resource. Can you please tell me how do you handle the 3rd and 4th steps in the github.com/antiduh/nsspi/blob/master/TestClient/ClientForm.cs. Thanks.:)

[antiduh]

The SSPI API exposes this through the authentication cycle. Keep in mind that SSPI is supposed to be provider agnostic - the calling code doesn't need to know whether it's working with NTLM tokens, kerberos tokens, or some other system's tokens.

The authentication cycle assumes that you already have access to some sort of credential - in Kerberos's case, the credential would be the ticket granting ticket (TGT).

So, on the client side, I get a handle to my user's TGT - which was created when the user logged on. On the server side, the service gets a handle to the TGT of whatever principle it's running on, which was created when the service started.

From there, the authentication cycle begins.

On the client side, there are three pieces of data involved in the authentication cycle.

• The token we last received from the server.
• The status of the client's half of the authentication cycle.
• The token that we are to transmit to the server so that the server may progress its half of the authentication cycle.

Note that the client usually starts, and so, on the first invocation we provide null for the server's previous token.

On the server side, there are the same three pieces of data:

• The token we last received from the client.
• The status of the client's half of the authentication cycle.
• The token that we are to transmit to the client so that the client may progress its half of the authentication cycle.

So the authentication cycle usually progresses as follows:

• The client invokes InitializeSecurityContext (ISC for short), providing null for the previous token from the server.
• ISC outputs the token to write to the server ('the output token'), and returns status 'Continue'.
• The client transmits his output token to the server.
• The server takes the received client token, and provides it as input to AcceptSecurityContext (ASC for short).
• ASC outputs the token to write to the client, and returns status 'Continue'.
• The client receives the servers token.
• The client invokes ISC, providing the received token.
• ISC returns a new token to output to the server, and returns status 'Continue'.
• Client transmits the token to the server.
• Server receives token from the client
• Server calls ASC, providing the received client token as input.
• ...

Depending on how much the two sides need to talk, there could be many iterations of the above cycle. Eventually, one side will return a status 'OK'. That means that, from that side's perspective, it has everything it needs. However, it will still have a token to write to the other side.

So the above could continue in one of the two following manners:

• The client calls ISC with the token received from the server.
• ISC outputs a token to write to the server and returns status 'OK'. The client is satisfied with its half of the authentication cycle, but we still have a token to write to the server.
• The client writes the token to the server.
• The server calls ASC with the token received from the client.
• ASC outputs null and returns status 'OK'.
• The authentication cycle is complete.

or

• Server receives token from the client
• Server calls ASC, providing the received client token as input.
• ASC outputs a token to write to the client and returns status 'OK'. The server is satisfied with its half of the authentication cycle, but we still have a token to write to the client.
• The server writes the token to the client.
• The client calls ISC with the received token.
• ISC outputs null and returns status 'OK'.
• The authentication cycle is complete.

In short: If ISC or ASC returns a token, then you have to write that to the other side, regardless of what status ISC or ASC return.

So how does kerberos fit into this design?

Well, the client doesn't have to specify the principle name of the server he wants to connect to; it's an optional parameter to the ClientContext class. So how would the client find out who the server is in order to get SGT from the KDC?

Well, you ask him.

So:

• The first time the client invokes ISC, it returns a token that is sent to the server asking him to identify himself.
• The server takes that token, calls ASC with it, and ASC returns a token that provides a response.
• The client takes that response, calls ISC.
• Now that the client's SSPI API knows what server it's talking to, it behind the scenes talks to the KDC to ask for the SGT.
• The client's call to ISC returns a token containing the SGT.
• The client sends the token containing the SGT to the server.
• The server calls ASC with that token containing the SGT
• The server now has proof the client is who he says he is, and authentication succeeds.
• The server's call to ASC returns a token indicating success.
• The server sends that token to the client.
• The client calls ISC with that token indicating success.
• ISC outputs no token and returns status 'OK'.
• Done.

That process may be more or less complicated, depending on circumstances and parameters. If you use the negotiate package, then the first couple tokens to be exchanged between the client and server will be queries about what security packages they support, and which is the most secure package that they both have. After they settle on the security package, the tokens will be about exchanging principle information and then finally tickets.

You can also initialize the ClientContext with a parameter indicating the principle name of the service to connect to - in which case, the client can probably skip a few steps, contact the KDC before sending a single packet, and be done in one or two packets.

However, please keep in mind that the SSPI API uses a custom protocol - it carries kerberos tickets in its payload, but it is not simply the kerberos protocol itself, or at least, you should not assume it is.

From the caller's perspective, it's an opaque protocol: you receive a packet, call the function, get an output packet, send it to the other side .. they receive a packet, call a function, get an output to send back ... and so on until the cycle is complete.

So far we've discussed the SSPI API - which is a win32 API, and is not my software. the InitializeSecurityContext win32 function is wrapped by my ClientContext.Init() method, and AcceptSecurityContext by my ServerContext.Init() method.

To answer your direct question: we start the cycle in the ClientForm when the user clicks the connect button:

    private void connectButton_Click( object sender, EventArgs e )
    {
        if( string.IsNullOrWhiteSpace( this.serverTextBox.Text ) )
        {
            MessageBox.Show( "Please enter a server to connect to" );
        }
        else
        {
            try
            {
                this.connection.StartClient( this.serverTextBox.Text, (int)this.portNumeric.Value );
                this.initializing = true;
                // ###############################
                DoInit();
                // ###############################

We call the DoInit() function the first time when the button is clicked. That performs the first call to InitializeSecurityContext and then using our own little toy custom protocol, we send the token to the server:

    private void DoInit()
    {
        SecurityStatus status;
        byte[] outToken;

        status = this.context.Init( this.lastServerToken, out outToken );

        if( status == SecurityStatus.ContinueNeeded )
        {
            Message message = new Message( ProtocolOp.ClientToken, outToken );
            this.connection.Send( message );
        }
        else if( status == SecurityStatus.OK )
        {
            this.lastServerToken = null;
            this.initializing = false;
            this.connected = true;
            UpdateButtons();
        }
    }

When we receive a packet back from the server, we'll look at what kind of packet it is, and if it's an authentication cycle packet, we'll call DoInit() again:

   private void connection_Received( Message message )
    {
        this.Invoke( (Action)delegate()
        {
            if( message.Operation == ProtocolOp.ServerToken )
            {
                if( initializing )
                {
                    // ###############################
                    this.lastServerToken = message.Data;
                    DoInit();
                    // ###############################                    
    }

Hopefully, that answers your question.

Please keep in mind the TestClient and TestServer are meant to be demo projects - not production code. Please think twice before copy-and-pasting the code.

Additionally, keep in mind that the SSPI API just gives you bytes to transmit, and its up to you to decide how to transmit those bytes.

If you look in the NSspi project, there's a Program.cs file that shows how to perform the authentication cycle locally, with the client and server running in the same process. The tokens are 'transmitted' by in memory - we just directly call the next function with the bytes returned from the previous function.

[antiduh]

Please let me know if the above comment answers your question, and if so, I'll close this issue.

[DMHP]

Thanks antiduh for the detailed explanation. I got it now. I'm just following your implementation to get an idea about how SSPI works as I have to develop a C#.net client to consume one of our server's (java) kerberos secured rest proxy with Active Directory as the KDC. Please close the issue.

[antiduh]

Does it implement GSSAPI? In that case, you can use the SSPI API to perform authentication, which means with some modifications you would be able to use Nsspi to implement it.

The following page outlines how to invoke the SSPI API to be compatible with GSSAPI:

https://msdn.microsoft.com/en-us/library/windows/desktop/aa380496(v=vs.85).aspx

If you modified nsspi to take those changes into account, it should work.

[DMHP]

Yes. The requirement is to implement it using GSSAPI. So as I'm developing the client in .NET I can use SSPI, that means some modifications to Nsspi as you said as the client and I can directly use GSSAPI in java server side for this communication flow. Do we need to consider SPNEGO spec [1] separately with our implementation or GSSAPI and SSPI covers that spec too?

[1] https://tools.ietf.org/html/rfc4559

[antiduh]

Yeah, that sounds like it should work, so long as Microsoft's claim to be GSSAPI compatible is true.

Note, when you go digging through the nsspi code, you're going to run across Constrained Execution Regions (CERs). I've had to manually implement them because the SSPI handle isn't compatible with .Net's SafeHandle class, which normally handles a lot of magic for you in a very concise way.

I have a fairly verbose blog article that provides a ground up explanation of CERs, why they're necessary etc.

Start here: https://antiduh.com/blog/?q=node/4

[DMHP]

Thanks antiduh. I will follow the things and will start the implementation. :)

[DMHP]

Hi antiduh,
I'm facing a problem here. I used Nsspi dll and created two C# console apps as client and server and it was working fine. But when I'm using the same C# client with java server, the server is accepting the TGT and creates the server token. But when generating the SGT in client side it fails.I mean when the client calls to the Init method for the second time it causes to an exception. Do you have any idea why this is happening. Thanks.

[antiduh]

I'm not sure how much I'm going to be able to help here. My only advice would be to read the Win32 SSPI documentation thoroughly, dig into what the errors mean, and make sure you follow the above MSDN article on GSSAPI interoperability to the letter.

[DMHP]

Hi, what will be the reason for getting this "The specified principle is not known in the authentication system." error in nsspi. I got it when I'm validating the server token which I got from server side after accepting the TGT of the client. Do you have any idea?

[antiduh]

It probably means that the client doesn't recognize the servers principle name (SPN). If I recall that documentation correctly, you need to perform translation of some of the received tokens before passing to InitializeSecurityContext because Microsoft's kerberos implementation doesn't understand some SPN formats.

[DMHP]

Hi antiduh,
I could implement my use case to communicate the C# client (SSPI based) and Java server (GSSAPI based). Thank you very much for the support provided. :)

[antiduh]

That's really good news, I'm glad you were able to get it to work. SSPI can be a right pain in the neck sometimes.

Would you be willing to contribute back your code? You don't have to (my license says you can do whatever you want with my code and your code), but I'd like to save folks in the future the trouble of reimplementing it themselves.

[DMHP]

Yes antiduh, Sure. I will contribute my code. I have a tight schedule till 1st July. Will contribute the code ASAP. thanks