Hi, I have reviewed the latest GitHub version of draft-ietf-ace-oscore-profile https://ace-wg.github.io/ace-oscore-profile/draft-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 [email protected] https://www.ietf.org/mailman/listinfo/ace
