Kerberos packets appear to be larger

[Jeremy Hunt]

Thanks Greg that was a fantastic and detailed analysis.

Sorry about the pdml files, I sent them because I liked the format, I 
will send a raw format if I have to again.

You have answered more questions, than I asked. So I only have one more.

 From what you say, I presume any of these configuration fields in the 
krb5.conf field
         default_tkt_enctypes
         default_tgs_enctypes
         permitted_enctypes
         kdc_req_checksum_type
         ap_req_checksum_type
         safe_checksum_type
would only have an affect once the key was regenerated. Is that correct?

If so it explains some of these fields having an effect in earlier 
testing but not now. In earlier testing I tested with brand new 
principals. Now I am testing with an existing 'testing' principal, with 
an existing key, which needs a key change to have an effect. So if my 
assumption in the last paragraph is correct we can reduce the size of 
the data packets, but only if the principal's key with them in the 
configuration file is regenerated. That is fantastic! Especially if 
changing the password is sufficient. But I can test for that.

I agree with your comments about v4 and salts. I was investigating being 
able to reduce the size of the packets. I noticed the extra salts and 
thought that was proof that none of these fields affected the size of 
the packets used in the kerberos protocol. Earlier, I was more 
interested in changing the checksum type as a safer change, and that is 
sufficient for my purposes.

Your comments on the AD-SIGNED-PATH field are of use too.

Thank you again,

Jeremy

Greg Hudson wrote:
> 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.
>
> ________________________________________________
> Kerberos mailing listKerberos at mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos