Updated Mutual Authentication Guidance #142
Conversation
Updated section on: 1. Mutual Authentication 2. Security Considerations for Client Authentication 3. Added security considerations for protecting the workload configuration
| @@ -584,14 +584,23 @@ To request a replacement Txn-Token, the requester makes a Txn-Token Request as d | |||
| A successful response by the Txn-Token Service to a Replacement Txn-Token Request is a Txn-Token Response as described in {{txn-token-response}} | |||
|
|
|||
| ## Mutual Authentication of the Txn-Token Request | |||
| A workload and Transaction Token Service MUST perform mutual authentication using strong authentication mechanisms. | |||
There was a problem hiding this comment.
since we are not defining what is "strong authentication", should we just stay with "TTS must authenticate workloads requesting TraTs"?
There was a problem hiding this comment.
@gffletch your thoughts? I think Atul has a point - we don't define "strong auth", and probably shouldn't. However, we also want to steer people away from using shared secrets etc.
There was a problem hiding this comment.
we can clarify that in the "Security Considerations", but not bring that into the normative language here.
There was a problem hiding this comment.
I'm fine with saying the TTS must authenticate the requesting workload and then add a security consideration covering the potential exposure if the requesting workload makes a transaction token request from a service that is not the TTS.
There was a problem hiding this comment.
Removed the "strong authentication" requirement and left "mutual authentication"
| * It MUST maintain a limited, pre-configured set of authorized workloads that MAY request Txn-Tokens. | ||
| * It MUST authenticate the requesting workload and confirm that it is included in the list of workloads authorized to request a transaction token. | ||
| * It SHOULD accept workloads credentials such as JWTs or X.509 certificates which MAY be provisiond using mechanisms such as {{SPIFFE}} or other provisioning protocols. | ||
| * It SHOULD use X.509 or JWT credentials in conjunction with MTLS {{RFC8446}}, or another secure authentication protocol, to securely authenticate the requesting workload. |
There was a problem hiding this comment.
AFAIK MTLS is only possible with X.509, right? Using JWT with TLS is possible, but that is not the same as MTLS
There was a problem hiding this comment.
I was overly focused on teasing out credential formats from authentication protocols. What I tried to say was - use X.509 certs with MTLS or use a JWT over TLS. Perhaps I should just say that.
|
|
||
| The requesting workload MUST have a pre-configured location for the Transaction Token Service. It SHOULD rely on mechanisms, such as {{SPIFFE}}, to securely authenticate the Transaction Token Service before making a Txn-Token Request. | ||
| * It MUST have a pre-configured location for the Transaction Token Service. | ||
| * If there is more than one Transaction Token Service, it MUST ensure that it is sending transaction token requests to the right Transaction Token Service to avoid leaking sensitive information like access tokens. |
There was a problem hiding this comment.
The current spec (Section 6) specifies that there is exactly 1 logical TTS per trust domain, so we should drop the new line 600.
There was a problem hiding this comment.
@gffletch I think you pointed this out in one of the issues- are you OK with removing this bullet given the limitation in Section 6?
There was a problem hiding this comment.
We've talked about a logical TTS which doesn't require a single endpoint.
Otherwise our text about the requesting workload needing to ensure it is talking to the correct TTS should cover this.
(I am doing this from my phone:)
There was a problem hiding this comment.
OK, so my take here is that we stick with a single logical TTS. I will add a security consideration to remind people why they should make sure they request transaction tokens to the right server (and not some rogue) and delete line 600.
| @@ -626,6 +635,9 @@ The authorization model within a trust domain boundary is most often quite diffe | |||
| ## Identifying Call Chains | |||
| A Txn-token typically represents the call-chain of workloads necessary to complete a logical function initiated by an external or internal workload. The `txn` claim in the Txn-token provides a unique identifier that when logged by the TTS and each subsequent workload can provide both discovery and auditability of successful and failed transactions. It is therefore strongly RECOMMENDED to use an identifier, unique within the trust domain, for the `txn` value. | |||
|
|
|||
| ## Workload Configuration Protection | |||
| A workload may be configured to access more than one Transaction Token Service to ensure redundency or reduce latency for transaction token requests. The workload configuration should be protected against unauthorized addition or removal of the Transaction Token Services that it may access. An attacker may perform a denial of service attack or degrade the performance of a system by removing Transaction Token Services from the workload configuration. Alternatively, an attacker may add its own Transaction Token Service to the configuration, resulting in the workload sending sensitive information such as Access Tokens to a Transaction token Service under the attacker's control. | |||
There was a problem hiding this comment.
This is conflicting with Section 6, we need to discuss whether we want to change that assumption.
There was a problem hiding this comment.
I can see cases where a transaction token service only issues tokens for a single domain, but I can also imagine that one is shared by two or more domains, especially if it is a more centralised model and it is attached to a Authorisation Server that services an entire enterprise, and must issue txn-tokens to many trust domains.
I do like the simplifications of a single transaction token service per trust domain though, but I wonder if that is how it will get deployed in practice.
What else breaks in the spec if we don't make this assumption?
There was a problem hiding this comment.
Updated to reflect a single logical transaction token service that may have multiple instances.
| @@ -626,6 +634,12 @@ The authorization model within a trust domain boundary is most often quite diffe | |||
| ## Identifying Call Chains | |||
| A Txn-token typically represents the call-chain of workloads necessary to complete a logical function initiated by an external or internal workload. The `txn` claim in the Txn-token provides a unique identifier that when logged by the TTS and each subsequent workload can provide both discovery and auditability of successful and failed transactions. It is therefore strongly RECOMMENDED to use an identifier, unique within the trust domain, for the `txn` value. | |||
|
|
|||
| ## Workload Configuration Protection | |||
| A workload may be configured to access more than one instance of a Transaction Token Service to ensure redundency or reduce latency for transaction token requests. The workload configuration should be protected against unauthorized addition or removal of Transaction Token Service instances. An attacker may perform a denial of service attack or degrade the performance of a system by removing an instance of a Transaction Token Services from the workload configuration. | |||
There was a problem hiding this comment.
Transaction Token Service (there's an extra 's')
In response to #135
Updated section on:
@gffletch @tulshi