Hi Jim, Thanks very much for good comments, replies inline.
On 2016-08-04 00:37, "Ace on behalf of Jim Schaad" <[email protected] on behalf of [email protected]> wrote: >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. Agree. > >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. Correct, but there is also the desire to use the context for client and server switching roles, and more generally sender and listener in a group. This relates to your comments on OSCOAP. > >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. OK. > >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. For simplicity changed to negotiation of KDF, OK? > >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? It is explained in [RFC5869] which is referenced but we can add that. > >6. In section 2, do you expect that TCA is restricted to CEK or would MAC >algorithms be usable as well? Changed to "AEAD or MAC". > >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. Yes, replay is mainly an issue for party V. > >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. I think we are just copying TLS 1.3 terminology here. “traffic_secret_0” is the “base key” used to derive the different client and server keys you request. > >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. Good catch. There is a story for how EDHOC works with ACE but we forgot to mention it here and make the reference: See figure 1 of https://tools.ietf.org/html/draft-seitz-ace-oscoap-profile-00 > >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. Yes, this was just to be concrete. Good proposal. > >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. This should be the entire message_1. > >12. Stupid question - Can you do a PSK in one direction and a signature in >the other? I’d like to pass that question on to CFRG. > >13. Not sure that it matters, but you have the COSE_KDF_Context structure >wrong everywhere. The partyU and partyV fields are not optional. Yes, we are re-considering the identities used. Also relates to your comment on OSCOAP. > >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. We strive for allowing a) short identifiers if there is a naming authority and b) sufficiently long random identifiers if a) is not possible. If possible we would like to avoid exhaustive search, although that would be doable. > >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. Agree. > >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? Yes, the latter is fine. We are considering this also in OSCOAP. > > >17. Section 5 - what happens if N_U or N_V is longer than the size of the >hash function. Good catch. This construct was intended to simply incorporate arbitrarily small nonces, as is encouraged in section 3.1 of [RFC5869]. >Also, what do you mean by the size of the hash function? Is >this the barrel size or the output size? 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. So far in EDHOC and OSCOAP the identity has been associated to the key, mainly for reasons of optimization. As mentioned above we are reconsidering this, for reasons of generality. > >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. Seems prudent, we will consider this in the next version. Thanks Göran _______________________________________________ Ace mailing list [email protected] https://www.ietf.org/mailman/listinfo/ace
