[krbdev.mit.edu #1278] No prompter interface for krb5_get_init_creds_keytab

[kenh@cmf.nrl.navy.mil via RT]

>>> I need to use a host key in a keytab (hence keytab) as a user's
>>> long-term key with a hardware token (user interaction).  
>
>Why do you need to do this?  When, in the real world, would this ever
>happen?

Actually, this is something we do every day here; we want the ability to
validate someone's hardware token for root access via sudo.  We used the
old API before, and I was updating everything to the new API.  It's not
like I was making this up, you know :-)  This is all tied up in the
requirement for hardware preauthentication at DOD supercomputer sites.

>>> This is to implement Matt Crawford's hw-auth draft.  Okay, so
>>> technically I don't need a keytab interface, but there's no way to
>>> give the API a raw key and provide a prompter interface, and that's
>>> the real deficiency.
>
>You haven't convinced me there's a deficiency here.

Well, let's turn this around a bit; is there a reason NOT to implement
this?  Okay, I understand the generic argument of additional API calls
increasing Kerberos programming complexity (it's complex enough as is),
and I can accept that in a generic sense ... but it seems like, in
hindsight, that if we were designing this API today, I would argue that
leaving the possibility of having a prompter callback in this function
(when doing so would be trivially simple) could only be a possible
win.  And I don't really see how to implement this without an API
change somewhere; it's either this, or implement something like
krb5_get_init_creds_skey.

--Ken