Security and eDirectory Replication
Novell Cool Solutions: Feature
Digg This -
Posted: 19 Feb 2003
We found this list of questions (and the impressive lists of answers) in a discussion about the security that's used when eDirectory performs replication tasks. We were impressed.
- How does one replica authenticate to an other?
- How does this replica know that the one requesting a (eg.) "full synch" is a real replica and not a third party program?
- How do we protect against a man in the middle attack? (and eavesdropping?)
- What information is encrypted and how?
Just the Facts
In brief, the replication agents verify each other based on server key pairs. Each server agent has its own key pair. The public key of the destination server agent is used by the source agent to verify identity. The servers also compare the remote agent's network addresses with those in its object in the tree. A limber process on each agent syncs the network address obtained from the local stack with the server object attributes in the tree. The servers authenticate themselves mutually before every skulk connection. This will filter out all 'man-in-the-middle' attacks.
The server keys are protected on each server box by a tree key. This key is created when the first agent is added to a new tree and then subsequently transferred (through admin challenge handshake) to every other agent that is added to the tree. Agents that are not members of this tree will not be able to obtain server keys required for skulking. During skulking, changed data is transferred in clear text, except for secrets like server/tree/user keys and passwords. These are encrypted using tree/server keys. If any of the packet data is tampered, then it will be detected at the receiving end and be rejected.
Each skulk session uses its own session key. It is not possible to record a skulking session and then replay it later to corrupt tree data.
In addition, each agent maintains a table of remote agents' addresses and timestamps (of last seen change) for the entire replica ring. Skulking agents only exchange delta from the last seen change. Skulking is also transitive so that if A syncs with B and B syncs with C, then A does not need to sync with C again.
Novell Cool Solutions (corporate web communities) are produced by WebWise Solutions. www.webwiseone.com