krb5-1.8-alpha1 and enc-padata

[Greg Hudson]

On Tue, 2010-02-02 at 17:18 -0500, Marcus Watts wrote:
> It seems that when the kdc generates a krb5_enc_kdc_rep_part,
> it includes an empty enc_padata list.  This is sent over
> the wire as such.  MIT krb5 1.6.3 code apparently ignores this.
> Clients that implement rfc 4120 more strictly may instead
> complain.

I see two big problems here:

1. return_enc_padata can generate an empty list, and does so on the
AS-REQ path against pre-1.8 clients most of the time.  The effect here,
as Marcus noted, is to generate bogus ASN.1 encodings in response to RFC
4120 clients.

2. In the TGS-req path, we call kdc_handle_protected_negotiation twice
in the case where the response is a referral (once in return_enc_padata
and once explicitly), instead of once if it's a referral and once if
it's not.  The main effect here is that we aren't doing FAST negotiation
on the TGS path in most cases.

(1) demonstrates the danger of creating hackish flow control instead of
proper designs when extending existing code.  The old code to return
referral padata wasn't great, but it wasn't awful.  When extended to
return FAST negotiation data as well, it became awful and buggy.

I should have noticed (2) when I was reindenting Sam's code, but I
apparently didn't understand it well enough.

Luckily, we have a month to fix both problems before 1.8.  Thanks very
much for uncovering this.