On Thu, Oct 29, 2009 at 01:34:42PM +0000, Darren J Moffat wrote: > Will Fiveash wrote: > > On Wed, Oct 28, 2009 at 05:08:42PM -0500, Douglas E. Engert wrote: > >> > >> Will Fiveash wrote: > >>> On Wed, Oct 28, 2009 at 05:24:42PM -0400, Wyllys Ingersoll wrote: > >>>> Will Fiveash wrote: > >>>>> On Wed, Oct 28, 2009 at 05:14:27PM -0400, Wyllys Ingersoll wrote: > >>>>>>>> The problem is that when you query the token and check the flags, > >>>>>>>> the token has no way to know if you want to read the private or > >>>>>>>> public areas so it cannot have any logic to indicate whether or > >>>>>>>> not to set the login bitfield in the flags. pktool defaults to the > >>>>>>>> safest method, which is to prompt always (we ran into trouble > >>>>>>>> when we did not do this on some devices other than softtoken). > >>>>>>> Looking at the spec there is support for different session types > >>>>>>> including the default of CKS_RO_PUBLIC_SESSION. Why can't the token > >>>>>>> use > >>>>>>> this to determine what the app wants to read and whether login is > >>>>>>> necessary? > >>>>>> That sounds like it should be possible but I haven't looked at the > >>>>>> code > >>>>>> to check. You should be discussing this with the EF iteam or > >>>>>> crypto-discuss at opensolaris.org . > >>>>> I've been cc'ing crypto-discuss at opensolaris.org on this thread. > >>>> > >>>> C_GetTokenInfo does not take a session handle as an argument, so the > >>>> token has no idea if you will be opening a readonly public session > >>>> or not and thus cannot tailor the info that it gives you. > >>> Fair enough but given this from the PKCS#11 v2.20 spec: > >>> After it opens a session, an application has access to the token?s > >>> public objects. All threads of a given application have access to > >>> exactly the same sessions and the same session objects. To gain > >>> access to the token?s private objects, the normal user must log in > >>> and be authenticated. > >>> it seems like our implementation of softtoken, which has C_GetTokenInfo > >>> setting CKF_LOGIN_REQUIRED regardless of the type of object that is > >>> going to be accessed, is violating the spec. Should I open a bug > >>> against the pkcs11_softtoken.so? > >> No, the CFK_LOGIN_REQUIRED says "True if there are some cryptographic > >> functions that a user must be logged it to preform." Its more or less > >> telling you that if you want to see/use everything you will have to > >> login. > >> > >> > >> If you just use C_OpenSession it will be in R/O to the token objects. > >> If you then use the C_Login the session will change an can then have > >> R/W access to token objects. > >> > >> PKCS#11 2.01 section 5.6 Sessions talks about this. > > Yep, I was just talking to Nico Williams about this and he convinced me > > that the problem is not that pkcs11_softtoken is setting > > CFK_LOGIN_REQUIRED but rather that the applications like pktool and the > > pkinit preauth plugin are prompting for login if that flag is set > > regardless of whether the softtoken object to be accessed is public or > > not. This seems crude and unnecessary. Note that in the case of the > > pkinit plugin this can cause a prompt for the user's PIN even if there > > are no certs in the user's softtoken. > > I asked on the cryptoki alias and so far the responses suggest we don't need > to set CKF_LOGIN_REQUIRED so I'm going to remove it (I've got a wad of other > stuff Kerberos needs changed in pkcs11_softtoken so I'll included it in > that). > > I agree that pktool(1) should not just "jump" to C_Login() in the cases > where the search didn't include private token objects. Regardless of my fix > to pkcs11_softtoken pktool(1) should probably still be fixed, but I'd rather > leave that to Wyllys et al. > > How you deal with pkinit preauth is up to you - but won't you need to > C_Login() to get the RSA private key anyway ? If you expect the > certificate and private key to be in the same token you could first do a > C_FindObjects() for the certificate and if you find that then do a C_Login() > and look for the matching private key.
Yes, that is what I'm thinking (search for a cert that is appropriate for PKINIT and if found then prompt/C_Login() to access the matching private key object). If no cert is found, don't prompt and just return failure. -- Will Fiveash Sun Microsystems Inc. http://opensolaris.org/os/project/kerberos/ Sent from mutt, a sweet ASCII MUA
