Subject: Re: [Ace] ACE pre-WG meeting

From: Margaret Wasserman <[email-masked]>
Date: Sat, 26 Apr 2014 07:06:31 -0400

Hi Goran,

Before you can talk meaningfully about some of the things you have mentioned for the problem statement, such as symmetric or assymmetric keys, I think it would be good to make sure we have agreement on the basic properties we need in a solution.  I am not sure we are all talking about mutually compatible scenarios.

Some people seem to be thinking of a system, like a typical wifi network, irrigation controller, sensor network, distribution center, or building control system, where the constrained nodees might talk directly to each other (both Client and Resource Provider may be constrained), but where it will be possible to reach a more capable a0Authentication Server (on the wifi AC, the controller, etc.) at the beginning of each session.  It is easy to see how you could add new nodes into a system like that, support removal of nodes, update keys etc.

Others seem to be looking at a more adhoc scenario, perhaps Zigbee-based, where nodes may be intermittently connected, and two constrained nodes may need to authenticate and authorize oneanother when there may be no other reachable nodes. In this case, the Authentication Server would be more of a provisioning system that pushes security policies and credentials to the constrained nodes when possible.  In this scenario, nodes will only become aware of changes (additional nodes in the system, removal of nodes, key changes) after sufficient connectivity with the Authentication Server.  This might be a fairly simple scenario for, as an example, a set of nodes that are charged nightly -- they could connect to the Authentication Server when charging and be updated nightly.  In more adhoc situations, where nodes could go days or months without reaching an authentication server, this would be a much more difficult scenario to address well.

It seems to me that people who are considering the first model have a different set of requirements and expectations than people who are thinking of the second model, and when we talk about possible solutions, different solution properties tend to work better for one scenario than the other.

I think it might be useful to walk through these two scenarios and see what the requirements, expectations and desirable properties are in each scenario.  When we are done understanding their requirements, etc. we could determine if the superset of those needs could be met by a single solution that would provide a satisfactory experience in both cases. I am concerned that the two scenarios may not have enough in common to be served by a single solution.  

IMO, the first case could be reasonably addressed by modifications to existing IETF protocols to consider the properties of constrained Clients and Resource Servers.  We would attempt to reduce communication overhead on the constrained nodes, and offload storage and processing overhead to the Authentication Server.  I personally see the work necessary to deal with the first scenario to be fairly clear and simply a matter of engineering.

I am less certain how existing IETF protocols could be applied to the second case, which I see as more of a provisioning scenario than a matter of offloading. There are numerous problems that could arise when/if some nodes are updated and others are not, etc.  There might be several subsets of this scenario based on application needs (I.e. Is it even possible to require that nodes be brought into contact with the Authentication Server when they are found to have out-of-date information?).  IMO, the requirements of this scenario are not well-enough understood to begin by designing a solution.  If we want to cover this case, I would prefer to see more work done on understanding the properties and requirements of systems that fall into this category before we begin to design solutions.  I am concerned that the needs of this scenario (or these scenarios) may not be well-enough understood for this to be an engineering problem at this point.

Margaret

-------- Original message --------
From Göran Selander <[email-masked]> 
Date: 04/25/2014  3:03 AM  (GMT-05:00) 
To [email-masked] 
Subject Re: [Ace] ACE pre-WG meeting 

I got some questions offline about this f2f interim meeting and how it is
supposed to work. 

Here is what I had in mind:

1. We try to fix a date for a 1-day meeting in about 5-6 weeks.

2. Before this meeting, people are invited to submit proposals of a more
detailed problem statement of ACE. With ³more detailed problem statement²
I mean for example properties of security protocols between nodes that a
solution should exhibit or support, e.g. whether symmetric and/or
asymmetric keys should be supported, whether negotiation of crypto suite
should be supported, support for intermittent connectivity, round trips,
processing or caching requirements etc.

The input could be in the form of mails to the ACE list, internet drafts,
or something in-between e.g. using some repository for documents. (There
will be at least one detailed input.)

3. We meet and discuss the different proposals and try to agree on a more
detailed problem statement, and then report back to the ACE list.

The reason for proposing a 1-day meeting is based on the assumption that
people have read the inputs and we can go directly to the things people
disagree on and hear the motivations (not necessarily coming to an
agreement). But I don¹t have a strong opinion about that.

Phone conference facilities could always be considered, but the intent
with such a f2f meeting is to give a chance to brainstorm, draw and
discuss pictures on a white board, etc.

What do you think about this?

Göran

On 24/04/14 10:24, "Göran Selander" <[email-masked]> wrote:

>
>Hi all,
>
>As was noted in the tutorial session this week, and previously in the
>charter discussions, neither the ACE charter nor the use case &
>requirements document provides sufficiently detailed problem statement to
>be able to evaluate candidate security protocols.
>
>The option to meet face to face and discuss the scope of ACE has been
>aired on several occasions. In an recent offline discussion I got a
>positive feedback about trying to arrange a meeting before Toronto. The
>purpose of the meeting would be to discuss - and hopefully produce - a
>more detailed problem statement proposal as input to the ACE work.
>
>A good time could be end-of-May / beginning-of-June to allow for travel
>arrangements and still leave enough time for editing drafts based on the
>output.  
>
>One possible location for this meeting is at the Ericsson premises in
>Kista out of Stockholm, Sweden. Kista is a short ride from airports
>Arlanda and Bromma.
>
>For those interested in attending, please fill in this Doodle ASAP:
>
>http://doodle.com/nw94ruh77fg3qvfg
>
>
>Please note that this would not be an official interim meeting, as ACE is
>not a WG yet.
>
>
>
>Göran
>
>
>

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

