Hi all
The message below is Ekr's review of the CoAP draft. The IPsec part (relates
mostly to section 10.1) might be of interest to this working group.
I'd go further than Ekr, and say that IPsec should not be used without IKE.
I'm not sure whether or not section 10.1 is there because they actually intend
people to use IPsec to secure CoAP in its intended environment, or whether it
is just there to "not leave any stone unturned". Certainly DTLS is described in
much more detail, while section 10.1 reminds me of some old security
considerations sections saying "just use IPsec".
Begin forwarded message:
> From: Eric Rescorla <e...@rtfm.com>
> Date: November 7, 2010 11:28:49 PM GMT+02:00
> To: "c...@ietf.org" <c...@ietf.org>
> Subject: [core] Review of draft-ietf-core-coap-03
>
> I've reviewed this document. Comments below.
>
> My concerns here are primarily about the security parts, which seem a
> bit handwavy. It's certainly possible to build systems where all the
> security provided by channel security mechanisms (IPsec and DTLS) but
> can't tell if this is such a system without more security analysis.
>
> In particular:
> - What's the general trust model in terms of the relationship between
> the servers and clients?
> - What are the assumed capabilities of the devices in question?
> - How is access control expected to behave with respect to proxy caches?
> (The HTTP story is clear but you've stripped out the HTTP access
> control mechanisms). I don't see how a server even verifies a
> client who goes through a cache.
> - I'd like to see some discussion of cross-protocol attacks, which
> seem likely with the NoSec mode.
>
> IPsec
> You don't actually say this, but I'm assuming that you intend to
> use IPsec's manual keying mode, rather than IKE. If so, this seems
> to have a series of obvious problems around the lack of guaranteed
> fresh keys/nonces, as well as replay attacks. In particular, if
> you're going to have single-packet messages which control network
> devices, it seems like anti-replay is very important, but RFC 4303
> says:
>
> If the key used to compute an ICV is manually distributed, a
> compliant implementation SHOULD NOT provide anti-replay service. If
> a user chooses to employ anti-replay in conjunction with SAs that are
> manually keyed, the sequence number counter at the sender MUST be
> correctly maintained across local reboots, etc., until the key is
> replaced. (See Section 5.)
>
> This seems like a fairly problematic combination and at minimum
> needs some discussion.
>
> I'm similarly concerned about the use of CCM, which fails
> catastrophically in the face of replayed packets. I'd like to
> understand how you're going to assure that the nonce is never replayed
> in the face of very long-lived keys used throughout a large network.
> Recall that the birthday limit for AES-CCM in ESP is only 2^{32}
> packets, but even that's for ~0.5 probability of replay. The security
> is weakened long before that.
>
> IMO it's very unwise to use ESP this way w/o at minimum some form of
> automatic key diversification.
>
>
> DTLS
> The claim that DTLS is an order of magnitude more complicated than CoAP
> is unsupported and, for instance, if we're just counting pages that doesn't
> appear to be correct. Certainly, if you just do TLS_PSK modes, that's
> not correct. In my experience, the majority of the code in a TLS stack
> is the crypto algorithms and the certificate processing. You will
> need the crypto algorithms in any case and the PSK profile you have
> chosen does not require certificates. If this is the basis for thinking
> that DTLS inadequate, you may want to rethink that. Regardless, please
> please remove this claim.
>
> Similarly, I don't know what "appreciable handshake overhead" means.
> Please provide some measurements for the profile you have chosen or
> remove this as well.
>
> The particular TLS PSK mode you specify has no private entropy other than
> from the shared key. If you are going to select this mode, you need
> language about the minimum entropy of the PSK. This is an issue for
> IPsec as well, btw.
>
> The PSK modes are not specified in 5246, so please fix this citation.
>
> Throughout the document you write "cypher suite". The TLS term is "cipher
> suite"
>
> The question of whether you should use certs is quasi-orthogonal to whether
> you use TLS_RSA_PSK. You can use self-signed certs with TLS_RSA_PSK.
>
>
> S 10.3.1.
> This seems kind of superfluous. Code in general has bugs and it's not
> clear that "stringent tests" are that useful for finding them.
>
>
>
> -Ekr
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
