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

[Michael B Allen <mba2000@ioplex.com>]

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?

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.

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?

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?

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)?

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.

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.

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?

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?

Thanks,
Mike