Hi Paul, I hope you are doing well. On request from Jim Schaad who acts as the document shepherd, we have submitted draft-ietf-ace-dtls-authorize-13 including the changes proposed below. Please feel free to contact us if you do not agree with these proposals.
Grüße Olaf Olaf Bergmann <bergm...@tzi.org> writes: > Thank you very much for your review and the very useful suggestions > therein. Please find our comments inline. All issues that have not been > resolved in the prior discussion threads with Ben and Jim have been > addressed in the editor's copy of the draft. > > Paul Kyzivat <pkyzi...@alum.mit.edu> writes: > >> I am the assigned Gen-ART reviewer for this draft. The General Area >> 1) MAJOR: Management of token storage in RS >> >> There seems to be an expectation that when the client uploads an >> access token that the RS will retain it until the client attempts to >> establish a DTLS association. This seems to require some sort of >> management of token lifetime in the RS. The only discussion I can find >> of this issue is the following in section 7: >> >> ... A similar issue exists with the >> unprotected authorization information endpoint where the resource >> server needs to keep valid access tokens until their expiry. >> Adversaries can fill up the constrained resource server's internal >> storage for a very long time with interjected or otherwise retrieved >> valid access tokens. >> >> This seems to imply a normative requirement to keep tokens until their >> expiry. But I find no supporting normative requirements about >> this. And, this section only presents it as a DoS attack, rather than >> a potential problem with valid usage. > > There is no normative requirement to keep tokens until their expiry. A > resource server could dispose of a stored token at any time, forcing a > client to retrieve another access token for subsequent requests directed > to the respective resource server. The only requirement imposed on the > resource server is that it must not send data to the client if there is > no valid access token that authorizes this action (this is described in > Section 3.4). > > Usually, a resource server implementation would keep the received access > tokens as long as it deems useful for the intended interaction with the > client, with the expiration time being an upper bound for the storage > time (see Section 3.4). > >> ISTM that there is an implied requirement that the RS have the >> capacity to store one access token for every PoP key of every >> authorized client. If so, that ought to be stated. If not, then some >> other way of bounding storage ought to be discussed. > > The ACE framework already states in Section 5.8.1 that the "RS > MUST be prepared to store at least one access token for future use" > and "RECOMMENDS that an RS stores only one token per > proof-of-possession key". This is now re-iterated in this profile > as suggested: > > NEW: > > A resource server MUST have the capacity to store one access token > for every proof-of-possession key of every authorized client. > > Although a reasonable implementation > of this profile would try to provide storage for every PoP key of > every authorized client, this could easily get out of bounds with the > separate upload mechanism to the authz-info resource as pointed out in > the cited paragraph from the security considerations. This now has > been elaborated as follows: > > OLD: > > A similar issue exists with the unprotected authorization > information endpoint where the resource server needs to keep valid > access tokens until their expiry. Adversaries can fill up the > constrained resource server's internal storage for a very long time > with interjected or otherwise retrieved valid access tokens. > > NEW: > > A similar issue exists with the unprotected authorization > information endpoint when the resource server needs to keep valid > access tokens for a long time. Adversaries could fill up the > constrained resource server's internal storage for a very long time > with interjected or otherwise retrieved valid access tokens. To > mitigate against this, the resource server should set a time > boundary until an access token that has not been used until then > will be deleted. > >> 2) MAJOR: Missing normative language >> >> I found several places where the text seems to suggest required >> behavior but fails to do so using normative language: >> >> * In section 3.3: >> >> ... Instead of >> providing the keying material in the access token, the authorization >> server includes the key identifier in the "kid" parameter, see >> Figure 7. This key identifier enables the resource server to >> calculate the symmetric key used for the communication with the >> client using the key derivation key and a KDF to be defined by the >> application, for example HKDF-SHA-256. The key identifier picked by >> the authorization server needs to be unique for each access token >> where a unique symmetric key is required. >> ... >> Use of a unique (per resource server) "kid" and the use of a key >> derivation IKM that is unique per authorization server/resource >> server pair as specified above will ensure that the derived key is >> not shared across multiple clients. >> >> The uniqueness seems to be a requirement. Perhaps "needs to be unique" >> should be "MUST be unique". (And something similar for the IKM.) > > We have changed "needs to be unique" to "MUST be unique" in the first > paragraph as suggested, and "the use of a key derivation IKM that is > unique" to "the use of a key derivation IKM that MUST be unique" in the > second paragraph you have mentioned. > >> * Also in section 3.3: >> >> All CBOR data types are encoded in CBOR using preferred serialization >> and deterministic encoding as specified in Section 4 of >> [I-D.ietf-cbor-7049bis]. This implies in particular that the "type" >> and "L" components use the minimum length encoding. The content of >> the "access_token" field is treated as opaque data for the purpose of >> key derivation. >> >> IIUC the type of serialization and encoding is a requirement. Will >> need some rewording to make it so. > > I take it that you and Ben have agreed that the example description does > not necessarily need normative language as the description of this key > derivation procedure is meant as an example how the authorization server > and the resource server can securely agree on a shared secret to be used > between the client and the resource server. > >> * In section 3.3.1: >> >> ... To >> be consistent with the recommendations in [RFC7252] a client is >> expected to offer at least the ciphersuite TLS_PSK_WITH_AES_128_CCM_8 >> [RFC6655] to the resource server. >> >> I think "is expected" should be "MUST". > >>From [1] I take it that you have been ok with the current wording to > indicate that this means a MUST implement while there may be cases where > a client knows that it can offer something else. > > [1] https://mailarchive.ietf.org/arch/msg/ace/V8WXg8dhE3UkDxbIbOK-D0VmD9U/ > >> * Also in section 3.3.1: >> >> ... This >> specification assumes that the access token is a PoP token as >> described in [I-D.ietf-ace-oauth-authz] unless specifically stated >> otherwise. >> >> I think "assumes ... unless" should be "MUST ... unless". > > We are happy to mandate PoP tokens. In the beginning when > the protocol was intended to be similar to OAuth, people wanted to be > have some loophole for other token types. The text now has been > changed as proposed in [2] to > > [2] https://mailarchive.ietf.org/arch/msg/ace/ddtl8a4fmvEdXhEWc3HQtv6RQgo/ > > OLD: > > This specification assumes that the access token is a PoP token as > described in [I-D.ietf-ace-oauth-authz] unless specifically stated > otherwise. > > NEW: > > This specification implements access tokens as proof-of-possession > tokens. > >> * Also in section 3.3.1: >> >> ... New access tokens issued by the >> authorization server are supposed to replace previously issued access >> tokens for the respective client. >> >> Is this normative? Should "are supposed to" be "MUST"? > > The ACE profiles would continue to work if there were multiple > access tokens for a single resource server/client association in > effect at a particular point in time. But neither OAuth nor ACE have > defined algorithms for merging authorization rules, and therefore, the > ACE WG has decided to keep things simple and assume that a newer > access token always replaces the old one. > > As a consequence, the framework document and the profiles are written > as if a newer access token always replaces older access tokens for a > respective association between resource server and client. To make > this assumption more clear, we have removed the "are supposed to". The > text now reads > > OLD: > > New access tokens issued by the authorization server are supposed to > replace previously issued access tokens for the respective client. > > NEW: > > New access tokens issued by the authorization server replace > previously issued access tokens for the respective client. > >> 3) MINOR: Insufficient specification >> >> (I'm waffling whether this is minor or major.) >> >> There are a couple of places where what seem to be requirements are >> stated too vaguely to be implemented consistently: >> >> * In the previously mentioned paragraph in 3.3.1: >> >> ... This >> specification assumes that the access token is a PoP token as >> described in [I-D.ietf-ace-oauth-authz] unless specifically stated >> otherwise. >> >> The "unless specifically stated otherwise" is too vague to be >> normative. How would the alternative be indicated? Is this an escape >> hatch for future extensions? If so, it needs more work to make that >> clear and to open a path for that future work. > > See above. Basically, we now require PoP tokens. (An alternative type of > access token would have been indicated with the token_type claim as > defined in the framework document.) > >> * Also in section 3.3.1: >> >> ... The resource server therefore must >> have a common understanding with the authorization server how access >> tokens are ordered. >> >> The last statement ("must have a common understanding") is >> mysterious. IIUC section 4 is covering the same topic in a less >> mysterious way. > > The reason for this seemingly mysterious statement is that it is > very difficult to define a strict order on access tokens that works > for all intended use cases the protocol has initially been designed > for. This was discussed in [3]. > > [3] https://mailarchive.ietf.org/arch/msg/ace/x9JFbn0a6CRdsIwmQdKReGu5q1E/ > > The only resolution the working group had agreed on by then was to treat > use the last token that was received as the newest. There is some text > in the framework that tells how the resource server might be able to > order access tokens. The most general would be to use the cti claim, > therefore the following text has been added to clarify this: > > NEW: > > The authorization server may, e.g., specify a "cti" claim for the > access token (see Section 5.8.3 of [I-D.ietf-ace-oauth-authz] to > employ a strict order. > > >> 4) NIT: Subsection organization >> >> Both 3.2 and 3.3 share a common structure: >> >> * The section begins with discussion of the interaction between the >> client and the AS. >> >> * it is followed by a subsection discussing the interaction between >> the client and the RS. >> >> It is odd to have a section with a single subsection. And the >> structure isn't easily discerned from the TOC. >> >> I suggest it would be clearer if each of these sections had *two* >> subsections, one covering the AS interactions and the other the RS >> interactions. IOW, put the material covering the AS interactions into >> a new subsection. > > Good point, this is indeed very odd. The structure now has been changed > to include a subsection "Access Token Retrieval from the Authorization > Server" for each of the two modes where the interaction between client > and authorization server is described. > > Grüße > Olaf _______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
