[krbdev.mit.edu #1278] No prompter interface for krb5_get_init_creds_keytab
kenh at cmf.nrl.navy.mil
Tue Dec 17 14:55:01 EST 2002
>>> 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
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
More information about the krbdev