Re: [Ace] Group Communication Security Disagreements
Hi, Reflecting on this discussion and the adoption of the related draft, if the draft is adopted I would suggest that before it goes forward an auditing section should be added to security considerations so that appropriate advice is given in the case a member of a group is compromised. I could envision several mechanisms to address that concern. Here are a few examples that would need to be considerably fleshed out: * An audit system is admitted to the group and records IP addresses and times of messages received. This may be compared to IPFIX records or packet logs to determine the veracity of sources. * Lower level source validation may be employed to determine the veracity of a source IP address. This validation might take the form of IPSEC-AH. * Endpoints might log transmission and receipt of messages so that information may be compared. Other approaches may be employed as well. On additional authorization methods, one approach to protect group membership would be to use a well known L3 multicast address and a separate application port for communications, thus permitting normal network filtering based on pre-authorization of the device at lower layers. The combination of these mechanisms should at least limit potential risk and the threat surface. Eliot On 7/28/16 4:02 PM, Michael Richardson wrote: > Michael StJohns wrote: > > On 7/27/2016 5:56 PM, Michael Richardson wrote: > > > > Kathleen Moriarty wrote: > >>> Mohit Sethi wrote: > >>> > designed/developed/specified for their use-case. I could definitely > >>> > see some IoT startup building a solution that switches on the lights > >>> > in a room as soon as you unlock the door (thus keeping them in the > >>> > same group). > >>> > >>> Or perhaps more usefully, turning the lights (and the oven) off when > you > >>> leave the house. > > >> Good points, but you could do this without them being in the same > >> group with some controller that managed the interactions with each. > >> This would be a good set of examples for the security considerations > >> sections, providing guidance to use a controller rather than group > >> keys to perform useful functions like these. > > mcr> I agree. > mcr> Perhaps we could convince Mike St.Johns to write that section? > > msj> Probably not - as long as symmetric key group communications is used > msj> as a control protocol. > > Well, who other than Nixon could go to China? > > mcr> And ACE has the right mechanisms to make this work well. > > msj> I agree - public key systems. But that seems to be out of scope here. > > I'm not convinced. What I have taken home is that people think they want to > use symmetric keys, and perhaps it might be safe among completely equivalent > devices. I take your point (strongly) that this bubble will be broken, with > catastrophic results. We need asymmetric methods between bubbles, and we > need to define that early. > > mcr> We should also consider whether we can use hash-chains, like S/KEY > did, to > mcr> authenticate messages that should only go out in emergencies. Such > messages > mcr> would clearly *need* to be multicast, but once used, they can never > be > mcr> reused. They can't be originated by more than one sender though > so it's > mcr> really the message stored by the "EMERGENCY STOP" button. > > msj> That's an interesting idea - but AIRC, hash chains could be > originated > msj> by anyone that held the signing/verification key. > > Yes, provided they distributed the initial (asymmetrically signed) h^n(k) > value out in advance, and gave all the devices enough time to verify that > signature. Plus flash to store the n-th hash. > > For the single sender/controller, multiple receiver/actuator situation this > would be almost as fast as the symmetric group key, yet much more secure. > > For the multiple sender situation, you need to replicate things n-times. > But it's still not n*m keys. > > msj> Let's do this the right way. Let's not bow to the "tyranny of the > msj> light switch" in accepting solutions that are NOT secure, even for > the > msj> limited scope they are proposing. > > +1. > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > > > > ___ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace signature.asc Description: OpenPGP digital signature ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
[Ace] Review of draft-selander-ace-cose-ecdhe-02
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 pro
