I have reviewed the whole draft and you will find comments below starting with five editorials comments. Every other comment is numbered.

Let us start with five typos where there is a duplication of the word "the":

Page 4:

XXS vulnerabilities also allow an attacker to execute code in the context of the browser-based client application and maliciously use a token indirectly through the _the_ client.

Page 11:

The example response in Figure 5 included a refresh token, which the client can use to obtain a new access token when the _the_ previous one expires.

Page 11:

Refreshing an access token is a token request using the "refresh_token" grant type made to the _the_ authorization server’s token endpoint.

Page 13:

Resource servers MUST be able to reliably identify whether an access token is bound using DPoP and ascertain sufficient information about the public key to which the token is bound in order to verify the binding with respect to the _the_ presented DPoP proof (see Section 7.1).

Page 13:

Resource servers supporting DPoP MUST ensure that the _the_ public key from the DPoP proof matches the pubic key to which the access token is bound.


1. Section 1. Introduction

The text states:

     The value of the header is a JWT [RFC7519] that enables the authorization server to bind issued tokens to the public part of the client’s key pair.

A client may use different key pairs.

Change :

"the client’s key pair"

into :

" a client’s key pair".

2. Section 2.Objectives

The text states:

    The primary aim of DPoP is to prevent unauthorized or illegitimate parties from using leaked or stolen access tokens by binding a token to a public key     upon issuance and requiring that the client demonstrate possession of the corresponding private key when using the token.

The objective needs to be described in terms of what ,the mechanism does and not yet at this time for which reasons.

Change into:

     The aim of DPoP is first to require a client to demonstrate possession of a public key when requesting an access token or a refresh token to an AS      where the AS will then bind that public key upon a token issuance and, then to demonstrate the possession of a public key included into a token
     when presenting a refresh token to an AS or an access token to a RS.


3. The next sentence looks odd as far as the English grammar is considered.

    This constrains the legitimate sender of the token to only the party with access to the private key and gives the server receiving the token added assurances
    that the sender is legitimately authorized to use it.

With the proposed change above, this sentence looks unnecessary and could be deleted.

4. Section 3 Concepts Page 5

In order to make crystal clear that they are to different DPoP Proofs, (DPoP Proof 1) and (DPoP Proof 2) should be shown on the figure as proposed below:

*+--------++---------------+
||--(A)-- Token Request ------------------->||
| Client |(DPoP Proof 1)| Authorization |
|||Server|
||<-(B)-- DPoP-bound Access Token ----------||
||(token_type=DPoP)+---------------+
||
||
||+---------------+
||--(C)-- DPoP-bound Access Token --------->||
||(DPoP Proof 2)|Resource|
|||Server|
||<-(D)-- Protected Resource ---------------||
||+---------------+
+--------+
Figure 1: Basic DPoP Flow
*
5. The text states:

     The basic steps of an OAuth flow with DPoP are shown in Figure 1:

     *(A) In the Token Request, the client sends an authorization grant (e.g., an authorization code, refresh token, etc.) to the authorization server         in order to obtain an access token (and potentially a refresh token).The client attaches a DPoP proof to the request in an HTTP header.

At the end of the sentence, add : (DPoP Proof 2).


6. The text states:

     *(C) To use the access token the client has to prove possession of the private key by, again, adding a header to the request that carries the DPoP proof.

Change into:

     *(C) To use the access token the client has to prove possession of the private key by using a header to the request that carries another DPoP proof (DPoP Proof 2).


7. Section 4.DPoP Proof JWTs

The text states:

     A valid DPoP proof demonstrates to the server that the client holds the private key that was used to sign the JWT.

For avoiding misunderstandings, it would be better to say that this applies to DPoP Proof JWTs and that it applicable for both ASs and RSs.

Proposed change:

     A valid DPoP proof demonstrates to a server, (i.e. an AS or a RS), that the client holds the private key that was used to sign a DPoP Proof JWT.

8. The text states:

     This enables authorization servers to bind issued tokens to the corresponding public key (as described in Section 5) and for resource servers to verify      the key-binding of tokens that it receives (see Section 7.1), which prevents said tokens from being used by any entity that does not have access to the private key.

The end of the sentence is using the wording "(...) which prevents said tokens from being used by any entity that does not have access to the private key".

a) It is proposed to remove the end of the sentence, i.e.: "), which prevents said tokens from being used by any entity that does not have access to the private key".     A new section 8.2 is being proposed (DPoP private key usage). See comment 17 which addresses this issue.

At this time, it would be adequate to add that a DPoP Proof JWT can only be used once.

b) Additional proposed text:

     A DPoP proof JWT is intended to be only usable once: it includes claims that allows an AS or a RS to detect replays.


9. Section 4.2.DPoP Proof JWT Syntax

The text states:

     The body of a DPoP proof contains at least the following claims:

(...)

     *"jti": Unique identifier for the DPoP proof JWT (REQUIRED).The value MUST be assigned such that there is a negligible probability that the same value         will be assigned to any other DPoP proof used in the same context during the time window of validity.Such uniqueness can be accomplished by encoding         (base64url or any other suitable encoding) at least 96 bits of pseudorandom data or by using a version 4 UUID string according to [RFC4122].The "jti" can         be used by the server for replay detection and prevention, see Section 8.1.

This looks like over engineering. 32 bits of pseudorandom data will be sufficient if used in conjunction with the "iat" claim. If the server (AS or RS) uses a concatenation of both the "iat" and the "jti" this makes 2 ^ 32 possibilities within the same second during a time windows of a few minutes (about 120 seconds).

