This is very much akin to needing to authenticate that a machine used
to perform the transaction submission was, indeed, configured by the
information technology staff. This is a very important concept that
cannot be discounted or ignored.
Essentially, what you need is a two-stage authentication process:
1) Authenticate that the machine connecting to your TLS server is
acceptable (via unique identification of the machine -- the function
of a per-machine X.509 certificate that the OP wants), then
2) identify the user on the machine to verify that he's really
authorized to perform the task that he's trying to do.
I would recommend the following approach:
1) Per-machine keys/certificates, embedded into the machine's TPM or a
hardware dongle that cannot be removed from the machine, issued by a
particular CA name (referred to here as "MachineCA")
2) Per-user keys/certificates, stored normally, and issued by any other CA name.
On the TLS server side, you would first send a ClientAuthRequest with
the acceptable CA name list only including "MachineCA".
If the client cannot authenticate, terminate the connection.
If the client authentication violates policy (working "after hours",
for example), terminate the connection. (I would be VERY careful
about this one, though, since there are any number of reasons why
someone would want/need to work after hours.)
If the client can authenticate, then immediately send another
ClientAuthRequest with an empty CA name list such that the user could
select the client certificate to use.
If the client sends the MachineCA certificate again, fail the connection.
Otherwise, proceed.
If you want to reduce the chance that the user will send the MachineCA
certificate twice in a row (thus failing the connection), compile a
list of CA names that the clients use, and add them all to the second
ClientAuthRequest (without mentioning MachineCA in that list).
(This is permitted by TLS, as well as SSL all the way back to SSLv2.)
People, remember: not every situation fits into your narrowly-defined
Holy Writ worldview. I've been trying to get this through your
collective heads for a while now. This is a situation that does not,
and the fact that you're trying to reinforce the dominant paradigm
without realizing that the standards allow for a LOT more leeway than
you're giving them credit for is only a testament to your
closed-minded dogmatic "expertise".
-Kyle H
On Fri, Jan 30, 2009 at 1:36 AM, Denis McCarthy
<dmccar...@annadaletech.com> wrote:
> Hello Arshad,
> Thanks for the email. I suppose the one thing I'd like to stress again
> is that we wish to authenticate a machine, not a user. Many users may
> log in to a certain machine (via a username and password that we would
> issue). What we need to do on our system is to ensure that the user
> logging is valid to log in on that particular computer ('terminal' as
> our customer calls them). The terminal itself is connected to the
> company that the user works for in our database.
> Regards
> Denis
>
> On Fri, Jan 30, 2009 at 12:08 AM, Arshad Noor
> <arshad.n...@strongauth.com> wrote:
>> Denis,
>>
>> You have already made the appropriate leap to this conclusion.
>> I was going to suggest that there is something atypical about
>> your application architecture if you're relying on authentication
>> of the *machine* without the use of a hardware token - such as a
>> smartcard, TPM chip, etc.
>>
>> What you want are FIPS 140-2 Level 2 (or above) certified crypto
>> tokens that generate keys on-board and store the certificate of
>> the user on the token (in addition to the browser). The private
>> key, however, never leaves the token, thus ensuring its security.
>>
>> Once your customers are issued these tokens with their personal
>> certificates, they can use it on any PC they desire (assuming
>> that the PC has been configured with the appropriate CA cert-
>> chain).
>>
>> If you absolutely need to rely on authenticating the PC, then
>> the only option you have is the TPM chip, because it is built
>> with the chip on the motherboard by the manufacturer.
>>
>> As an aside, StrongAuth, Inc., the company I represent has been
>> in the business of architecting, building & operating some of the
>> largest closed-PKIs in the world for enterprises, with the use of
>> crypto-tokens. Most recently, we built a PKI for a bio-technology
>> company that embedded secure processors with digital certificates
>> into three different parts of their product, so that they may
>> strongly authenticate to each other before being used. This was
>> designed to deter counterfeiters from cloning the consumable part
>> of their product. The device is currently awaiting FDA approval
>> before coming to market.
>>
>> Feel free to get in touch with us, if we can be of any help to you.
>>
>> Arshad Noor
>> StrongAuth, Inc.
>>
>> Denis McCarthy wrote:
>>>
>>> Thanks for the suggestion David. Unfortunately we are not connecting
>>> to an active directory domain - our application has to go out over the
>>> internet. I did a bit of fiddling with the certificates snap ins, but
>>> Microsoft only makes certificates installed in the user account
>>> available to IE. One other thing I've been mulling over - is it
>>> possible to get a cheap piece of hardware (i.e. a dongle of some sort)
>>> that you can put an X509 certificate on? If so, could anyone point me
>>> in the direction of a company that provides such a product?
>>> Regards
>>> Denis
>>
>> --
>> dev-tech-crypto mailing list
>> dev-tech-crypto@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-tech-crypto
>>
>
>
>
> --
> Annadale Technologies Limited
> --
> dev-tech-crypto mailing list
> dev-tech-crypto@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-tech-crypto
>
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
