Re: authentication (SRP*, DH, TLS)

Paul Rubin wrote:
gmu2006@xxxxxxxxx writes:
If I do SSH like pub/priv key auth without TLS beneath the keys will
be on the wire.

I thought SSH pub/priv was like TLS without certificates, so all peers
have to know the pub keys of everyone they talk to. Could you be
thinking of password authenticated SSH, which does send the password
after establishing a secure connection against a stored public key at
the client side? I'm not that up on SSH.

I might be wrong here. I'm thinking about the case where you
upload your pub key to the SSH server and use your priv key locally
to login to that server without entering passwords.

OK, the detailed picture:
A distributed system := masternode & {node1, node2, node3)
B masternode offers core services and every node(1..3) connects to
masternode
C as long as all clients (not nodes) connect to the master node only
there's no problem with key storage (client's priv key available
locally only and public key on masternode, replace client with node
and have the same for inter-node auth)
D what keys do I store where when I assume that each node also has
to authenticate against all other nodes (including masternode) and
despite the rule above that nodes talk to each other without the
help of masternode or the client has to connect to a service on a
node and not masternode?

1. Make a CA that issues itself a self-signed certificate (CA root
cert). If you have just a few nodes and you're a low-rent operation,
there's a crude perl script including with OpenSSL that can do this.
If you want something more serious, there are online CA services that
you can consider. If you want to issue certs to a bazillion clients,
you probably should get a specialist involved.

2. Install the CA root cert on all nodes and on all clients. This is
a public file and it's the same everywhere, so just build it into the
replicated software config.

3. For each entity that needs authentication (master node and
node1,2,..., and maybe the clients as well), generate a keypair
(normally done on the end-entity unless there's a good reason to do
otherwise) and have the CA issue a cert for the public key. Install
the cert on the entity. The cert includes the entity's public key,
and some identifying strings saying what entity it is (master node,
node #3, etc).

4. If client #37 wants to talk to node #2, it opens a connection, gets
node #2's certificate, checks the certificate's signature against the
preconfigured CA root, and if valid, proceeds with the connection.
This guarantees no MITM. In the version with client certificates, the
client presents its own cert and the server checks it. You might want
to set up separate CA's for nodes and clients, depending on your
deployment strategy and maybe other factors.

requiring all clients to retrieve a certificate will not be supported
well as far as I know our marketing, support and customers.
but we could at least try to do this between services as the
clients that are used by users (not admins) don't directly talk to
the services but have to go through an additional service which
then talks to the masternode, anyway.
this would leave only the administrative clients and services to
use the strong bidirectional cert check.
I mean no online banking site ask you to install a certificate you
receive via postal mail or somethink like that. it's you who tries to
make sure that you're talking to the real bank and not a channel
which terminates in a phishing db.

I've been reading Viega's books (C/C++ Sec Cookbook and the one with
the Cowboy Hat, don't remember the exact name) but skipped Applied
Crypto.

Applied Crypto is a good book but not really what you want for this.

Eric Rescorla, "SSL and TLS" is good if you want the gritty details of
how TLS works. But you probably want something more like a cookbook.

If this is a large scale commercial project, then as mentioned above,
you should probably get a specialist involved.

good idea, but security is not taken as seriously as I would like to,
so not highly likely.

PS: thanks for all the input so far

.

Relevant Pages

  • Re: Dummies Guide for RADIUS/Certs
    ... I have set up IAS. ... client computers impacts certificate enrollment. ... configure Group Policy for domain member wireless clients so ... Cert Templates that is now enrolled on the IAS server. ...
    (microsoft.public.internet.radius)
  • Re: Multiple vulnerabilites in vendor IKE implementations, including Cisco,
    ... > in a concentrator and configure the clients to only talk ... > to a server with that certificate. ... I've seen clients that support it, so I assume concentrators from the ... You _could_ dole out a single cert to all clients, ...
    (Bugtraq)
  • Re: certificate authority
    ... Should the Certificate Service be running? ... > Just FYI, in SBS2003, CEICW will auto generate a cert without CA. ... > (Assuming you setup the clients via the SBS client seutp wizard). ...
    (microsoft.public.windows.server.sbs)
  • Re: CertSrv Question
    ... The reason most likely is that the CA cert is still there in the NTAuth ... > After installing a Stand-alone CA on a server in the Active Directory, ... > it replicates a trusted root to all the clients in the network. ... How is it valid if the certificate is no longer existing? ...
    (microsoft.public.win2000.security)
  • Re: SMS 2003 SP1 Client Install Problem or Policy Retreival Problem?
    ... > Failed to find running shell process ... >> It is possible that the crypto store has somehow been corrupted. ... >>> The MP is setup and thousands of other clients have access. ... >>> Failed to find the certificate in the store, ...
    (microsoft.public.sms.admin)