The fate of krb5_auth_con_setivector/getivector

[Greg Hudson]

A very long time ago, before ivectors were generalized into cipher
states, there were three APIs:

    krb5_auth_con_initivector(context, auth_context)
    krb5_auth_con_setivector(context, auth_context, pointer)
    krb5_auth_con_getivector(context, auth_context, out_pointer)

The "ivector" referenced here is used by krb5_mk_priv; if set, the
cipher state is chained from message to message.
krb5_auth_con_initivector still a public API, which is used by
kprop/kpropd and probably not much else.

krb5_auth_con_setivector/getivector didn't survive the 1.3 API prune, so
are not technically public APIs in MIT krb5.  They are exported by
libkrb5 but not prototyped.  krb5_auth_con_setivector causes two
problems for the implementation:

* The caller doesn't indicate the length of the cipher state it wants to
  use.  Up until now the implementation assumes you want the block size
  of the session key enctype, which is broken for RC4.  One can make a
  better guess by creating and discarding a cipher state, which is my
  workaround for the moment.

* The caller's memory is aliased into the auth context.  As a result (or
  just due to oversight), the ivector isn't freed when the auth context
  is destroyed, so krb5_auth_con_init -> krb5_auth_con_initivector ->
  krb5_auth_con_free leaks memory.  We could use a flag to keep track of
  whether the cipher state memory is owned by the auth context; for the
  moment I'm just ignoring the memory leak.

My preference is to make krb5_auth_con_setivector and _getivector return
EINVAL in 1.12.  Does anyone have objections?