Agenda

1.1> Approval Of Agenda
1.2> Approval Of Previous Minutes

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.1 > ISO/IEC JTC1 SC18, SC21, SC27
3.2 > CCITTX.500
3.3 > ECMAPCTE+
3.4 > IEEE POSIX P1003.0
3.5 > Others

5>    AOB

6>   Next Meeting
 
 

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

Yes

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:
ISO/IEC JTC1/SC18
ISO/IEC JTC1/SC25
ISO/IEC JTC1/SWG-EDI
ISO TC 68/SC2
EWOS MHS(X.400)
X500
may also need to be considered.

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

TBS

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

None

1.     Need for the Work

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.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

• Administration
• Application Access

3.     Basis for the Work

• Authentication
• Key Distribution
• Credential Management
• Audit

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

• OSF
• UI
• Project MAXSIX
• ECMA SESAME project

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

• Secret key mechanisms (eg. Kerberos)
• Public key mechanisms (eg. X509)
• Generic APIs (eg. DEC's GSSAPI)

4.     Worked Other Organisations

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/(EC JTC1/SC18
ISO/IEC JTC1/SC25
ISO/IEC JTC1/SWG-EDI
ISO TC 68/SC2
EWOS MHS(X.400)
X500

 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.

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.