Large pac causes gss_accept_sec_context to fail

[Martijn de Gouw]

Hi,

On 14-10-2020 21:46, Greg Hudson wrote:
> On 10/14/20 2:24 PM, Martijn de Gouw wrote:
>> I've found a redhat article about
>> disabling pac data: https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Faccess.redhat.com%2Fsolutions%2F969123&data=02%7C01%7C%7C24b64a9b529a43211e6508d87079cf9c%7C612607c95af74e7f8976faf1ae77be60%7C0%7C0%7C637383015898191640&sdata=dZryZnj8pxkrb77aSeKJWJhsP4s9PrBBJ64zc0Q%2FXFM%3D&reserved=0.
> 
> I don't have access to read that, unfortunately.

You can create a free RHEL Developer Subscription. But it boils down to 
rpc.svcgssd being replaced by gssproxy, which handles the (very) large 
kerberos tickes much better. RH suggests to disable the PAC data so the 
tickets remain much smaller.

> 
>> The token is very big for those users (~7k). I did some tracing in the
>> krb5 library to see what really goes wrong here, since the error is not
>> very descriptive. I was able to dig down in
>> src/lib/krb5/asn.1/asn1_encode.c, where the token is decoded. There is a
>> lot of decode_atype() performed on the token, until finally omit_atype()
>> returns ASN1_MISSING_FIELD, called by get_tag() for a->type =
>> atype_sequence (embedded in a type atype_tagged_thing tag, I think?).
> 
> What kind of object is being decoded?  That is, in the stack trace, what
> is the entry point into the ASN.1 code?  It would have a name like
> decode_krb5_ap_req().

The entry point is:
krb5_gss_accept_sec_context_ext()
   kg_accept_krb5()
     decode_krb5_ap_req()
       k5_asn1_full_decode()
         decode_atype_to_ptr()

 From there is a hundreds of calls to get_tag() and decode_atype() and 
some decode_sequence().

> 
> In src/lib/krb5/asn.1/README.asn1 there is a section on debugging at the
> end.  It provides a (laborious) process for determining where an error
> like this is occurring within the ASN.1 type definition.
> 
>> Now I'm wondering is MS is really doing something wrong here, or krb5 is
>> unable to handle this PAC data. the 'net ads kerberos pac dump' does not
>> complain or show any errors when dumping PAC data for any user.
> 
> PAC data isn't encoded in ASN.1; the code to process it lives in
> src/lib/krb5/krb/pac.c.  The issue is likely in the surrounding Kerberos
> protocol object.  It could be a truncation issue as Simo hypothesizes,
> although I would expect that to normally yield a different error like
> ASN1_OVERRUN.
> 

It's a good pointer pointer indeed. I'm going to try to the check of the 
token is the same on both client and server as well.

Regards,
-- 
Martijn de Gouw
Designer
Prodrive Technologies
Mobile: +31 63 17 76 161
Phone:  +31 40 26 76 200