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

[Francesca Palombini <[e-mail]>]

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