a suggestion for improving pkinit preauth plugin token choosing

[Lee Hinman]

krbdev-request at mit.edu writes:

> Date: Wed, 12 May 2010 10:13:10 -0700
> From: "Henry B. Hotz" <hotz at jpl.nasa.gov>
> Subject: 
> To: Nicolas Williams <Nicolas.Williams at oracle.com>
> Cc: Sam Hartman <hartmans at mit.edu>, "krbdev at mit.edu" <krbdev at mit.edu>
> Message-ID: <68359A5E-03EA-4ED1-84C4-DDBE174BD930 at jpl.nasa.gov>
> Content-Type: text/plain; charset=us-ascii
>
>
> On May 12, 2010, at 8:50 AM, Nicolas Williams wrote:
>
>> On Wed, May 12, 2010 at 08:56:39AM -0400, Sam Hartman wrote:
>>> I actually agree with henry that "please insert a token," should be out
>>> of scope for preauth plugins.
>>> My rationale is that the current prompter interface is kind of weak when
>>> it interacts with GUIs etc, and the more we can avoid using it, the
>>> better.
>> 
>> That rationale applies even more so to PAM than to the gic prompter.  At
>> least the gic prompter tells you what kind of thing it's prompting for,
>> whereas PAM has no such concept.  Yet we can't apply the same rationale
>> to PAM and say "sorry, no please insert a token prompt, you have to
>> figure out all by yourself that the reason you can't login is that you
>> haven't plugged your smartcard in".
>
>
> Why is everyone so afraid to let an attempt "fail"?  Maybe it's not
> your first choice, but why is it so bad?
>
> If it "fails" then you can return a meaningful error message that
> tells the user how to do it over so it works.  You can say "I couldn't
> find any smart cards.", or "I found the following credentials and I
> don't know which one to use.  Please remove the extras and try
> again.", or "Please call extension HELP.", or even "Please call
> security to have yourself arrested because you are a dangerous
> terrorist."  ;-)
>
> You can tell the user absolutely anything you want that might be
> helpful, and you don't have any pre-existing constraints from a design
> that didn't anticipate your specific situation.

I'm not sure if this is helpful or not, but one of the things we added
to the pkinit code for our own use was a "pkinit_cert_match" option to
krb5.conf.  That ends up being a regular expression match that we can do
against parts of the certificate.  For example we use:

pkinit_cert_match = <SAN>^[0-9]{10}@mil$

To find the certificate that has a subject alternate name of 10 digits
followed by @mil.  This matches the certificate we care about on the DoD
Common Access Cards.  It has worked well for determining which of the 3
certs on the CAC to use as well as ignoring certificates from other
sources.

-- 
Lee Hinman