Kerberos and "forwarded" TGS-REQ -- help!
Derrick
In my desperation I believe I've read every Krb5 MIT doc, and source
but I cannot put two and two together to get my answer.
My situation is that I am building a client Kerberos authentication
subsystem for an application that will speak "Microsoft CIFS." I am
speaking to a remote server that is asking for "User to User"
authentication within its CIFS "extended security" blob. I know I
need a) a service ticket to talk to that server and b) a forwarded
ticket to allow that server to work on behalf of me. A typical
windows 2000 client works against this device just fine. So I know it
can be done :-)
Secondly, I have my service ticket and can talk to all kinds of
servers that do not require "User to User" authentication (just
standard stuff). I know of two ways to get a forwarded TGS:
krb5_fwd_tgt_creds() - which I cannot find any documentation on
except a one line comment in the krb5 sources. Yet the etheral trace
yields similar information when compared to a windows 2000 client
asking for the same stff.
get_credentials() - using a "KRB5_GC_USER_USER" defined constant.
This one works too, sometimes, depending on what arguments I pass it
:-)
Which should I really use? I've had much more luck with the first
one, because the second one expects me to have a cred->second_ticket
assigned to the data structure. I can put my original service ticket
in there, but I'm not sure that's what I am really supposed to do, and
I haven't found anyone else that has had this same problem. So I'm
working with the fwd_tgt_creds() option because I do not receive as
many errors from the function call. :-)
This returns to me a krb5_data * object which I presume is a
forwardable ticket (at least Ethereal seems to show the request going
out and a reply coming back).
Now, I need to some how get that krb5_data (my forwarded ticket) into
a request that I can put in a CIFS "Session setup." My instints say
that krb5_mk_req_extended() should be used to do this, which is the
function call I use to send my standard service ticket to a remote
host (win2000 for example). However when I attempted this I received
the BADMSG error (probably because the krb_data * returned from the
fwd_tgt_cred() is not formatted as an AP-RESP or something?).
My disconnect is trying to figure out where I should be putting my new
forwardable ticket, and where I should put my original service ticket.
When watching a trace from a Windows 2000 client I seem to see that
the ticket data within the SessionSetup is 2000 bytes rather then
roughly 1000 bytes (which would explain service ticket (1,188 bytes or
so) + forwarded ticket (1088 bytes or so). However the bulk of that
data seems to be in the "authenticator data" field of the ethereal
trace.
Is there any krb5 calls I need to make (or better understand) to merge
my two tickets into one "blob" and generate an AP-REQ to forward off
to my "User to User" CIFS server?
Thanks again for any help you may provide.
DS
Sam Hartman
all about, understand what forwarded tickets are all about and
understand the difference between them. You should then understand
how to get the second_ticket (which should be a tgt given to you by
the remote service) from your particular application protocol.
Please look at sections 2.9.2 and 3.3.3 of
draft-ietf-krb-wg-kerberos-clarifications-06.txtfor a description of
how u2u works.
There is a long expired draft describing the u2u GSSAPI mechanism
Microsoft uses. I don't have a copy of that, but if you can find one
it might help you a lot. One incredibly bad recommendation from that
draft is to use the error return from the KDC to determine whether you
should use user2user or normal service tickets. Don't do that;
instead use the mechanism negotiatied by SSPI or by SPNEGO to
determine this.
Forwarded tickets are also described in the Kerberos clarifications
draft.
--Sam
________________________________________________
Kerberos mailing list Kerb...@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
Derrick Schommer
RFC's, drafts, second drafts, third drafts, and technical documents.
I'm almost there, the hard part is done.
Just an FYI: The issue was the GSS-API checksum value (0x8003) and the
authenticator (which I didn't know how to populate, but recently
understand how this gets populated with mk_req_ext())
Thanks again!
Derrick