---

From: Michael Richardson <[email-masked]>
Date: Sat, 26 Apr 2014 19:16:45 -0400

Margaret Wasserman <[email-masked]> wrote:
    > Some people seem to be thinking of a system, like a typical wifi
    > network, irrigation controller, sensor network, distribution center, or
    > building control system, where the constrained nodees might talk
    > directly to each other (both Client and Resource Provider may be
    > constrained), but where it will be possible to reach a more capable
    > a0Authentication Server (on the wifi AC, the controller, etc.) at the
    > beginning of each session.  It is easy to see how you could add new
    > nodes into a system like that, support removal of nodes, update keys
    > etc.

What is you notion of "session" here?
I think that many would like the relationship to be rather long lived.

    > Others seem to be looking at a more adhoc scenario, perhaps
    > Zigbee-based, where nodes may be intermittently connected, and two
    > constrained nodes may need to authenticate and authorize oneanother
    > when there may be no other reachable nodes. In this case, the
    > Authentication Server would be more of a provisioning system that
    > pushes security policies and credentials to the constrained nodes when
    > possible.  In this scenario, nodes will only become aware of changes
    > (additional nodes in the system, removal of nodes, key changes) after
    > sufficient connectivity with the Authentication Server.  This might be
    > a fairly simple scenario for, as an example, a set of nodes that are
    > charged nightly -- they could connect to the Authentication Server when
    > charging and be updated nightly.  In more adhoc situations, where nodes
    > could go days or months without reaching an authentication server, this
    > would be a much more difficult scenario to address well.

I'm not sure I understand why Zigbee is mentioned in this scenario.
I'm asking, because I'm not sure I understand what *Zigbee* brings that
changes the situation.   I think the critical point is that,  the AS has
pushed a policy to the node with the resource, indicating who could be
authorizated, but the nodes have to do the negotiation directly.

    > It seems to me that people who are considering the first model have a
    > different set of requirements and expectations than people who are
    > thinking of the second model, and when we talk about possible
    > solutions, different solution properties tend to work better for one
    > scenario than the other.

I don't think that many of us are considering the second scenario at all.

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

---

From: Ludwig Seitz <[email-masked]>
Date: Mon, 28 Apr 2014 10:08:38 +0200

On 04/26/2014 01:06 PM, Margaret Wasserman wrote:
> Hi Goran,
>
> Before you can talk meaningfully about some of the things you have
> mentioned for the problem statement, such as symmetric or assymmetric
> keys, I think it would be good to make sure we have agreement on the
> basic properties we need in a solution.  I am not sure we are all
> talking about mutually compatible scenarios.
>
> nodes into a system like that, support removal of nodes, update keys etc.

Note that in some cases the nodes could talk directly to an AS, but not 
at the same time as they have a secure session established between them. 
This is because establishing a second secure session in parallel to the 
AS would require too much memory (or take too much time). So either they 
have to tear down and re-establish sessions (very expensive in terms of 
round trips, time, and battery consumption) or the AS has to provide the 
client with some credentials before it goes on to contact the resource 
server or the AS has to provide the resource server with access control 
policies before the client connects to it.

How would that fit into the scenarios you describe?

/Ludwig

-- 
Ludwig Seitz, PhD
SICS Swedish ICT AB
Ideon Science Park
Building Beta 2
Scheelevägen 17
SE-223 70 Lund

Phone +46(0)70-349 92 51
http://www.sics.se

---

From: Göran Selander <[email-masked]>
Date: Mon, 28 Apr 2014 09:02:37 +0000

Hi Margaret

I was considering what you call >>basic properties>> to be part of a problem statement (>>support for intermittent connectivity>> was listed as an example), so thanks for kicking off the discussion! As you say, it may well be that people have different settings in mind - and there may be more differences than what you bring up  - how would we know until we have written down the assumptions in more detail?

I’m not sure we need to agree on anything at this stage, but I agree that we need to make clear any difference in assumptions so that we have a discussion around how to handle that (e.g. if there are differences in assumptions whether only one case should be supported or if multiple cases should be allowed).

In the same way I find it difficult at this stage to judge what is >>well-enough understood … to be an engineering problem >>  but that is a good question once the problem statement(s) are on the a table, and a potential topic for a f2f meeting.

Some comments inline.

From: Margaret Wasserman <[email-masked]<mailto:[email-masked]>>
Reply-To: Margaret Wasserman <[email-masked]<mailto:[email-masked]>>
Date: Saturday 26 April 2014 13:06
To: Göran Selander <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Ace] ACE pre-WG meeting

Hi Goran,

What are the differences between these scenarios in your view?

  *   Intermittent connectivity is assumed in the second and not in the first.
  *   Policy decision made in the AS in the first scenario, but not in the second.
  *   Other differences?

Can we make more precise what assumptions you think we should make? (maybe implied by the answer to the previous question)

Göran

Margaret

-------- Original message --------
>From Göran Selander <[email-masked]<mailto:[email-masked]>>
Date: 04/25/2014 3:03 AM (GMT-05:00)
To [email-masked]<mailto:[email-masked]>
Subject Re: [Ace] ACE pre-WG meeting

Göran

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