In LCS2005 SP1, two new federation models were introduced; the ability to federate with the three big public IM providers AOL, MSN & Yahoo! and Enhanced federation by which peer enterprises are discovered via DNS SRV. Further, enhanced federation could be enabled in two different modes. Restricted Enhanced Federation in which only domains configured in the allow list domain were used to locate the federated peer via DNS SRV. This was the default federation model in LCS 2005 SP1. The other model was Un-restricted Enhanced Federation which allowed domains with valid certificates to connect to your Access Edge Server.
With the release of OCS 2007, two new security and protection mechanisms for the federation model “Allow discovery of federation partners” (called Un-restricted Enhanced Federation in LCS 2005 SP1) have been introduced.
One of the reasons a list of allowed domains was added in LCS2005 SP1 was to prevent an attacker from using a “directory harvesting attack” to discover usernames within an enterprise. The idea behind a directory attack is that you try two values (in this case usernames) from a to z, aa to zz, etc. and by looking at the results, discovering if a valid username matches the values you tried. In OCS 2007, in order to prevent this attack a federated peer is allowed to communicate with a fixed number of usernames in a certain time period. Once this is exceeded, attempts to try new usernames will be rejected. This method works by using the fact that an enterprise will have a fixed number of valid usernames but an attacker has to try far more names that will be invalid. There are more sophisticated attacks than one described, but all basically will usually try more invalid names than valid ones.
The second mechanism is message rate limitation where the Access Edge Server restricts the rate at which it accepts messages from the federated peer. The precise rate is based on traffic analysis. A federated peer discovered through DNS SRV starts out at a highly restricted rate. Once the Access Edge Server sees an acceptable ratio of successful responses to failure responses sent to the federated peer it then allows a higher rate of messages. Periodically the server checks the ratio and readjusts the rate if appropriate. This allows limiting the resources the Access Edge Server uses on behalf of a federated peer.
Because both of these mechanisms have the potential to impact legitimate communications, either when a large amount of traffic is sent across the federated link, or when a large number of parties are communicating on both ends, adding a federated peer to Allow list removes these restrictions. In order to be able to easily identify both legitimate peers and potential attackers a list of “Notable Peers” is maintained in the administration UI. The mechanisms are designed and calibrated to allow quite heavy legitimate traffic whilst protecting the system automatically from the attacks described, and allow administrators to easily find the domains that their users communicate with and take appropriate action if required.
There are two actions an administrator can take; firstly they can add the domains to the deny list, secondly they can block the peer certificate via the Operating System certificate store. Blocking the certificate at the OS level is most efficient but can be circumvented by the attacker getting a new certificate. Adding the domain to the deny list makes it harder for the attacker as they will require a new domain too. Both actions can be taken for maximum protection and efficiency.
As these additional features offers a good level of security and make federation configuration much easier, ““Allow discovery of federation partners” is the default federation model in OCS 2007. If your enterprise’s needs require a different federation model, this default can be changed easily on the Access Edge Server.
– James Undery
SDE II, Unified Communications Group