Subject: [Ace] ACE Charter - connectivity assumptions

From: Göran Selander <[email-masked]>
Date: Tue, 11 Mar 2014 09:26:22 +0000

During the BOF it was requested to be more specific about the connectivity
assumptions of the various nodes, more specifically whether it could be
assumed that the RS or the Client could connect to the AS. The discussion
was very focused on the particular use case presented at the BOF. Here are
some starting points for further discussion.

1. The discussion relates to Client or RS connectivity to the AS for
obtaining relevant authorization information. If valid authorization info
is already available to the RS, it should not be necessary to connect to
the AS. 

2. It was acknowledged that in the particular use case (container
transport at sea) Internet connectivity could not be assumed. Even if this
hadn¹t been the case, e.g. truck/train transport or other use case, we
should not take for granted that billions of devices are always connected
just because it is theoretically possible. Internet connectivity has a
cost and low cost is one of the reasons why constrained devices are at all
used. There may be some need for configuration needed to secure
connectivity, which may be missing if the environment changes as was
illustrated by the use case. Etc. . With this in mind, we should assume
that for certain use cases the constrained Client or RS may be
disconnected from the Internet for periods of time.

3. Even if the AS is not a constrained device it may be disconnected from
time to other. For some use cases, AS functionality may be implemented in
devices which are not always available, e.g. the Resource Owner¹s
smartphone, home server or some other device which may be occasionally
switched off or disconnected.

In general we should assume that Client and RS may have intermittent
connectivity with the AS, and in particular that it cannot  be guaranteed
that there is connectivity to the AS at the time of the access request.

Göran

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 12 Mar 2014 22:08:37 +0100

Hi Goeran,

thanks for moving this difficult point forward.

Comments inline.

> is already available to the RS, it should not be necessary to connect to

Yes, if the authorization information + keying material is already
cached then it does not need to be retrieved again.

There is, however, a trade-off when it comes to revocation: the longer
you are able to cache the more difficult it will be to quickly revoke.

> disconnected from the Internet for periods of time.

What about having connectivity to an authorization server that is on
board the ship? To translate this to the home networking case you it is
one thing to assume connectivity to some server on the Internet and a
different aspect to assume connectivity to an authorization in the
user's home network.

Needless to say with your assumption is that if you do not have Internet
connectivity then some value of Internet connected devices (e.g., remote
monitoring, remote configuration) goes away.

> switched off or disconnected.

Do we accept the side effect that the solution will not work in some of
those cases? If there is no information cached at client<->RS then
without connectivity to the AS the entire mechanism will not work.

> that there is connectivity to the AS at the time of the access request.

You are saying that with some requests you assume there is connectivity
and with other requests there isn't. That does not sound right to me.

The client / RS needs to obtain authorization information and keying
material from the AS. They also need to peridically check the revocation
status. They are also likely to require time information.
This will not work without some level of connectivity.

Ciao
Hannes

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

---

From: Göran Selander <[email-masked]>
Date: Fri, 14 Mar 2014 08:30:52 +0000

Hi Hannes

Good questions. 

A general comment: I think this is largely a question of mindset. If we
assume constant connectivity for all devices at no cost, we will come up
with a different solution than if we assume that there is a non-negligable
cost. (With “cost” including: fees to connectivity provider, configuration
in network and/or device to enable connectivity, performance aspects of
constrained devices such as battery life time etc.) In some applications
it may be feasible to make a trade off between e.g. immediate revocation
and cost.

More inline.

>you are able to cache the more difficult it will be to quickly revoke.

Agree 

>different aspect to assume connectivity to an authorization in the

Yes, that is the smartphone / home server case I mention below. Both
options (cloud AS or local AS) are possible. The case of local AS
temporarily without Internet connectivity would be able to serve RS with
missing access policies, but if the Resource Owner need to update its
policies, the local AS would need Internet connectivity (unless the RO is
also “on board”). 

I think we should allow different service providers to decide on different
architectures to address their respective need for prompt access,
immediate revocation etc.

>monitoring, remote configuration) goes away.

Agree.

>without connectivity to the AS the entire mechanism will not work.

Again, there are trade-offs to make. We could allow this, if it can be
made clear what the consequence is. Alternatively we could assume there
must be a local AS available, which however may not always be connected to
the Internet.

>and with other requests there isn't. That does not sound right to me.

Let me say it in fewer words:
At the time of the C->RS access request it cannot be guaranteed that C or
RS can access AS. (If we allow this, see above.)

>This will not work without some level of connectivity.

Yes, time was brought up in the BOF. Let’s make that a separate thread.

Göran