Subject: [Ace] Design Consideration Document as one milestone?

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 13 Mar 2014 02:09:58 +0100

Goeran raised a question about adding a milestone for a document that
captures assumptions and design criteria.

He contributed an initial version of such a document with
https://tools.ietf.org/html/draft-seitz-ace-design-considerations-00

What does the rest of the group think about that idea?

Would you be willing to review such a document?
Would you be willing to contribute to such a document?

Ciao
Hannes

---

From: Göran Selander <[email-masked]>
Date: Thu, 13 Mar 2014 15:00:55 +0000

Hi Hannes

Thanks for bringing this up. Let me give some context.

In the preparation for the BOF (and as was later shown in the BOF) it was
clear that there are strong opinions about the (in)feasibility of /public
key/ crypto in constrained devices. Some people state that ³there will
only be two public key operations in the lifetime of this device²,
referring to the high cost for asymmetric crypto so that they are only
used to establishing secret keys that are used thereafter. Yet other
people state ³the cost for public key crypto is negligable in today¹s
devices² 

Looking into the literature it is clear that public key crypto is in many
cases affordable, but also that it does not come for free. Moreover, when
comparing e.g. with message transmission and reception in wireless
embedded devices, you get another picture what may be expensive in
security protocol execution from an energy consumption point of view.
Section 3.2.2 discusses this in a symmetric crypto context.

This draft was put together in a rush a few days before cutoff and
contains mainly obvious things. As said, I¹m happy to use this as a basis
for a Wiki or restart the discussion. What I would like to see documented
is the (non-obvious) cost comparisons  and trade-offs between e.g.
round-trips and crypto operations, symmetric vs asymmetric operations etc.
to be able to refer to in future discussions when we need to assess the
feasibility of a particular security protocol in a constrained environment.

Göran

---

From: Olaf Bergmann <[email-masked]>
Date: Thu, 13 Mar 2014 16:36:18 +0100

> captures assumptions and design criteria.

I think that this document would be useful to track assumptions and
design considerations. If there was a milestone for this (is that really
necessary?) than it should be very later, after finishing most of the
protocol design.

Gruesse
Olaf

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 13 Mar 2014 17:05:56 +0100

Hi Goeran,

you raise another difficult question that relates a bit to the type of
IoT devices have in mind. I fully agree with the challenge you
identified regarding symmetric vs. asymmetric key crypto. It will be
difficult to reach a consensus on that topic since most people in the
group are actually not building devices themselves and therefore just
use what fits their solution best.

The cost of transmission that you mention is also important but the
implication of just having fewer round-trips is a bit too simplistic
since a constrained resource server will obviously suffer a lot since he
has to listen for incoming connection attempts.

So, I fear that (while these are super important aspects) we will have a
hard time to make any useful decisions about them is two-fold:

 * We are not designing complete systems in the IETF and the energy
assumption relates to the overall system (rather than a single
protocol). Most of it is outside the IETF protocol design.

 * The processing capability obviously depends on the hardware and we
are not making any statement about hardware in the group. Looking at
Carsten's presentation from the BOF it also relates to cost, which is
again a very complicated topic since hardware cost is not the only cost
in product development.

The classes in the LWIG terminology document do not go into any level of
details regarding computational power and energy consumption. Only the
memory requirements are listed in more detail and they seem to be rather
hand-wavy.

Ciao
Hannes

On 03/13/2014 04:00 PM, Göran Selander wrote:
> _______________________________________________
> Ace mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ace
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 13 Mar 2014 17:12:06 +0100

If we want to publish a document as part of the group then we also need
to have a milestone for it.

You need to tell me whether you think it is useful to add such a
document as a deliverable to the charter or not and whether you are
willing to review/contribute.

Ciao
Hannes

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 13 Mar 2014 17:37:02 +0100

On 13 Mar 2014, at 17:05, Hannes Tschofenig <[email-masked]> wrote:

> I fully agree with the challenge you
> difficult to reach a consensus on that topic

