[15827] in Kerberos_V5_Development
Re: a suggestion for improving pkinit preauth plugin token choosing
daemon@ATHENA.MIT.EDU (Jeffrey Hutzelman)
Mon May 24 19:43:45 2010
Date: Mon, 24 May 2010 19:43:30 -0400
From: Jeffrey Hutzelman <jhutz@cmu.edu>
To: "Henry B. Hotz" <hotz@jpl.nasa.gov>,
Nicolas Williams <Nicolas.Williams@oracle.com>
Message-ID: <E3A39D2568349DC869100466@minbar.fac.cs.cmu.edu>
In-Reply-To: <8146FF70-4669-44C5-8098-1CFAC289A4CE@jpl.nasa.gov>
MIME-Version: 1.0
Content-Disposition: inline
Cc: krbdev@mit.edu, jhutz@cmu.edu
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu
--On Tuesday, May 11, 2010 11:40:46 AM -0700 "Henry B. Hotz"
<hotz@jpl.nasa.gov> wrote:
>> Don't get me
>> wrong, I think it'd be nice to have a PAM item or PAM data naming
>> convention for sharing PINS or PKCS#11 sessions (respectively) between
>> modules so that PAM modules that could share a single token need not
>> prompt for a PIN for that token more than once. (Not that it's likely
>> that you'll have more than one module on a stack that can make use of
>> tokens.)
>
> Actually, it makes a lot of sense to have both pam_pkcs11 and pam_krb5
> (with PKINIT) as both "sufficient" on a laptop that may, or may not, have
> network connectivity. I don't think I'm arguing for that kind of change
> to PAM, since I assume it would work to just re-open the PKCS#11 module.
Not only does it make a lot of sense; it's something I've been planning on
deploying for something like 5 years now. Most of what's been stopping me
have been local issues, like not having deployed a PKINIT-capable KDC or
figured out how I want to handle issuing credentials. Then again, there's
also the issue of finding a card/token I'll still be able to buy if I look
away for more than 5 minutes ("Don't blink. Don't even blink. Blink and
you're dead. they are fast, faster than you could believe; don't turn your
back, don't look away, and don't blink.")
> Furthermore the card is usually issued by a different organization from
> the one using/deploying the card, so *any* use of the issuer-defined UPN
> value in the card's certificate is almost certainly wrong!
I was planning on being the counterexample, but then, my deployment wasn't
going to be very large.
> Linux with the Debian pam_krb5 is way, way easier to set up than Apple or
> Microsoft, because they don't do a bunch of inappropriate things based on
> the UPN. Every time I think about all the time I've wasted dealing with
> the problems caused by all the time Apple and MS wasted creating those
> problems in the first place I just want to. . . </rant!!>
I was under the impression that Microsoft envisioned a common deployment
model involving certificates issued by a CA controlled by AD. Certainly in
that case it would be appropriate for PKINIT to use a UPN or
Krb5PrinicpalName from the certificate. Of course, one should always
understand an issuer's naming policy before trusting names provided by that
issuer.
Note that PKINIT allows for both models -- you can use the
Krb5PrincipalName in the certificate, or a policy-defined mapping (either a
transformation or a database lookup) from some name in the certificate to a
principal name, or you can just pre-register public keys or whole
certificates in the KDB.
-- Jeff
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
