[OpenAFS-devel] Corrupted ticket sent in rx packet from Windows 1.3.7700

Douglas E. Engert deengert@anl.gov
Tue, 18 Jan 2005 14:20:11 -0600


This fails on Unix too.

Using a modified aklog with OpenAFS 1.3.74 on Solaris 9.
I can get bos to fail with trying to use a large ticket
where the ticket size is 1421. According to Ethereal
the last 61 bytes of the ticket are sent in a RX Response as zeros.
The UDP fragmentation is different, as the MTU is different,
and the corrupted bytes start in the first fragment.
But it still comes down to the fist 1416 bytes of the response
are valid, which looks like it is related to the RX buffer size,
and the comment below in rx_packet.h below.


The above was done using a different account as the test below.
But in both casess its the corruption is after 1416 of header
and ticket.



Douglas E. Engert wrote:
> This may be a problem in RX with large tickets. It may fail on Unix
> as well. My test AD account is now a member of 50 groups, which produces
> a ticket that is large enough to reproduce the problem.
> 
> rx_packet.h says:
> 
>    226  #define RX_JUMBOBUFFERSIZE 1412
>    227  #define RX_JUMBOHEADERSIZE 4
>    228  /*
>    229   * RX_FIRSTBUFFERSIZE must be larger than the largest ack packet,
>    230   * the largest possible challenge or response packet.
>    231   * Both Firstbuffersize and cbuffersize must be integral 
> multiples of 8,
>    232   * so the security header and trailer stuff works for 
> rxkad_crypt.  yuck.
>    233   */
>    234  #define RX_FIRSTBUFFERSIZE (RX_JUMBOBUFFERSIZE+RX_JUMBOHEADERSIZE)
>    235  /*
> 
> This says a response can not be larger then 1416 bytes. But the RX response
> being sent is 1501 bytes (56 bytes header + 1445 ticket) with the first
> 1416 bytes valid, and the last 85 being corrupt.
> 
> Its not clear why the restriction, or why it is not being enforced 
> correctly.
> 
> 
> 
> Douglas E. Engert wrote:
> 
>> One user has been having problems with OpenAFS 1.3.7700 on Windows 2K.
>>
>>
>> Using Ethereal and tracing the KRB5 TGS_REP as it arrives, and the
>> RX response as it is sent shows that the last 85 bytes of the ticket
>> are corrupted somewhere in KfW or OpenAFS.
>>
>> The Ticket len as reported by Ethereal in the RX packet is 1445 bytes
>> long, the first 1360 bytes of the ticket are valid.
>>
>> So far we only have one trace, with one user, bu the user has
>> failed on more then one machine. We are attempting to get
>> a second user with a large ticket, Windows 2003 is the KDC,
>> so we need to create a user with a bigger PAC.
>>
>> Some circumventions appear to be to install the AD NOPAC hotfix,
>> use aklog -m or gssklog.  All of which reduce the size of the ticket
>> but don't fix the underlying problem.
>>
>> At first we thought it might be a UDP fragmentation problem,
>> but we have traces with a ticket of size 1277 that fragments
>> but works correctly and is not corrupted.
>>
>> The user had problems prior to 1.3.7700 too.
>>
>> Any ideas?
>>
>>
>>
>>
>>
>>
>>
>>
> 

-- 

  Douglas E. Engert  <DEEngert@anl.gov>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444