Subject: Re: [Txauth] Questions on key validations by RS

From: Justin Richer <[email-masked]>
Date: Sat, 1 Feb 2020 16:49:16 -0500

Hi Ryo,

You are absolutely right that the “JWSD” method from the spec only works with POST and PUT methods, since it only protects the body. This is a known major limitation of this method, in addition to it not protecting headers or adding replay protection. I only put this method in as a stop-gap demonstration of the concept of a general key presentation mechanism, and it does manage to work OK for the tx endpoint (since there’s always a body there). I think it’s debatable whether the specifics of this method are generally useful.

Regardless, for presentation to the RS, I think that HTTP Signing and MTLS are much more useful general-purpose key binding mechanisms. Even DPoP, which has its own limitations, is usable across different method types and could be used here.

I think it’s important for TxAuth that the token presentation mechanism and the client key proofing mechanism used during the transaction are separable. It makes the most sense for the client to be able to use the same thing in both places, but I don’t think that should be a hard equivalence since that puts requirements on the RS that might not apply.

 — Justin

> On Jan 31, 2020, at 3:13 PM, Ryo Kato <[email-masked]> wrote:
> 
> Hi,
> 
> I'm reading the draft 04, and I have some questions now.
> 
> The draft says:
> ```
> The Resource Server (RS) accepts tokens from the RC and validates them
> ```
> and also
> ```
> Any keys presented by the RC to the AS or RS MUST be validated as part of
> the transaction in which they are presented.
> ```
> 
> Therefore, I understand that the *RS* MUST validate the proof of
> possession of
> RC's keys when accepting tokens from the RC.
> (And I understand this procedure is for so called "sender-constrained
> token")
> 
> However, I think it is a bit ambiguous about the way for *RS* to
> validate that keys.
> 
> Assuming the `proof` parameter is `jwsd`, i.e. Detached JWS.
> 
> The current draft 04 says:
> 
> ```
> the RC takes the serialized body of the request and signs it
> ```
> 
> Yes, RC's transaction (continuation) requests to AS are always HTTP POST
> requests,
> and their body is always a non-empty JSON object.
> 
> Whereas, RC's requests to *RS* are not always POST, so they can be plain
> GET requests.
> Since GET request body is missing in general, the input for JWS will be
> missing too.
> 
> In this case, what should we take for JWS instead of request body?
> 
> - Ryo
> 
> 
> 
> -- 
> Txauth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/txauth

---

From: Ryo Kato <[email-masked]>
Date: Mon, 3 Feb 2020 00:52:23 +0900

Hi Justin,

Thank you for detailed explanation.

> I think it’s important for TxAuth that the token presentation
mechanism and the client key proofing mechanism used during the
transaction are separable.

I agree with you.

In the future, more detailed instructions would help RS implementers
because RS will have to accept all possible algorithms (HTTP Signing,
MTLS, DPoP, and so on) without any prior negotiation.

- Ryo

---

From: Justin Richer <[email-masked]>
Date: Mon, 3 Feb 2020 14:54:40 -0500

> MTLS, DPoP, and so on) without any prior negotiation.

I see what you’re saying, but I don’t think that’s completely true. 

It’s going to be between the RS and AS to figure out what kind of tokens are issued and accepted for a given API. So if the RS doesn’t support the signing mechanism associated with a given token, it wouldn’t accept that token. If an AS is issuing tokens that its RS’s can’t accept (and validate), then that’s a problem with the relationship between the AS and the RS. 

I also want to note that there are many implementations out there that let the API offload the processing of the token request to another component, like a gateway or a proxy, or use another external service to check the incoming request’s parameters to see if they fit the security policy for the API in question. In all of these cases, the “RS” is the logical combination of all of these, and so the “RS” can be adapted to accept different types through its security layer and not necessarily the API code directly.

 — Justin