During this blog post, we'll be discussing different key exchange patterns and their related use cases.
1. Direct Key Transfer
If one party has a token and key and wishes to share this with another party, the key can be directly transferred. WS-Secure Conversation is a good example for this. Under WS-Secure Conversation, when the security context token is created by one of the communicating parties and propagated with a message it occupies this pattern to do the key exchange. This is accomplished by the initiator sending an RSTR (either in the body or header) to the other party. The RSTR contains the token and a proof-of-possession token that contains the key encrypted for the recipient.
The initiator creates a security context token and sends it to the other parties on a message using the mechanisms described in WS-Trust specification. This model works when the sender is trusted to always create a new security context token. For this scenario the initiating party creates a security context token and issues a signed unsolicited <wst:RequestSecurityTokenResponse> to the other party. The message contains a <wst:RequestedSecurityToken> containing (or pointing to) the new security context token and a <wst:RequestedProofToken> pointing to the "secret" for the security context token.
2. Brokered Key Distribution
A third party MAY also act as a broker to transfer keys. For example, a requestor may obtain a token and proof-of-possession token from a third-party STS. The token contains a key encrypted for the target service (either using the service's public key or a key known to the STS and target service). The proof-of-possession token contains the same key encrypted for the requestor (similarly this can use public or symmetric keys).
WS-Secure Conversation also has an example for this pattern when the security context token is created by a security token service – The context initiator asks a security token service to create a new security context token. The newly created security context token is distributed to the parties through the mechanisms defined here and in WS-Trust. For this scenario the initiating party sends <wst:RequestSecurityToken> request to the token service and a <wst:RequestSecurityTokenResponseCollection> containing a <wst:RequestSecurityTokenResponse> is returned. The response contains a <wst:RequestedSecurityToken> containing (or pointing to) the new security context token and a <wst:RequestedProofToken> pointing to the "secret" for the returned context. The requestor then uses the security context token when securing messages to applicable services.
3. Delegated Key Transfer
Key transfer can also take the form of delegation. That is, one party transfers the right to use a key without actually transferring the key. In such cases, a delegation token, e.g. XrML, is created that identifies a set of rights and a delegation target and is secured by the delegating party. That is, one key indicates that another key can use a subset (or all) of its rights. The delegate can provide this token and prove itself (using its own key – the delegation target) to a service. The service, assuming the trust relationships have been established and that the delegator has the right to delegate, can then authorize requests sent subject to delegation rules and trust policies.
For example a custom token is issued from party A to party B. The token indicates that B (specifically B's key) has the right to submit purchase orders. The token is signed using a secret key known to the target service T and party A (the key used to ultimately authorize the requests that B makes to T), and a new session key that is encrypted for T. A proof-of-possession token is included that contains the session key encrypted for B. As a result, B is effectively using A's key, but doesn't actually know the key.
4. Authenticated Request/Reply Key Transfer
In some cases the RST/RSTR mechanism is not used to transfer keys because it is part of a simple request/reply. However, there may be a desire to ensure mutual authentication as part of the key transfer. The mechanisms of WS-Security can be used to implement this scenario.
Specifically, the sender wishes the following:
- Transfer a key to a recipient that they can use to secure a reply
- Ensure that only the recipient can see the key
- Provide proof that the sender issued the key
This scenario could be supported by encrypting and then signing. This would result in roughly the following steps:
1. Encrypt the message using a generated key
2. Encrypt the key for the recipient
3. Sign the encrypted form, any other relevant keys, and the encrypted key
However, if there is a desire to sign prior to encryption then the following general process is used:
1. Sign the appropriate message parts using a random key (or ideally a key derived from a random key)
2. Encrypt the appropriate message parts using the random key (or ideally another key derived from the random key)
3. Encrypt the random key for the recipient
4. Sign just the encrypted key
Most part of this blog post is extracted from WS-Trust 1.4 specification.