Subject: [I2nsf] Can the Flux Advanced Security Kernel described by draft-ietf-nfsv4-lfs-registry-02 be used for I2NSF?

From: Linda Dunbar <[email-masked]>
Date: Tue, 17 Feb 2015 23:57:16 +0000

David, Jarrett, and Thomas,

I2NSF is to specify a mechanism for clients to communicate their specific "Flow Based security policies" (request/monitor/report) to a system, and map these security policies to the security functions present in security devices in that system.(see charter http://www.ietf.org/mail-archive/web/i2nsf/current/msg00281.html)

draft-ietf-nfsv4-lfs-registry-02 describes "The Flux Advanced Security Kernel (FLASK) [FLASK99]" as an implementation of an architecture to provide flexible support for security policies. Section 2.1 of [FLASK99b], summarizes the architecture of FLASK to:
1. describe the interactions between a subsystem which enforces
security policy decisions and a subsystem which makes those
decisions
2. the requirements on the components within each subsystem.

Question to you: do you think if FLASK can be extended for I2NSF purpose?

Thanks, Linda

From: OPS-DIR [mailto:[email-masked]] On Behalf Of Romascanu, Dan (Dan)
Sent: Monday, February 16, 2015 5:31 AM
To: [email-masked]
Cc: [email-masked]
Subject: [OPS-DIR] OPS-DIR review for draft-ietf-nfsv4-lfs-registry-02

I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG.  These comments were written with the intent of improving the operational aspects of the  IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review.  Document editors and WG chairs should treat these comments  just like any other last call comments
Status: Ready

Details: This document defines a new IANA registry for security labels formats specifications, the initial entries in the registry and the associated policies. The document seems to be useful and is clearly written. No new protocol or protocol extensions are defined. There seem to be no manageability or operational considerations related to the new registry, so the review defined in RFC 5706 does not apply.

Regards,

Dan

---

From: Dave Quigley <[email-masked]>
Date: Tue, 17 Feb 2015 19:33:36 -0500

On 2/17/2015 6:57 PM, Linda Dunbar wrote:
> I2NSF is to specify a mechanism for clients to communicate their
> specific “Flow Based security policies” (request/monitor/report) to a
> system, and map these security policies to the security functions
> present in security devices in that system.(see charter
> http://www.ietf.org/mail-archive/web/i2nsf/current/msg00281.html)
>
> draft-ietf-nfsv4-lfs-registry-02 describes “The Flux Advanced Security
> Kernel (FLASK) [FLASK99]” as an implementation of an architecture to
> provide flexible support for security policies. Section 2.1 of
> [FLASK99b], summarizes the architecture of FLASK to:
>

When I get to work tomorrow I'll read over the I2NSF protocol spec and 
give you an answer. The FLASK security labels are better known by their 
more common name of SELinux labels. If you look at SELinux it will give 
you a better idea than flask. SELinux doesn't specify flows explicitly 
but you can analyze the policy to detect the information flows. 
SELinux's main security model is type enforcement. In this model every 
subject and object are given a label and then rules are defined how they 
interact. I'll look over I2NSF tomorrow and see if the FLASK model 
(Which SELinux is based on) could be adapted for other methods. The main 
takeaway from FLASK was that until that point trusted systems hardcoded 
the mechanism and policy for their security models into the OS itself. 
With FLASK the idea was to separate the policy from the mechanism so 
that multiple models could be supported rather than MLS which was almost 
always what was encoded.

You should see a reply tomorrow from my work email address but the name 
should be the same.

Dave