I don’t think that such a decision is possible or desirable.
We didn’t do that for CoAP (which has security modes, and preferred cipher suites, for both shared-key and public-key), and we shouldn’t try to do that here.

Grüße, Carsten

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 13 Mar 2014 17:45:55 +0100

Hi Carsten,

while that's an interesting way to post pone the problem it introduces
interoperability problems.

Clients implementing one option who talk to resource servers
implementing different options.

Do you see the interop challenges there?

Ciao
Hannes

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 13 Mar 2014 18:03:53 +0100

> interoperability problems.

This doesn’t postpone the problem, it simply acknowledges that it is not a problem because it can’t be solved.

> Do you see the interop challenges there?

Starting from the Berlin model:

M------A
|     (|)
|     (|)
C------S

It is probably worth keeping the C-S protocol free of asymmetric crypto, if only for performance reasons.
The A-S protocols (both the direct one and the one tunneled through M and C) are intra-domain and can therefore more easily be chosen for the specific application, so it is easier to live with both a symmetric and an asymmetric variant being around and to be chosen from; this is also true for the C-M protocol.
The M-A protocols should allow for a much larger variety, based on what is in use in the specific application sector.

But again, let’s generate those solutions first and evolve the objectives based on what is achievable, not the other way around.

Grüße, Carsten

---

From: Göran Selander <[email-masked]>
Date: Fri, 14 Mar 2014 11:02:38 +0000

Hi Hannes

More good comments.

There are two things here:

1. One is to describe how properties of a security protocol impact the
"performance” of constrained devices in scope of this work, and what trade
offs are possible.

2. The other is to list and motivate assumptions and design choices made
in the work to select/profile the security protocol to be made by this
group.

The motivations in 2. should be based on the understanding to the
properties in 1. Whether we need to actually document 1. or not depend on
if we assume that people who will review 2 have this knowledge.

While we cannot optimise the protocol for each given system, I claim that
there is some basic knowledge about constrained devices which may speak
for/against certain protocol candidates.

Maybe we should have tutorials on this too?

I think Klaus’ draft on practical issues with DTLS, although not speaking
about security protocols in general, is a good starting point:
http://tools.ietf.org/id/draft-hartke-dice-practical-issues-00.txt

More comments inline

>has to listen for incoming connection attempts.

Yes, round trips is too simplistic, e.g. size of messages has a large
impact too considering fragmentation. Even “listening" is too simplistic,
since there are various aspects of discontinuous reception, low-power
listening etc. So what can we say? There is expertise on specific
platforms and although there may be differences, my expectation is that
there is some common features like e.g. the cost for communication vs
symmetric crypto in a security protocol.

Göran

---

From: Sandeep Kumar <[email-masked]>
Date: Fri, 14 Mar 2014 16:51:38 +0100

Hi Hannes

The interoperability challenge you describe will be as much as a client
implementing "the chosen" option that talks to a resource server which does
not implement any option since it does not have the resources to implement
"the chosen" option. Given few options, it will be the system designers who
needs to mix-and-match devices based on the appropriate security
requirements into their system. Keep the number of options extremely small
(maybe 2).

Sandeep

On Thu, Mar 13, 2014 at 5:45 PM, Hannes Tschofenig <
[email-masked]> wrote:

> > I don't think that such a decision is possible or desirable.
> > We didn't do that for CoAP (which has security modes, and preferred
> cipher suites, for both shared-key and public-key), and we shouldn't try to
> do that here.
> >
> > Grüße, Carsten
> >

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 14 Mar 2014 07:15:06 +0100

Hi Sandeep,

if we call a specification describing a set of features a 'profile' then
you are in essence saying that you want the group to standardize more
than one profile.

In this email thread we only spoken about the difference between
symmetric vs. asymmetric crypto but there might be other differentiating
features as well (pending further exploration).

Did I interpret you correctly?

Ciao
Hannes

