I see no challenge from the proxy for authentication in the trace you sent. The only Kerberos traffic I see is a TGT for Realm: LABRISTEST.COM issued to test1.
If the proxy were enforcing authentication, I would expect a trace with "StatusCode: 407, Proxy authentication required" returned by proxy. See http://technet.microsoft.com/en-us/library/bb984870.aspx for example of a likely trace where proxy requires auth.
I dont see any NTLM or Kerberos based auth to the proxy.
The client will only request tickets if it has to (i.e. proxy says auth required). Until then it does not know what tickets to request and tries anonymously. So you should see a ticket request after accessing proxy anonymously. And that too, only if there is no cached ticket locally at the client side. Its also possible that despite no ticket locally cached, you see no request because of a negative cache (cached the fact that previous request for ticket failed).
I also note you are not using IE (UserAgent: Mozilla/5.0 (Windows NT 6.1; rv:8.0) Gecko/20100101 Firefox/8.0) for testing this. I suggest you use IE for testing unless you are certain firefox is configured to respond to auth requests correctly.
Update (16th Jan):
You should always flush DNS cache (ipconfig /flushdns) and kerberos cache before collecting traces. This allows seen KDC detection related DNS traffic and kerberos ticket requests success/failure.
Its also important to know how you configure the proxy settings in the browser as this has some say in the tickets requested. The proxy port appears to be 3128 and the name is labris-1. So, you will likely need to register http/labris-1:3128 and http/labris-1.labristest.com:3128 SPN on the AD object used by the proxy service. You also need to add the reg key from http://support.microsoft.com/default.aspx?scid=kb;EN-US;908209 for all IE greater than V6. Make sure the keytab is updated and accessible on the squid server.