[3710] in Kerberos-V5-bugs
Re: [krbdev.mit.edu #1278] No prompter interface for krb5_get_init_creds_keytab
daemon@ATHENA.MIT.EDU (kenh@cmf.nrl.navy.mil via RT)
Tue Dec 17 14:55:51 2002
Message-Id: <rt-1278-3790.11.1041951131024@krbdev.mit.edu>
In-Reply-To: <rt-1278@krbdev.mit.edu>
From: "kenh@cmf.nrl.navy.mil via RT" <rt-comment@krbdev.mit.edu>
Reply-To: rt-comment@krbdev.mit.edu
To: krb5-prs@mit.edu
Errors-To: krb5-bugs-admin@mit.edu
Date: Tue, 17 Dec 2002 14:54:43 -0500 (EST)
>>> 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
_______________________________________________
krb5-bugs mailing list
krb5-bugs@mit.edu
http://mailman.mit.edu/mailman/listinfo/krb5-bugs
