Subject: Re: [I2nsf] I2NSF Scope discussion

From: John Strassner <[email-masked]>
Date: Tue, 3 Feb 2015 01:48:39 +0000

Hi Dacheng,

RBAC is **one** way to govern which operations a particular user (playing a role, in this case) is permitted to execute on a set of objects.

Bob has pointed out that his group (and indeed, NIST) currently prefers ABAC (attribute-based access control).

There are advantages and disadvantages of each of these approaches. There are also other approaches.

I’m currently thinking that perhaps, a **generic** model for representing which operations a given user can perform on a given object is required; then, appropriate models, such as RBAC and ABAC, could be “plugged into” this framework.

Comments?

regards,
John

Dr. John Strassner, Ph.D.
CTO, Software Laboratory, CRD

Futurewei Technologies
US R&D Center
2330 Central Expressway
Building A, office A2-2143
Santa Clara, California   95050

  Office:  +1.408.330.4923
  Email:   [email-masked]

From: I2nsf [mailto:[email-masked]] On Behalf Of Dacheng Zhang
Sent: Saturday, January 31, 2015 6:07 AM
To: Linda Dunbar; [email-masked]
Cc: Romascanu, Dan (Dan); [email-masked]
Subject: Re: [I2nsf] I2NSF Scope discussion

I like most of the idea. Only one quick question .
Could you please give some additional description about   "Develop a Role Based Access Control to express the Security Intent by Applications/Administrators/OSS”. Do you indicate that we need to provide an authorization mechanism for the interface?

Cheers

Dacheng

发件人: Linda Dunbar <[email-masked]<mailto:[email-masked]>>
日期: 2015年1月29日 星期四 上午10:43
至: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
抄送: "Romascanu, Dan (Dan)" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
主题: [I2nsf] I2NSF Scope discussion

Over the email discussion on the I2NSF list, it becomes clear that there are two distinct interfaces for I2NSF:

-          Capability or Functional Oriented interface between Controller and Devices (or devices’ adaptor), which focuses more on the functional security policies for the functions listed above.

-          Service Oriented interface between Applications/Users and the Controller, which is more intent description for service requests, monitor, reports, etc.

It is envisioned that clients of the I2NSF include security administrators, management systems, applications (or its controller), or security functions that detect suspicious threat triggering more vigorous security resources.

http://www.ietf.org/internet-drafts/draft-xia-i2nsf-capability-interface-im-00 provides a concrete set of content going through the functional interface:

                                           +---------+

                                           |Src/dest |

                                         +-> address |

                                         | |  scope  |

                                         | +---------+

                                         |

                                         | +---------+

                                         +->  User   |

              +--------+                 | +---------+

              |        |                 |

           +-->  Rule  |    +---------+  | +---------+

           |  |        |  +-> Objects +--+-> Service |

           |  +--------+  | +---------+  | +---------+

           |              |              |

           |      *       |              | +-----------+

           |      *       |              +->Application|

           |      *       |              | +-----------+

           |              |              |

+-------+  |  +--------+  |              | +----------+

|       |  |  |        |  |              +-> Schedule |

|Policy +--+-->  Rule  +--+              | +----------+

|       |  |  |        |  |              |

+-------+  |  +--------+  |              |            +---------+

           |              |              |   *      +->Antivirus|

           |      *       |              +-> *      | +---------+

           |      *       |                  *      |

           |      *       |                         | +---------+

           |              |                         +->  IPS    |

           |              |                         | +---------+

           |  +--------+  |                         |

           |  |        |  |                         | +----------+

           +-->  Rule  |  |                         +->  URL     |

              |        |  |                         | | Filtering|

              +--------+  |               +-------+ | +----------+

                          |             +->Permit +-+

                          | +---------+ | +-------+ | +----------+

                          +-> Actions +-+           +->   File   |

                            +---------+ | +-------+ | | Blocking |

                                        +-> Deny  | | +----------+

                                          +-------+ |

                                                    | +----------+

                                                    | |   Data   |

                                                    +-> Filtering|

                                                    | +----------+

                                                    |

                                                    | +------------+

                                                    | | Application|

                                                    +->   control  |

                                                    | +------------+

                                                    |

                                                    |   *

                                                    +-> *

                                                        *
Figure 1 The overall Information Model for I2NSF Capability Interface

For the Functional/Capability Interface, I2NSF deliverables should include:
•       Develop a comprehensive set of informational Models for the functions listed above with regard to different aspects of OAM (Operations/Administration/Maintenance) including polices requests, monitoring, reports, fault/consistency management, etc.
•       Develop the corresponding Data Models, e.g. YANG model.
•       Compare with existing IETF protocols for “OBJECTs, ACTIONs, FILTERING, etc” (e.g. PCP, Radius, etc)
•       Specify the secure mechanisms to carry the content identified by the informational models. E.g. TLS to carry the information.
•       Authentication and registration mechanism
E.g. who is legitimate to issue security policies or monitor reports over the Functional Interface.

For the Service Layer Interface, I2NSF deliverables should include:
•       Develop a Role Based Access Control to express the Security Intent by Applications/Administrators/OSS
•       Develop comprehensive set of “TARGETs” for the Security Intent
–       e.g. Security Target in Data Centers network, in Access Network, in Wide Area network, etc
–      Develop informational model for “Users”, “Roles”, “Permissions”
•       Develop the corresponding Data Models, e.g. YANG model.
•       Compare with existing IETF protocols for “Roles”, “Users”, “Permissions”, etc.

