Re: [Ace] Shepard comments on draft-ietf-ace-oscore-profile

[Jim Schaad <[e-mail]>]

Looks fine.

Jim


> -----Original Message-----
> From: Francesca Palombini <[e-mail]>
> Sent: Monday, February 18, 2019 4:55 AM
> To: Jim Schaad <[e-mail]>; draft-ietf-ace-oscore-
> [e-mail]
> Cc: [e-mail]
> 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" <[e-mail]> wrote:
> 
> 
> 
>     > -----Original Message-----
>     > From: Francesca Palombini <[e-mail]>
>     > Sent: Thursday, January 31, 2019 6:26 AM
>     > To: Jim Schaad <[e-mail]>; draft-ietf-ace-oscore-
>     > [e-mail]
>     > Cc: [e-mail]
>     > Subject: Re: Shepard comments on draft-ietf-ace-oscore-profile
>     >
>     > Hi Jim,
>     >
>     > Inline.
>     >
>     > Thanks,
>     > Francesca
>     >
>     > On 31/01/2019, 01:34, "Jim Schaad" <[e-mail]> 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
>     >
>     >
>     >
> 
> 
>