Ticket #59 (assigned defect)

Opened 3 years ago

Last modified 1 year ago

security: enforce proper client authentication

Reported by: yvesjm Assigned to: yvesjm (accepted)
Priority: critical Milestone: 0.2.0
Component: agent Version: 0.1.7
Keywords: Cc:

Description

There must be a digest/challenge authentication instead of a simple HMAC auth.

Change History

05/21/06 21:13:17 changed by yvesjm

  • milestone set to milestone2.

05/21/06 21:13:25 changed by yvesjm

  • status changed from new to assigned.

06/19/06 21:48:42 changed by yvesjm

  • summary changed from client auth is vulnerable to replay attacks to security: client auth is vulnerable to replay attacks.

10/01/06 17:07:59 changed by yvesjm

  • milestone changed from 0.3.0 to 0.2.0.

10/03/06 19:36:11 changed by yvesjm

Currently, I'd rather use SSL certificates issued to each client, or else keep the current model of auto generated passwords, but use challenge/response as mentioned *and* wait for an approval from the sysadmin before a computer is 'active'.

02/26/07 14:25:19 changed by yvesjm

  • summary changed from security: client auth is vulnerable to replay attacks to security: enforce proper client authentication.

I was not able to implement client-side certificates after a few tries.

Maybe we should authenticate clients using:

"Any new client is moved to a "pending" group (simplest and possibly best method)", then manually moved by the admin to other groups. the problem is that there is no current implementation of "groups", although I want to do that soon.

See [SecurityModel] for more info.

01/05/08 02:45:14 changed by yvesjm

  • owner changed from yvesjm to stephan.
  • status changed from assigned to new.

Stephan is working on this one.

01/05/08 14:17:22 changed by stephan

  • status changed from new to assigned.

A possible solution would look like this and depends on #101:

Client connects the first time w/out X509 credentials and downloads CA certificate, generates a private key using the wrapper, creates a CSR and sends it to the server. The server replies with a token.

The server admin may then authorize the client (effectively causing the CSR to be processed and a certificate to be generated). After authorization the client is then able to access its certificate using the earlier supplied token.

At this point the client does have a certificate/private key pair which then is used in connections and allows the server to authenticate clients this way.

01/07/08 17:09:51 changed by stephan

Preparations in server code done, see [402].

01/08/08 19:49:52 changed by stephan

More preparations in server code done, see [420].

NOTE

This change breaks the server code. Every method now gets called with an additional first argument, being the X509 certificate the client presented (if it was valid!).

All RPC functions need to be modified to make this work again. However, I think we might want to go for a 'real' class having a _dispatch method (which gets called instead of any method) to have unified authentication there. The _dispatch method would in turn, after authenticating the client and checking its permissions, either call the requested method with the authentication information stripped off or replaced by some user identifier, or return an error code of some kind.

01/09/08 11:23:45 changed by stephan

This ticket depends on #108 and #109.

01/10/08 12:32:53 changed by stephan

Added some more code in [427]. Note that two arguments get injected now: the certificate information (DB model instance or None) and the remote IP address (for use in logging, etc.).

01/16/08 17:18:02 changed by stephan

  • owner changed from stephan to yvesjm.
  • status changed from assigned to new.

With the new server RPC framework this works fine (see sources:trunk/nwu/server/rpc).

The coding part is done, but tests still need to be written. Assigning ticket to Yves.

01/17/08 15:46:14 changed by yvesjm

  • status changed from new to assigned.
  • version set to 0.1.7.
-->