Project review: GSS credential store extensions

[Sam Hartman]

>>>>> "Greg" == Greg Hudson <ghudson at MIT.EDU> writes:

    Greg> On 07/12/2012 01:53 PM, Sam Hartman wrote:
    >> If it helps people with API names and stuff, I'm going to argue Moonshot
    >> should use this for initial credential aquizition.
    >> In particular I think we'll want to support:
    Greg> [...]

    Greg> Will the application typically know what sorts of stuff it needs to
    Greg> provide before it starts to acquire creds and initiate a security context?
In the case where this is used, yes.

    Greg> In the krb5 world, you have to make an AS request and get a
    Greg> preauth-required error before you know what questions to ask the user.
    Greg> As such, neither gss_acquire_cred_with_password nor
    Greg> gss_acquire_cred_from connect up very well.  Because of this, it seems
    Greg> like a questionable idea to me (and to Simo) to conflate "where the
    Greg> creds are" with "what secrets and/or parameters I need to know in order
    Greg> to create initial creds".

I'd like to challenge this wizdom even for krb5.  It's true for
OTP-style interfaces that you often don't know until you get something
back from your KDC what's going on.  However, for passwords and pkinit
that's not generally true.  Microsoft has demonstrated that you can (and
I believe they always do) deploy pkinit where you know before the AS
request what smart card you want to use.
And there are certainly cases where you know the password beforehand.

As I've explained when this has come up before, I'm not looking for a
prompter interface. I understand there are things you cannot do without
that.  Even if there was a prompter interface to use, I'd still want
acquire creds extensions, because designing prompter callbacks to force
feed information that is already known leads to a bad API.

--Sam