I have an update for the dial-in information for our meeting tomorrow.
The new information for dial-in is listed below. Also with the change in
DST for both the US and Australia it has been suggested to move the
meeting to Wednesday morning instead. If you have any comments about a
new time and date for the telecon please feel free to contact me and we
can see about rescheduling it. Also I have attached the Label Format
Specification document for your review.
Telecon dial-in information:
U.S. toll free: 866-682-4770
Australia toll free: 1800420354
Conference code: 8530264 (new)
Security Passcode: 7042044
1. Dial the Global Access Number for your country
2. Enter the Conference Code, followed by #
3. Enter the Security Passcode, followed by #
On Tue, 2010-04-06 at 17:40 -0400, David P. Quigley wrote:
> Date/Time: April 14th 4:00 - 5:00 PM EST
> Dial-in: 866-545-5218
> Participant code: 7042044#
>
> This meeting will review what Labeled NFS discussions and developments
> occured at IETF 77 and will also review the Label Format Specification
> document that Jarrett and I wrote during IETF 77. I will send out the
> document at the beginning of next week once its been through prepub.
>
> Proposed Agenda
> -----------------------
>
> + IETF Note Well Agreement
>
> This is a reminder that our discussions are governed by the
> IETF Note Well Agreement. See:
>
> http://www.ietf.org/NOTEWELL.html
>
> We will start each week's meeting with this announcement.
>
> + Review IETF77 Labeled NFS related developments
>
> + Discuss Label Format Specification document
>
>
> _______________________________________________
> nfsv4 mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/nfsv4
Network Working Group D. Quigley
Internet-Draft National Security Agency (NSA)
Intended status: Standards Track J. Lu
Expires: October 8, 2010 Oracle
April 6, 2010
Registry Specification for MAC Security Label Formats
draft-quigley-label-format-registry-00
Abstract
In the past Mandatory Access Control(MAC) systems have used very
rigid policies which were hardcoded into the particular protocol and
platform. As MAC systems are more widely deployed additional
flexibility in mechanism and policy is required. Where traditional
trusted systems implemented Multi-Level Security and integrity
models, modern systems have expanded to include technologies such as
type enforcement. Due to the wide range of policies and mechanisms
it has proven through past efforts to be virtually impossible to
accomodate all parties in one security label format and model.
To accomodate multiple MAC mechanisms and label formats this document
proposes a registry of label format specifications. This registry
contains several identifiers to accomodate both integer and string
preferences and associates those identifiers with an extensive
document outlining the exact syntax and use of the particular label
format.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
Quigley & Lu Expires October 8, 2010 [Page 1]
Internet-Draft LSF Registry April 2010
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on October 8, 2010.
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the BSD License.
Quigley & Lu Expires October 8, 2010 [Page 2]
Internet-Draft LSF Registry April 2010
Table of Contents
1. Requirements notation . . . . . . . . . . . . . . . . . . . . . 4
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
5. Normative References . . . . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7
Quigley & Lu Expires October 8, 2010 [Page 3]
Internet-Draft LSF Registry April 2010
1. Requirements notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
2. Introduction
With the acceptance of security labels in several mainstream
operating systems the need to communicate labels between these
systems becomes more important. Unfortunately these systems are
diverse enough that attempts at establishing one common label format
have been unsucessful. The reason for this is that systems implement
different MAC models some of which do not share any common ground.
One solution is to define a single label format which consists of the
union of the requirements of all MAC models/implementations. This is
not ideal because it introduces an environment where many MAC models
would either have blank fields for many of the label's components or
will ignore the values that are present all together. This
environment introduces waste and complexity where it isn't needed.
Additionally if a policy authority or identifier field is specified
in the label format it would require a robust description that could
be implemented which would lock policy administration into the
described model.
Ideally a mechanism to address this problem should allow the most
flexibility possible in terms of policy administration while
providing a specification that is suffient to allow for
implementation of the label format and understanding of the semantics
of the label. This means that the label format specification (LFS)
would ideally contain a syntactic description of the label format and
a description of the semantics for each component in the label. This
allows protocols to specify the type of label and label semantics
that it requires while leaving policy and policy administration to
the individual organizations using the protocol in their environment.
Policy administration within an organization is a difficult problem.
This should not be made even more difficult by having to request
permission from external entities when crafting new policy or just
making department specific modifications to existing policies. The
policy authority field would allow an LFS to specify a scheme for
policy administration without forcing it on all users of security
labels. However by agreeing to implement a particular LFS the
protocol agrees to that policy administration mechanism when
processing labels of that type.
Quigley & Lu Expires October 8, 2010 [Page 4]
Internet-Draft LSF Registry April 2010
3. Security Considerations
This document defines a mechanism to associate label selection
identifier with a document outlining the syntax and format of a
label. There is no security consideration in such an association.
The label specification documents referenced by each registration
entry should state security considerations for the label mechanism it
specifies.
4. IANA Considerations
This section provides guidance to the Internet Assigned Numbers
Authority (IANA) regarding creation of a new registry in accordance
with RFC 5226.
This submission requests the creation of a new registry called
"Security Label Format Selection Registry". The new registry has the
following fields:
o Label Format Selector: An integer number that maps to a particular
label format (e.g. CALIPSO label format defined by RFC 5570).
The name space of this identifier has the range of 0..65,535.
o Label Description: A human readable ASCII text string that
describes the label format, e.g. "Common Architecture Label IPv6
Security Option (CALIPSO)". The length of this field is limited
to 128 bytes.
o Status: A short ASCII text string indicating the status of an
entry in the registry. The status field for most entries should
have the value "active". In the case that a label format
selection entry is obsolete, the status field of the obsoleted
entry should be "obsoleted by entry NNN".
o Label Format Specification: A reference to a stable, public
document that specify the label format, e.g. an URL to RFC 5570.
The Label Format Selector name space ranges from 0 to 65,535. The
initial assignments of the registry are as follows:
Quigley & Lu Expires October 8, 2010 [Page 5]
Internet-Draft LSF Registry April 2010
+------------------+-------------------+--------+-------------------+
| Label Format | Description | Status | Reference |
| Selector | | | |
+------------------+-------------------+--------+-------------------+
| 0 | Reserved | - | - |
| 1 - 127 | Private Use | - | - |
| 128 - 255 | Experimental Use | - | - |
| 256 | CIPSO (tag type | active | [Reference to |
| | #1) | | document] |
| 257 | CALIPSO (RFC | active | [RFC 5570 URL] |
| | 5570) | | |
| 258 | FLASK Security | active | [TBD] |
| | Context | | |
| 258 - 65535 | Unassigned | - | - |
+------------------+-------------------+--------+-------------------+
Table 1: Label Format Specifier Ranges
A label format specification document is required to add a new entry
to this registry. The IANA Consideration section of the label format
document should clearly reference the Label Format Selection registry
and request allocation of a new entry. The well-known IANA policy,
Specification Required, as defined in section 4.1 of RFC 5226, will
be used to handle such requests. Note that "Specification Required"
policy implies this process requires a Designated Expert reviewer,
i.e. adding a new entry to this registry requires both a published
label format specification and a Designated Expert review.
In the case that a label format selector number is assigned to a
label format and the label format specification is changed later, a
new selector assignment should be requested. The same Specification
Required IANA policy applies to such requests. The IANA
Consideration section of the updated label format specification
should be explicit in which old label selector assignment it
obsoletes. Below is an example of obsoleted entry in the registry:
Quigley & Lu Expires October 8, 2010 [Page 6]
Internet-Draft LSF Registry April 2010
+---------------+-------------------+-------------+-----------------+
| Label Format | Description | Status | Reference |
| Selector | | | |
+---------------+-------------------+-------------+-----------------+
| 0 | Reserved | - | - |
| 1 - 127 | Private Use | - | - |
| 128 - 255 | Experimental Use | - | - |
| 256 | CIPSO (tag type | active | [Reference to |
| | #1) | | document] |
| 257 | CALIPSO (RFC | active | [RFC 5570 URL] |
| | 5570) | | |
| 258 | FLASK Security | obsoleted | [old spec URL] |
| | Context | by 263 | |
| . | | | |
| . | | | |
| 263 | FLASK Security | active | [new spec URL] |
| | Context (v2) | | |
| 264 - 65535 | Unassigned | - | - |
+---------------+-------------------+-------------+-----------------+
Table 2: Label Specifier Updated Ranges
5. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Authors' Addresses
David P. Quigley
National Security Agency (NSA)
Phone: (301)688-0849
Email: [email protected]
URI: http://www.nsa.gov
Jarrett Lu
Oracle
Email: [email protected]
Quigley & Lu Expires October 8, 2010 [Page 7]
_______________________________________________
nfs-discuss mailing list
[email protected]
