Kerberos packets appear to be larger

[Greg Hudson]

On 08/08/2013 01:41 AM, Jeremy Hunt wrote:
> I can produce a snoop trace of both from my DEV environment, in fact I
> have the 1.11 already. Do you want a PDML export, a txt export, the raw
> snoop file or any other format?
> Do you mind if I just send it to you rather than the list.

[Jeremy sent me PDML files privately.]  PDML files seem kind of
inconvenient since I can't import them into wireshark.  Raw pcap files
which I can import into wireshark are preferable, but for now I was able
to (with some effort) read the PDML by hand, so there's no need to
re-send them.  It looks like the expansion you're seeing breaks down
into 109 additional bytes of padata and 72 bytes in the encrypted part
of the ticket.

The padata is larger because we always send explicit salts in 1.11.x.
We don't have a way to turn off explicit salts, but there are some other
ways to reduce the amount of padata sent.  Using a v4 salt on the client
long-term key is one of them; you appear to have tried this, but only in
the configuration files.  You will have to actually regenerate the
client key for this to have an effect.  Note that using the v4 salt type
on multiple principals makes it easier to conduct an offline dictionary
attack against many principals at once.

The other way is to allow the client to request one of the AES enctypes
in its AS request; this causes the KDC to only send a PA-ETYPE-INFO2
field and no PA-ETYPE-INFO or PA-PW-SALT field (because any client new
enough to understand AES is new enough to understand PA-ETYPE-INFO2).
Even without using the v4 salt type, this should cut the padata field
back down to around 50 bytes.  It doesn't matter if the client would
actually use an AES reply key or session key, only that an AES enctype
appears in the request.

The packet dumps don't show the encrypted part of the ticket (this would
require configuring Wireshark with a keytab containing the service key,
which in this case is the TGT key).  But 72 bytes happens to be the size
of the AD-SIGNEDPATH authdata element we added in 1.8.  We also don't
have a way to turn this off, although we're planning to add one in 1.12.
 However, this element should already be reflected in your 1.8
deployment.  Is it possible that you modified the 1.8 code to remove
AD-SIGNEDPATH?  If so, you'll need to modify the 1.11.x code as well.