Yaron Sheffer writes: > • Bidirectional operation is one of the main advantages of IKE/IPsec > over TLS, so I think allowing only a client-server model is a major > omission. People will want to implement meshes of these small devices. > In your example, the lawnmower talks to the garage door to let it out...
Or the lawnmover talks to the house area controller, which will control the garage door. The assumption here is that the other end is full IKEv2 implementation, i.e. house area controller do support full IKEv2, and it can act as responder. Most of the communications will go through it. Setting up meshes is much more complex than using some centralized controller. For example the lawnmover and the garage door would need some kind of authorization step before the garage door would allow lawnmover to open the door. This is much easier to set up in the centralized controller. If you want to use full mesh, you can use full IKEv2. Even full IKEv2 implementation will then be very tiny compared to the other policy, authentication and authorization infrastructure code you need to allow that kind of operations. > • Raw public keys have very few advantages over shared keys. In a mesh, > you still need to provision all N (public) keys into each of N devices. Not necessarely. In many cases the minimal implementations will only connect to the house are controller, and in that case the minimal client only need to know the house are controllers public key. It can learn that on the first connection and remember it from there on. Main benefits from the public keys is that you can easily create temporary trust relationships, and revoke them easily. Note, that most of these small devices do not have any kind of user interface, or it is very minimal (one button or so), thus changing shared secret on the device is in practice impossible. With shared secrets you would need to share the same secret with all partners, i.e. your door opener that both allows you to open your own home garage door, and the office garage door would most likely use same shared secret with both doors, and this would leak the shared secret to the office garage door adminstrator, who would now be able to open your home garage door. With raw public keys that is not possible, as both doors only know which fingerprint is allowed to open the door, but they do not know the actual private key needed to do the operation. > On the other hand, certificates (despite their well known problems) > allow for much simpler provisioning, when you need to provision a closed > group of devices and you generate your own CA. What I'd really want is a > profile of 5280 where you just sign the public key but cut off all the > identity and extensions crap. Unfortunately this is unlikely to ever > materialize. Certificates is more complex than full IKEv2, thus if you are using certificates you should use full IKEv2 too. > Some Detailed Comments > > • Responding to Create Child SA: does it really matter if you respond > with a "syntax error" (i.e. you don't recognize this exchange at all) or > with "no additional SAs"? The sender will tear down the IKE SA anyway. No. The NO_ADDITIONAL_SAS do NOT tear down the IKE SA nor will it tear down the existing Child SA. It will just indicate that you only support one Child SA, and you will not support IKE SA rekey. The other end which got NO_ADDITIONAL_SAS might then tear down the IKE SA if it wants to, but that is his policy decision. In normal case the IKE implementations will try to rekey Child / IKE SAs when the soft lifetime expires, and only delete the Child / IKE SAs when the hard lifetime expires. There might be quite big difference there. Sending INVALID_SYNTAX would forceably immediately remove the IKE SA without any extra notifications. > • Why not omit AH from the minimal implementation? I would expect omst of the minimal implementations will omit it, but from the IKEv2 point of view it, there is no big difference whether ESP or AH is negotiated in the IKEv2. Decision whether the minimal implementation supports AH or ESP is not done in this document, this only covers the IKEv2 parts. > • I don't understand why Appendix A is needed. And if it is, I don't > think the Cert Request and Cert payloads should be included, if they're > not supported included in the profile. As appendix A says: ---------------------------------------------------------------------- Appendix A. Header and Payload Formats This appendix describes actual packet payload formats. This is required to make the document self contained. The descriptions are mostly copied from the RFC5996 and more information can be found from there. ---------------------------------------------------------------------- It is there to make the document self contained. I wanted to have smaller document which contains everything person implementing the minimal implementation needs. CERT and CERTREQ payloads are needed if you implement raw public keys from Appendix B.2. > • Seems to me you should include PRF_HMAC_SHA2_256. That is not in the RFC5996, and I only included (partial) list of algorithms which are in RFC5996. Also SHA2 is too complex for minimal really implementations, but of course any algorithms listed in the IANA registries can be used on certain environments, especially if there is already requirement for them. For example in some environments the AES_CCM might be used because it is already included on the hardware. > • A.8: For the AUTH payload you can omit DSS. Agree. Removed. > • Is ID_RFC822_ADDR relevant for this type of devices? Could be. For example to identify the remote garage door opener, there might be initial step to allow meaningful identity to be stored in the device, and then when same garage door opener is used in the office, the [email protected] is much more understandable for the adminstrator than the device id 0x238e853d. > • B.1: I think the Delete payload is not just "nice to have", because > otherwise you have a major resource leak on the server. Which implies > the device needs to send *three* exchange types. There is no resource leak, as IKEv2 do have its own mechanisms to clear up state. I.e. when the server detects that the remote garage door opener who created the IKE SA a while ago, has gone silent, and there is no cryptographically protected messages (IKEv2 or ESP) coming from the device, it should start DPD as specified in the Section 2.4 of RFC5996. It will send DPD messages to the garage door opener, and when it will not answer the IKE SA is teared down. Also as the responder end is full IKEv2 device (minimal IKEv2 devices cannot talk to each other) it will have much more resources and can easily store those few tens or hundreds or even millions of extra IKE SAs for few minutes... :-) > • B.2: "Using Raw Public Keys is much simpler, and it allows similar > scalability than certificates." As noted above, this is true for > client-server setup but not for a meshed group of peers. Meshes are not minimal, so they are not really part of this minimal IKEv2 specification. Minimal IKEv2 devices cannot be used to form a mesh, as minimal IKEv2 devices cannot talk to each other. The minimal IKEv2 device always talks to the full IKEv2 device. -- [email protected] _______________________________________________ Lwip mailing list [email protected] https://www.ietf.org/mailman/listinfo/lwip
