Re: [Ace] Review of draft-ietf-ace-oscore-profile

[John Mattsson <[e-mail]>]

The question in my view is if this draft should create collisions. All other drafts that have ever been discussed in the IETF takes efforts to not create any collisions in the first place

https://tools.ietf.org/html/draft-selander-lake-edhoc-01
https://tools.ietf.org/html/draft-mattsson-ace-tls-oscore-00
https://tools.ietf.org/html/draft-friel-tls-atls-04

All these assignment mechanism can be used together collision-free without ID Context and with minimal length Sender ID / Recipient ID. So I don’t think the statement that “Collisions are going to be a common problem across all of these different ways of getting OSCORE contexts established.” is correct.

Group OSCORE is a different story, there the assignment mechanism have to handle collisions with ID Contexts (unless the deployment is strictly local, e.g. when used only over a local radio technology). 

One option is that this draft recommends the use of an ID context and that a bis version of the draft makes the simple changes to not get collisions in the first place.

It would as you say have been very good if RFC 8613 discussed how to negotiate Sender ID / Recipient ID. If there is ever a bis version, this should definitly be added. 

John

-----Original Message-----
From: Jim Schaad <[e-mail]>
Date: Tuesday, 8 September 2020 at 21:14
To: John Mattsson <[e-mail]>, Göran Selander <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: RE: [Ace] Review of draft-ietf-ace-oscore-profile

John,

I am wondering if this is really the document that should be dealing with this collision problem.   A number of the collisions that might occur are going to be out of the ACE scope and a more general discussion of the problem should probably occur in a BIS version of the CoRE OSCORE document itself.   Memory says that the document does not claim to deal with how names are assigned to contexts, but I think that having a centralized location that LAKE, ACE (AS, Groupcomm and pub-sub) and perhaps other methods that we don’t currently have in our radar.  Collisions are going to be a common problem across all of these different ways of getting OSCORE contexts established.

Jim


-----Original Message-----
From: Ace <[e-mail]> On Behalf Of John Mattsson
Sent: Tuesday, September 8, 2020 12:40 AM
To: Göran Selander <goran.selander=[e-mail]>; [e-mail]
Subject: Re: [Ace] Review of draft-ietf-ace-oscore-profile

Hi,

Just want to say that I don't have any strong opinions on how to proceed. I just wanted to point out the collision problems with the draft are more severe that the group have discussed. Ignoring collisions seems like a mistake, and to my understanding there seems to be no benefits of the AS dictating Sender and Recipient IDs.

I think Jim has a good point in that the solution with symmetric key authentication comes with a lot of limitations anyway.

/John 

-----Original Message-----
From: Göran Selander <goran.selander=[e-mail]>
Date: Monday, 7 September 2020 at 17:05
To: John Mattsson <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: Re: [Ace] Review of draft-ietf-ace-oscore-profile

Hi,

Just want to acknowledge, as was discussed in the WG meeting today, that the major comment below is alternatively a possible -bis update. I think this is good functionality, and even though related problem statements have been discussed before, this solution has not. And although the change is small it comes at a late stage. But if it doesn't make it for this version then let's make it in an update soon. 

Göran


