Subject: [Lwip] Comments: draft-ietf-lwig-ikev2-minimal-01

From: Yaron Sheffer <[email-masked]>
Date: Mon, 21 Oct 2013 00:16:02 +0300

Although I am co-chair of ipsecme, please treat these comments as an 
individual's.

In general I think a minimal subset of IKEv2 can be very useful. But I 
wonder if this is too minimal:

• 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...
• 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. 
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.

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.
• Why not omit AH from the minimal implementation?
• 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.
• Seems to me you should include PRF_HMAC_SHA2_256.
• A.8: For the AUTH payload you can omit DSS.
• Is ID_RFC822_ADDR relevant for this type of devices?
• 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.
• 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.

Thanks,
Yaron

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 25 Oct 2013 15:38:13 +0300

> 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. 

> 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. 

> identity and extensions crap. Unfortunately this is unlikely to ever 

Certificates is more complex than full IKEv2, thus if you are using
certificates you should use full IKEv2 too. 

> 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. 

> 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-masked] is much more understandable for the adminstrator
than the device id 0x238e853d.

> 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... :-)

> 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-masked]