-----Original Message----- From: Marco Tiloca <marco.til...@ri.se> Sent: Friday, January 31, 2020 10:32 AM To: Jim Schaad <i...@augustcellars.com>; draft-ietf-ace-key-groupcomm-osc...@ietf.org Cc: ace@ietf.org Subject: Re: draft-ietf-ace-key-groupcomm-oscore
Hi Jim, On 2020-01-31 16:46, Jim Schaad wrote: > > -----Original Message----- > From: Marco Tiloca <marco.til...@ri.se> > Sent: Friday, January 31, 2020 3:24 AM > To: Jim Schaad <i...@augustcellars.com>; > draft-ietf-ace-key-groupcomm-osc...@ietf.org > Cc: ace@ietf.org > Subject: Re: draft-ietf-ace-key-groupcomm-oscore > > Hi Jim, > > Thanks for these comments! > > Please, find some replies below. > > Best, > /Marco > > On 2020-01-31 00:16, Jim Schaad wrote: >> This is not a finished review - but I wanted to get it out. >> >> Jim >> >> >> General - Should the concept of a legal requester be part of the >> information that is transported with the public key? I don't believe >> that this is currently done, but would additionally allow for a >> server to ignore comments from individuals who are not authorized for that >> role. > <MT> > This can be indicated in the public key, and then the Group Manager indicates > this "role" to other group members, when providing them with the public key > of the legal requester. > > However, how can the Group Manager verify that a legal requester is indeed > one, as its public key claims? If we stick to raw public keys, this seems not > possible as the only thing that the Group Manager really does is verifying > possession of the corresponding private key upon joining. > > This would probably require certificates rather than public keys, as provided > in the 'client_cred' parameter upon joining, which is something that > ace-key-groupcomm is anyway admitting, while we are just not doing it here. > Then, it becomes about trusting the certificate issuer on legitimately > claiming that the certificate owner is indeed a legal requester. > </MT> > [JLS] I was assuming that the GM could pull this information from the 'scope' > field of the token. <MT> Ok, so it should be just about adding one more role to the current valid ones for 'scope', and updating the list of possible role combinations. Then it's up to the policy evaluation at the AS to confirm that a client is indeed a legal requester, and that that ends up in the token. </MT> [JLS] I just realized we are not talking about the same problem. I was thinking about propagating the difference between a publisher (client) and a responder (server) from the key server to the users of the keys. This would mean that a server would be able to say - but this message is not authorized to ask me a question, so don't reply (or fail). > >> Section 2.2 - must new security parameters be regenerated on each >> membership change? > <MT> > If the application really requires forward and backward security, yes. > This is further discussed in the first security consideration of Section 14. > > Related, more general aspects about this are discussed in the security > considerations of ace-key-groupcomm. In particular, the Group Manager may > want to enforce a more relaxed policy than "on each membership change", > though making some compromise on the continuity of backward and forward > security. > </MT> > [JLS] My problem is that I consider the secret key different from the > parameters - might be a semantic issue <MT> Other than that, the ID Context (Group ID) is also renewed; the Master Salt may be renewed; the used Sender IDs have to remain the same. Maybe we can have here some of the text on this from the first paragraph of https://tools.ietf.org/html/draft-ietf-core-oscore-groupcomm-06#section-2.1 </MT> [JLS] Perhaps we need to have some type of term for the difference between those items which are "static" over time and those items which are "dynamic" over time. This might also be a difference in what is returned on the issue you raised today in the virtual. Jim > >> Section 2.2. - Does completion of a group rekeying include confirmed >> redistribution before the version number is incremented? > <MT> > I would say no, but regardless it's something to clarify, possibly already in > ace-key-groupcomm . > > Having the Group Manager generated and sent out the new keying material is > sufficient to also increment the version number. > > It is good that the Group Manager can also get confirmation of distribution, > mostly for possible individual re-provisioning, possibly up to a maximum > number of retries. > > Worst case, some group members remain behind, will not be able to retrieve a > context or decrypt correctly, and will eventually go to the Group Manager to > understand the current status, including the latest version number, and get > the latest group key material. > </MT> > [JLS] This is how I read the text - please do some clarification <MT> Yes, will do. </MT> > >> Section 4.2.1 - I think that we are going to need a discussion on a >> couple of issues related to the OSCORE half of how these values are >> going to be created. Pieces of the discussion are: 1. What is the >> POP her going to try and prove. Specifically is timeliness part of >> the discussion. 2. What do we do about token which grants access to >> multiple topics. Is joining the second group considered to be a >> re-join rather than an original join for the purposes of this >> discussion? 3. What are the interactions about cached public keys, >> when are these ok and how is this communicated to the client as a failure? > <MT> > Sure. Some comments on your points for the discussion: > > 1. Ultimately the POP is about the owned private key used to sign by the > joining node. Building this part of the challenge this way ties the challenge > itself with the OSCORE context the two peers have. This is the same > construction we have in [1] for building a signature challenge, so probably > both documents would likely be affected. > > 2. Tokens covering multiple groups/topics are a next thing to define in > ace-key-groupcomm. Adapting this challenge-based POP will follow. As a > general case, the client wants to use different public keys in different > groups, which would mean providing one POP signature for each key. Then, the > N_S challenge can be as follows: > > --- If the Access Token is posted to /authz-info , the RS returns an array of > N_S, i.e. as many as the number X of groups/topics in the 'scope' of the > token. Since the client may then upload Y < X public keys (some of which for > more than one group), the client should include in the joining request Y > signatures, together with the respective used Y N_C nonces and Y N_S nonces > of the X provided by the Group Manager. > > --- If a TLS exporter is used, 'context_value' has to be non empty, e.g. > it can include the public key or a hash of it. For simplicity, we may want to > have 'context_value' always non empty, i.e. also when only one public key is > involved and even in the simple case of one group/topic only. > > --- In the OSCORE case, HMAC-Hash may take as 'salt' one more concatenated > element, e.g. the public key or a hash of it. For simplicity, we may want to > have 'salt' always including this additional element, i.e. also when only one > public key is involved and even in the simple case of one group/topic only. > > 3. Cached public keys and how to handle them are discussed later in Section > 5. If something goes wrong, the joining process fails and the Group Manager > sends error responses as described in Section 4.3. > > > [1] > https://tools.ietf.org/html/draft-tiloca-ace-group-oscore-profile-01#s > ection-3.1 > > </MT> > >> Section 4.3 - Does it make sense to return a new rsnoce as part of >> these errors? >> > <MT> > That's certainly possible, though I am not sure of the advantage, compared to > sticking to the first one returned in the response to the Token POST. > </MT> > [JLS] depends on the "nonce" quality - that is one time only use. <MT> We can make it optional for the server to return a new nonce in the error response. If received, the client has to use that latest nonce when building the challenge to sign for the new joining request. </MT> Best, /Marco > Jim > > > -- > 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 > > > -- 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 _______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
