Looks fine. Jim
> -----Original Message----- > From: Francesca Palombini <francesca.palomb...@ericsson.com> > Sent: Monday, February 18, 2019 4:55 AM > To: Jim Schaad <i...@augustcellars.com>; draft-ietf-ace-oscore- > prof...@ietf.org > Cc: ace@ietf.org > Subject: Re: Shepard comments on draft-ietf-ace-oscore-profile > > Hi Jim, > > Here is the update including your comments. It also includes minor > comments from Marco (thanks!) that we had missed before. > > https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-ace- > oscore-profile.txt&url2=https://ace-wg.github.io/ace-oscore-profile/draft- > ietf-ace-oscore-profile.txt > > Concerning the error caused by unrecognized fields in the > OSCORE_Security_Context, I only defined that for the RS: in fact, the client > does not validate the token, so stopping the processing because of an > unrecognized field would open up for easy DoS attacks by intermediaries. If > the AS actually sends unrecognized fields, the RS will anyway stop the > process itself when receiving the token. > > This was the last change, so if you are ok with this, I will go ahead and > submit > a new version. > > Francesca > > On 31/01/2019, 17:46, "Jim Schaad" <i...@augustcellars.com> wrote: > > > > > -----Original Message----- > > From: Francesca Palombini <francesca.palomb...@ericsson.com> > > Sent: Thursday, January 31, 2019 6:26 AM > > To: Jim Schaad <i...@augustcellars.com>; draft-ietf-ace-oscore- > > prof...@ietf.org > > Cc: ace@ietf.org > > Subject: Re: Shepard comments on draft-ietf-ace-oscore-profile > > > > Hi Jim, > > > > Inline. > > > > Thanks, > > Francesca > > > > On 31/01/2019, 01:34, "Jim Schaad" <i...@augustcellars.com> wrote: > > > > > > 1. Please update the text for MUST/SHOULD/MAY to include the > language > > from > > RFC 8174. > > > > FP: Right, thanks. Updated now in the github. > > > > 2. Section 3.2.1 - What to do is clear if a field is not missing. > What is > > the correct behavior if a field is present that the client and/or > resource > > server does not recognize. Is this a fatal error or is it > sufficient that > > they may not behave the same? > > > > FP: Assuming you are referring to fields missing in the > > OSCORE_Security_Context, (please correct me otherwise) this is a good > > point. We currently do not define what happens if the security context > has > > unrecognized parameters. We don't foresee this happening, as the AS > > should know what the client and RS implement. However, to cover this > case > > (bad implementation or something went wrong), to be on the safe side, > we > > propose that there is a fatal error in that case. In fact, we don't know > what > > additional parameters might be registered in the > OSCORE_Security_Context, > > and although they could be "risk-free" (as in optional additional > information > > non-necessary for the security context derivation), they could also be > input > > to the key derivation for example, in which case the endpoint non- > > recognizing them would end up storing a "wrong" security context. What > do > > you think? > > Sounds good. I had a vague thought that perhaps some of the group items > might be added in the future but no hard items to add. > > Jim > > > > > Jim > > > > > > > > > _______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