To highlight the fact that "jti" is a complement of "iat", it should be placed after "iat" in the description".

Proposed change:

*"jti": JWT identifier that complements the "iat" claim to handle replay protection for a given server (REQUIRED).

      The value MUST be assigned such that there is a negligible probability that the same value will be assigned to any other DPoP proof received by the server       within the same second during a short time window of validity (i.e. a few minutes only) . This MUST be accomplished by encoding 32 bits of pseudorandom data.


10. Figure 3.

The end of figure 3 is as follows:

(...)
     {
"jti":"-BwC3ESc6acc2lTc",
"htm":"POST",
"htu":"https://server.example.com/token";,
"iat":1562262616
}
Figure 3: Example JWT content of a "DPoP" proof

In order to follow the ordering of the claims, as proposed before, it would be more adequate to write it as follows:

(...)
     {
"htm":"POST",
"htu":"https://server.example.com/token";,
"iat":1562262616
"jti": EE238F3F,

}
Figure 3: Example JWT content of a "DPoP" proof

Please note that the "jti" value is shorter.


11. The text below figure 3 states:

      Of the HTTP content in the request, only the HTTP method and URI are included in the DPoP JWT, and therefore only these 2 headers of the request
      are covered by the DPoP proof and its signature.

The four claims should be covered by the signature.

Proposed change:

Of the HTTP content in the request, only the HTTP method ("htm" claim"), the URI ("htu" claim), the issuance time of the DPoP proof JWT ("iat" claim)     and the DPoP proof JWT identifier ( jti "claim") are included in the DPoP JWT, and therefore only these 4 headers of the request are covered by the DPoP proof
    and its signature.

12. Section 4.3.Checking DPoP Proofs

The text states:

     To check if a string that was received as part of an HTTP Request is a valid DPoP proof, the receiving server MUST ensure that

1.the string value is a well-formed JWT,
2.all required claims are contained in the JWT,

It would be wise to indicate what are "all the required claims"

Change the last above sentence into:

2.all required claims are contained in the JWT, at least the "htm" claim, the "htu" claim, the "iat" claim and the "jti "claim.


13. The text states:

     5.that the JWT is signed using the public key contained in the "jwk" header of the JWT

Typo: Since the sentence above all these conditions already includes the word "that" (/the receiving server MUST ensure that/),
the word "that" in this sentence should be removed.

Change into:

     5.the JWT is signed using the public key contained in the "jwk" header of the JWT


14. The text continues with:

8.the token was issued within an acceptable timeframe (see Section 8.1), and
9.that, within a reasonable consideration of accuracy and resource utilization, a JWT with the same "jti" value has not previously been received
            at the same URI (see Section 8.1).

References to text located in the "Security considerations" section should be avoided.

In addition this text needs to be revised in order to take benefit of the use of a combination of "iat" and "jti".

Change the two last above sentences into:

[the receiving server MUST ensure that]

8.the "iat" time is within an acceptable timeframe (a few seconds skew SHOULD be allowed).

           Note: To accommodate for clock offsets, the server SHOULD accept DPoP proofs that carry an "iat" time in the reasonably near future (e.g., a few seconds in the future).

9.and that, in order to accept the DPoP proof JWT, both the "iat" claim and the associated "jti" claim have not already been seen before during the time window
            used by the server; otherwise refuse the DPoP proof JWT.


15. Section 5.DPoP Access Token Request (Page 12)

The text states:

An authorization server MAY elect to issue access tokens which are not DPoP bound, which is signaled to the client with a value of "Bearer" in the "token_type" parameter
       of the access token response per [RFC6750].

This has a consequence for the client which is not mentioned but should be mentioned.

Proposed additional text:

       When the client receives an access token, it MUST check whether the "token_type" parameter of the access token response contains a value of "Bearer" or a value of " DPoP".        If a "Bearer" token is received whereas the client indeed wanted a "DPoP" token, then the client SHALL discard the response.


16. Section 8.1.DPoP Proof Replay

Replace the current text with:

      In order to prevent the replay of a token at the same endpoint (the HTTP endpoint), only a single DPoP proof JWT which contains the same claims is accepted during a time window       set by the server.This prevents both legitimate and illegitimate clients to use twice a same DPoP proof JWT. A JWT that is still valid can be associated with a new DPoP proof JWT
     and hence can be re-used during its validity period.

      The mechanism which is based on both the "iat" and the "jti" claims occupies 64 bits of memory (32 +32 bits) per DPoP proof JWT that has been accepted.
      The entries can be flushed after the end of the time window.

      Clients have no way to know in advance the exact value of a time window used by a server.If they wait too long for using a DPoP proof JWT, a DPoP proof JWT / access token pair
      may be rejected, even it is cryptographically correct.

17. Add a new section 8.2:

      8.2.DPoP private key usage

      A legitimate client does not necessarily need to "have access to" the private key that is being used to sign a DPoP proof JWT, but can simply "use" the private key without knowing its value.       This means that it is able to perform cryptographic computations either for its own benefit or for the benefit of other users. In the later case, an illegitimate client may be given both an access token       and a DPoP Proof JWT by a legitimate client.The fact that a DPoP proof JWT can only be used once does not protect against this collaborative attack.


18. Currently there is no "Privacy considerations" section, whereas there should be one.

This point is addressed in a separate email since it proposes new text.

Denis


_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Reply via email to