Re: [Ace] AD review of draft-ietf-ace-oscore-profile-08
Hi Francesca, Sorry to cut this so close to the wire...I was on vacation and came back to a sizeable inbox. On Mon, Feb 17, 2020 at 03:55:29PM +, Francesca Palombini wrote: > Hi Ben, > > I am now done with updating the draft following most of your review comments. > Out of the 105, I have implemented 88 in the draft, while those left need > agreement in the wg as previously mentioned, or require your OK (see inline). > > You can see the result of the update in the PR here: > https://github.com/ace-wg/ace-oscore-profile/pull/25 If you give me the > go-ahead, I will merge this PR and submit a new version, and then we can > continue working on the open issues. I will have to download the changes locally to view them, as the in-browser viewer does not do well with the long lines. > These open issues are: > > * The mechanism of letting the RS pick the identifier of the client is not > worth the additional complexity. > 6, 7, 32, 61, 65, > * Recommendation about length of nonces N1 and N2 to use. > 5, 52 > * Define and register 2 new ACE parameters to transport the nonces used in > the exchange, instead of using "cnonce". > 3, 53, 60 > * Check with IANA > 102 > > I hope to discuss these in the mailing list (continuing on the separate > thread), and at the interim. > > I will cut and paste the rest (46 , 47, 58 , 67 , 92 + a couple of more) > which I have answered below, whatever is not reported below I found no issue > in doing the modifications you suggested, or is covered by the open points I > mentioned. Please do bring any of those I do not touch on up again if you > feel they were not solved in the PR. > > Thanks again for your extensive review! > Francesca > > On 03/02/2020, 05:06, "Benjamin Kaduk" wrote: > > 29. The AS MUST also assign an identifier to the RS (serverId), > MAY > >assign an identifier to the client (clientId), and MAY assign an > >identifier to the context (contextId). These identifiers are > then > >used as Sender ID, Recipient ID and ID Context in the OSCORE > context > >as described in section 3.1 of [I-D.ietf-core-object-security]. > The > >couple (client identifier, context identifier) MUST be unique in > the > >set of all clients on a single RS. Moreover, when assigned, > >serverId, clientId and contextId MUST be included in the > >OSCORE_Security_Context, as defined in Section 3.2.1. > > > > When certain fields are optional, we typically have to ask whether > it's > > possible for the two parties to disagree about whether the field is > > present. IIUC, the OSCORE context derivation procedure includes > enough > > information to prevent that possibility, but it would be good if > someone > > would confirm that. > > > > FP: That is correct, a number of fields have default values when non > present. Hkdf, alg, salt, contextId, rpl. On the other hand, ms, clientId and > serverId need to be set. > > Hmm, so there is not a great mechanism to distinguish "absent" from > "present with default value", but the practical consequences of such an > attack seem quite limited. > > FP: That is right. I did not add any text about this, as this is more OSCORE > implication. That's okay. > > > > 34. "access_token" : h'a5037674656d7053656e73 ...' > > (remainder of access token omitted for brevity)', > > > > In addition to the invalid-CBOR-diagnostic-notation-syntax comment, > we > > also have unbalanced quotes. > > > > FP: Right, but this is not valid CBOR diagnostic notation syntax > anyway, do you have a better idea? I do not think it would be useful to have > the full token here. Will remove the unbalanced quote. > > This is probably manageable, though we do often see people put a > disclaimer > before the example that are truncated for readability; > some other ADs may have other suggestions, too. > > FP: Thanks for the input text :) Now added. > > ... > > > 43. hkdf: This parameter identifies the OSCORE HKDF Algorithm. > For more > > information about this field, see section 3.1 of > > [I-D.ietf-core-object-security]. The values used MUST be > > registered in the IANA "COSE Algorithms" registry and MUST be > > HMAC-based HKDF algorithms. The value can either be the > integer > > > > It's a little unfortunate that we basically are relying on "I know > it > > when I see it" for determining which algorithms are HKDF algorithms. > > > > FP: Agreed, but we don’t really have another way to say this. If you or > COSE experts (Jim) have any idea please let us know. > > I think we inherited this from JOSE :-/ > > FP: That would
Re: [Ace] Scope question
-Original Message- From: Marco Tiloca Sent: Monday, February 24, 2020 2:14 PM To: Jim Schaad ; draft-ietf-ace-key-groupcomm-osc...@ietf.org Cc: 'Ace Wg' Subject: Re: Scope question Hi Jim, On 2020-02-24 19:02, Jim Schaad wrote: > I was starting to code up the encoding of scope and wanted to clarify > what the encoding is. > > The text appears to say that the encoding is: > > scope = [ groupId: tstr, ?[* role : any ]] > > I was expecting this to be more along the lines of > > scope = [ + scope_item ] > scopeItem = [ groupId: tstr, ?[* role : any ]] > > This would allow for more than one group to be identified in a single > token which I think is important given some of the statements about > only having a single token for a client. This does not solve the > resource server having multiple audiences but that is fine. ==>MT At the January interim, we mentioned a multi group/topic scope as next step. The format you suggest above is essentially the one we also had in mind. This should be firstly defined in the ace-key-groupcomm document. This should be just fine for the Token request/response and the Access Token itself. Then I am thinking of what happens next. In a general case, in each of the specified groups a different signature algorithm (etc.) is used. Then, in the 2.01 response from /authz-info , we would have 'sign_info' also as an array of arrays and 'pub_key_enc' as an array (unless the very same configuration applies for each scopeItem above). Same goes for 'rsnonce' becoming an array. The order of such arrays' elements is the same as for the scopeItems in the 'scope' claim. <== [JLS] I am having some problems with thinking that this is a good idea. The only reason to have different signing keys is to keep the different signature keys isolated in terms of correlation. If this is the case then adding a situation where we are going to share this information with a specific entity seems to be a bad idea. I would think that if the signing keys are going to be separate then that should be true all of the back as far as possible. This would mean that, if possible, that even the AS should not know that the different signing keys are associated with the same entity. Jim > > I am unsure if it makes sense to allow for the array to be removed for > scope in the second example in the event that only one group is > specified. One byte saved at the expense of more code. ==>MT I think it makes sense to avoid that byte, and essentially revert to the original scope format when only one group is specified. <== 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 ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] [EXTERNAL] RE: Access token question
On 2020-02-24, at 18:04, Jim Schaad wrote: > > • The proposal from Carsten that has not get adopted anywhere yet. Well, not adopted in the literal sense, but it has been used as a blueprint both in research works and in standardization. The main question that is holding this back from being a more complete solution is how to represent authorization that is dependent on request parameters (in particular, in bodies, both FETCH and POST/PATCH). Maybe that is too hard to do in a generic way, and AIF should focus on providing a placeholder for profile specific information about request body handling. (I have taken the opportunity to resubmit AIF with updated references: https://datatracker.ietf.org/doc/draft-bormann-core-ace-aif/ .) Grüße, Carsten ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
[Ace] Scope question
I was starting to code up the encoding of scope and wanted to clarify what the encoding is. The text appears to say that the encoding is: scope = [ groupId: tstr, ?[* role : any ]] I was expecting this to be more along the lines of scope = [ + scope_item ] scopeItem = [ groupId: tstr, ?[* role : any ]] This would allow for more than one group to be identified in a single token which I think is important given some of the statements about only having a single token for a client. This does not solve the resource server having multiple audiences but that is fine. I am unsure if it makes sense to allow for the array to be removed for scope in the second example in the event that only one group is specified. One byte saved at the expense of more code. Jim ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] [EXTERNAL] RE: Access token question
I have found that I had to put a scope encoding format into my database for each audience definition. Just saying that the scope is CBOR is not going to be sufficient, just like saying that it is a text string is not enough. For the text string side you have: * It is a text string * It is a text string with space separated values * It is a text string with space separated values and each value has an underscore which separates operation and resource (MQTT) On the binary side you have: * The proposal from Carsten that has not get adopted anywhere yet. * The group communication format (roughly based on the above format) There is a question about how all of the binary values are going to work if you do a JSON encoded request rather than a CBOR encoded request. At the moment, I am assuming that the binary value is encoded (in CBOR) and then base64url encoded and placed in the JSON. I am not sure if people are going to want to define this as being native JSON instead depending on how the fields of the binary format are encoded. Given all of this, I don’t know if adding something to the framework is going to be generally useful or not. So much of what a scope looks like is going to be application dependent. With any luck we are going to be able to get a good set of scope definitions at some point in the near future and can produce a survey document. I am not holding my breath on this yet. Jim From: Francesca Palombini Sent: Sunday, February 23, 2020 11:55 PM To: Mike Jones ; Jim Schaad ; 'Seitz Ludwig' Cc: 'Ace Wg' Subject: Re: [EXTERNAL] RE: Access token question Thanks all! Section 8.13 of the framework is exactly what I was looking for, I don’t know how I did not see it. A bit surprised there is no text referencing it in the framework itself. Also, about the “scope” claim registration: the claim description and the specification document give 2 different pointers. The claim description ref points to the description for JWT (JSON string etc), I think this should be adapted to using CBOR (writing a section in the ACE framework, which could then reference both pointers). Also minor, I would add the precise section of 6749 we should look at, which I assume is 3.3. Francesca From: Mike Jones mailto:michael.jo...@microsoft.com> > Date: Friday, 21 February 2020 at 19:45 To: Jim Schaad mailto:i...@augustcellars.com> >, Francesca Palombini , 'Seitz Ludwig' mailto:ludwig.se...@combitech.se> > Cc: Ace Wg mailto:ace@ietf.org> > Subject: RE: [EXTERNAL] RE: Access token question And https://tools.ietf.org/html/rfc8693#section-7.4, which registers “scope” at https://www.iana.org/assignments/jwt/jwt.xhtml. -- Mike From: Jim Schaad mailto:i...@augustcellars.com> > Sent: Friday, February 21, 2020 9:15 AM To: 'Francesca Palombini' mailto:francesca.palomb...@ericsson.com> >; 'Seitz Ludwig' mailto:ludwig.se...@combitech.se> >; Mike Jones mailto:michael.jo...@microsoft.com> > Cc: 'Ace Wg' mailto:ace@ietf.org> > Subject: [EXTERNAL] RE: Access token question You are missing something https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-33#section-8.13 defined here From: Francesca Palombini mailto:francesca.palomb...@ericsson.com> > Sent: Friday, February 21, 2020 4:37 AM To: Seitz Ludwig mailto:ludwig.se...@combitech.se> >; Mike Jones mailto:michael.jo...@microsoft.com> >; Jim Schaad mailto:i...@augustcellars.com> > Cc: Ace Wg mailto:ace@ietf.org> > Subject: Access token question Hi, Quick question regarding access token and scope. I know that “scope” semantics is left to the application to define, but in general I would expect to include there some information about resource and method/operations allowed on that resource. Please correct me if any of this is not exact. It was my understanding that “scope” (or more precisely the “scope” value) defined for the Client-AS request and response should be included in the access token as well. Checking in CWT, there is no such “scope” claim defined. “aud” claim is indeed defined for the CWT, but that should correspond to “aud” parameter in the ACE request/response. So where do I put the exact resource and operations in the access token? What am I missing? Francesca ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
