Key Renewal Periods for Symantec Encryption Management Server (formerly known as PGP Universal Server)
|Article:TECH205541|||||Created: 2013-04-25|||||Updated: 2013-04-25|||||Article URL http://www.symantec.com/docs/TECH205541|
Symantec Encryption Management Server (SEMS) has the ability to renew keys automatically and operates under key renewal parameters that can be configured in individual Consumer Policies. Consideration should be given for Key renewal time periods and how it applies to a particular deployment scenario.
One scenario includes SEMS only deployed in the mail stream, or Gateway deployment. In this method, users do not have a Symantec Encryption Desktop client and only SEMS manages keys for the users. In this mode, the users may often send email through the SEMS such that keys stay active and are renewed on a regular basis.
In certain environments, email may be routed to SEMS only if encryption is needed. In these cases, the frequency could be much less that users are considered active and key renewal time constraints could be reached.
The two values that pertain to key renewal are Auto-Renew Keys Every and Stop Renewing After. To find these values, click on the Consumer Policy in question, then click the Keys Edit button. As this applies to individual Consumer Policies, setting these values for one Consumer Policy may not affect all users.
Auto-Renew Keys Every: This value specifies the time period in which keys are considered valid or not expired. The default value configured in the Consumer Policy on SEMS is two weeks. As long as users are active within two weeks, keys are renewed for the users on a scheduled basis and keys remain active and do not expire.
The renewal period should comply with an organization’s security policies, as well as try to maintain a balance to keep keys renewed. Setting this value too aggressively for a particular environment may lead to many user’s keys being needlessly expired.
The best way to achieve a good balance of key renewal is to consider what is the longest acceptable time period a user may *not* communicate with the server and still be considered active. For example, in a gateway deployment, a typical user may send emails at the very least, a few times per week. If this is the case, then the key renewal period of 2 weeks is acceptable because keys will continue to be renewed and users will continue to stay active.
In a different scenario, consider Symantec Drive Encryption, in which users may be remote and not communicate to the SEMS for extended periods of time. In this scenario, determine what is the longest acceptable amount a time a user could be without communicating with the SEMS, but still be active. If a user may not be active for 3 months, then move this to 6 months. If a user may not be active for 7 months, move this to 1 year. By configuring the key renewal policies in this way, user’s keys will never needlessly be expired.
Stop Renewing After: This specifies a period of inactivity after which a key will not be automatically renewed. After the Auto-Renew Keys Every value has been reached, a timer goes into effect. If a user does not communicate with the SEMS within this value, then the key is expired and is never renewed at that point.
In reference to the above setting to renew keys, the proper “Stop Renewing After” value should be one value above the renewal period. For example, if a Renew Keys Every has been set to 3 months, then the Stop Renewing After value should be 6 months. If the Renew Keys Every value has been set to 1 year, then the Stop Renewing keys value should be set to 2 years. By configuring the key renewal policies in this way, users keys will never be in a situation where a renewal period outlives the stop renewal period. In other words, a key may not expire until after the “Stop Renewing After” period has been reached, and therefore, that particular key will never get renewed, regardless of user activity. Please adhere to this recommendation for best results.
CAUTION: Choosing the option "Never Renew" sets SKM and SCKM keys to Never Expire. Setting this parameter cannot be reversed. Once a key is set to "Never" expire, SEMS cannot revert back to an expiration date to the key in question.
GKM and CKM keys are generally set to Never Expire, so in the case of key renewal, the signatures on the keys is what will expire.
Article URL http://www.symantec.com/docs/TECH205541