To: Irvine P1003.6 Working Group Attendees (based on attendance list recorded in minutes) The attached notes describe a proposal for "Authentication and Related Services" (nee I&A) work in POSIX. They are being sent mainly for the benefit of those people who didn't stay until Friday and missed the opportunity to pick up the paper version. There are also some minor updates (in the definition of services). As indicated below, following further work by the sub-group, and consideration of other relevant work such as in the IETF and the X/Open Security WG, we will update and disseminate this report to solicit input for Denver. The target for this update is end-May. It is anticipated that the update will include proposals for new projects where appropriate, so please take this opportunity to comment on this first draft. Specific input would be welcome on: - scope - principles - proposed liaisons - services identified - existing practice - priorities - name of the work area Thanks, Piers 27APR93 Ps. I am cc-ing this to the X/Open SWG too. Apologies in advance to Roland Buresund as you (I believe) will be the only person to get this twice. ------------------------------------------------------ Piers McMahon 27APR93 ICL post: Kings House, 33 Kings Road, Reading, RG1 3PX, UK email: p.v.mcmahon@rea0803.wins.icl.co.uk OR p.mcmahon@xopen.co.uk phone: +44 734 586211 extension 3285 fax: +44 734 855106 ------------------------------------------------------- ------------------cut-here--------------- Post: ICL, Kings House, 33 Kings Road, Reading, RG1 3PX, UK Phone: +44 734 586211 x3285 Fax: +44 734 855106 Email: p.v.mcmahon@rea0803.wins.icl.co.uk p.mcmahon@xopen.co.uk 27APR93 To: P1003.6 Working Group Authentication and Related Security Services -------------------------------------------- The attached note is an outline proposed definition for the "Authentication and Related Security Services" [Footnote 1] work area for POSIX. It includes suggestions for an initial draft of the list of the services which need to be standardised which I have based on the agreement reached in our initial sub-group meeting, and the subsequent plenary discussions. As I reported to the plenary, our sub-group has planned work between now and the next meeting which includes further definition and review of services, and identification of existing practice to be standardised. Therefore, please give any major comments to me and/or to the P1003.6 mailing list on this initial draft - preferably by the end of April. In the light of any comments received from the P1003.6 WG and others, the sub-group will produce an updated version of this paper which will include for discussion a strawman definition of new project(s) - including an preliminary assessment of relevant PAR Review Criteria considerations. This will also take into account how we can leverage or relate to relevant security work being done within other areas including, but not limited to: - Open Software Foundation - Distributed Computing Environment - X/Open Security WG - IETF Common Authentication Technology, Authorisation & Access Control WGs - ISO (primarily SC21/WG8, but also SC21/WG1, SC6 and SC27) - ECMA TC36/TG9 - Security in Open Systems - SESAME Project - CEN/CENELEC ITAEGV Security APIs Ad Hoc Group - UK Ministry of Defence Security Technology Demonstrator Programme The revised document shall be circulated widely to solicit input before the Denver meeting. Piers McMahon ---------- Footnote 1: In response to comments that were made at the 20APR93 P1003.6 plenary, I suggest that the name of the work area be changed from "Identification and Authentication" to "Authentication and Related Security Services". There are two reasons for this: (a) This allows, but does not prescribe, the consideration of distributed authorisation services and support functions within the scope of the group's work. (b) This title is deliberately intended to be consistent with the new work item "Authentication and Related Security Services for Distributed Applications" (JTC1 N2040) which SC21/WG8 has recently included in its programme of work. It would be preferable if there is convergence between the work which SC21/WG8 do on mechanism-independent security interfaces and that done as part of the work destined for SC22/WG15. While I will continue to contribute to and/or track the SC21/WG8 work through the UK national body representative, a formal POSIX liaison - through the appropriate US TAG(s) - will probably be needed here. -------attachment------ Authentication and Related Security Services - Definition --------------------------------------------------------- Summary This document scopes, suggests some principles for, and proposes a definition of, the "Authentication and Related Security Services" work as input to P1003.6 WG discussions, and specifically the decision on where it is appropriate to initiate new PASC standards projects in this area. The document is at a very preliminary stage. Comments are welcome. Scope In general, authentication and related security services enable users and applications to authenticate themselves to the system, to each other, and to obtain access rights which can be used as input to access control decisions. There is a close and overlapping relationship between this area and networking services (see general principals). The placement of the authentication and related security services within a wider POSIX framework, their fit with P1003.0, and the definition of a complete taxonomy of unsatisfied interface requirements are all out of scope of this document. However the framework and architectural issues are being actively addressed as part of the P1003.22 work and will strongly influence this work area. General Principles For authentication and related security services to be standardised, and hence to be widely applicable, it is important that the interfaces defined for these services meet a number of basic acceptance criteria which are identified and exemplified as follows: - policy independence not just TCSEC/FC, but also commercial etc - authentication method independence not just password, but also biometrics etc - security protocol independence not just Kerberos, but also X509, Sesame etc - algorithm independence not just DES, RSA, but also IDEA, DSA etc - operating system independence not just UNIX, but also VMS etc - operating environment independence not just DCE, but also ONC etc - location independence not just platform login, but also n/w login Issues relating to legislative controls on use, export, and import of security products must also be considered so that the standard is not just applicable to one legal regime, but is acceptable internationally. Specific exceptions to these principles may be thought desirable where a particular mechanism or algorithm is a de facto standard. However, as security in general and distributed security in particular are rapidly developing areas, it would be unwise to enshrine today's mechanism in a standard, and to mandate it as a conformance requirement for everyone. The security services should be standardised, not the mechanisms. Service Areas The Authentication and Related Security Service areas include the following: * Human user authentication The interface form may be - CLIs - GUIs?? The semantic scope of such interfaces includes: - asserting an identity - authorisation attribute requests - such as specifying a role, or selecting from a role list - use of different authentication mechanisms - such as password based and smart cards - session tailoring - such as defining an environment variable Existing practice includes: - UNIX login, su - UNIX ftp, telnet, rlogin, rsh etc - Kerberos klogin etc - OSF DCE dce_login - SESAME login * Application authentication The semantic scope of such interfaces are the same as human authentication, but also include interfaces for obtaining (references to) authentication information Existing practice includes: - Kerberos - DCE - IBM EDB - SESAME - NIST (password key management) * Inter-application security context establishment The semantic scope of such interfaces includes: - establishing "network credentials" - setting security context requirements - mutual authentication - secure transfer of security attributes - getting security context information and security attributes - delegation Existing practice includes: - GSS-API - IBM EDB - DEC DASS - Kerberos - DCE - SESAME * Distributed Authorisation The semantic scope of such interfaces includes: - making access control decisions based on distributed attributes Existing practice/work includes: - DCE - IETF AAC * Continuing authentication The semantic scope of such interfaces includes: - specifying security requirements for inter-application communication - privacy of communications - integrity of communications - rechecking the inter-application authentication ("re- keying") Existing practice includes: - GSS-API - IBM EDB - DEC DASS - Kerberos - DCE - SESAME * Related management services The interface form may be - APIs - CLIs - GUIs?? The semantic scope of such interfaces includes: - managing authentication information and user access control information - import/export of credentials - generating passwords etc - revocation Existing practice includes: - UNIX passwd - UNIX (SVR4) sysadm - DEC DASS - Kerberos - OSF DCE - SESAME - IBM EDB - NIST (user management) --------ooOOoo---------