Subject: [Ace] How to progress?

From: Stefanie Gerdes <[email-masked]>
Date: Wed, 23 Jul 2014 19:19:17 +0200

Hi everyone,

The discussion today and during the previous meetings made me think that
there are still a lot of unspoken assumptions and requirements flying
around. I think we won't be able to come to an agreement on a solution
if we don't manage to identify the key assumptions and requirements.
This is why I came up with a couple of questions which I think would
help to explore the context of the problem we are trying to solve. I
know that there will in most cases not be only one answer to these
questions but I think we will need to get a feeling about the range of
answers.

These are the questions I came up with:
1. What categories of constrained devices do we want to support (C0, C1..)?
  1a) What are the smallest devices we are going to support (RAM, ROM, etc)?
2. For each device in the architecture: What are the limitations of this
device?
  2a) Are the limitations always the same?
  2b) How much can we gain from introducing less constrained actors?
3. What message sizes do we want to consider?
4. What are the application security requirements for the
   communication between constrained nodes?
  4a) Integrity
  4b) Confidentiality
  4c) Non-Repudiation
  4e) ...
  4f) Are all of these always needed?
5. Which level of security is needed on the devices (high, middle, low)?
  5a) Do we always need devices to be tamper-proof?
6. How do the constraints of the nodes influence the protocols to be used?
7. Can we find a single protocol which supports all kinds of devices in
  every part of the architecture?
8. What roles do proxies have that we want to support?
9. Do we need authorization without user interaction?
10. Which constraints concerning the connectivity of devices do we want
   to support?
  10a) "Offline" authorization (only some devices are "online", no
       device is online, etc)
  10b) Intermittent connectivity
  10c) Special connectivity requirements (e.g. unidirectional links)

I thought it might be helpful to collect the relevant questions and
assumptions in a wiki: http://trac.tools.ietf.org/wg/ace/trac/wiki/Questions

What do you think?

Thanks,
Steffi

---

From: Likepeng <[email-masked]>
Date: Wed, 23 Jul 2014 17:46:57 +0000

>I thought it might be helpful to collect the relevant questions and assumptions in a wiki: http://trac.tools.ietf.org/wg/ace/trac/wiki/Questions

I think it is a good idea.

It will be better if we can put choice questions or yes/no questions, instead of open questions, to narrow down the scope and make them easier to be answered.

Kind Regards
Kepeng

-----邮件原件-----
发件人: Ace [mailto:[email-masked]] 代表 Stefanie Gerdes
发送时间: 2014年7月23日 13:19
收件人: [email-masked]
主题: [Ace] How to progress?

Hi everyone,

The discussion today and during the previous meetings made me think that there are still a lot of unspoken assumptions and requirements flying around. I think we won't be able to come to an agreement on a solution if we don't manage to identify the key assumptions and requirements.
This is why I came up with a couple of questions which I think would help to explore the context of the problem we are trying to solve. I know that there will in most cases not be only one answer to these questions but I think we will need to get a feeling about the range of answers.

2. For each device in the architecture: What are the limitations of this device?

I thought it might be helpful to collect the relevant questions and assumptions in a wiki: http://trac.tools.ietf.org/wg/ace/trac/wiki/Questions

What do you think?

Thanks,
Steffi

_______________________________________________
Ace mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ace

---

From: Rene Struik <[email-masked]>
Date: Wed, 23 Jul 2014 14:32:57 -0400

Hi Stefanie:

I provided a first stab at this - see below.

Two additional notes:
- Desired functionality should drive design and design considerations 
{some of the questions below seem to unnecessarily restrict the design 
freedom}. Ultimately, one deploys a system, because of provided device 
and network/system functionality, ease of use and ease of maintenance.
- Functionality should consider that networks may be composed of 
components that have been sourced from multiple vendors along the supply 
chain (and may have changed hands along, e.g., system integration during 
pre-operational use or during operational use itself.

Best regards, Rene

>    1a) What are the smallest devices we are going to support (RAM, ROM, etc)?
RS>> Design should be based on desired functionality, flexibility, and 
ease of use, more so than a priori putting roadblocks on perceived 
complexity forward that would limit the design freedom. Usually, lots of 
optimizations can be done once one has an overall design that meets the 
desired deployment and ease of use use cases. It is very hard to make 
definitive statements here.
<<RS

