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