Document Reference : RGSec-N014

ISO/IEC JTC1/SC22/WG15 Security Rapporteur Group Meeting

Stockholm, Sweden - 4 November 1991


1 >   Introductions
1.1> Approval Of Agenda
1.2> Approval Of Previous Minutes
2>   POSIX Security Extensions (P1003.6)
2.1 > Status Of POSIX P1003.6 Within IEEE
2.2 > Status Of POSIX P1003.6 Within ISO/IEC SC22/WG15
2.3 > Future POSIX Security Work
2.3.1 >       P1003.6a
2.3.2 >       Distributed Security Services
3 >    Liaison activities
3.1 > ISO/IEC JTC1 SC18, SC21, SC27
3.2 > CCITTX.500
3.4 > IEEE POSIX P1003.0
3.5 > Others
4 >    Resolutions

5>    AOB

6>   Next Meeting

Kevin V Murphy
SC22/WG15 Security Rapporteur

WG15/RGSec N017

Definition of the Security Services for Distributed/Network Environments

I.   Administration

Candidate(s) for Chair, Technical Editor and Secretary
Name Company Role
TBS Chair
TBS Vice-chair
TBS Secretary
TBS Technical Editor

II.  Working Group

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

III. Deliverable Documents

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

IV.  Scope Statement

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 standardized

Administration API
Application Access API
will be produced for the distributed security services identified defining the abstract syntax and high level protocol for such services as authentication and key distribution.

V.   Overlap/Dependencies on other work

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.

VI. User Need

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.

VII. How will this overlap/overload affected Interests?

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,

VIII. Commitment to TCOS-SEC Raquirementst


IX. Relation to IS0 structure and other coordination issues

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:
may also need to be considered.

X.   Proposed positioning In TCOS numbering scheme, document scheme associated ISO document scheme


XII. What objections have been identified to this area of work, or expected base document(s)?



Background to the Distributed Security Services PAR

1.     Need for the Work

1.1    The Liaison Group set up to identify areas of overlap and interdependency between the POSIX groups covering Security (1003.6), System Administration (1003.7) and Distributed Systems (1003.8, .12. .17. 1224 and 1228} has identified the area of trusted networks, authentication within networks and networtt management as one where work on harmontzatfan and synchronization between the groups is required.

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.     Work to be Done

2.1    As part of the review and update of the 1003.0 reference models, a model covering the provision and administration of distributed security services needs to be produced. This would seem most appropriate as an additional subsection to section 5.2 System Security and Privacy Services. This section already references the need for services of this type.

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

need to be produced for each of the services identified within the model

3.     Basis for the Work

3.1    IS 7498-2 Security Addendum covering Architectural Framework/Security Services is a basis for the development of the model.  Possible candidate services are: 3.2    Kerberos, produced as part of the MIT Project Athena, which already forms part of several implementations can be used as a starting point for the development of the API

3.3    It is unlikely that Kerberos will provide a standard in itself and the work of other organisations such as:

will also need to be reviewed to see what contribution it can make.

3.4    There are also some basic choices about the use of particular mechanisms such as the choice between:

which will also need to be addressed as part of this work.

4.     Worked Other Organisations

4.1    The work of the ISO/IECJTC1 groups abo needs to be considered to see how compatibility can be maintained. The Catalogue of JTC1 Security Related Prefects (JCT1/SC22 N849) contains a list of such projects. The major groups producing work in this area are:
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.


WG15/RGSec N021
X.500 vs. POSIX ACLs

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.

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.

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.

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.

WG15/RGSec N022