2. For each device in the architecture: What are the limitations of this
device?
   2a) Are the limitations always the same?
   2b) How much can we gain from introducing less constrained actors?
RS>> Not so useful to a priori get a turf war on perceptions on complexity, without having the right anchors to try and be creative with an overall design exercise.
<<RS
  3. What message sizes do we want to consider?
RS>>
Small is beautiful, but somewhat premature and not that useful to bind hands behind the back in a vacuum.
<<RS
  4. What are the application security requirements for the
    communication between constrained nodes?
   4a) Integrity
   4b) Confidentiality
   4c) Non-Repudiation
   4e) ...
   4f) Are all of these always needed?
RS>>
For overall IoT potential to be reached, one needs to provide usual security constructs (on crypto front: AEAD cipher based AES, ECC engine, RNG, perhaps PUF block;
on security front: authenticated key agreement scheme, cert scheme, provisioning scheme, key management functionality, synchronization scheme). Luckily, most of the
basic building blocks can be considered to be commodity blocks, esp. if built-in using hardware support (in terms of RAM/ROM, energy use, computational time
latencies, etc.) What I see missing is security policy management functionality (device roles, including meta-roles to effectuate changes hereto, language so as to
convey this info in messages, etc.
<<RS
  5. Which level of security is needed on the devices (high, middle, low)?
RS>>
Not sure what High/Middle/Low means. The cost of providing <128 bit crypto bit strength is probably very similar to that of providing 128 bits crypto bit strength
(case in point: most AEAD cipher simply truncate MAC tag size from AES block size of 128 bits to, e.g., 64 bits, without any computational cost penalty. The only
cost here would be communication time latency and, thereby, energy cost.
<<RS
  5a) Do we always need devices to be tamper-proof?
RS>>
Not sure whether ensuring the authenticity and/or confidentiality of keying material, security material, and, e.g., implementation code would be in scope for IETF to
prescribe. This seems to be more a device manufacturer's prerogative, where industry bodies sometimes may impose certain assurance levels (EAL, etc.)
<<RS
  6. How do the constraints of the nodes influence the protocols to be used?
RS>>
Designs should take into account limitations in targeted capabilities of devices, both in terms of computational capabilities, storage space, availability of tamper
evidencing, peak and average energy consumption, time latency impact of communicated information, etc. Obviously, small is beautiful here, but also uniform design
catering to minimization of overall system architectural design cost is more important than trying to locally optimize various components. This should also take
into account device provisioning, configuration, management capability, where one should remember that the most expensive component of the solution may be any personnel
that may be required to make things work, maintain, etc. {much higher impact than incremental cost of, e.g., implementing commodity crypto components}.
<<RS

  7. Can we find a single protocol which supports all kinds of devices in
   every part of the architecture?
RS>>
Personal perspective: YES, if we stick to the objective of a design that minimizes the total implementation cost over the entire device and network lifecycle, including
provisioning.
<<RS
  8. What roles do proxies have that we want to support?
RS>>
This discussion is best deferred till after initial architectural design has been painted. Overall, most importantly, if delegation happens on a device a specific device
communicates with, this specific device should be blissfully obliviously unaware of this.
<<RS
  9. Do we need authorization without user interaction?
RS>>
Obviously, in many cases the answer is yes (since, e.g., receipt of AEAD-secured packets accepts these if incoming security processing succeeds with the proper key
and where knowledge of the key implies authorization (black-and-white authorization). There are definitely lots of cases where a human decision element is required
or beneficial, e.g., with network provisioning and configuration.
<<RS
  10. Which constraints concerning the connectivity of devices do we want
    to support?
   10a) "Offline" authorization (only some devices are "online", no
        device is online, etc)
   10b) Intermittent connectivity
   10c) Special connectivity requirements (e.g. unidirectional links)
