Subject: [6tisch-security] PSK vs. RPK vs. certs: costs?

From: Thomas Watteyne <[email-masked]>
Date: Fri, 13 May 2016 14:41:22 +0200

All,

At the 6tisch-sec call yesterday, we discussed three approaches: PSK, RPK
and certs.

Can someone indicate:
- the cost in number of packets of each approach
- an idea on the memory footprint of the associate solution
- what protocol we can use off-the-shelf, what protocol we need to create

Thomas

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 16 May 2016 12:51:17 +0300

Thomas Watteyne writes:
> At the 6tisch-sec call yesterday, we discussed three approaches: PSK, RPK and
> certs.

I am using IKEv2 as an example here, mostly because that is what I
know best.

> - the cost in number of packets of each approach

In IKEv2 all except EAP uses 2 pairs of messages, i.e., 4 in total.
The first exchange does the Diffie-Hellman and its size depends mostly
on the Diffie-Hellman group used. Second exchange does the
authentication and its size depends on the authentication. For the PSK
AUTH payload is size of the HASH, i.e., 32 bytes for the SHA2-256. For
certs and raw public key it is signature, thus about same as public
key, and for 256-bit EC it is about same size than PSK hash, i.e., no
real difference there.

For both raw public key and certificates there is need to transmit the
public key during the exchange too unless the other end already knows
it. For raw public keys, the 256-bit EC key is about 100 bytes.
Certificates are usually in the order of 500-1000 bytes, which makes
them too large for normal use in the IoT. You can of course
transmit only the pointer to the certificate in IKEv2, and then the
JCE can fetch the certificate from network. 

> - an idea on the memory footprint of the associate solution

If you already have Diffie-Hellman public key operations, then I do
not think adding public and private key operations uses too much
memory footprint. 

> - what protocol we can use off-the-shelf, what protocol we need to

I would recommend using existing key management protocols. Taking
existing crypto protocol and making key management protocol out of
that, is not that hard, but unless you really know what you are doing
and even then, there is possibility that the way you use things are
not safe. Especially if someone then later uses your protocol in a way
which was not originally asssumed. For example TLS history has several
examples of such issues. Secure shell, and IKE had their own issues
too.

It is better to take existing protocol and reduce features from it to
make it smaller and suitable to IoT than to create completely new
protocol and hope it is safe. For example I have already implemented
minimal IKEv2 and that was less than 1000 lines of code (either python
or perl, not counting crypto libraries). 
-- 
[email-masked]

---

From: Thomas Watteyne <[email-masked]>
Date: Tue, 17 May 2016 08:50:04 +0300

Tero,
Thanks for the details. Great to read the overhead of RPK is not that high.
I agree with you on reusing existing protocols. Do you have a link to the
1000-line Python implementation of IKEv2?
Thomas

-- 
_______________________________________

Thomas Watteyne, PhD
Research Scientist & Innovator, Inria
Sr Networking Design Eng, Linear Tech
Founder & co-lead, UC Berkeley OpenWSN
Co-chair, IETF 6TiSCH

www.thomaswatteyne.com
_______________________________________

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 17 May 2016 15:00:27 +0300

Thomas Watteyne writes:
> Thanks for the details. Great to read the overhead of RPK is not that high. I
> agree with you on reusing existing protocols. Do you have a link to the

https://pypi.python.org/pypi/ike

I never published my perl version (would have required me to get some
permissions etc from the company), but as both of these are mostly
just proof of concept type of implementations it does not really
matter. But both the perl and python version did work against full
IKEv2 version (they of course cannot interoperate as both of them are
minimal versions, thus they do not support working as responder). 
-- 
[email-masked]

---

From: Thomas Watteyne <[email-masked]>
Date: Tue, 17 May 2016 15:14:21 +0300

Awesome, thanks for the pointer

On Tuesday, May 17, 2016, Tero Kivinen <[email-masked]> wrote:

> [email-masked] <javascript:;>
>

Thomas Watteyne, PhD