In addition, the I2NSF working group will
•        Document a high-level architecture that will describe the functional building blocks for the dynamic negotiation of security service parameters, the dynamic and subsequent allocation of network security resources and the operation of such resources, including means to assess that what has been allocated complies with what has been negotiated.
•       Document small and well-scoped use cases to constrain the scope of the work and achieve sufficient focus for the working group to deliver successful outcomes. And
•        Analyze candidate protocols that may carry the information to be exchanged through the various interfaces.

Any more suggestions?

Cheers,

Linda Dunbar
_______________________________________________ I2nsf mailing list [email-masked]<mailto:[email-masked]> https://www.ietf.org/mailman/listinfo/i2nsf

---

From: "Dacheng Zhang" <[email-masked]>
Date: Tue, 03 Feb 2015 18:07:50 +0800

Agree! Maybe we can say developing an access control mechanism for the
interface? Although I have no problem with developing a RBAC for the
interface, mentioning it in the charter will reduce the number of our
potential choices. 

Just IMHO..

发件人:  John Strassner <[email-masked]>
日期:  2015年2月3日 星期二 上午9:48
至:  dacheng de <[email-masked]>, Linda Dunbar
<[email-masked]>, "Natale, Bob" <[email-masked]>, John Strassner
<[email-masked]>, "[email-masked]" <[email-masked]>
抄送:  "Romascanu, Dan (Dan)" <[email-masked]>, "[email-masked]"
<[email-masked]>
主题:  RE: [I2nsf] I2NSF Scope discussion

Hi Dacheng,
 
RBAC is **one** way to govern which operations a particular user (playing a
role, in this case) is permitted to execute on a set of objects.
 
Bob has pointed out that his group (and indeed, NIST) currently prefers ABAC
(attribute-based access control).
 
There are advantages and disadvantages of each of these approaches. There
are also other approaches.
 
I’m currently thinking that perhaps, a **generic** model for representing
which operations a given user can perform on a given object is required;
then, appropriate models, such as RBAC and ABAC, could be “plugged into”
this framework.
 
Comments?

regards,
John
 
Dr. John Strassner, Ph.D.
CTO, Software Laboratory, CRD
 Futurewei TechnologiesUS R&D Center2330 Central Expressway
Building A, office A2-2143Santa Clara, California   95050
 Office:  +1.408.330.4923
 Email:   [email-masked]

Could you please give some additional description about   "Develop a Role
Based Access Control to express the Security Intent by
Applications/Administrators/OSS”. Do you indicate that we need to provide an
authorization mechanism for the interface?

Cheers

Dacheng

 

发件人: Linda Dunbar <[email-masked]>
日期: 2015年1月29日星期四上午10:43
至: "[email-masked]" <[email-masked]>
抄送: "Romascanu, Dan (Dan)" <[email-masked]>, "[email-masked]"
<[email-masked]>
主题: [I2nsf] I2NSF Scope discussion

Over the email discussion on the I2NSF list, it becomes clear that there are
two distinct interfaces for I2NSF:
-         Capability or Functional Oriented interface between Controller and
Devices (or devices’ adaptor), which focuses more on the functional security
policies for the functions listed above.

-         Service Oriented interface between Applications/Users and the
Controller, which is more intent description for service requests, monitor,
reports, etc. 

It is envisioned that clients of the I2NSF include security administrators,
management systems, applications (or its controller), or security functions
that detect suspicious threat triggering more vigorous security resources.
 
http://www.ietf.org/internet-drafts/draft-xia-i2nsf-capability-interface-im-
00 provides a concrete set of content going through the functional
interface: 
 
                                           +---------+
                                           |Src/dest |
                                         +-> address |
                                         | |  scope  |
                                         | +---------+
                                         |
                                         | +---------+
                                         +->  User   |
              +--------+                 | +---------+
              |        |                 |
 
For the Functional/Capability Interface, I2NSF deliverables should include:
•      Develop a comprehensive set of informational Models for the functions
listed above with regard to different aspects of OAM
(Operations/Administration/Maintenance) including polices requests,
monitoring, reports, fault/consistency management, etc.
•      Develop the corresponding Data Models, e.g. YANG model.
•      Compare with existing IETF protocols for “OBJECTs, ACTIONs,
FILTERING, etc” (e.g. PCP, Radius, etc)
•      Specify the secure mechanisms to carry the content identified by the
informational models. E.g. TLS to carry the information.
•      Authentication and registration mechanism
E.g. who is legitimate to issue security policies or monitor reports over
the Functional Interface.
 
For the Service Layer Interface, I2NSF deliverables should include:
•      Develop a Role Based Access Control to express the Security Intent by
Applications/Administrators/OSS
•      Develop comprehensive set of “TARGETs” for the Security Intent
–      e.g. Security Target in Data Centers network, in Access Network, in
Wide Area network, etc
–     Develop informational model for “Users”, “Roles”, “Permissions”
•      Develop the corresponding Data Models, e.g. YANG model.
•      Compare with existing IETF protocols for “Roles”, “Users”,
“Permissions”, etc.
 
In addition, the I2NSF working group will
•       Document a high-level architecture that will describe the functional
building blocks for the dynamic negotiation of security service parameters,
the dynamic and subsequent allocation of network security resources and the
operation of such resources, including means to assess that what has been
allocated complies with what has been negotiated.
•      Document small and well-scoped use cases to constrain the scope of
the work and achieve sufficient focus for the working group to deliver
successful outcomes. And
•       Analyze candidate protocols that may carry the information to be
exchanged through the various interfaces.
 
Any more suggestions?
 
Cheers, 
 
Linda Dunbar
_______________________________________________ I2nsf mailing list
[email-masked] https://www.ietf.org/mailman/listinfo/i2nsf