Subject: Re: [nfsv4] WG last call for Registry Specification for MAC Security Label Formats

From: RJ Atkinson <[email-masked]>
Date: Wed, 27 Aug 2014 09:36:05 -0400

All,

I think that at least one more editing pass is needed before
this I-D will be ready for publication.

Specific comments below are organised by section and page,
as best I am able to do that.

Section 2:
	The definition of MLS here is unlikely to be helpful or clear 
        to someone who doesn't already know what MLS means.  Also, 
        the citation provided is very far from being the best citation.
        The best single citation is certainly [BL73], but other RFCs
        have cited several other documents that are useful in understanding
        the MLS concept.  In this area, more citations would be better
        in the interest of clarity to the reader.

	Please rewrite the definition for MLS, after examining RFC-1825, 
        Section 5.4 (1st paragraph) and also RFC-2401, Section 8 (both
        1st & 2nd paragraphs).  Please also consider the following quote
        from [NSA07], page 29:
          "In multilevel environments, all users have an associated 
           clearance level identifying the maximum security level 
           of data that they may access, and all objects have security 
           labels associated with them."

	For "MLS", please add these citations:
          [BL73]   Bell, D.E. & LaPadula, L.J., "Secure Computer Systems:
                   Mathematical Foundations and Model", Technical Report
                   M74-244, The MITRE Corporation, Bedford, MA, May 1973.

          [DIA]    US Defense Intelligence Agency, "Compartmented Mode
                   Workstation Specification", Technical Report
                   DDS-2600-6243-87.

          [DoD85]  US National Computer Security Center, "Department of Defense
                   Trusted Computer System Evaluation Criteria", DoD
                   5200.28-STD, US Department of Defense, Ft. Meade, MD.,
                   December 1985.

          [DoD87]  US National Computer Security Center, "Trusted Network
                   Interpretation of the Trusted Computer System Evaluation
                   Criteria", NCSC-TG-005, Version 1, US Department of Defense,
                   Ft. Meade, MD., 31 July 1987.

          [NSA07]  US National Security Agency, Information Assurance Directorate,
                   "Protection Profile for Multi-Level Operating Systems in
                   Environments Requiring Medium Robustness", Version 1.91, 
                   13 March 2007, Ft Meade, MD, USA. 
                   URL:  https://www.niap-ccevs.org/pp/pp_os_ml_mr2.0_v1.91.pdf

<
  Section 4:   IPSO (RFC-1108)

  Section 4 also should cite and discuss RFC-1108 (IPSO), which remains 
  the most widely implemented IPv4 security option and remains in widespread 
  deployment.  Also, IPSO should be allocated a "Label Format Selector" 
  in the Initial Registry of Section 6.1.

  To the best of my knowledge, IPSO is the *only* IP label option that
  is supported by very widely deployed commercial IP routers.  The
  router-based interface-oriented IPSO ACL support makes IPSO desirable
  in a number of existing (both long-standing and recent) MLS network
  deployments.  Cisco IOS has supported IPSO-based packet filtering for 
  ~2 decades and still supports that today).  (Aside: CALIPSO was designed 
  to be practical to implement even in ASIC/FPGA-based IP routers; CIPSO 
  is completely hopeless in this regard because of the complexity of the 
  CIPSO option parsing.)

  If desired, I can supply a brief paragraph describing IPSO as candidate
  new text for Section 4.

  Proposed replacement text for Section 4.1 follows:

              The "Commercial IP Security Option (CIPSO)" label format is
              documented in [CIPSO] and in [FIPS-188].  While the cited
              Internet-Draft is long expired, it is widely supported in
              deployed MLS systems that support IPv4.  IANA has assigned
              IPv4 option number 134 to CIPSO.  CIPSO is defined ONLY as 
              an IPv4 option.  IANA has never assigned any IPv6 option
              value to CIPSO.
              
  Proposed replacement text for Section 4.2 follows:
 
              The "Common Architecture Label IPv6 Security Option (CALIPSO)"
              label format is specified in [RFC-5570] and is defined for IPv6.
              As noted in RFC-5570, Section 10, CALIPSO is a direct derivative 
              of the IPv4 "Simple IP Security Option (SIPSO)", therefore CALIPSO 
              is NOT derived from CIPSO in any way.

  (Aside:  CALIPSO represents an explicit rejection of the mis-design of CIPSO.
   SIPSO was a serious attempt to fix CIPSO and the IETF's explicit decision 
   not to standardise CIPSO or publish CIPSO as an RFC reflected widespread
   IETF security community concerns with the design flaws of CIPSO and an
   IETF preference for SIPSO.)

   Section 4.3:   This one sentence is very far from being clear to someone
                  who is not already familiar with FLASK.  We ought to be able
                  to provide at least a short paragraph describing FLASK here.
                  Also, there appears to be a typo as this section does not
                  cite [FLASK], although that is in the References.  Probably,
                  the FLASK formal security model ought to be cited also,
                  as that makes the semantics of FLASK more clear.  Please
                  also add a citation for:

                  [FLASK99b]  Secure Computing Corporation, "Assurance in the
                              Fluke Microkernel Formal Security Policy Model",
                              Document 00-0930896A001 Rev B, 17 Feb 1999,
                              Secure Computing Corporation, Roseville, MN, USA
                              URL: http://www.cs.utah.edu/flux/fluke/html/fspm.ps.gz

   Section 6.1:   A "Label Format Selector" value should be defined here 
                  for IPSO [RFC-1108].

Yours,

Ran Atkinson

---

From: Tom Haynes <[email-masked]>
Date: Fri, 29 Aug 2014 17:51:37 -0400

Hi Ran,

Thanks for the review. Replies inline.

> 	For "MLS", please add these citations:

Given the scope and size of the document, this looks like overkill (more on this in
Note 2 at the end of this part of the reply). I would have loved this feedback when doing RFC 7204.

And I really love the line:
   Computers and
   networks often are designated "multi-level secure" if they support
   the separation of labelled data in conjunction with information flow
   security policies.

It really nails down subject and object labels for me!

How about this:

   Multi-Level Security (MLS):  a traditional model where objects are
      given a sensitivity level (Unclassified, Secret, Top Secret, etc.)
      and a category set [RH_MLS].

becomes this:

   Multi-Level Security (MLS):  a traditional model where subjects are
      given a security level (Unclassified, Secret, Top Secret, etc.)
      and objects are given security labels that mandate the access of
      the subject to the object [].

Note 1: Not sure if I favor “given a security label” over “given a security level”.

Note 2: I’m thinking of citing BL73 and RFC 2401. My intent here is to
point and not to provide a comprehensive bibliography.

>  deployment.

Okay

>  Also, IPSO should be allocated a "Label Format Selector" 

Done

>  If desired, I can supply a brief paragraph describing IPSO as candidate

Please, that would be appreciated.

>              an IPv4 option.  IANA has never assigned any IPv6 option

Done

>              is NOT derived from CIPSO in any way.

Done

>                  who is not already familiar with FLASK.  

Agreed, but the intent is not to describe each of these implementations,
but to point.

> We ought to be able

How about this:

4.4.  Flux Advanced Security Kernel (FLASK)

   The Flux Advanced Security Kernel (FLASK) [FLASK99] is an
   impelementation 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.

>                  cite [FLASK], although that is in the References.  

Done

> Probably,

Done

> Ran Atkinson

And again, thanks!

> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nfsv4