www.thomaswatteyne.com

---

From: Michael Richardson <[email-masked]>
Date: Tue, 17 May 2016 10:27:22 -0400

Thomas Watteyne <[email-masked]> wrote:
    > At the 6tisch-sec call yesterday, we discussed three approaches: PSK,
    > RPK and certs.

    > - the cost in number of packets of each approach

I think that this little point in detailing this until one explains the
threats and the attacks that are defended against.
        Full plate armor is much
        better than chain mail against swords, but fail against bullets.
        I'm told that chain mail is significant worse than no armor (against
        bullets) because the chain mail creates shrapnel.

Secondly, PSK, RPK and certs are not protocols, but ways to authenticate the
DH exchange.  They may or may not provide authentication of the host itself.

    > - what protocol we can use off-the-shelf, what protocol we need to

We have DTLS and IKEv2.  I can imaging using IKEv2 over OSCOAP.
It requires two exchanges (four packets).
   I1 - sample I have is 504 bytes, which includes 12 choices in
        algorithms (crypto-agility), and a 256 byte modp2048.  A ECDH would
        be much smaller (32 bytes rather than 256).  So let's call it 256 bytes.
        This includes ethernet and IPv4 and UDP overhead.
   R1 - 404 byte reply.  1 choice, 256 byte g^y, ethernet.
   I2 - 584 bytes, encrypted response, no certificate.
      - 1532 bytes, includes 1059 byte RSA certificate (DER encoding)
   R2 - 1480 bytes, includes certificate of equal size.

As I understand OSCOAP, we can send COSE objects, and *THEY* can be signed
with an assymetric key, "directly". (well, not directly, there is a still a
hash layer inside the signature)

If one does that, then potentially one does not need to do a key exchange *at
all*.    There is a replay concern though which we would need to address.

--
]               Never tell me the odds!                 | ipv6 mesh networks [

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Michael Richardson <[email-masked]>
Date: Tue, 17 May 2016 10:56:15 -0400

> minimal versions, thus they do not support working as responder).

Do you think that a minimal responder (only) would be bigger or smaller?
I think smaller.

---

From: Göran Selander <[email-masked]>
Date: Tue, 17 May 2016 17:38:32 +0000

Hi

I'm still struggling with understanding the objectives and the
assumptions. Here is an attempt, please bear with me.

1. If I understand draft-richardson-6tisch--security-6top-05 right, the
objective of the join procedure is for the JN to obtain either (a) a
network-wide shared symmetric key (I assume this is K2) or (b) an 802.11AR
LDevID certificate.

Correct so far?

2. Isn't another objective to establish session keys between the JN and
the JCE that will be used e.g. by JCE for configuration of the JN? I
assume that is relevant both for (a) and (b) above.

3. When it comes to what initial credentials (PSK, RPK, or certs) to use
to authenticate the join procedure, I don’t disagree with Tero’s list of
issues with PSK, but I believe there are many aspects to consider here and
maybe one size doesn’t fit all? The risks with PSK are known and the use
of pair-wise symmetric keys and commissioning in a controlled deployment
environment still makes sense in many industrial settings.

The discussion on PSK vs RPK vs certs reminds me of the a similar
discussion in the ACE WG meeting in Buenos Aires where the WG was nicely
split into three camps. The conclusion from that discussion was that we
probably need to support all three because of the variety of deployment
settings. I don’t know if that is relevant here, but I make that
assumption in this mail.

4. One potential approach to achieve 1 and 2 above, given 3, is to do it
in phases:

Phase I: Run a key establishment protocol between JN and JCE authenticated
with the initial credentials (PSK, RPK, certificate) to establish a shared
master secret between JN and JCE. From the master secret, JN and JCE can
individually derive a common session key SK used to protect communication
between JN and JCE. (Done 2 above.)

Phase II (a): The JCE configures K2 on JN and receives a response to
verify that the configuration succeeded, the message exchange is protected
by SK. Alternatively, the JN requests K2 (GET) from JCE and receives it in
the response, the message exchange protected by SK. (Done 1 (a) above.)

