Bound vs. Unbound
Similarly, both HMAC and policy sessions can be set to be either bound or unbound. A bound session means the session is “bound” to a particular entity, the “bind” entity; a session started this way is typically used to authorize multiple actions on the bind entity. The bind entity's authorization value is used to calculate the session key but isn't needed after that. This can be advantageous from a security perspective, because the calling application doesn't need to keep prompting for the authorization value (password) or maintain it in memory.
Bound sessions can also be used to authorize actions on other entities, and in that case, the bind entity's authValue adds entropy to the session key creation, resulting in stronger encryption of command and response parameters—sort of a poor man's salt. The authorization values for both the bind entity and the entity being authorized figure into the HMAC calculation.
An unbound session is used to authorize actions on many different entities. A policy session is most commonly configured as an unbound session. With the security offered by policy sessions, an HMAC isn't as important, and using policy sessions without having to calculate and insert HMACs is much easier.
Use Cases for Session Variations
Now let's answer the obvious question: what are the major use cases for bound/unbound and salted/unsalted sessions? There are many possibilities, but the most common ones are as follows:
• Unbound sessions are most commonly used for two cases:
• If the session is also unsalted, this combination is often used for policy sessions that don't require an HMAC. This is okay because policy sessions use policy commands and
HMAC authorization isn't really required in many cases. This simplifies the use of the policy session by eliminating the overhead of calculating the HMACs. The use case for this is any policy authorization that doesn't include the
• They can also be used by HMAC sessions to authorize actions on many different entities.
• Bound sessions have two cases:
• Authorizing actions on the bind entity: This HMAC authorization can be used to authorize many actions on the bind entity without prompting for the password each time. For example, an employee might want to view their personnel file many times; this type of authorization would work for that.
• Authorizing actions on an entity other than the bind entity: In this case, both the bind entity's authValue and the authValue of the entity being authorized figure into the HMAC calculation. This results in a stronger session key and stronger encryption and decryption keys.
• Unsalted session: when the authValue of the bind entity is deemed strong enough to generate strong session and strong encryption and decryption keys. If a system administrator can enforce sufficient controls on the strength of a password, an unsalted session using that password may be sufficient.
• Salted session: when the authValue isn't considered strong enough for generating secure session and encryption/decryption keys. A web site could request two different passwords from a user: one to be used as the authorization value for use of an encryption key, and the other to be used for the salt. The combination of the two would be much stronger than using a single password, as long asa cryptographically strong salt was used.
Now that you have a foundation for starting sessions, let's see some differences between HMAC and policy sessions.