RS>>
Networks should be able to operate also in sleepy settings, where connectivity is not a given. Moreover, networks should be able to recover from temporary glitches in
normal expected operational conditions. For sleepy devices, reliance on online connectivity should be the exception, rather than the rule.
<<RS

What do you think?

Thanks,
Steffi

-- 
email: [email-masked] | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 23 Jul 2014 21:05:57 +0200

Hi Steffi,

the attempt so far was to answer these questions from a different
direction: instead of starting with a specific device platform (e.g.,
class, memory requirements, message size, etc.) we thought that the use
cases are going to constrain the solution space and help to guide our work.

It turned out that this is rather complex since we have not managed to
receive detailed enough use case descriptions that would, for example,
let us rule out a specific communication design pattern or prefer a
specific credential type.

My worry is that we design for an artificial platform that may or may
not reflect the use cases people have in mind. Of course, it might be
possible that folks in the group do not want to share the details about
their use cases and then we are obviously a bit in trouble since we just
have to guess.

There are, however, a question listed below that are quite good and
raised during the working group meeting. For example, the 'intermittent
connectivity' aspect was raised today as something that has not been
explored in enough detail. Also the roles of proxies in the architecture
is an aspect that has been discussed at the BOF already and there was
the hope that specific use cases would give more details about the
real-world use case. So far, it is not even clear what protocols the
proxy would bridge.

Ciao
Hannes

On 07/23/2014 07:19 PM, Stefanie Gerdes wrote:> Hi everyone,
> assumptions in a wiki:
http://trac.tools.ietf.org/wg/ace/trac/wiki/Questions
> Steffi

On 07/23/2014 07:19 PM, Stefanie Gerdes wrote:> Hi everyone,
> assumptions in a wiki:
http://trac.tools.ietf.org/wg/ace/trac/wiki/Questions

---

From: Michael Richardson <[email-masked]>
Date: Wed, 23 Jul 2014 17:26:32 -0400

> 1. What categories of constrained devices do we want to support (C0, C1..)?

I am skeptical that we will support C0 devices even with symmetric methods,
will they even support DTLS at all (from a code space point of view...)
I can HOWEVER, imagine a C0 device offloading part of it's DTLS setup to a
less constrained devices in a proprietary way, such that what results is that
it only processes symmetrically signed, DTLS encrypted CoAP messages.

    > 2b) How much can we gain from introducing less constrained actors?

My take is that the important limitations of the constrained device are
not RAM/ROM/CPU/energy,  but rather network connectivity (quantity, latency,
and connectivity), and specifically the limits that puts on useful user
interfaces.

So the key service that the AS offers the RS is that it can evaluate complex
policies expressed poorly by not-always sane (but well meaning) humans, and
translate that into a series of authorization tokens that are easy to
evaluate.

(For instance, let's say that I wrote a policy like; "let all the members of
my family control the hot-tub temperature any available value, except for
Aunt Mertyl who is too elderly to understand she isn't allowed, so just give
her the ability to turn the jet on"... could be translated into, rather than
a group statement, into a series of unicastable tokens {member-of-family X
reasonable-temperatures}, which it distributes to the smartphones of the
people who needs them.  I guess if the WG prefers, I can translate to a
Banana example)

    > 3. What message sizes do we want to consider?

I'm not sure I understand the question.
I think that it should be possible to do all ACE provisioning over CoAP,
and I think CoAP likes 1K max message sizes, right?

    > 4f) Are all of these always needed?

We need confidentiality, but we may assume it might be provided by layer-2 at
times.  We might not need any of the rest of the tokens are sufficiently
bound to the identities. In the general case, we have to support the
messages transiting the hostile open internet over multiple layer-2,
and contain bearer tokens. So from a specification point of view, we have a
MUST implement for all of these things, but a MAY on using them.

    > 5a) Do we always need devices to be tamper-proof?

No, we can not afford all devices to be tamper-proof, but we might insist that
all devices be field upgradeable (that might be out of scope).  I might even
suggest that being tamper proof is opposed to some forms of field upgradeble.
Tamper proof != tamper detection/auditing.

In general, I think it is out-of-scope.

    > 6. How do the constraints of the nodes influence the protocols to be used?