Phase II (b): JN makes an enrolment request integrity protected with SK,
and receives as response the 802.11AR LDevID certificate. (Done 1 (b)
above.)

5. Both phases can be run between JN and JCE on top of CoAP, and in
principle doesn’t require IP, unless there is some other reason why IP is
needed. 

Phase I: The key establishment protocol can be embedded in COSE and sent
over CoAP. Diffie-Hellman in COSE is the content of EDHOC (2 messages),
but you can embed some other protocol like IKEv2 in COSE instead.

Phase II (a): This is one round trip with OSCOAP (which are COSE objects
sent with CoAP), either a POST or a GET and its response (2 messages).

Phase II (b): An enrolment request is quite naturally a COSE object which
can be sent in a CoAP POST, and the response payload would then be the
802.11AR LDevID certificate (2 messages)

Again, since I don’t know all details here I’ve probably misunderstood
something.

Göran

On 2016-05-17 16:27, "6tisch-security on behalf of Michael Richardson"
<[email-masked] on behalf of [email-masked]>

---

From: Michael Richardson <[email-masked]>
Date: Wed, 18 May 2016 21:39:53 -0400

> assume that is relevant both for (a) and (b) above.

The idea is to establish this first 6top connection.
The JCE can then configure (via 6top) the LDevID into the node, and push
the domain's certificate into the new node.  The first connection is
authenticated with the IDevID and ???+ownership voucher. (I have specific
ideas about the ??? which may involve more PKI than some would like)

Then it should do a new authentication round with the new credentials, and
quite possibly store (D)TLS session resumption token generated by the new
node.

Or, it could provision some pair-wise PSK between JCE and new node to be used
later on.

    > maybe one size doesn’t fit all? The risks with PSK are known and the

Yes, but we have some specific requirements in 6tisch as to it's industrial
applicability that significantly narrows the scope.   Please take a look at
https://tools.ietf.org/html/rfc5673 and
https://tools.ietf.org/html/draft-ietf-roll-rpl-industrial-applicability-02

the second document did not go forward because it became clear that RPL alone
could not satisfy the requirements; the 6tisch WG was created in large part
to satisfy things.

    > Phase I: Run a key establishment protocol between JN and JCE
    > authenticated with the initial credentials (PSK, RPK, certificate) to
    > establish a shared

    > verify that the configuration succeeded, the message exchange is

Well, I think you've described our plan exactly.
The Phase I protocol is DTLS/CoAP/6top unless we think of a better way, such
as doing OSCOAP above CoAP.

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 19 May 2016 14:32:52 +0300

> Do you think that a minimal responder (only) would be bigger or smaller?

Bigger. Mostly because for minimal initiator does not need to cope
with multiple simultaneous exchanges.

Of course everything depends what kind of limitiations you do. Most
likely you would need to support multiple "clients" connecting to you,
i.e. you need to support multiple IKEv2 connections at the same time,
and you need to support packets coming in interleaved.

Also IKEv2 initiator can limit things a lot, for example it can only
send one set of crypto algorithms, and specific traffic selectors.
Responder needs to have full parsers to be able to parse the full
crypto algorithm proposal, and picking one from there, and it needs to
be able to narrow down the traffic selectors etc. Also responder end
usually will need policy lookup code, i.e., based on who is connecting
it needs to know whether connection is allowed or not, and which
configuration (PSK etc) to use.

If we make limitiations which are NOT in the IKEv2 base spec then we
can most likely make the responder about the same size as initiator,
but then it would not really be IKEv2 anymore (i.e., if we say that
there can only be one crypto algoritm proposal, we are not really
conforming IKEv2, as conforming IKEv2 implementation could send us
more complicated proposal, and we could not cope with it).

Anyways I have not tried writing minimal responder, but my guess is it
would be about 20-50% bigger than very minimal initiator.

