|
⇤ ← Revision 1 as of 2006-12-16 20:08:12
Size: 254
Comment:
|
Size: 2034
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 5: | Line 5: |
| Fill in later! | = Conventions for this document = We'll use these conventions: * `$DOMTOOL` refers to `/afs/hcoop.net/common/etc/domtool`, the root of global DomTool data = Users and authentication = The principals that figure into DomTool authentication are either AFS/Kerberos users (like `adamc`) or HCoop machine hostnames (like `mire`). When one of these entities connects to another with some request to make, it authenticates using SSL. To faciliate this, we have our own SSL certificate authority (CA) living in `/etc/domtool` on `deleuze.hcoop.net`. We use this CA to sign keys belonging to DomTool-related principals. The DomTool tools only recognize this certificate authority, so, e.g., Veri``Sign can't grant any DomTool privileges. Each principal has its CA-signed certificate stored in `$DOMTOOL/certs/$NAME.pem`, where `$NAME` is the UNIX username of a user or the one-word hostname of a server. Any user is allowed to read these certificates, which are the public key halves of public key cryptography. The private keys are stored in `$DOMTOOL/keys/$NAME/key.pem`. AFS permissions are set such that, besides admins, only the user in question has the ability to read the key data. In contrast to certificates, keys have their own directories because AFS only allows directory-level permissions. '''Meta note''': This clearly isn't the most direct way to do authentication. I chose to do things this way initially because of that wise security mantra to implement as little as possible of your own cryptography infrastructure. By basing our authentication on that implemented in well-tested OpenAFS code, along with some help from the OpenSSL library, we avoid opportunities to introduce new bugs. But the result definitely isn't so aesthetically pleasing. --AdamChlipala |
This page describes the client/server distributed configuration architecture of DomTool. For (largely orthogonal) information on the programming language used for configuration, see DomTool/LanguageReference.
1. Conventions for this document
We'll use these conventions:
$DOMTOOL refers to /afs/hcoop.net/common/etc/domtool, the root of global DomTool data
2. Users and authentication
The principals that figure into DomTool authentication are either AFS/Kerberos users (like adamc) or HCoop machine hostnames (like mire). When one of these entities connects to another with some request to make, it authenticates using SSL.
To faciliate this, we have our own SSL certificate authority (CA) living in /etc/domtool on deleuze.hcoop.net. We use this CA to sign keys belonging to DomTool-related principals. The DomTool tools only recognize this certificate authority, so, e.g., VeriSign can't grant any DomTool privileges.
Each principal has its CA-signed certificate stored in $DOMTOOL/certs/$NAME.pem, where $NAME is the UNIX username of a user or the one-word hostname of a server. Any user is allowed to read these certificates, which are the public key halves of public key cryptography.
The private keys are stored in $DOMTOOL/keys/$NAME/key.pem. AFS permissions are set such that, besides admins, only the user in question has the ability to read the key data. In contrast to certificates, keys have their own directories because AFS only allows directory-level permissions.
Meta note: This clearly isn't the most direct way to do authentication. I chose to do things this way initially because of that wise security mantra to implement as little as possible of your own cryptography infrastructure. By basing our authentication on that implemented in well-tested OpenAFS code, along with some help from the OpenSSL library, we avoid opportunities to introduce new bugs. But the result definitely isn't so aesthetically pleasing. --AdamChlipala