1.1> Approval Of Agenda2> POSIX Security Extensions (P1003.6)
1.2> Approval Of Previous Minutes
2.1 > Status Of POSIX P1003.6 Within IEEE3 > Liaison activities
2.2 > Status Of POSIX P1003.6 Within ISO/IEC SC22/WG15
2.3 > Future POSIX Security Work2.3.1 > P1003.6a
2.3.2 > Distributed Security Services
3.1 > ISO/IEC JTC1 SC18, SC21, SC274 > Resolutions
3.2 > CCITTX.500
3.3 > ECMAPCTE+
3.4 > IEEE POSIX P1003.0
3.5 > Others
6> Next Meeting
Kevin V Murphy
SC22/WG15 Security Rapporteur
Candidate(s) for Chair, Technical Editor and Secretary
Name Company Role TBS Chair TBS Vice-chair TBS Secretary TBS Technical Editor
No. of active participants: TBS No. of correspondent members identified: TBS Breakdown of active participants; Producer: TBS User: TBS Other: TBS No. of companies/interests represented: TBS International participation identified: X-Open
Reference Model for inclusion In P1003.0
Expected size: TBS Project time frame: First Draft: TBS Start Balloting; TBS Candidate for "base document": P1003.0
Standard for Distributed Security Services.
Expected size: TBS Project time frame: First Draft: TBS Start Balloting; TBS Candidate for "base document": None
The definition of the model, distributed services, and administrative functions required to support security in a network environment.
A reference model to cover the distributed security services and their administration will be produced for inclusion in P1003.0. This model will be based on the work currently done by other standards organisations and the practical implementations being developed in this area.
This model will then be the basis for the investigation of existing mechanisms and interfaces developed to supply these services, such as Kerberos by the MIT Project Athena, GSSAPI by DEC, Project MAXSIX and the ECMA SESAME project.
Further relevant input vill be solicited.
A standardizedAdministration APIwill be produced for the distributed security services identified defining the abstract syntax and high level protocol for such services as authentication and key distribution.
Application Access API
TCOS standards assumed: P1003.6, .7, .8, .12, .17
The Security group (P1003.6), Administration group (P1003.7) and the Distributed Services groups (P1003.8, .12, .17) will need to be aware of the work done under this PAR and be prepared to coordinate their standards with it.
All these 5 groups are doing work which overlaps in some way with this area. The work done under this PAR will be a focus for these areas of overlap.
This area of overlap between the Security, Administration and Distributed Services groups has been identified by the liaison group formed to invesgitage the interactions between these groups.
The work is required to allow the synchronisation and harnonization of the standards of .6, .7 and .DS. and to ensure compatibility and interoperability with the current work of the other organisations.
The need for this work is immediate to bridge the gap between the work currently being done to produce practical solutions to these problems and the emerging ISO standards.
The work is specifically designed to cover the overlap between these 3 areas.
It will also overlap the work of proprietary network management systems and organisations such as OSF and UI.
It will use the work currently being done by such organisations and will provide a focus for the hamonization of such developments,
Coordination will be needed with a range of ISO groups and others which are working in this area. The major one identified are:
ISO/IEC JTC1/SC27 IT Security Techniques ISO/IEC JTC1/SC22 (WG15) Languages (Covers POSIX Security) ISO/IEC JTC1/SC6 OSI Lover Layers ISO/IEC JTC1/SC21 OSI Architecture Upper Layers ECMA/TC32 Security in Open Systems ECMA/TC46 Security Framework CCITT/SVGII/Q19 Distributed Application Security
The work of other such as:
ISO TC 68/SC2
may also need to be considered.
1.2 Work is in progress within other organisations which overlaps this same area and there is the possibility of problems wtth compatibility and interoperabffity unless this area is addressed.
1.3 Commercial pressures are already forcing the development
of proprietary solutions to address the practical problems of security
in a distributed and networked environment and work is need to bridge the
gap between these devetopments and the emerging ISO standards.
2.2 The current body of work covering the area of trusted networks, from other organisations concerned with the development of standards and those producing commercial solutions, needs to be reviewed and evaluated.
2.3 Using the outcome of this evaluation a set of APIs covering
3.3 It is unlikely that Kerberos will provide a standard in itself and the work of other organisations such as:
3.4 There are also some basic choices about the use of particular mechanisms such as the choice between:
ISO/IEC JTC1/SC27 FT Security Techniqu—
ISO/IEC JTC1/SC22 (WG15) Languages (Covers POSIX Security)
ISO/1EC JTC1/SC6 OSI Lower Layers
ISO/IEC JTC1/SC21 OSI Architecture Upper Layers
4.2 Within CCITT
CCITT/SVGII/Q19 Distributed Application Security
4.3 Within ECMA
ECMA/TC32 Security in Open Systems
ECMA/TC46 Security Framework
4.4 The work of several others organisations overlap various aspects of security and may need to be considered eg.
ISO TC 68/SC2
4 March 1991
Paul A. Karger
Open Software Foundation
11 Cambridge Center
Cambridge, MA 02142 USA
+1 617 621 8994
The access control list designs coming out of the X.500 and POSIX 1003.6 standards committees conflict in-certain ways. As both are intended to become ISO standards and both will likely be used in the same computer system, it would be highly desirable if one were at least a subset of the other. I have not fully studied the X.500 proposals, but after a superficial reading, I see the following conflicts:
a) POSIX ACLs specify that if a process is a member of multiple groups and any of the groups has access to an object, then the process gets access. (The rights are OR-ed together.) X.500 ACLs specify that if a user matches multiple subtree user classes, then the user gets access only if ail the subtree user classes have access. (The rights are AND-ed together.) This is a direct conflict between the proposed standards. POSIX rationalizes its choice, because in Berkeley UNIX, a process may turn its group memberships on and off and thus could always get access, regardless.Other than these two conflicts, POSIX ACLs appear to be subsets of X.500 ACLs. However, I have not fully understood X.500 ACLs, so there may be other problems. In particular, I have not seen how default ACLs work in X.500.
b) POSIX ACLs have the concept of a MASK_OBJ that is logically anded wirh all access rights granted to any process by any ACL entry for a named user or group other than the owner of the object or the reserved entry OTHER_OBJ for all other processes not otherwise named. There is no corresponding concept of MASK_OBJ in X.500. This is understandable, since MASK_OBJ exists only for compatibility with the old UNIX owner/group/other protection scheme.
I don't propose a solution at this time. I propose that
the POSIX 1003.6 committee and the X.500 committee need to communicate
with one another to attempt to resolve the incompatibilities.
It would be highly desirable if POSIX ACLs were a proper subset of X.500
ACLs, as that would make the user interface much simpler to understand.
The European Security Evaluation Criteria (ITSEC) specifically call for
ease of secure use as an evaluation criteria, and such a subsetting relationship
would definitely improve ease of secure use.