The more features minimal initiator supports the smaller the size
difference between initiator and responder is...
-- 
[email-masked]

---

From: Michael Richardson <[email-masked]>
Date: Thu, 19 May 2016 09:54:23 -0400

> likely you would need to support multiple "clients" connecting to you,

For the join process, we only need to support one client (the JCE).
Once the join SA is setup, only then the PCE might connect to do scheduling,
and that would be single-threaded too.
But, for 6top hop-to-hop, if we use per-pair 802.15.9 security on the IEs, it
would require multiple responses.

    > Also responder end

That's a good point.

    > more complicated proposal, and we could not cope with it).

If we put IKEv2 on top of CoAP, one affect might be to limit things to one
request at a time, and eliminate a whole bunch of TS options...

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 20 May 2016 15:05:13 +0300

> For the join process, we only need to support one client (the JCE).

In join process, I would assume that the joining node is the
initiator, and the JCE is the responder, and there might be multiple
joining nodes joining to the same JCE at the same time. Thus the JCE
needs to be able to cope with multiple different initiators at the
same time.

I.e., I would assume that in joining protocol the joining node is the
one who initiates the joining process and connectes to the JCE. Of
course if there is some other exchange from the joining node to the
JCE first which will then trigger the JCE to start connection to the
JN, then the roles are different, and then JN will have just one
incoming connection at one time.

> and that would be single-threaded too.

I would assume that the scheduling might be run over the K2. 

> would require multiple responses.

802.15.9 is already bit different, as there is already some things
which make things easier. 

> request at a time, and eliminate a whole bunch of TS options...

In 802.15.9 the IKEv2 do not create Child SA at all, as there is no
need for that, i.e. it uses RFC6023 which will leave out Child SA
negotiation, including the TS payloads completely. The 802.15.9 uses
the first 16 octets of the KEYMAT generated by IKEv2 for the AES-CCM
key directly for the per-pair key.

One thing that 802.15.9 with IKEv2 does not yet do is to define
protocol to distribute the 802.15.4 shared keys. I.e., it just says
that for shared key transport we need to add new feature to IKEv2, but
do not add it there, as this is something that is better done in the
IETF than in IEEE. It should be very short RFC just specifying how to
encode the shared key information and the keying material when it is
transmitted over the IKEv2 SA. Most likely we want to keywrap the
key somehow, but that should still be quite easy, as we are just
transmitting shared key over the already protected and authenticated
channel. 
-- 
[email-masked]

---

From: Göran Selander <[email-masked]>
Date: Fri, 20 May 2016 14:24:41 +0000

Hi Michael,

Thanks. Some further questions just to see I got it right.

>The idea is to establish this first 6top connection.

I assume that is Phase I, as below.

>the domain's certificate into the new node.

I assume that happens after Phase I, so that the security for those
configuration operations is rooted in Phase I.
 
About “push of domain certificate” - I thought this was like an enrolment
protocol: JN makes an enrolment request (protected with keys from Phase I)
and receives the certificate in the response. Or is the join request and
enrolment request combined?

Is the same asymmetric key pair used for the IDevID certificate and the
LDevID certificate?

>The first connection is

I would like to better understand this part, what are the requirements?

>quite possibly store (D)TLS session resumption token generated by the new

I can understand the motivation to separate the IDevID credential from the
LDevID credential in principle. But if the key pair is the same, or if the
second key pair is provisioned during manufacture, I don’t see a big
difference using the credentials derived during Phase I.

>Or, it could provision some pair-wise PSK between JCE and new node to be

Again, Phase I results in symmetric key material including a session key,
why not use that until it needs to be rotated (in which case the LDevID
certificate would be the right credential to use)?

>https://tools.ietf.org/html/draft-ietf-roll-rpl-industrial-applicability-0

I glanced through the documents. Would you say that this excludes any of
PSK, RPK, and certs, or that all three should be possible to support?

>as doing OSCOAP above CoAP.

OK, good. Which of the phases do you want to run before IP?

Göran