Subject: [Ace] Constrained Authorization Server?

From: Margaret Wasserman <[email-masked]>
Date: Fri, 14 Mar 2014 08:55:50 -0400

In an offline discussion, I was asked whether I think the ACE effort should consider situations where the Authorization Server is a constrained node.  I wrote the following answer, and I thought it might be useful to share it here:

> I think that depends on what you mean by "constrained".  I don't think an authorization server needs to have a user input device, necessarily…  It could be embedded in a home gateway, or a building control system or an irrigation controller.  However, i don't think that you will want to have a battery-operated, intermittently connected authorization server, because it might not be available when the client and server want to talk to one another.
> 
> If you assume that a "constrained" node can be always-on/always-connected, can have enough data storage to hold authentication and authorization information for a network of nodes, and has enough CPU to run crypto operations to service every connection that those nodes want to make to each other or to the outside… Well, if you assume that a constrained node can do those things, the problem becomes a lot easier.  :-)
> 
> I see the point of this effort as figuring out how the bulk of those operations can be handled by a less-constrained server that is storing the auth information and doing most of the authorization and authentication work on behalf of the constrained nodes.
> 
> So, no, I don't think of the authorization server as being a constrained node in the same sense as battery-operated sensors, actuators, etc.

Margaret

---

From: Pat Kinney <[email-masked]>
Date: Fri, 14 Mar 2014 08:05:51 -0500

I agree with Margaret's analysis with one exception, what about an emergency situation where mains power has been lost?  A network of battery-powered devices could be providing a critical service, so the Authorization Server might be on a short-lived UPS.  In this case it could be considered "constrained".  Given this, is it reasonable to expect the network to continue operating without the authorization server?  I.E. in an established network can the Authorization Server be intermittent?

Pat

Pat Kinney
Kinney Consulting LLC
IEEE 802.15 WG vice chair, TG chair
ISA100.11a WG chair
O: +1.847.960.3715
[email-masked]

On Mar 14, 2014, at 7:55 AM, Margaret Wasserman <[email-masked]> wrote:

> So, no, I don't think of the authorization server as being a constrained node in the same sense as battery-operated sensors, actuators, etc.

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

---

From: Margaret Wasserman <[email-masked]>
Date: Fri, 14 Mar 2014 09:25:54 -0400

Hi Pat,

Depending on what security mechanisms we use, and how the applications are written, it is possible that existing associations between the battery operated nodes could survive as long as the session keys (or whatever temporary credentials they are using for ongoing communication) remain valid.  The nodes would not be able to establish a new authenticated session without an Authentication Server, and no new nodes could usefully join the network (since they couldn't establish secure communication with any other nodes), but ongoing associations would survive, perhaps for quite a long time (depending on the key lifetimes).  Would that be sufficient for the case described below?

Of course, many systems that are truly critical will be plugged into a UPS that is sufficient to power the system until an emergency generator can come online.  

Margaret

---

From: Pat Kinney <[email-masked]>
Date: Fri, 14 Mar 2014 09:38:03 -0500

To your first point, would that be sufficient?  I think it can work as long as the system designer understands this point.  

To your second point, in my experience, counting on an emergency generator is not really a good idea, the mains went away for a reason, assuming that back-up generator is totally redundant is a bad assumption.  I know this a an extreme case but recall Fukushima, in addition to the mains the emergency generators also went down, sensors indicating critical temperatures and such would still be required.

Pat

Pat Kinney
Kinney Consulting LLC

On Mar 14, 2014, at 8:25 AM, Margaret Wasserman <[email-masked]> wrote:

Hi Pat,

Margaret

---

From: Robert Cragie <[email-masked]>
Date: Fri, 14 Mar 2014 15:17:09 +0000

Hi Margaret,

I agree it depends what you mean by "constrained". LWIG has a 
terminology document which tries to put some context to the adjective: 
http://tools.ietf.org/html/draft-ietf-lwig-terminology-07.

I think what is important to consider is how constrained the AS itself 
is (as a node and device) and how constrained the connection to the AS 
is. If the client/RS is first communicating through a constrained node 
network then via a border router, it may still be expedient to consider 
a protocol which can run on a constrained node network, as this becomes 
the limiting factor unless some sort of caching or distribution can be 
considered. This is independent to what resources the AS itself has for 
processing.

Robert

On 14/03/2014 12:55 PM, Margaret Wasserman wrote:
>
> In an offline discussion, I was asked whether I think the ACE effort 
> should consider situations where the Authorization Server is a 
> constrained node.  I wrote the following answer, and I thought it 
> might be useful to share it here:
>
>> I think that depends on what you mean by "constrained".  I don't 
>> think an authorization server needs to have a user input device, 
>> necessarily...  It could be embedded in a home gateway, or a building 
>> control system or an irrigation controller.  However, i don't think 
>> that you will want to have a battery-operated, intermittently 
>> connected authorization server, because it might not be available 
>> when the client and server want to talk to one another.
>>
>> If you assume that a "constrained" node can be 
>> always-on/always-connected, can have enough data storage to hold 
>> authentication and authorization information for a network of nodes, 
>> and has enough CPU to run crypto operations to service every 
>> connection that those nodes want to make to each other or to the 
>> outside... Well, if you assume that a constrained node can do those 
>> things, the problem becomes a lot easier.  :-)
>>
>> I see the point of this effort as figuring out how the bulk of those 
>> operations can be handled by a less-constrained server that is 
>> storing the auth information and doing most of the authorization and 
>> authentication work on behalf of the constrained nodes.
>>
>> So, no, I don't think of the authorization server as being a 
>> constrained node in the same sense as battery-operated sensors, 
>> actuators, etc.
>
> Margaret
>
>

---

From: Michael Richardson <[email-masked]>
Date: Sat, 15 Mar 2014 15:20:06 -0400

Margaret Wasserman <[email-masked]> wrote:
    > should
    > consider situations where the Authorization Server is a constrained
    > node.  I
    > wrote the following answer, and I thought it might be useful to share
    > it here:

    > I think that depends on what you mean by "constrained".  I don't think
    > an
    > authorization server needs to have a user input device, necessarily…  It

To the extent that we now understand "user input" can also mean ethernet-like
(100tx/802.11) interface with HTTPS/RESTful interface that can speak to
smartphone, and/or a transitive push connection (via "the cloud") to such a
device, I think that the authorization has a user input.

    > always-on/always-connected,
    > can have enough data storage to hold authentication and authorization
    > information for a network of nodes, and has enough CPU to run crypto
    > operations to service every connection that those nodes want to make to
    > each other or to the outside… Well, if you assume that a constrained
    > node
    > can do those things, the problem becomes a lot easier.  :-)

I am prepared to assume that the AS has all of these things, and consider
such a device to be far less constrained than the other devices, even if it
can't run Office..

    > So, no, I don't think of the authorization server as being a constrained
    > node in the same sense as battery-operated sensors, actuators, etc.

+1

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

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