Re: [Ace] WGLC draft-ietf-ace-oscore-profile-13.txt

[Marco Tiloca <[e-mail]>]

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

* s/after the first OSCORE exchange/after the first message exchange
using OSCORE


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.

* 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.

* s/If the request verifies/If the request is successfully verified

* s/until token expiration/until token deletion, due to e.g. expiration
or revocation

* s/the same or different/the same or a different one

* Figure 1 can also show the achievement of mutual authentication,
following the OSCORE exchange at the end


Section 3.1

* s/object. kid field carrying/object, with the kid field carrying


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.

* s/in the the/in the

* s/in the 'cnf' parameter of the token/in the 'cnf' claim of the token


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.

* s/This parameter identifies the OSCORE_Input_Material/This parameter
identifies the OSCORE_Input_Material object

* s/the "id" type is byte string/the "id" type is bstr

* 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 :-)
 

Section 4

* s/the RS and client authenticates themselves/the RS and client
authenticate each other
 
* 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)


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)
 
* 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."
 
* 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
 
* s/using the "access_token" parameter/using the 'access_token' parameter

* 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?

* 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?

* 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).
 
* 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.


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.


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'.

* s/in the 'osc'/in the 'osc' field
  
* "... the RS must respond" --- Should this not be a MUST ?
 
* s/is different from the ace_client_recipientid/is different from the
value specified in the received 'ace_client_recipientid' parameter

* Second paragraph after Figure 11

   - s/MUST discard/MUST ignore
  
   - s/the "cnf" parameter of/the 'cnf' claim of

   - s/matches the OSCORE Input/matches with the identifier of the
OSCORE Input

   - 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.
  
   -s/in the "cnf" parameter/in the 'cnf' claim
  
* 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.
  
   - 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.
  
  
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.
  

Section 4.3

* s/Secret from the parameter, received/Secret from the parameter received

* If the client stops the exchange, it should also unlock the ID1 value
previously offered.

* s/to RS/to the RS

* 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.


Section 5

* s/profile, other/profile, but other


Section 6

* s/context expires/context expires or is revoked   (2 instances)

* 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.

* 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)


Section 7

* s/usecase/use case

* s/for a client/for a same client   (2 instances)

* I think it's better to expand C and Cs to "client" and "clients"


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://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-ace-oscore-profile%2F&data=04%7C01%7Cmarco.tiloca%40ri.se%7C330189d7d82b48dd1e8e08d88438f043%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637404727980974848%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=DCzcOuQ7MnBLs0hxiHbIAi%2B1VjBHLBJRzi4N8P9VDV4%3D&reserved=0>
>
> ---------- Forwarded message ---------
> From: <[e-mail] <mailto:[e-mail]>>
> Date: Tue, Oct 27, 2020 at 12:14 PM
> Subject: [Ace] I-D Action: draft-ietf-ace-oscore-profile-13.txt
> To: <[e-mail] <mailto:[e-mail]>>
> Cc: <[e-mail] <mailto:[e-mail]>>
>
>
>
> 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://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-ace-oscore-profile%2F&data=04%7C01%7Cmarco.tiloca%40ri.se%7C330189d7d82b48dd1e8e08d88438f043%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637404727980974848%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=DCzcOuQ7MnBLs0hxiHbIAi%2B1VjBHLBJRzi4N8P9VDV4%3D&reserved=0>
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-ace-oscore-profile-13
> <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-ace-oscore-profile-13&data=04%7C01%7Cmarco.tiloca%40ri.se%7C330189d7d82b48dd1e8e08d88438f043%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637404727980984842%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=OaxJICL6Bp%2Fzt5DMwUWcv04yU07JkvEILCNy17Moqro%3D&reserved=0>
> https://datatracker.ietf.org/doc/html/draft-ietf-ace-oscore-profile-13
> <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-ace-oscore-profile-13&data=04%7C01%7Cmarco.tiloca%40ri.se%7C330189d7d82b48dd1e8e08d88438f043%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637404727980984842%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=7Ac6UdrbH6IBIcm2%2BYWd4iwufwIblv76Nq4VretJZuw%3D&reserved=0>
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-oscore-profile-13
> <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Frfcdiff%3Furl2%3Ddraft-ietf-ace-oscore-profile-13&data=04%7C01%7Cmarco.tiloca%40ri.se%7C330189d7d82b48dd1e8e08d88438f043%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637404727980994840%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=R%2Bj8cmPnyb8DUEcygCzhOpCJBqQbS8gDalwSsVZtdkw%3D&reserved=0>
>
>
> 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://eur02.safelinks.protection.outlook.com/?url=http%3A%2F%2Ftools.ietf.org%2F&data=04%7C01%7Cmarco.tiloca%40ri.se%7C330189d7d82b48dd1e8e08d88438f043%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637404727980994840%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=pec0ClOMPHj%2BsHa%2ByDBFOvDj90aPwlcEURCcQI6igxI%3D&reserved=0>.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> <https://eur02.safelinks.protection.outlook.com/?url=ftp%3A%2F%2Fftp.ietf.org%2Finternet-drafts%2F&data=04%7C01%7Cmarco.tiloca%40ri.se%7C330189d7d82b48dd1e8e08d88438f043%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637404727981004834%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=AJhNeMUrwuGWnKk7Oazo4jFxm0gX1t7hMcI9IvRIQCk%3D&reserved=0>
>
>
> _______________________________________________
> Ace mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/ace
> <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%7C637404727981004834%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=wMdtJRfiWur2dXXZw8z84usAX7P9vHcvhGy%2BPNHeDVg%3D&reserved=0>
>
>
> -- 
> Daniel Migault
> Ericsson
>
> _______________________________________________
> Ace mailing list
> [e-mail]
> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Face&amp;data=04%7C01%7Cmarco.tiloca%40ri.se%7C330189d7d82b48dd1e8e08d88438f043%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637404727981024818%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=SlpecuiDXwgoE5ogL8jSqtUO7zVut7dr1q6VXX8y9Z8%3D&amp;reserved=0

-- 
Marco Tiloca
Ph.D., Senior Researcher

RISE Research Institutes of Sweden
Division ICT
Isafjordsgatan 22 / Kistagången 16
SE-164 40 Kista (Sweden)

Phone: [phone]
https://www.ri.se