Subject: [6tisch] 6top-to-6top access control model

From: Qin Wang <[email-masked]>
Date: Wed, 9 Apr 2014 03:52:03 -0700 (PDT)

Hi all,

6top in a node may need to access (GET/POST) its
neighbor’s 6top’s MIB. For example, a parent needs to assign
hardcells to its children; a node may POST a RPC to initialize softcell negotiation process. For mitigate the risk of
unauthorized access, access control mechanism is needed.
 
There are many different access control
models, such as Access Control List (ACL), Role-based Access Control (RBAC).
Considering 6top-to-6top access requirement, I think RBAC may be a candidate,
where the Role refers to the relationship between the two nodes. For example,
some data can only be modified by parent, and some data can be set by any
legal neighbor. It is just a thought. Please input your comments.
 
Thanks
Qin

---

From: Thomas Watteyne <[email-masked]>
Date: Thu, 10 Apr 2014 18:53:46 -0700

Qin,

As explained by Hannes [1], we are dealing with two different notions:
authentication and authorization. The solution to solving this will depend
a lot of on the solution the security DT will come up with, and I don't
think we have a good solution at this point.

I believe we should make the security DT aware of this requirement, rather
than designing an independent solution.

Thomas

[1] http://www.ietf.org/mail-archive/web/ace/current/msg00518.html

On Wed, Apr 9, 2014 at 3:52 AM, Qin Wang <[email-masked]> wrote:

> Hi all,
>
> 6top in a node may need to access (GET/POST) its neighbor's 6top's MIB.
> For example, a parent needs to assign hardcells to its children; a node may
> POST a RPC to initialize softcell negotiation process. For mitigate the
> risk of unauthorized access, access control mechanism is needed.
>
> There are many different access control models, such as Access Control
> List (ACL), Role-based Access Control (RBAC). Considering 6top-to-6top
> access requirement, I think RBAC may be a candidate, where the Role refers
> to the relationship between the two nodes. For example, some data can only
> be modified by parent, and some data can be set by any legal neighbor. It
> is just a thought. Please input your comments.
>
> Thanks
> Qin
>
>
> _______________________________________________
> 6tisch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tisch
>
>

---

From: Qin Wang <[email-masked]>
Date: Thu, 10 Apr 2014 19:04:04 -0700 (PDT)

Thomas,

I agree with you. The better way is to bring our requirement to security DT. Can you emphasis it in the Friday's call?

Thanks
Qin
On Friday, April 11, 2014 9:54 AM, Thomas Watteyne <[email-masked]> wrote:
 
Qin,

As explained by Hannes [1], we are dealing with two different notions: authentication and authorization. The solution to solving this will depend a lot of on the solution the security DT will come up with, and I don't think we have a good solution at this point.

I believe we should make the security DT aware of this requirement, rather than designing an independent solution.

Thomas

Hi all,

---

From: Thomas Watteyne <[email-masked]>
Date: Thu, 10 Apr 2014 19:04:28 -0700

Absolutely.

On Thursday, April 10, 2014, Qin Wang <[email-masked]> wrote:

> Thomas,
>
> I agree with you. The better way is to bring our requirement to security
> DT. Can you emphasis it in the Friday's call?
>
> Thanks
> Qin
>   On Friday, April 11, 2014 9:54 AM, Thomas Watteyne <
> [email-masked]<javascript:_e(%7B%7D,'cvml',[email-masked]');>>
> wrote:
>  Qin,
>
> On Wed, Apr 9, 2014 at 3:52 AM, Qin Wang <[email-masked]<javascript:_e(%7B%7D,'cvml',[email-masked]');>
> > wrote:
>
> Hi all,
>
> [email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');>

---

From: Michael Richardson <[email-masked]>
Date: Sat, 12 Apr 2014 15:55:46 -0400

Qin Wang <[email-masked]> wrote:
    > 6top in a node may need to access (GET/POST) its neighbor’s 6top’s
    > MIB. For example, a parent needs to assign hardcells to its children; a
    > node may POST a
    > RPC to initialize softcell negotiation process. For mitigate the risk of

Agreed.

    > access requirement, I think RBAC may be a candidate, where the Role
    > refers to the

I don't really understand how you are using these terms.
They are not mutually exclusive; they are classifications for mechanisms.

Thomas Watteyne <[email-masked]> wrote:
    > I believe we should make the security DT aware of this requirement,
    > rather than
    > designing an independent solution.

noted.
There are two fundamental questions:
1) can we really limit this meaningfully to parents talking to children,
   or do we mean, any 6LN within radio range, i.e. no layer-3 hop.
   (Is TTL check enough? can we assume any kind of radio power check?)

2) if we decide that all 6LR in the mesh can do this operation,
   (to any other node),  what is the effect?

I question whether we can meaningful assign a role like "parent-of-FOO"
for each 6LN "FOO", that can meaningfully be evaluated in a timely fashion by
the 6LN without the help of any kind of Authorization Server.  So, we are
left with rather easily defeated layer-3 adjacency checks, and what can
we do in the 6top protocol to validate things.

--
]               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 =-

---

From: Qin Wang <[email-masked]>
Date: Sat, 12 Apr 2014 17:48:48 -0700 (PDT)

Hi Micheal,

what if we mean any 6LN within radio range can do this operation on limited resources, e.g. softcell-reservation rpc? 

Thanks
Qin
On Sunday, April 13, 2014 3:55 AM, Michael Richardson <[email-masked]> wrote:

Qin Wang <[email-masked]> wrote:
    > 6top in a node may need to access (GET/POST) its neighbor’s 6top’s
    > MIB. For example, a parent needs to assign hardcells to its children; a
    > node may POST a
    > RPC to initialize softcell negotiation process. For mitigate the risk of
    > unauthorized access, access control mechanism is needed.

Agreed.

    > There are many different access control models, such as Access Control
    > List (ACL), Role-based Access Control (RBAC). Considering 6top-to-6top
    > access requirement, I think RBAC may be a candidate, where the Role
    > refers to the

Thomas Watteyne <[email-masked]> wrote:
    > I believe we should make the security DT aware of this requirement,
    > rather than
    > designing an independent solution.

noted.