Documentation for SecurityContext.step method gives confusing example about python-gssapi

[jborean93]

Thus according to the example I assumed that 'ctx.complete' should become 'True' immediately after the 1st call to SecurityContext.step().

At least for Kerberos auth it is not guaranteed for this to happen. If you specify mutual auth (like in your example) the context will only be complete once the responding token to authenticate the server has been processed. Other authentication mechanisms can have multiple iterations; NTLM is 3, 4 if wrapped in SPNEGO, token in total.

In any case the complete property is derived from the result of the GSSAPI call and not logic in python-gssapi.

Bottom line - I have put an additional check for 'context.complete' to the middle of the loop and did a 'break' to exit from the loop in the middle of the 2nd iteration (so output_token=None is not used by send_and_receive() ).

I agree, the example should be updated to check if output_token has a value and break the loop if it's not.

[jborean93]

Also just looking through the patch and I see

and we have 'An expected per-message token was not received' error (GSS_S_GAP_TOKEN).

Isn't this a sign that the messages are being processed out of order and the code should be updated to process them in order? I can't claim to understand the NFS side, or the code there but this just sounds wrong to me.

[kvv81]

Other authentication mechanisms can have multiple iterations; NTLM is 3, 4 if wrapped in SPNEGO, token in total.

You gave very interesting example I have never seen... I think you saw it with SMB + smbprotocol library authentication, didn't you (NTLM is not used with NFS4, this is Microsoft-only direction)?

Could you please advise how it can be reproduced? Should SMB server report only 'NEGOEX' mechanism in SMB NEGOTIATE response for this to happen? How it can be done (what configuration steps are needed to reproduce this)?

[kvv81]

Also just looking through the patch and I see

I'm very pleased you have reviewed the patch! I would be happy if you reviewed it and give some feedback.
Frankly speaking, I'm not very strong in Python (I write mostly on C++), and doing those changes was a required step for me
(nobody else knows a basics of GSSAPI).

Isn't this a sign that the messages are being processed out of order and the code should be updated to process them in order? I can't claim to understand the NFS side, or the code there but this just sounds wrong to me.

Yes, your're perfectly right - if GSS context (created by initator) uses sequence checking and we have out-of-order packets for some reason, GSS_S_GAP_TOKEN is the result we will see. However, NFS4 protocol is designed to be sequence-agnostic.
This chapter from rfc2203 (5.2.2. Context Creation Requests) can explain it better than me:

   When GSS_Init_sec_context() is called, the parameters
   replay_det_req_flag and sequence_req_flag must be turned off. The
   reasons for this are:

   *    ONC RPC can be used over unreliable transports and provides no
        layer to reliably re-assemble messages. Thus it is possible for
        gaps in message sequencing to occur, as well as out of order
        messages.

   *    RPC servers can be multi-threaded, and thus the order in which
        GSS-API messages are signed or wrapped can be different from the
        order in which the messages are verified or unwrapped, even if
        the requests are sent on reliable transports.

   *    To maximize convenience of implementation, the order in which an
        ONC RPC entity will verify the header and verify/unwrap the body
        of an RPC call or reply is left unspecified.

[jborean93]

You gave very interesting example I have never seen... I think you saw it with SMB + smbprotocol library authentication, didn't you (NTLM is not used with NFS4, this is Microsoft-only direction)?

Yea I mostly work in a Microsoft centric world so NTLM is unfortunately quite common. It's not surprising that NFS doesn't support NTLM and to be honest nothing should really support NTLM because it's an old and mostly insecure protocol.

Could you please advise how it can be reproduced? Should SMB server report only 'NEGOEX' mechanism in SMB NEGOTIATE response for this to happen? How it can be done (what configuration steps are needed to reproduce this)?

NEGOEX is a different protocol and it somewhat acts as a more advanced SPNEGO/Negotiate protocol. I've not really played around with it too much but from what I understand it's how PKU2U and CloudAP is negotiated in SPNEGO auth. I believe modern versions of GSSAPI (MIT and Heimdal) support Negoext through the SPNEGO mech but I've not really tested them to try them out. For SMB the server typically sends the mech list of mechanisms it supports in the negotiate phase which can include things like NTLM, Kerberos, Negoext, etc.

I'm not 100% sure what you need to reproduce it but simply send an SMB request on a Windows host and you will see the the first token in the negotiate response.

Ultimately this is all implemented in the GSSAPI provider and python-gssapi just acts as an interface to call this provider. It's mostly to demonstrate my point that you cannot expect step() to produce 1 token and 1 token only.

I would be happy if you reviewed it and give some feedback.

The code there seems fine to me, the only thing I really found was the out of sequence stuff but as you've mentioned this seems to be expected for NFS.

In the end if Kerberos is the protocol negotiated you should expect 2 tokens in total; 1 sent by the client and 2 received by the server that authenticates the server to the client. If you aren't requesting mutual auth (since you are signing and verifying you want mutual auth) then you would only expect the 1 token sent by the client. Other protocols can have an arbitrary amount of exchanges and their logic is entirely down to how it's implemented. I don't know enough about NFS to really give any more advice sorry.

Finally #266 adjusts the example to have the check on output_token. AFAIK if there is no output token you can assume the context is complete.

[kvv81]

Thank you very much for details and fix!