I can not answer this yet.

    > 8. What roles do proxies have that we want to support?

That's a hard question.
Can we start by making a list of what kind of roles proxies *can* do?

    > 9. Do we need authorization without user interaction?

Yes; it needs to be possible to give authorization servers a general policy
and let them generate new authorizations for new clients without an
interaction with either the RS or a human.

    > 10c) Special connectivity requirements (e.g. unidirectional links)

C and RS must each (seperately) be online during enrollment.
C must be able to act on RS when both are disconnected from everything.

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

---

From: Göran Selander <[email-masked]>
Date: Thu, 24 Jul 2014 05:49:08 +0000

Hi Steffi, WG chairs and all,

First, on Steffi's high level question ³How to progress?².

The ACE WG meeting yesterday focused on the difficult questions, which I
think makes sense for a f2f meeting. But listening to the discussion, I
sensed no major disagreement of the general problem statement although
there are further use cases or aspects of use cases to be added, specific
details debated, and opinions of scope of the work. If this is indeed the
case - that there is an agreement about the problem statement at a certain
level - I think I would make sense to progress the work by listing what we
actually do agree upon, in parallel to working on the open questions.

One purpose with draft-seitz-ace-problem-description is exactly this.
Section 4 (4.1 - 4.10) of the problem description is trying to extrapolate
a list of more detailed assumptions and requirements from the use cases.
We also made a review of this list in the group of 8 persons attending the
Stockholm interim meeting, which is reflected in the -01 version. It also
lists some identified open issues (4.11).

There has been very few comments on this draft in general and section 4 in
particular.

- Do you (all) agree to the statements in section 4 of
draft-seitz-ace-problem-description?

- Is this useful as a starting point?

I include some specific items from section 4 into Steffi's questions
inline below. The items are labeled with the section number from the draft.

Göran