On 2020-09-05, 14:51, "Ace on behalf of John Mattsson" <[e-mail] on behalf of john.mattsson=[e-mail]> wrote:

    Hi,

    I have reviewed the latest GitHub version of draft-ietf-ace-oscore-profile
    https://protect2.fireeye.com/v1/url?k=cd0dd5df-93bc0ebf-cd0d9544-86e2237f51fb-51fc8fb4bf065a0f&q=1&e=5ecc1a37-faa1-4082-857b-150aa2dc3b9a&u=https%3A%2F%2Face-wg.github.io%2Face-oscore-profile%2Fdraft-ietf-ace-oscore-profile.html

    In general this draft looks very good. I have one major comments, and several more minor comments.

    Major comment
    -------------------

    - Asignment of OSCORE Sender and Recipient IDs

    I think the specified mechanism where the AS dictates the OSCORE connection parameters is unfortunate. It introduces several current and future limitations. The current assignment mechanisms only works without problems in close systems where the RS does not have any other non-AS OSCORE connections, where the CoAP client and CoAP server roles are fixed and cannot be switched, and where only draft-ietf-ace-oscore-profile is used. In systems where the OSCORE nodes can switch between CoAP client and CoAP server (a feature explicitly supported by OSCORE) the current mechanism is likely to lead to RecipientID collisions. Also in future systems where the AS also supports a more modern key management with PFS using e.g. a future draft-ace-edhoc-oscore-profile, the mechanism would not work together in an efficient way. My understanding is that the authors would like the solution to work with both role switching and EDHOC.

    How to negotiate these type of connection identifiers (in this case OSCORE Sender and Recipient IDs) have been studied and specified several times in e.g. draft-selander-lake-edhoc, draft-ietf-tls-dtls-connection-id. A solution where each party choses its OSCORE recipient ID for the connection always work without collisions. Such a negotiation could quite easily be added to the roundtrip with the nonces N1 and N2. My feeling is that it would be worthwhile to do such a change. This would also require a new identifier for the OSCORE_Security_Context Object, either a new objectID or a hash of the object could be used. I think this would be a good change as the current "hack" of using the ACE client sender Id and and ID context to identify the object might lead to other future limitations.

    The suggested changes would lead quite equal message sizes and storage requirements, they might even lead to some small improvements.

    Minor comments
    -------------------

    - "server authentication"

    My understanding is that server authentication with this draft requires two additional things. That C trusts AS and that RS sends an OSCORE response back. The draft should point this out similarly to the way it points out that a OSCORE request is required for proof-of-possession. As C trust in AS, and RS sending an OSCORE response back are both optional, I would recommend to maybe remove "server authentication" from the abstract and intro.

    - "The nonces are encoded as CBOR bstr if CBOR is used, and as Base64 string if JSON is used"

    Would be good to define exactly how the Master salt is created when JSON is used. I.e. is the Base64 encoded strings used, or are the byte strings after Base64 decoding used.

    - "the authz-info endpoint is not a protected resource, so there is no cryptographic protection to this request."

    I do not think this follows from the OAuth ACE term “protected resource”. Most resources on the web are not protected resources, but use cryptographic protection (https:// HTTPS)

    - "An OSCORE_Security_Context is an object that represents part or all of an OSCORE Security Context"

    The object cannot represent all of an RFC 8613 OSCORE Security Context as sequence number, replay window, and Master salt are missing. I would also strongly recommend removing "context" from the name of the object so that it is not confused with an RFC 8613 context. Maybe OSCORE input keying material or something similar.

    - "CBOR type"

    The types listed are CDDL types. Should at least mention CDDL or change to actual CBOR types.

    - "Security Context identified by "kid""

    This message has two different "kid", one on the ACE level and one on the OSCORE level, would be good to clarify which "kid" this refers to.

    - "client" "server"

    I think the draft should have a sentence saying that the terms "client" "server" when used without specification refer to the ACE client C and the ACE resource server RS. There is another server in the ACE architecture, and on the CoAP level the nodes can switch roles.

    - "input salt"

    input salt is not defined when it is used in section 2.

    - "clientID", "serverID", "contextID"

    I am not fond of these new abbreviations for the OSCORE parameters for several reasons. The draft uses the term "clientID" for "ACE client sender ID" = "ACE resource server recipient ID", the term "serverID" for "ACE client recipient ID" = "ACE resource server sender ID", and the term "contextID" for "ID context". "clientID" and "contextID" is also together used as an identifier for the "OSCORE_Security_Context Object".

    The problems I have with these terms are that "client ID" and "serverID" give the impression that they are identifiers for the nodes C and RS, which they are not. In two-party OSCORE, the identifiers (senderID and recipientID) are not connected to any of the parties more than the other. In fact, a node needs to be in control of its recipient IDs but does not really need to care much about its sender IDs.

    - RFC 8613 Appendix B.2

    To me it does not seem clear if draft-ietf-ace-oscore-profile can be used together with the mechanism in Appendix B.2 of RFC 8613. The mechanism in Appendix B.2 leads to a new Context ID. Is it allowed to use that mechanism after using draft-ietf-ace-oscore-profile? In draft-ietf-ace-oscore-profile, the AS dictates a specific “ID Context”?

    Cheers,
    John

    _______________________________________________
    Ace mailing list
    [e-mail]
    https://www.ietf.org/mailman/listinfo/ace


_______________________________________________
Ace mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ace