Need for security model

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

As of Dec 2, hythloday (James Harlow) is no longer with the Zynot project.

As such, we are in need of a security model. I have provided an
overview of the XBuild trust model (which can be applied to virtually
every file) in another email - however, we still need a security/trust
model for discovering and using exported Xeta services - and a access
control system for the Xeta services...

The requirements specification and some comments from theDevil-
(Frantz Dhin):

~    * Authentication
~          o Server authentication: Clients must be able to verify that
~            they are communicating with a valid server.
~          o Client authentication: Servers must be able to verify that
~            clients are valid.
~          o User authentication: There must be a way to verify that
~            user is who he claims to be.
~          o Authorization: What level of user rights are granted after
~            authentication. Is user or client granted only the right
~            to browse, or to carry out installs? Is user or client
~            permitted to make operations that builds new toolchains or
~            are they constrained to using the services that are
~            already offered only?
~    * Auditing: What happened, who caused it to happen and when did it
~      happen. Failed transaction attempts must also be recorded.
~    * Access control: Control of permissions to resources. Does user
~      or client have access to XBuild A, but not to XBuild B? Does
~      user or client have access to using toolchain A, but not
~      toolchain B?
~    * Integrity: Verify that data has not been modified in transit
~      over network.
~    * Confidentiality: Protect data in transit against eavesdropping.
~    * Non-repudiation: Make sure that no client, server or user is
~      able to deny a transaction after it happened.


Some thoughts about single sign-on and trust between Xeta units would
be welcome. A security boundary could be established, and effectively
it could work, not only for Xeta, but the others tools that will
complement it in the  future. All nodes within a Zynot security
boundary will most likely have Xeta or some Xeta component installed.
How can we leverage this to extend the management capabilities of our
tools?

- ----- END QUOTE -----

My comments:

The authorisation subclause of the authentication clause is redundant
- - it falls under access control.
I have dealt with integrity and trust with my part of the model - but
more suggestions and comments are welcome.
Confidentiality is easily achieved using SSL.
Non-repudiation will be hard to implement under strict interpretation
- - however, it is possible to implement a weak form of this by
cross-referencing transaction logs and flagging conflicts.

Single sign-on is nasty business... How can you be sure it's the same
client again? Re-authentication is neccessary each time a session is
established... However, it does not need to be the same as the primary
authentication.

http://www.gnu.org/software/hurd/auth.html

This page describes the authentication model for the HURD. With a few
modifications, it can be adapted for use across a network.

I hope to see your comments.

- -- Zhen Lin
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQE/0ghjv+6a/MPcjnERAkq/AJ9Fo2D9ZYxF4fzLjJe+2B18Tqy3SwCfQK8p
zvBMSj4FU+H6dgKDVCmUEEY=
=BlEb
-----END PGP SIGNATURE-----