Hi Marco, Thanks, very helpful as always! I have implemented all the comments in this PR https://github.com/ace-wg/ace-oscore-profile/pull/44 , if you give me the OK I can merge and upload a new submission. Happy to see that the comments were about clarifications and editorials.
Inline detailed answers. Thanks again! Francesca From: Marco Tiloca <marco.til...@ri.se> Date: Thursday, 19 November 2020 at 17:04 To: <draft-ietf-ace-oscore-prof...@ietf.org>, Ace Wg <ace@ietf.org> Subject: Re: [Ace] WGLC draft-ietf-ace-oscore-profile-13.txt Resent from: <alias-boun...@ietf.org> Resent to: Francesca Palombini <francesca.palomb...@ericsson.com>, <ludwig.se...@combitech.se>, Göran Selander <goran.selan...@ericsson.com>, <martin.gunnars...@ri.se> Resent date: Thu, 19 Nov 2020 08:03:54 -0800 (PST) Hello OSCORE profile authors and ACE, Please, find below some WGLC comments. Hope it helps! Best, /Marco Section 1 * s/is not done by a/is not achieved through a FP: Ok, fixed. * s/after the first OSCORE exchange/after the first message exchange using OSCORE FP: Ok, fixed. Section 2 * "This specific identifier, encoded as a byte string, is assigned by the AS to be unique in the sets of its OSCORE Security Contexts ..." To avoid confusion, it's probably better to say "unique among the issued sets of OSCORE input material", since the AS can have actual OSCORE Security Contexts it uses to communicate with Clients or Resource Servers. FP: Ok, fixed. Replaced with OSCORE security input materials * Referring to 'id' as specific identifier, the text says: "and is not used as input material to derive the full OSCORE Security Context." That's correct, but then the identifier is later included in Table 1 "OSCORE_Input_Material Parameters" :-) Perhaps it's fine to just revert to OSCORE_Security_Context_Object, both for the name of Table 1 and in different spots of the text? They would still consider 'id' as OSCORE Input Material Identifier, while aligned with the registry name from Section 9.4. FP: I see your point, but the name was source of discussion before and I'd rather not go back on that. I don't think it is a problem that the 'id' is both part of the "OSCORE_Input_Material" object and also not part of the actual input material. After all it needs to be part of the object to identify it. What I did is to change its CBOR label though, to have it as 0, since I think that makes more sense that to be in the middle of other input materials. Note that this is a change that will affect implementations. * s/If the request verifies/If the request is successfully verified FP: Ok, fixed. * s/until token expiration/until token deletion, due to e.g. expiration or revocation FP: thanks for this comment. I did only keep expiration as example, * s/the same or different/the same or a different one FP: Ok, fixed. * Figure 1 can also show the achievement of mutual authentication, following the OSCORE exchange at the end FP: Good point, added. Section 3.1 * s/object. kid field carrying/object, with the kid field carrying FP: Ok, fixed. Section 3.2 * "... profile negotiation can be omitted" - I think "profile signaling" better reflects what may happen here, see also the beginning of the paragraph. FP: Ok, fixed. * s/in the the/in the FP: Ok, fixed. * s/in the 'cnf' parameter of the token/in the 'cnf' claim of the token FP: Ok, fixed. Section 3.2.1 * In the text entries following Table 1, the CBOR integer labels need to be aligned with the CDDL summary at the end of the section. FP: I think it was? Now I moved id to index 0, so I switched the order there too. * s/This parameter identifies the OSCORE_Input_Material/This parameter identifies the OSCORE_Input_Material object FP: I will let the RFC editors decide on that one :) Don't want to become too verbose if it's not needed. * s/the "id" type is byte string/the "id" type is bstr FP: ah, good point. I actually changed all the description to extend the type (so byte string instead of bstr, etc), in order not to use CDDL in text. * This version -13 has removed 'clientId' and 'serverId' from Table 1 and thus as code points from the "OSCORE Security Context Parameters" registry. No strong need to include them back, but even if this profile does not use them and does not send them on the wire, I think they still belong to the same namespace, since they are descriptive of a security context and are in fact also used as input material to derive it :-) FP: I agree with that, and think the first draft to use them will register them. The registration of the OSCORE_Input_Material does not specify how this material is used, that is up to the draft describing the derivation process, so it does not make sense to register them here without explaining the derivation process using those parameters. Section 4 * s/the RS and client authenticates themselves/the RS and client authenticate each other FP: Ok, fixed. * s/successfully verified the response from the RS/successfully verified a response from the RS as protected with the established OSCORE context (similar occurrences are also later in the text) FP: Ok, fixed. Section 4.1 * In the first paragraph, I suggest to rephrase as "and the posted access token is still retained". That doesn't require to explicitly mention "valid", since asserting especially validity can be non-trivial for the client, e.g. in case of Token revocation. (similar occurrences are also later in the text) FP: I am not sure about this one: I don't think talking about "retaining" an access token is precise enough (a token might be "retained" in memory, but expired). "Valid" to me seems less ambiguous. I would expect implementations to have a way to mark token as valid or non valid (e.g. if expired or revoked). What woud be difficult for implementations to assert validity? * In the second paragraph, I suggest to extend the ending as: "... makes sure that it does not collide with any of its Recipient IDs currently used. These include also Recipient IDs used as ID1 value for ongoing executions of this profile." FP: Good point, I think I got it. Rephrased it with " nor with any other identifier ID1 if the client is executing this exchange with a different RS at the same time." * s/the client MUST wrap the token and N1 in a CBOR map/the client MUST wrap the token, N1 and ID1 in a CBOR map FP: Ok, fixed. * s/using the "access_token" parameter/using the 'access_token' parameter FP: Ok, fixed. * In the sixth paragraph, the last sentence says "... as different nonces will be used." Doesn't the client and the RS also negotiate new IDs like they did in the first posting of the same original token? FP: yes, but the client might decide to reuse the same ID, I don't really see a problem with that. * In the last paragraph: "The client MUST only send the access token in the payload, no nonce or identifier are sent." Just to be sure, can you expand on this request format? I suppose the client still uses Content-Format "application/ace+cbor", just including only the 'access_token' entry in the map. Correct? FP: Yes that is correct. The request is the same as in Figure 10 with the exception that it is protected with OSCORE and that no nonce nor ids are sent. * In the last paragraph: "... the RS will replace the old token with the new one, maintaining the same Security Context." This replacement step can be expanded for clarity. A simple 1-to-1 replacement would overwrite also the stored 'cnf' claim from the original token, among other things. So it should be more about selectively replacing some information originally coming the first token, while keeping some other from it. What to actually replace should include, for instance, information related to access rights (e.g. scope), and to the new token's lifetime (exp, exi). FP: I believe what you were commenting here (i.e. the RS behavior) is actually described in details in section 4.2, starting with "If the RS receives the token in a OSCORE protected message...". I only want to give the intuition here, focusing more on the client without go into the details of what the RS has to do as a consequence, which is why I am tempted to not make a change here. But if you think something is missing from 4.2, let me know and I'll see if we can expand there. * While reading this, I was wondering if one could repost the same first token to rekey the OSCORE context. This is mentioned at the end of Section 4.3, but anticipating the possibility here and adding a forward pointer to Section 4.3 would help. FP: I added a paragraph in section 4.1 (starting with "The client may also chose to re-POST the access token...") Section 4.1.1 and Section 4.1.2 * The first sentence captures the case where the first token is posted or re-posted. It can be rephrased to cover also the posting of a token for updating access rights, where these parameters are not included. FP: Ok, added text at the end of the sentence. Section 4.2 * "any of the mandatory parameters from the AS or the identifier) ..." It's worth making it explicit that the mentioned identifier is 'id'. FP: I actually meant the identifier id1. Added it. * s/in the 'osc'/in the 'osc' field FP: Ok, done. * "... the RS must respond" --- Should this not be a MUST ? FP: No, this requirement comes from the framework, so it is non normative (the normative one is "The RS MUST follow the procedures defined in section 5.8.1 of [I-D.ietf-ace-oauth-authz]") * s/is different from the ace_client_recipientid/is different from the value specified in the received 'ace_client_recipientid' parameter FP: Ok, done. * Second paragraph after Figure 11 - s/MUST discard/MUST ignore FP: Ok, done. - s/the "cnf" parameter of/the 'cnf' claim of FP: Ok, done. - s/matches the OSCORE Input/matches with the identifier of the OSCORE Input FP: Ok, done. - Related to a previous comment about token replacement, some information has to be retained from the first token, as not present in the new one. FP: I am not sure how to implement this comment without making it very hard to read. I trust readers at this point will understand what "discard the old token and associate the new token" means. -s/in the "cnf" parameter/in the 'cnf' claim FP: Ok, done. * It can happen that all is fine for the RS, it installs the OSCORE Security Context, it responds to the client, and the response gets lost. In this case: - After a timeout expiration, can the client simply repost the same token as mentioned at the end of Section 4.3? This can be another reason for reposting the original token, to mention in the sixth paragraph of Section 4.1. FP: Yes, added. - Should the server delete the token and the OSCORE Security Context, if not receiving an OSCORE protected request from the client before a timeout expires? After all, it's reasonable to assume that a client sends a request right away or not long after the token post is completed. If this is included, it would be one more point in the bullet list for the RS in Section 6. FP: It is reasonable, however I don't want to add it to Section 6 as I don't want to make it a requirement to the RS. It is up to applications to define policies for such a timeout. We make it clear that it's only after the first OSCORE exchange has happened that C and RS are assure that the exchange succeeded. How long to wait, I think should be out of scope. Section 4.2.1 and 4.2.2 * The first sentence captures the case where the first token is posted or re-posted. It can be rephrased to cover also the posting of a token for updating access rights, where these parameters are not included. FP: Ok, done Section 4.3 * s/Secret from the parameter, received/Secret from the parameter received FP: Ok, done * If the client stops the exchange, it should also unlock the ID1 value previously offered. FP: I believe this is implementation details. I think this should be covered by the clarifications above. * s/to RS/to the RS FP: Ok, done * The end of the last paragraph mentions possibly reposting the same first token to rekey the OSCORE context. Consistently with the fourth paragraph of Section 4, I suggest to mention here again that this request is not protected, since not related to updating access rights. FP: Ok, done Section 5 * s/profile, other/profile, but other FP: s/,/; instead, but done Section 6 * s/context expires/context expires or is revoked (2 instances) FP: Again, I am hesitant to add revoked here, as the framework barely touches on revocations of tokens, and explicitely states that expiration is the norm instead. * In the fourth bullet point, isn't this actually fine if the reposted token is exactly the original first token? In that case, new nonces (and I guess also IDs) are exchanged. FP: This is fine, but it means the RS is wishing to re-derive a new context, so the old one must be discarded. * I think there should be one more bullet point in the client list, for when the client receives back ID2 == ID1 from the RS, after having reposted the original first access token. (This relates to a previous comment for Section 4.1; I thought a reposting of the first original token involves an exchange of new nonces as well as of new IDs) FP: Why? I don't understand why this is not already covered. Ah ok so maybe this is not valid anymore? Section 7 * s/usecase/use case FP: Ok, done * s/for a client/for a same client (2 instances) FP: Ok, done (I am sure the RFCEditor will change this to something else too :) ) * I think it's better to expand C and Cs to "client" and "clients" FP: Ok, done On 2020-11-08 23:51, Daniel Migault wrote: Hi, This email starts a WGLC for the draft draft-ietf-ace-oscore-profile until Monday November 23. We would like to send the document back to the IESG with sufficient confidence, so please take the time to review it carefully provide comments and feed backs. Note that also that the document (13) is being reviewed by the security directorate. Yours, Daniel [1] https://datatracker.ietf.org/doc/draft-ietf-ace-oscore-profile/<https://protect2.fireeye.com/v1/url?k=561b951b-0980ac2a-561bd580-86e2237f51fb-7e8ff0f2b460277b&q=1&e=50e404d5-8770-4cd3-bd41-476381ce5ab8&u=https%3A%2F%2Feur02.safelinks.protection.outlook.com%2F%3Furl%3Dhttps%253A%252F%252Fdatatracker.ietf.org%252Fdoc%252Fdraft-ietf-ace-oscore-profile%252F%26data%3D04%257C01%257Cmarco.tiloca%2540ri.se%257C330189d7d82b48dd1e8e08d88438f043%257C5a9809cf0bcb413a838a09ecc40cc9e8%257C0%257C0%257C637404727980974848%257CUnknown%257CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%253D%257C3000%26sdata%3DDCzcOuQ7MnBLs0hxiHbIAi%252B1VjBHLBJRzi4N8P9VDV4%253D%26reserved%3D0> ---------- Forwarded message --------- From: <internet-dra...@ietf.org<mailto:internet-dra...@ietf.org>> Date: Tue, Oct 27, 2020 at 12:14 PM Subject: [Ace] I-D Action: draft-ietf-ace-oscore-profile-13.txt To: <i-d-annou...@ietf.org<mailto:i-d-annou...@ietf.org>> Cc: <ace@ietf.org<mailto:ace@ietf.org>> A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Authentication and Authorization for Constrained Environments WG of the IETF. Title : OSCORE Profile of the Authentication and Authorization for Constrained Environments Framework Authors : Francesca Palombini Ludwig Seitz Göran Selander Martin Gunnarsson Filename : draft-ietf-ace-oscore-profile-13.txt Pages : 32 Date : 2020-10-27 Abstract: This memo specifies a profile for the Authentication and Authorization for Constrained Environments (ACE) framework. It utilizes Object Security for Constrained RESTful Environments (OSCORE) to provide communication security and proof-of-possession for a key owned by the client and bound to an OAuth 2.0 access token. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ace-oscore-profile/<https://protect2.fireeye.com/v1/url?k=577dc830-08e6f101-577d88ab-86e2237f51fb-0882f337db2a5b4a&q=1&e=50e404d5-8770-4cd3-bd41-476381ce5ab8&u=https%3A%2F%2Feur02.safelinks.protection.outlook.com%2F%3Furl%3Dhttps%253A%252F%252Fdatatracker.ietf.org%252Fdoc%252Fdraft-ietf-ace-oscore-profile%252F%26data%3D04%257C01%257Cmarco.tiloca%2540ri.se%257C330189d7d82b48dd1e8e08d88438f043%257C5a9809cf0bcb413a838a09ecc40cc9e8%257C0%257C0%257C637404727980974848%257CUnknown%257CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%253D%257C3000%26sdata%3DDCzcOuQ7MnBLs0hxiHbIAi%252B1VjBHLBJRzi4N8P9VDV4%253D%26reserved%3D0> There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ace-oscore-profile-13<https://protect2.fireeye.com/v1/url?k=76148db7-298fb486-7614cd2c-86e2237f51fb-6db7a86c1af38e00&q=1&e=50e404d5-8770-4cd3-bd41-476381ce5ab8&u=https%3A%2F%2Feur02.safelinks.protection.outlook.com%2F%3Furl%3Dhttps%253A%252F%252Ftools.ietf.org%252Fhtml%252Fdraft-ietf-ace-oscore-profile-13%26data%3D04%257C01%257Cmarco.tiloca%2540ri.se%257C330189d7d82b48dd1e8e08d88438f043%257C5a9809cf0bcb413a838a09ecc40cc9e8%257C0%257C0%257C637404727980984842%257CUnknown%257CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%253D%257C3000%26sdata%3DOaxJICL6Bp%252Fzt5DMwUWcv04yU07JkvEILCNy17Moqro%253D%26reserved%3D0> https://datatracker.ietf.org/doc/html/draft-ietf-ace-oscore-profile-13<https://protect2.fireeye.com/v1/url?k=6a06d0a5-359de994-6a06903e-86e2237f51fb-61db490b8c9907fa&q=1&e=50e404d5-8770-4cd3-bd41-476381ce5ab8&u=https%3A%2F%2Feur02.safelinks.protection.outlook.com%2F%3Furl%3Dhttps%253A%252F%252Fdatatracker.ietf.org%252Fdoc%252Fhtml%252Fdraft-ietf-ace-oscore-profile-13%26data%3D04%257C01%257Cmarco.tiloca%2540ri.se%257C330189d7d82b48dd1e8e08d88438f043%257C5a9809cf0bcb413a838a09ecc40cc9e8%257C0%257C0%257C637404727980984842%257CUnknown%257CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%253D%257C3000%26sdata%3D7Ac6UdrbH6IBIcm2%252BYWd4iwufwIblv76Nq4VretJZuw%253D%26reserved%3D0> A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-oscore-profile-13<https://protect2.fireeye.com/v1/url?k=71594c3d-2ec2750c-71590ca6-86e2237f51fb-f0c9e033402ad200&q=1&e=50e404d5-8770-4cd3-bd41-476381ce5ab8&u=https%3A%2F%2Feur02.safelinks.protection.outlook.com%2F%3Furl%3Dhttps%253A%252F%252Fwww.ietf.org%252Frfcdiff%253Furl2%253Ddraft-ietf-ace-oscore-profile-13%26data%3D04%257C01%257Cmarco.tiloca%2540ri.se%257C330189d7d82b48dd1e8e08d88438f043%257C5a9809cf0bcb413a838a09ecc40cc9e8%257C0%257C0%257C637404727980994840%257CUnknown%257CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%253D%257C3000%26sdata%3DR%252Bj8cmPnyb8DUEcygCzhOpCJBqQbS8gDalwSsVZtdkw%253D%26reserved%3D0> Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org<https://protect2.fireeye.com/v1/url?k=ca0c6a74-95975345-ca0c2aef-86e2237f51fb-f8b34619f6d31a0a&q=1&e=50e404d5-8770-4cd3-bd41-476381ce5ab8&u=https%3A%2F%2Feur02.safelinks.protection.outlook.com%2F%3Furl%3Dhttp%253A%252F%252Ftools.ietf.org%252F%26data%3D04%257C01%257Cmarco.tiloca%2540ri.se%257C330189d7d82b48dd1e8e08d88438f043%257C5a9809cf0bcb413a838a09ecc40cc9e8%257C0%257C0%257C637404727980994840%257CUnknown%257CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%253D%257C3000%26sdata%3Dpec0ClOMPHj%252BsHa%252ByDBFOvDj90aPwlcEURCcQI6igxI%253D%26reserved%3D0>. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/<https://protect2.fireeye.com/v1/url?k=ec181a40-b3832371-ec185adb-86e2237f51fb-0c8012effe9f8cf8&q=1&e=50e404d5-8770-4cd3-bd41-476381ce5ab8&u=https%3A%2F%2Feur02.safelinks.protection.outlook.com%2F%3Furl%3Dftp%253A%252F%252Fftp.ietf.org%252Finternet-drafts%252F%26data%3D04%257C01%257Cmarco.tiloca%2540ri.se%257C330189d7d82b48dd1e8e08d88438f043%257C5a9809cf0bcb413a838a09ecc40cc9e8%257C0%257C0%257C637404727981004834%257CUnknown%257CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%253D%257C3000%26sdata%3DAJhNeMUrwuGWnKk7Oazo4jFxm0gX1t7hMcI9IvRIQCk%253D%26reserved%3D0> _______________________________________________ Ace mailing list Ace@ietf.org<mailto:Ace@ietf.org> https://www.ietf.org/mailman/listinfo/ace<https://protect2.fireeye.com/v1/url?k=8c63f3f8-d3f8cac9-8c63b363-86e2237f51fb-12f198f7f4eaea38&q=1&e=50e404d5-8770-4cd3-bd41-476381ce5ab8&u=https%3A%2F%2Feur02.safelinks.protection.outlook.com%2F%3Furl%3Dhttps%253A%252F%252Fwww.ietf.org%252Fmailman%252Flistinfo%252Face%26data%3D04%257C01%257Cmarco.tiloca%2540ri.se%257C330189d7d82b48dd1e8e08d88438f043%257C5a9809cf0bcb413a838a09ecc40cc9e8%257C0%257C0%257C637404727981004834%257CUnknown%257CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%253D%257C3000%26sdata%3DwMdtJRfiWur2dXXZw8z84usAX7P9vHcvhGy%252BPNHeDVg%253D%26reserved%3D0> -- Daniel Migault Ericsson _______________________________________________ Ace mailing list Ace@ietf.org<mailto:Ace@ietf.org> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Face&data=04%7C01%7Cmarco.tiloca%40ri.se%7C330189d7d82b48dd1e8e08d88438f043%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637404727981024818%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=SlpecuiDXwgoE5ogL8jSqtUO7zVut7dr1q6VXX8y9Z8%3D&reserved=0<https://protect2.fireeye.com/v1/url?k=1b3a6707-44a15e36-1b3a279c-86e2237f51fb-a3272a3cd4614bf8&q=1&e=50e404d5-8770-4cd3-bd41-476381ce5ab8&u=https%3A%2F%2Feur02.safelinks.protection.outlook.com%2F%3Furl%3Dhttps%253A%252F%252Fwww.ietf.org%252Fmailman%252Flistinfo%252Face%26amp%3Bdata%3D04%257C01%257Cmarco.tiloca%2540ri.se%257C330189d7d82b48dd1e8e08d88438f043%257C5a9809cf0bcb413a838a09ecc40cc9e8%257C0%257C0%257C637404727981024818%257CUnknown%257CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%253D%257C3000%26amp%3Bsdata%3DSlpecuiDXwgoE5ogL8jSqtUO7zVut7dr1q6VXX8y9Z8%253D%26amp%3Breserved%3D0> -- Marco Tiloca Ph.D., Senior Researcher RISE Research Institutes of Sweden Division ICT Isafjordsgatan 22 / Kistagången 16 SE-164 40 Kista (Sweden) Phone: +46 (0)70 60 46 501 https://www.ri.se<https://protect2.fireeye.com/v1/url?k=1ed65bc0-414d62f1-1ed61b5b-86e2237f51fb-af23a91f66f28bf9&q=1&e=50e404d5-8770-4cd3-bd41-476381ce5ab8&u=https%3A%2F%2Fwww.ri.se%2F>
_______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
