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

[Ken Hornstein]

>Now I think I understand.  You're just using the keytab because it's
>convenient, not because you have some requirement to authenticate as
>the specific key in the keytab.  You're also trying to avoid making
>the user type his password again, even though the user will have to do
>the hardware preauth interaction.

Right, exactly.  Well, it's a _bit_ more complex than that.  Sam explained
it fairly well in his message, but the problem is that the host key is
taking the place of the user's long-term key.  So that needs to make it
into the library ... but you can't feed a raw key into
krb5_get_init_creds_password(), and krb5_get_init_creds_keytab() doesn't
take a prompter, and so on ... I thought about something along the lines
of krb5_get_init_creds_skey(), but the problem with THAT is that you want
to be able to pass in multiple keys to match whatever the KDC sends back,
and designing an API for that seemed more work than I wanted to tackle
(and I wasn't sure it was the right answer).

>For that matter, isn't the hardware token specific to the user?  Can
>you use an arbitrary user's hardware token with the key in the keytab?
>How do you know which token is being used, since the client name in
>the as-req is goint to be the name from the keytab?

Well ... since you asked ...

What I did was write a half-assed implementation of a memory keytab,
just enough to make krb5_get_init_creds_keytab() work.  I then read out
all of the host keys out of the on-disk keytab and placed them into the
memory keytab, but with the user's principal as the principal name in
the keytab entry.  Seems to work alright.  And before anyone mentions ...
yes, I know that I had to use a private API to register a new keytab
type, but it seems like the right solution there is to write a "real"
memory keytab type (since it's the only way to feed in a key to calls
like krb5_rd_req()).

--Ken