[15783] in Kerberos_V5_Development
Re: a suggestion for improving pkinit preauth plugin token choosing
daemon@ATHENA.MIT.EDU (Henry B. Hotz)
Mon May 10 19:55:44 2010
Mime-Version: 1.0 (Apple Message framework v1078)
From: "Henry B. Hotz" <hotz@jpl.nasa.gov>
In-Reply-To: <mailman.631.1273507450.28565.krbdev@mit.edu>
Date: Mon, 10 May 2010 16:55:39 -0700
Message-Id: <579D3BAA-A55E-4803-ACBA-65A1222F15D9@jpl.nasa.gov>
To: "krbdev@mit.edu" <krbdev@mit.edu>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu
On May 10, 2010, at 9:04 AM, krbdev-request@mit.edu wrote:
> Message: 2
> Date: Mon, 10 May 2010 05:21:06 -0400
> From: Sam Hartman <hartmans@MIT.EDU>
> Subject: Re: a suggestion for improving pkinit preauth plugin token
> choosing
> To: kerberos-discuss <kerberos-discuss@opensolaris.org>
> Cc: MIT Kerberos Dev List <krbdev@mit.edu>
> Message-ID: <tsl7hncun7h.fsf@mit.edu>
> Content-Type: text/plain; charset=us-ascii
>
> I agree that what you propose is an improvement over the current
> algorithm.
>
> I'm uncomfortable with two things.
>
> 1) No way at all to deal with tokens that require login. I wouldn't
> mind if this needed to be explicitly enabled. I think what the
> discussions so far have suggested is that we know of no smart cards
> falling into this category especially because they will not work with
> the MS model, but we do know of non-smart-card PKCS11 devices falling
> into this category.
>
> 2) Prompting user to insert smart card if none are found.
>
> I think I'm in the rough on #2.
>
> Neither of these are blocking issues.
In both cases, I have to ask if they should be handled by a PKINIT plugin at all.
In order to do PKINIT, there are some prerequisites: You need to have the PKI credentials available (and selected/identified), and unlocked. I'm personally OK with requiring pre-unlock access to the information needed to identify the credentials you want to use, but if I'm being PIV-card provincial feel free to speak up.
I think prompting (via supplied prompter function) to unlock use of the secret key is in scope for a pre-auth plugin. It had better be possible for that function to bridge between a PAM conversation and supplying a PIN to pkcs11.
I also think that things like "pretty please insert your card" are outside the scope of what a pre-auth plugin ought to be responsible for. A pre-auth plugin should just return an error indicating "no cred's", or "multiple (ambiguous) creds".
I think user context-setup interactions (like "pretty please insert your card") are a higher-level issue, and the responsibility of pam_krb5, or maybe even the application calling PAM. If it's a command line, then it prints the appropriate error, and the user can insert the card and do it over. (Actually, I think I've argued for do-over in the PAM case as well, haven't I?)
------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
