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

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Michael B Allen-4
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/[hidden email]
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 [hidden email] from IPv4:192.168.2.16 \
        for krbtgt/[hidden email] [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 `[hidden email]'
  Server is `test/[hidden email]'
  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
Reply | Threaded
Open this post in threaded view
|

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

Rogier Krieger
Suffice it to say that I do not have all the answers :)

On 10/8/05, Michael B Allen <[hidden email]> wrote:
> 6) What is Vno in the ktutil list output?

The kvno (key version number) increases with every password/key
change. You'll probably want to make sure your keytabs keep the
correct key and kvno when talking to the KDC. Otherwise, things are
likely out of sync.


> 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.

The keytab is primarily for automated purposes of authentication. Such
as servers or services that need to authenticate themselves or deal
with session keys dealt out by the KDC. This is one of the reasons why
you should keep that file in a secure location (and be careful about
its backups).


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

To prevent such guessing, you have the option of deploying
pre-authentication. In that way, the KDC only sends out a TGT to users
that provide proof of their identity with the request. Usually, this
means that the client sends along a timestamp encrypted with the
principal's secret key, which the KDC kan decrypt for verification (as
it has that key on record).

Once the pre-authentication data is succesfully decrypted, the KDC
sends out a TGT. This is a Kerberos 5 feature; it's not present in
Kerberos 4. You can a the pre-authentication attribute to your
principals or mandate it for your realm in the configuration file.

Hope this helps,

Rogier

--
If you don't know where you're going, any road will get you there.

Reply | Threaded
Open this post in threaded view
|

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

Love Hörnquist Åstrand
In reply to this post by Michael B Allen-4

Michael B Allen <[hidden email]> 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/[hidden email]
> 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 [hidden email] from IPv4:192.168.2.16 \
>         for krbtgt/[hidden email] [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 `[hidden email]'
>   Server is `test/[hidden email]'
>   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


attachment0 (487 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

ronnie sahlberg
In reply to this post by Michael B Allen-4


On 10/8/05, Michael B Allen <[hidden email]> wrote:
...
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)?

This was a bug in early windows implementations. Their ASN library were limited so that it could only use 16 bit oid componnets.

So  the real value(113554) was truncated to 16 bits and became  48018.

The old buggy value is still accepted by ms as to provide compatibility with hosts that are not patched yet.


I.e.   they are the same.