Re: [Ace] WGLC for draft-ietf-ace-oscore-profile

[Francesca Palombini <[e-mail]>]

Hi Jim,

Thank you for your review comments. We agree with all your points, and have opened issues: https://github.com/ace-wg/ace-oscore-profile/issues to get this fixed.

Inline some detailed answer.

Thanks,
Francesca

On 22/10/2018, 21:09, "Jim Schaad" <[e-mail]> wrote:

    * Section 1 - I understand the reasoning behind having the server send back
    a nonce, although it would be good to have a description someplace about why
    this is being done.  (I would also make it optional as not all RS need to do
    this.)  I do not understand the reasoning behind having the client send a
    nonce to the server.

FP: The motivation for the nonce construction was in the security considerations, but I agree that having it in the Protocol Overview makes sense, so I opened an issue to fix that. The reason behind having the client create a nonce is that we are protecting against an attacker replaying an old RS message (containing an old nonce), which would provoke the creation of an old security context on the Client, and reuse of keys and nonces for a different (new) message.
    
    * Section 3.1 - This is more general than the section, but you should not
    use the URI path in the text, instead you should be using the name that is
    in the authz document.

FP: Agreed, issue opened to fix this.
    
    * Section 3.2 - Does it really make sense to use 'COSE_Key' to transport the
    key data?  Would a different field name be better?

FP: This was brought up several times, so we will make this change now.
    
    * Section 3.2 - Please provide a justification for the requirement that the
    ids must be unique over the set of all clients and RS.   I can see that the
    client ids need to be unique on a single RS and RS ids need to be unique for
    any given client but not the broader statement.

FP: You are right, this requirement is too wide. We will replace with your suggestion.
    
    * Please add an explicit section on when a RS and a client should discard
    the security context.

FP: Ok we will add this. As mentioned in the issue, I have now only this 3 cases in mind: Partial IV space ends (either C or RS); the kid context on the RS side does not match with N1 (RS); C receives a number of Unauthorized (C), although that is a consideration/recommendations, details would be application specific. Do you see any other case relevant for this section?
    
    * Section 6 - Ok I'll bite  - how does not echoing the nonce allow for a
    man-in-the-middle attack given that the salt and shared secret are still
    going to be known only to the C and RS and not to the MITM.  I can see a DOS
    attack being made, but that can be done even without this just by causing
    the response to never be delivered.

FP: Ok so our mistake here is to use the term MitM, so to solve this we will replace with "on-path attacker". The following sentence should be correct with that fix "Moreover, the client echoes the nonce created by the RS, which verifies it before deriving the Security Context, and this protects against an adversary acting as an on path attacker and substituting the nonce in transit from client to RS to provoke the creation of different Security Contexts in the client and RS." Yes this is a DOS, but could also lead to reuse of keys and nonces, as mentioned before.
    
    * Appendix - I am not sure that I think that the EDHOC profile should be in
    this document as oppose to being in it's own document.  The fact that we
    have not even tried to get this to work in any of the interop tests means
    that I am less sure that it is well baked.

FP: Agreed, we will remove this from this document and move it to its own document
    
    Jim
    
    
    > -----Original Message-----
    > From: Ace <[e-mail]> On Behalf Of Jim Schaad
    > Sent: Monday, October 8, 2018 2:35 PM
    > To: [e-mail]
    > Subject: [Ace] WGLC for draft-ietf-ace-oscore-profile
    > 
    > The chairs believe that the set of documents dealing with the OAuth
    > framework for constrained environments is nearing the point that we should
    > be able to advance it to the IESG for publication.   We therefore want to
    > have a full list of issues that need to be dealt with at the Bangkok
    > meeting.
    > 
    > This starts a 2 week WGLC for draft-ietf-ace-oscore-profile
    > 
    > We know that the following issues are outstanding:
    > 
    > draft-ietf-ace-oscore-profile:
    > *  No current known issues
    > 
    > 
    > Jim & Roman
    > 
    > 
    > _______________________________________________
    > Ace mailing list
    > [e-mail]
    > https://www.ietf.org/mailman/listinfo/ace