Enctype handling in client preauth2 system

[Sam Hartman]

I'm implementing the encrypted challenge fast factor and I've run into
what I believe is broken behavior in the client's handling of enctypes in the preauth loops spread between get_in_tkt.c and preauth2.c.

Here's what happens today.
krb5_get_init_creds  has a local variable called etype that is initialized to 0.
It's passed into krb5_do_preauth  as a pointer.

There, it is updated whenever a etype_info or etype_info2 is found.
You would expect to find one of these both in a KDC preauth_required
error or in a as reply.  In an as reply, you'd expect only one entry,
and you'd hope that entry corresponded to whatever the AS reply was
actually encrypted in.

This etype is passed into the internal preauth systems, but not into
the plugins.

The client_get_data procedure (a callback passed into plugins) has an
option to get the etype that the as reply is actually encrypted in.
It has no option to get the etype variable set by the etype-info2.

Now, it's reasonable to assume in the as-reply case that these two
etypes will be the same: if not, all sorts of stuff will break and you
probably will not be able to decrypt the AS reply.  Also, to get into
that situation the KDC has to violate RFC 4120.  However in the error
case you want access to the etype_info2 so you know which client key
to use.


I propose to make the following changes:

* Change the existing client_get_data call to return the etype tracked
  based on etype-info2 rather than the AS reply etype, so that it is
  useful in the error case.

* Initialize the etype variable to the AS reply etype when we get the
  AS reply.  That way, if you have no etype-info2 (which might happen
  for pkinit), it works correctly.

--Sam