1

I use GSS API to authenticate myself with the SMB 2.0 server using Kerberos authentication (gss_init_sec_context call). I know that I can renew TGT using kinit -R command. But I want to be able to renew my service ticket obtained as well.

In the protocol spec it says the client needs to renew the kerberos tickets..

Is it possible to renew service ticket? or should I create a new context?

Any pointers about this related to SMB 2.0 reauthentication using GSS api are also really welcome

zapstar
  • 489
  • 2
  • 9
  • 21
  • from this page [link](http://technet.microsoft.com/en-us/library/bb742516.aspx) I know that service ticket can be renewed (See section - Understanding Kerberos concepts, in that sub section Client/Server Exchange). But i want to know if I can do something via GSS API or unix shell (like kinit). BTW I'm using MIT Kerberos. – zapstar Aug 28 '13 at 18:35

1 Answers1

1

Does the service ticket contain a RENEWABLE flag?

You cannot renew any tickets with the GSS-API. This must be done with the mechanism below by other means. GSS-API is too high-level, it actually does not know anything about the underlying mech -- in this case Kerberos -- technique.

This shouldn't bother you actually, as long a service ticket is cached in the CC, the API will/should reuse it with new context. Since SMB is session-based, you must have a new GSS context for that.

If you stil want to tamper with the mechanics below, study this site. Though I would not recommed this.

Michael-O
  • 18,123
  • 6
  • 55
  • 121
  • I'm getting confused. You are saying to request for a renewable service ticket and also saying to establish a new context using GSS API. Is there a way to tell GSS API to establish a new context and renew a service ticket if necessary and not create a new one? Yes I do see a RENEWABLE flag in the TGS-REQ, here's the wireshark capture. Please let me know if u want any more information. [dump](http://sdrv.ms/17mvSB6). – zapstar Aug 28 '13 at 18:48
  • ok got it! I was confused with GSS API. read a bit more about it and finally helped me out after reading stuff from you as well.. Thanks a bunch! But do give me suggestions if any from the wireshark capture! – zapstar Aug 28 '13 at 19:50
  • Is it now clear why you cannot renew the ticket with GSS-API only? – Michael-O Aug 28 '13 at 20:19
  • I use kinit -R to renew my TGT. For the service ticket to be renewed I just remove my old context and create a new context via GSS API? According to your explanation I conclude that Kerberos will take care of renewing the service ticket if it is cached. Note that the service ticket would have expired.. – zapstar Aug 29 '13 at 05:03
  • But as you can see in the dump after I receive session expired response from the server, while I'm trying to reauthenticate GSS API automatically sends a TGS-REQ, but does not renew the ticket (Does not set this is a renew request). What to do? – zapstar Aug 29 '13 at 05:24
  • First, I read the dump files and they seem fine. I See AS-REQ/REP and TGS-REQ/REP. This is normal behavior. You should always creae a new context when you create a new SMB or TCP session. Yes, Kerberos must act with the renewal and GSS-API does not care how this has to happen. I am sorry, but I do not see any session expired in the dump file but only session success. As a side note, disable as DES ciphers. They are not secure anymore. – Michael-O Aug 29 '13 at 06:40
  • We're in the dev env of SMB protocol (implementation), so we're not so concerned with security. The creation of new context seems to be helping me.. – zapstar Aug 29 '13 at 07:54
  • 1
    I do not talk about SMB but about Kerberos. DES cipher can be forged (easily). You should know that a GSS context is not thread-safe. It's best to create a new one, which is quite cheap, imho. – Michael-O Aug 29 '13 at 08:24