Re: SPNEGO, gssapi examples, keytab, cracking passwords, ...

[Love Hörnquist Åstrand <lha@kth.se>]

Michael B Allen <mba2000@ioplex.com> writes:

> I'm playing around with GSSAPI, trying to understand it and kerberos in
> anticipation of implementing client side SMB extended security / SPNEGO,
> and I have been accumulating newbie questions. Rather than bombard the
> list with 10 separate messages I'm sending them all-in-one. If anyone
> can help with any of them I'd appreciate it. Here they are:
>
> 1) Is the gssapi_server supposed to communicate with the KDC? I see it
> opens /etc/krb5.keytab. I assume it's getting the test/machine@FOO.NET
> service principal secret key from there directly? I don't need to run
> 'kinit test/quark.foo.net' or something?

It doesn't need to talk to the KDC.

> 2) When I run the gssapi_{client,server} example it seems like it's
> working (it get's through the token exchange) but, from looking at
> Ethereal captures, something is always trying and failing to get a
> forwardable krbtgt ticket:
>
>     2005-10-06T23:38:07 TGS-REQ miallen@FOO.NET from IPv4:192.168.2.16 \
>         for krbtgt/FOO.NET@FOO.NET [forwarded, forwardable]
>     2005-10-06T23:38:07 Bad request for forwardable ticket
>     2005-10-06T23:38:07 sending 119 bytes to IPv4:192.168.2.16
>
> Why?
>
> I'm doing everything on the same host BTW.

GSS-API thinks it needs to get a forwardable ticket (because the delegation
flag is set) and forward it, but the TGT isn't forwardable so the request
failes. Maybe the client should ignore to do a request if the TGT isn't
forwardable.


> 3) What is the status of SPNEGO support? I tried the
> gssapi_{client,server} with -m spnego and gss_indicate_mechs claims it's
> supported but the gss_server output reports Kerberos 5 was used:
>
>   # /home/miallen/tmp/heimdal-0.7.1/appl/test/gssapi_server 
>   Using mech: Kerberos 5
>   User is `miallen@FOO.NET'
>   Server is `test/quark.foo.net@FOO.NET'
>   gss_verify_mic: hej
>   gss_unwrap: hemligt INT
>   gss_unwrap: hemligt CONF
>
> I suspect this just means that SPNEGO was used to negotiate a mechanism
> and that ultimately Kerberos 5 was chosen and used to actually
> authenticate?

Yes, SPNEGO doesn't show up after the negitation is done, the negotiated
mech replaces SPNEGO.

> 4) Is there any interest in adding NTLMSSP support to the gssapi
> implementation or would the Heimdal overseers sneer at the impurity of
> NTLM cruft in what is really a Kerberos product?

When mech-glue code is imported, I see no problem inn added NTLMSSP.

> 5) What is the difference between Kerberos 5 (1.2.840.113554.1.2.2) and
> Microsoft Kerberos 5 (1.2.840.48018.1.2.2)? Is it just the authorization
> data (PAC)?

I think that microsoft getting the oid wrong. Not to be confused with the
u2u oid.

> 6) What is Vno in the ktutil list output? I noticed that the first time
> I added the "test" principal it was 1 whereas after deleting it and
> re-adding it (so that I could set a non-random password) it became 0.

I think this is a bug in kadmin/libkadm5 somewhere that causes the kvno to
be 0, that bad. change the password once and it will be 1 as it should be.

> 7) Is there a good document that describes how principals are to be
> managed? I'm confused as to what principals need to be exported to
> the keytab. Is it just service principals that need to be exported to
> the keytab? For some reason I get the feeling user principals are less
> important.

Server princial needs to be exported to a keytab, its also possible to feed
the kerberos functions a password for a service, but that is never used.

> 8) If a ticket is encrypted with the principal's secret key, then
> couldn't I get a ticket for any user and do an offline dictionary attack
> on the password?

The returned initial ticket is encrypted with the user's secret key, so
yes, its offline attackable. Use good password and force users to have good
parserwords with a password policy. Or use PK-INIT.

> 9) From appl/test/gssapi_client.c
>
>     148     input_chan_bindings.acceptor_addrtype = GSS_C_AF_INET;
>     149     input_chan_bindings.acceptor_address.length = 4;
>     150     acct_buf[0] = (remote.sin_addr.s_addr >> 24) & 0xFF;
>     151     acct_buf[1] = (remote.sin_addr.s_addr >> 16) & 0xFF;
>     152     acct_buf[2] = (remote.sin_addr.s_addr >>  8) & 0xFF;
>     153     acct_buf[3] = (remote.sin_addr.s_addr >>  0) & 0xFF;
>     154     input_chan_bindings.acceptor_address.value = acct_buf;
>
> If sin_addr.s_addr is always network byte order but the above explicit
> BE encoding routine assumes the value is host byte order. Is this wrong?

Very good question, right now I can't find the reference for this.

Love

PGP signature