>  1a) What are the smallest devices we are going to support (RAM, ROM,

[ 4.2 Constrained Devices

o C and RS may be class 1 (potentially with large effort) or more
        powerful devices.]

>2. For each device in the architecture: What are the limitations of this

[ 4.2 Constrained Devices

o C and/or RS may be constrained in terms of power, processing,
        communication bandwidth, memory and storage space, and moreover

         - unable to manage complex authorization policies

         - unable to manage a large number of secure connections

         - without user interface

         - without constant network connectivity

         - unable to precisely measure time

         - required to save on wireless communication due to high power
           consumption

o AS is not a constrained device.

o All devices can process symmetric cryptography without incurring
        an excessive performance penalty.

         - We assume the use of a standardized symmetric key algorithm,
           such as AES.

         - Except for the most constrained devices we assume the use of
           a standardized cryptographic hash function such as SHA-256.

      o Public key cryptography requires additional resources (e.g. RAM,
        ROM, power).

      o A DTLS handshake with public key cryptography involves
        significant computation, communication, and memory overheads in
        the context of constrained devices.

         - The RAM requirements of DTLS handshake with public key
           cryptography may be prohibitive for constrained devices.

         - Certificate-based DTLS handshake requires extensive resources
           e.g. in terms of ROM.

]

>   communication between constrained nodes?

[4.6 Resource access

o By default, the resource request shall be integrity protected
        and may be encrypted end-to-end from C to RS.  It shall be
        possible for RS to detect a replayed request.  (DTLS supports
        this.)

      o By default, the response to a request shall be integrity
        protected and may be encrypted end-to-end from RS to C.  (DTLS
        supports this.)

]

>10. Which constraints concerning the connectivity of devices do we want

[ 4.5 Access to authorization information

o RS may not be able to communicate with AS at the time of the
        request from C.

o RS may store or cache authorization information.

GS: there was also a question about whether C could be unable to
communicate with AS at the time of the request to the RS, see
http://www.ietf.org/mail-archive/web/ace/current/msg00725.html

]

---

From: Stefanie Gerdes <[email-masked]>
Date: Thu, 24 Jul 2014 12:39:54 +0200

Hi Hannes,

On 07/23/2014 09:05 PM, Hannes Tschofenig wrote:
> direction: instead of starting with a specific device platform
> (e.g., class, memory requirements, message size, etc.) we thought
> that the use cases are going to constrain the solution space and
> help to guide our work.
> 
> It turned out that this is rather complex since we have not managed
> to receive detailed enough use case descriptions that would, for
> example, let us rule out a specific communication design pattern or
> prefer a specific credential type.
> 
> My worry is that we design for an artificial platform that may or
> may not reflect the use cases people have in mind. Of course, it
> might be possible that folks in the group do not want to share the
> details about their use cases and then we are obviously a bit in
> trouble since we just have to guess.

Yes, absolutely. I share your concern. I just think it might be easier
to discuss different aspects of the use cases instead of discussing a
complete use case at once. So I think it is useful to find key
questions to break the problem into digestible pieces.

Viele Gruesse
Steffi

---

From: Stefanie Gerdes <[email-masked]>
Date: Thu, 24 Jul 2014 16:15:22 +0200

Hi everyone,

Thank you for you input. I made an update to the questions based on the
comments I received so far. Please make sure I got your points.

Are these the questions we need to ask to define the problem we want to
solve? Are there more relevant aspects to the problem?

Please consult http://trac.tools.ietf.org/wg/ace/trac/wiki/Questions for
a more readable version.

# ACE: Exploring the problem space

1. What categories of constrained devices do we want to support (cf.
http://tools.ietf.org/rfc/rfc7228)?
 * C0 (data size << 10 KiB, code size << 100KiB) and above
 * C1 (data size ~ 10 KiB, code size ~ 100KiB) and above
 * C2 (data size ~ 50 KiB, code size ~ 250 KiB) and above
 * What are the smallest devices we are going to support (RAM, ROM, etc)?
2. What are the limitations of constrained devices?
 * Limited RAM, ROM
 * No user interfaces
 * Unable to precisely measure time
 * Limited ability to send / receive messages
 * Limited Energy
 * Are the limitations always the same?
3. Which configurations of constrainedness do we want to consider?
 * C and RS are constrained
 * C is constrained but RS is not
 * RS is constrained but C is not	
4. What can we gain from introducing less constrained actors?
 * Translate complex policies into authorization tokens which are easy
to validate
 * Providing the owner's policies without user interaction at the time
of authorization
 * Attribute Validation (does the entity in possession of a certain key
really posses the claimed attributes)
 * Providing a user interface to owners
 * Time Keeping
5. What are the limitations of less constrained actors?
6. What limitations of underlying protocols do we have to consider?
 * Frame size
7. What are the application security requirements for the communication
between constrained nodes?
 * Integrity
 * Confidentiality
 * Non-Repudiation
 * ...
 * Are all of these always needed?
8. Which level of security is needed on the devices (high, middle, low)?
 * Do we need the constrained devices to have unique identities?
 * Do we always need devices to be tamper-proof?
 * Do we need tamper detection/auditing?
 * Do we need end to end security?
9. How do the constraints of the nodes influence the protocols to be used?
10. Can we find a single protocol which supports all kinds of devices in
every part of the architecture?
 * Communication between two constrained devices
 * Communication where one endpoint is constrained
 * Communication between less constrained devices as needed to transmit
the authorization information
11. What roles do proxies have that we want to support?
 * Reverse proxies
 * Forward proxies
 * Cross-protocol proxies
12. Do we need authorization without user interaction?
13. Which constraints concerning the connectivity of devices do we want
to support?
 * "Offline" authorization (only some devices are "online", no device is
online, etc)
   - RS may not be able to communicate with AS at the time of the
request from C.
   - C may not be able to communicate with AM at the time of the request.
   - C may not be able to communicate with AS at the time of the request.
   - C must be able to act on RS when both are disconnected from everything
 * Intermittent connectivity
 * Latency
 * Special connectivity requirements (e.g. unidirectional links)
 * Sleepy Devices
14. Do we need to consider problems concerning the lifecycle of devices
other than the operational phase?
 * Commissioning
 * Maintenance
 * Decommissioning
 * Handover

Viele Grüße
Steffi