On 03/14/2014 04:51 PM, Sandeep Kumar wrote:
> implementing "the chosen" option that talks to a resource server which
> does not implement any option since it does not have the resources to
> implement "the chosen" option. Given few options, it will be the system
> designers who needs to mix-and-match devices based on the appropriate
> security requirements into their system. Keep the number of options
> extremely small (maybe 2).
> 
> Sandeep
> 
> 
> On Thu, Mar 13, 2014 at 5:45 PM, Hannes Tschofenig
> <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     Hi Carsten,
> 
>     > On 13 Mar 2014, at 17:05, Hannes Tschofenig
>     <[email-masked] <mailto:[email-masked]>> wrote:
>     >
>     > We didn’t do that for CoAP (which has security modes, and
>     preferred cipher suites, for both shared-key and public-key), and we
>     shouldn’t try to do that here.
>     >
>     > Grüße, Carsten
>     >
>     > [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

---

From: Göran Selander <[email-masked]>
Date: Mon, 17 Mar 2014 06:28:47 +0000

Trying to generalise Carsten's and Sandeep¹s input on the various options
of ³symmetric vs. asymmetric². Aren¹t the two main questions about the
following keys:
                   
                  K1: What kind of keys shall be used by the Resource
Server and Authorization Server to protect the authorisation information?

K2: What kind of keys shall be used by the Client and Resource Server to
protect the access request/response procedure?

Two assumptions were made in the architecture presentation of the BOF:

K0: There are keys established between RS and AS (what kind?). How these
are established is out of scope for the work.

P1: The keys in K1 can be used to establish the keys in K2. This
protocol/algotrithm is in scope for the work.

(P1 is one of the main tasks of ACE together with how to transfer
authorization information from AS to RS, which may be the same protocol)
 
What we didn¹t discuss in the BOF was whether the keys in K0 are identical
to the keys in K1. If they are not, the implicit assumption is however:

P0: The keys in K0 can be used to establish the keys in K1. This
protocol/algorithm is in scope for the work.

Then there are the meta questions like

M1: Shall the work specify a single kind of keys K0, K1, K2?

M2: Shall the work specify different cipher suites?

Examples of working assumptions:

Example 1.
---
M1: yes 
M2: no 
K0: asymmetric 
K1: symmetric 
K2: symmetric 

P0 could e.g. be Diffie-Hellman (say DTLS with raw public keys)
P1 could be your favourite symmetric key candidate protocol

Example 2.

---
M1: yes  
M2: yes 
K0: symmetric 
K1: symmetric 
K2: asymmetric 

K1 = K0, so there is no P0. The key used in K2 may be specified in the
authorisation information, say "h(PK_C) has the right to GET
/bloodpressure², where h(PK_C) is the hash of the public key of the
Client.  P1 carries and protects the authorisation information and
communicates also which cipher suite is to be used between Client and RS.

Example 3.
---
M1: no
M2: no
K0: asymmetric or symmetric
K1: symmetric
K2: symmetric

The work specifies two alternatives for establishing the keys in K1 (say
as in examples 1 or 2). The protocol P1 uses whatever keys K1.

Now mapping Carsten's and Sandeep¹s input to this terminology. Both answer
M1: no.

If I understand Carsten right he says that K2 should be symmetric. Some
keys established between RS and AS may be either symmetric or asymmetric.
Like in example 3?

If I understand Sandeep right he is saying that we should allow both
symmetric and asymmetric keys in K2, and he answers M2: yes. Were you
thinking of communicating ciphersuites like in 2?

Did I get it right?

Is this helpful or does it just complicate matters?

Göran

PS

I left out potential keys used in communication between Client and AS
because
a) it is not necessary that they communicate at all
b) the Client may use different keys in communicating with AS and RS,
respectively
c) the keys used may depend on access policy (see Ex. 2 above) and we want
the authorisation solution to be independent of access policy.

On 14/03/14 07:15, "Hannes Tschofenig" <[email-masked]> wrote:

>>     > I don¹t think that such a decision is possible or desirable.
>>     > We didn¹t do that for CoAP (which has security modes, and
>>     shouldn¹t try to do that here.
>>     >
>>     > Grüße, Carsten
>>     >