This may be a bit scatterbrained as I did this review in several sessions and the thoughts might not be consistent.
1. In section #1, I would put in the fact that the derived key would only be used for a period of time, after which a new ECDH key exchange would be run again. 2. It is not clear, but based on how the value of kid_ev is defined, it might be reasonable to state that there is an expectation that generally U will be a client and V a server. 3. I would like to see the PSK half of the world setup so that it is not required that the same key/kid pair be used in both directions. Using a different key in each direction makes things cleaner for some issues. Both cases of the same and different pairs should be permitted. 4. I see no reason to say that what one is negotiating is a hash function. What you are negotiating is a "Key Agreement w/ KDF" algorithm. I don't see that you are using the hash function by itself anywhere. 5. In section 2, you should give a reason for including or not including the nonces in the protocol. Since they are optional when would they be useful? 6. In section 2, do you expect that TCA is restricted to CEK or would MAC algorithms be usable as well? 7. In section 2, I missed where the replay parameter was included in the COSE_Header - it seems to be in the key for party U and non-existant for party V. The closest that one comes it the use of the message_1 signature as AAD. 8. In figure 3, I would prefer to see two different traffic keys being derived. It is not an issue in Figure 2 as that just says keying material. Using different keying material in each direction prevents reflection attacks. 9. In section 2.1, you talk about authentication methods but do not discuss authorization methods. Does this need to be built into message_1 or are there other methods that will be functional here. May need to refer to how some of them might work since this will also potentially affect how the distribution of the keys in advance works. For example, if an OAUTH token is published to a well-known location that contains both authorization and authentication information. 10. In section 3.1, I am not sure that you really want to have only a single algorithm in this specification. I would make it more generation in terms of how a COSE_Key is built and then have a statement elsewhere rather than spread throughout the document about what algorithms are mandatory to support. 11. In section 3.4.2 - I think that you need to have a more comprehensive external_AAD structure that what is here. I am not sure that you should not AAD information from the CoAP header as well in all of the messages. 12. Stupid question - Can you do a PSK in one direction and a signature in the other? 13. Not sure that it matters, but you have the COSE_KDF_Context structure wrong everywhere. The partyU and partyV fields are not optional. 14. Section 3.5, I don't believe in uniquely identified kids on any device unless that device is going to enforce that as a true statement. That means that it will not allow for a key to be registered with it unless the kid is unique. There is nothing wrong with doing an exhaustive search of all of the keys with the same kid as long as the number of them is not too large. 15. Section 3.5.3: If you are sending along a certificate, it is not clear to me that you need to have a kid as well. The certificate is where you are going to get the key from not the kid. 16. Section 4.1 - kid_eu - Does this really need to be a counter on a per party V basis or can it just be a counter based on the use of the credential that is being used to do the authentication? 17. Section 5 - what happens if N_U or N_V is longer than the size of the hash function. Also, what do you mean by the size of the hash function? Is this the barrel size or the output size? 18. Identity of the Parties: There is a question on what the identity structure that is being used to grant access is for ACE. For those who have been in the IETF long enough, one answer would be to move back to the world of SPKI (Simple Public Key Infrastructure) where the key is the entity that is used for identifying an entity and not some other piece of information like a text string or an address. Doing a security analysis, one might find that one wishes to do a binding of the identity information into the key derivation process. If keys are the marker of identity, then this is would be including the keys as part of the context information thus tying the signature and key into the resulting key. The requirement to include identity information is probably needed more if access control is being based on a name rather than a key however. In this case it is likely more important that the binding processes is included in the KDF context in some manner. 19. Use of the signature/MAC for chaining of items: I did a fast review of how the fields of message_1 and message_2 are used in the final KDF processing. From what I saw, there are only a couple of things that are not directly re-used as part of the context. These are: 1) the exact encoding of the messages, 2) the list of key agreement algorithms, 3) the list of TCA algorithms, 4) kid_eu and kid_ev, and 5) the protected attributes in each of the messages. Exact encoding can be addressed by using the same encoding rules that are in COSE - that is use of a minimal encoding size along with a stricter statement bout checking the grammar in the processing rules. I am not worried about the two lists of algorithms as message_1 is authenticated and the rules should state that the returned values in message_2 are checked against the original list. The final pair of algorithms are either directly (TCA) or indirectly (Key agreement) included in the computing of the traffic keys. The KIDs might want to be included, and doing so would allow for generation of different traffic keys in each direction. The protected attributes should potentially be included in the computation along with the keys to provide tying the identity and signatures together in a tighter binding. I don't know that there is an attack that can be launched here, but this would make it that much more difficult. Jim _______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
