Obsolete:MNET 1.0 technotes
- Draft -- Warning: Braindump in progress --Martin Langhoff 12:40, 20 July 2006 (WST)
- Discussion at General Developer Forum
Trust relationships and encryption notes
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 PHP's integrated OpenSSL functions. This is a strong contender, as it offers a good key creation, signing and encryption 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 end up with a horribly weak implementation that we will be very proud of.
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. URL itself is an important point of trust -- see next point.
- Maybe the 'Register Moodle' database that Moodle.org maintains could make your site keys optionally available in a searchable/browsable directory, and provide some means of requesting a peering arrangement -- even if it is just listing the main admin's email address.
URL as a point of trust, and HTTPS problems
When trusting a web app like Moodle, the URL itself is an important point of trust, specially if it is via HTTPS. We could say that the trust levels are
- Bare IP-based HTTP URL: the admin controls the server.
- Bare name-based HTTP URL: the admin controls the server and DNS.
- Self-signed HTTPS URL: transactions are also encrypted, and we are less vulnerable against MITM attacks.
- CACert-signed HTTPS URL: there is some assurance of server administrator identity.
- Paid CA signed HTTPS URL: there is some assurance of server administrator identity and money ;-) (Actually, CAs do some due diligence to check that Amazon.com is actually Amazon Ltd.)
However, the http clients we have in PHP are brittle and hard to use in most of these cases:
- Hard to get https support (curl compile options, non-free dependencies)
- Hard to get meaningful errors when the certs aren't good. PHP's libcurl support has the needed bits and pieces, but it is hard to access them directly when using a library such as nusoap.
- Hard to register an "unofficial" CA such as CACert.
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.
Alternative: Use HTTPS infrastructure (or not!)
One does wonder
- Why are we signing/encrypting all this stuff when we use HTTPS?
- Why are we trying to manage our own key distribution and trust mechanisms if we can use HTTPS's?
- Why struggle with key security when Apache's SSL implementation does a kind-of-reasonable job of protecting the private keys?
In a sense, we are making it much, much harder on ourselves. However, there are several threshold issues
- Not all users can use HTTPS easily -- configuration is hard. We aim to make configuration very easy as soon as there is a gpg utility in the path. Setting that path if it's not the default should be the only hard thing in our scheme.
- Apache's SSL private keys won't be useful to authenticate as an HTTPS client. We need both. Our scheme is of symmetric peers, on top of HTTPS but the HTTPS infrastucture is client/server.
- There may be many Moodles in the same HTTPS host sharing the same keys -- (this can be worked around though).
Base API
Should be very easy to extend -- not sure if the services themselves can be cleanly pluggable as they will surely involve serious core Moodle changes, but the API should not be constrained by preconceptions.
Each service can use the core protocol or break out and do its own thing. We do need to ask several questions, however, and so it is a good idea to define an entry point and a base RPC-ish protocol.
Base protocol
- Need to define whether to use SOAP or XMLRPC.
- Functionally equivalent
- XML-RPC simple, easier to debug
- SOAP has more in the way of introspection -- which may be of use
- The library must let us manage HTTPS cert stuff
- The library must let us encrypt/sign the payload
- Even if Moodle has other XML-RPC or SOAP entry points, we want a segregated entry point (url) for security/auditability purposes. You can eventually lock it down via httpd.conf / .htaccess
- Version the protocol?
- Declare "prefix" namespaces for each service for extensibility.
Services
Simple UI and implied promises
Outline of what I'd expect a site admin to see when looking at the relations with a given host X:
- Offer Services
- Allow users from X to SSO here {yes/no} {see report}
- Allow users from X to enrol to courses here {yes/no} {only courses from list/category} {see report}
- Allow admins from X to enrol users to courses here {yes/no} {only courses from list/category} {see report}
- (maybe) Allow admins/teachers from X to retrive course zipfiles (without user data) {yes/no} {only courses from list/category} {see report}
- (If moodle has a LOR behaviour) Allow admins/teachers from X retrieve published LOs. {yes/no}
- Use Services
- Remote server X allows all users from this Moodle to SSO. Allow? {all/some/no} {see report} {manage allowed users}
- Remote server X allows nominated users from this Moodle to SSO. Allow? {yes/no} {see report} {manage allowed users}
- Remote server X allows users from this Moodle to enrol interactively to (all/some/no) courses. (informational message only)
- Remove server X allows administrators to enrol users to (all/some) courses. {enrol users}
- Remote server X allows administrators/teachers to retrieve course zipfiles. Use as source? {y/n}
- Remote server X allows administrators/teachers to LOs. Use as source? {y/n}
User SSO
You know you want it! ;-)
Enrolment
There are 3 behaviours defined
- Allow/disallow interactive enrolment by 'remote' users. This means changes on the 'server' side, and all we need to do is to work on the enrolment infrastructure (or the manual plugin, but that could leave custom interactive plugins vulnerable).
- Manual enrolment (by admin or teacher) is always still available. The students page should however indicate the source of the user.
- Remote admin can enrol. This will need protocol support and possibly via an enrolment plugin.
