Obsolete:MNET 1.0 technotes

Draft -- initiated by Martin Langhoff

Establishing trust relationships

The community hub is formed by Moodle installations establishing P2P-style trust relationships. Once those relationships have been established, each Moodle can offer services from other trusted nodes, and use the offered services.

We need to define key infrastructure for managing the trust relationships, probably using a public key encryption scheme. Currently looking at...

Core encryption/signing infrastructure

• Using GPG via
  • Crypt_GPG - a proposed PEAR package, wraps around the gpg binary. We are lucky and v0.20 is offered under LGPL, though it depends on PHP5 for its error handling (easy to fix).
  • TinyPHP or something similar. See DIY risks.
• Using PHP's one mcrypt functions. See DIY risks.

DYI risks: we are not actually crypto developers, so if we go out an implement message signing ourselves there is a good chance we will miss a subtle point and have trouble.

Key generation and storage

Moodle installations should be able to generate keys or load preexisting keys. GPG tends to want the key as a file, so the root of moodledata is a reasonably good place for it. Unfortunately, it is also often world-readable.

Note that the key handling will never be as secure as personal GPG keys can be. The keys and the encryption machinery have to be accessible by www-data. So in most cases any user with shell access to the server can impersonate your Moodle install.

Key exchange mechanisms

• Each Moodle can publish its GPG public key openly in a standard url.
• Optionally, public keys can be exchanged out-of-band and loaded manually
• We do not want these keys to show up on established GPG keyrings, and it is probably overkill to establish a moodle keyring. When trusting a web app like Moodle, the URL itself is an important point of trust, specially if it is via HTTPS.

Encryption and performance

Full GPG encryption is costly. To support high-traffic scenarios we should use GPG to setup the dialogue, trade a randomly generated session key, and then continue with symmetric encryption using that session key.

Note that this assumes we are being 'stateful' where we work on top of a stateless protocol. So we should cache the session key, and have an explicit expiry for it. If we are close to the expiry, negotiate a new one. Which leads me to...

Encryption and clocks

Moodle nodes should be on reasonably sync'd up servers. Part of the key setup process needs to check whether the system clocks are reasonably in sync.

Work involved

• Revamp Crypt_GPG
• HTTP client to handle HTTPS correctly, and dealing with self-signed certs in a user-friendly way
• Define a simple API to
  • Publish pub cert
  • Publish services offered
  • Trigger services offered
  • Create "allow users to SSO" service
    • Options: users shortlist, remote admin approval
    • Requires Auth API work and plugin changes
  • Create "allow users to enrol in courses" service
    • Options: courses shortlist, remote admin approval
    • Requires Enrol API work and plugin changes

• User-friendly admin pages
  • Establish and manage trust relations
  • Open/close services
  • Each service with an associated usage report. Examples:
    • What remote users are logging in, from where, which remote admin OKd them
    • What remote users are enrolled in, from where, which remote admin OKd them