From bcn Fri Jun 19 13:17:48 1992 Date: Fri, 19 Jun 1992 20:17:48 -0700 From: Clifford Neuman To: ietf@ISI.EDU, saag@TIS.COM, cat-ietf@MIT.EDU Subject: BOF on Authorization and Access Control (aac) Status: O There will be a new BOF on Authorization and Access Control at the July IETF. A description of the BOF follows. I'd appreciate it if those with ideas for additional topics would let me know. WEDNESDAY, July 15, 1992 7:00-10:00pm Evening Session BOF Authorization and Access Control BOF (aac) (Clifford Neuman/ISI) Authorization and Access Control Mechanisms for the Internet ------------------------------------------------------------ A BOF has been scheduled to discuss authorization and access control issues for the Internet. The discussion will center around two problems: first, the need for a uniform method for specifying access control information, and second on services and mechanisms for managing authorization in the Internet. Specifying Access Control Information Several authentication mechanisms are now in place on the Internet. These mechanisms include the use of passwords, simple assertion, network addresses, trust in the identification of users by remote hosts, and stronger methods such such as Kerberos and Digital Equipment Corporation's DASS. Authorization mechanisms are usually application specific and rely on a single authentication method. We will discuss the methods used by various applications to specify authorization information, in hopes of coming up with a common method that can be applied across all applications. Such an approach should allow the specification of the strength of the authentication method to be used, as well as the identity of the individual. Managing and Distributing Authorization Information The second topic for discussion will be evolving mechanisms and architectures for authorization in distributed systems. Among the methods to be discussed are those used by the Open Software Foundation's Distributed Computing Environment, the Digital Distributed System Security Architecture, restricted proxies and Kerberos, and the European Computer Manufacturers Association standards. We will look for common characteristics among these mechanisms and discuss what might be appropriate for the IETF to do in this area. From bcn Tue Jul 28 02:36:01 1992 Received: from tgo.isi.edu by venera.isi.edu (5.65c/5.65+local-6) id ; Tue, 28 Jul 1992 09:38:14 -0700 Date: Tue, 28 Jul 1992 09:36:01 -0700 Posted-Date: Tue, 28 Jul 1992 09:36:01 -0700 Message-Id: <199207281636.AA02940@tgo.isi.edu> Received: by tgo.isi.edu (5.65c/4.0.3-4) id ; Tue, 28 Jul 1992 09:36:01 -0700 From: Clifford Neuman To: ietf-aac Subject: Draft minutes of AAC BOF Status: O DRAFT Minutes of the Authorization and Access Control BOF (AAC) Cambridge IETF July 15, 1992 7:00 PM Chair: Clifford Neuman USC Information Sciences Institute [Please comment, fill in any areas where you feel elaboration is necessary, or tell me where I should attribute items to individual attendees]] The first meeting of a new BOF on Authorization and Access Control met at the July IETF. The purpose of the BOF was to discuss authorization and access control issues for the Internet. The discussion centered around two problems: first, the need for a uniform method for specifying access control information, and second on services and mechanisms for distributing authorization in the Internet. The agenda for the meeting was: 1. Discussion of requirements for the specification of access control information. 2. Discussion of existing and evolving distributed authorization mechanisms including: DCE, DSSA, ECMA/Sesame, and Proxies. 3. Discussion of the relationship between this group and the common authentication technology working group. 4. Discussion of our goals. Discussion: The first two items were related and discussion flowed from one into the other and back again. The need for a uniform method of specifying access control information for distributed applications was discussed. One of the motivations for such an interface is to interact with the network authentication methods that are evolving. Such methods identify the subject accessing a service, but service specific methods are then needed to decide whether the subject is authorized access. Most existing applications do not presently maintain the information needed to make such decisions. In the near future, application developers will have a common interface (the GSSAPI) that they can use to add strong authentication to their applications. That solves only half the problem. Ideally there would also be a common set of tools that they can use to decide whether the subject is authorized access. The general consensus was that our work in this area should concentrate on access control list mechanisms, but that support for capabilities should also be considered. It was also mentioned that work has gone on in POSIX and elsewhere to specify access control list mechanism for Unix. It was felt that we should consider such work, and build upon rather than replace it, but that we must support the needs of network applications. Also, some of the features of the distributed authorization mechanisms (described later) might be reflected in the ACL mechanism. An access control list (ACL) can be associated with objects to be protected. The ACL contains entries that identify subjects, either as individuals, or as members of groups. The entries specify the rights of the named subject to access the protected object. One extension to the concept important for use on the Internet is that the identification of the subject should also identify the authentication method (or set of acceptable methods) to be used in identifying the subject. A less straightforward extension is the addition of an optional field to each ACL entry that would allow restrictions of the authorization to be specified. Examples of restrictions include time of use, the need for additional authentication or authorization (e.g. a cosigner), etc. Steve Crocker pointed out that the mechanism and abstraction must be simple and easy to understand in the common case, a sentiment with which everyone agreed. It was felt that our goals in this area should be to: 1. Identify the target applications from which to draw requirements. e.g. Mailing lists, files, login, X windows. 2. Identify the security models to be supported. e.g Discretionary Access Control, Mandatory Access Control, Capabilities, Access Control Lists, etc. 3. Work out the appropriate access control abstractions. 4. Consider an application programmer interface (API) to support those abstractions. (consider POSIX, DCE, our own, etc.). The second phase of the meeting concentrated on the evolving mechanisms and architectures for authorization in distributed systems. This phase consisted of informal presentations of some of the mechanisms. Joe Pato described the authorization mechanism used by OSF's Distributed Computing Environment. Authorization in DCE is based on privilege attribute certificates issued by a privilege server. These certificates are restricted Kerberos tickets (see restricted proxies described later) that specify the UID and groups to which a principal belongs. The privilege attribute certificate is then used by the principal to assert its membership in groups, and its UID. John Linn then described the authorization mechanisms that are part of the Digital Distributed System Security Architecture (DSSA). One key aspect of the DSSA is that authorization credentials are pulled by the server, rather than pushed by the client, though the client provide's hints suggesting which credentials should be pulled. A second aspect of the DSSA is that reduced authorization can be granted by establishing a new role, a new principals with reduced privileges. Pierce McMahon then described the ECMA/Sesame security architecture. In ECMA/Sesame, a security service issues credentials certifying the authorization held by principals. [Pierce can you help me out here? If you can give me a one paragraph description that would be useful]. Next, Clifford Neuman described restricted proxies. A restricted proxy can be implemented on top of an authentication mechanism by issuing authentication credentials authorizing a second party (the grantee) to act as the issuer for the purpose of performing a restricted set of operations, under specific conditions. These restrictions are supported by Kerberos V5 in the authorization data field. It was then described how restricted proxies can be used to implement a range of authorization mechanisms from capabilities, to authorization and group servers, and how restricted proxies might interact with the access control list mechanisms described earlier. The next topic of discussion was how these mechanism might be used by applications. In particular, might it be appropriate to develop a common API within which they might fit. If so, might this API become part of the common authentication technology (GSSAPI) so that the programmer only need deal with one mechanism, instead of two. It was felt that our immediate goals in the distributed authorization area should be: 1. To look for common characteristics among the mechanisms. 2. Decide on a course of action The range of possibilities include encouraging the use of a common credential format, developing other interoperability mechanism, defining a common API, and unifying the protocols. In general, we must decide what the product of a potential working group would be, and to develop a set of goals and milestones. It was felt that work is needed in the area of authorization and access control, and that the group should continue to meet, probably once more as a BOF, to lay the foundation for the formation of a working group, and then as a working group. A mailing list has been set up, ietf-aac@ISI.EDU. Requests for addition or deletion should be sent to ietf-aac-request@ISI.EDU. From P.V.McMahon.rea0803@dsbc.icl.co.uk Tue Jul 28 16:14:10 1992 Received: from ben.uknet.ac.uk by venera.isi.edu (5.65c/5.65+local-6) id ; Tue, 28 Jul 1992 16:14:10 -0700 Received: from eros.uknet.ac.uk by ben.uknet.ac.uk via UKIP with SMTP (PP) id ; Wed, 29 Jul 1992 00:00:39 +0100 Received: from eccles.dsbc.icl.co.uk by eros.uknet.ac.uk with UUCP id <15668-0@eros.uknet.ac.uk>; Wed, 29 Jul 1992 00:00:31 +0100 Received: on eccles.dsbc.icl.co.uk over UUCP id AA15180; Tue, 28 Jul 92 23:54:09 BST Received: from oasis.icl.co.uk by iclbra.oasis.icl.co.uk (4.14/) id AA18889; Tue, 28 Jul 92 23:52:41 bst Received: from oasis.icl.co.uk by bunny.oasis.icl.co.uk (4.14/oasis-2.04-client) id AA03510; Tue, 28 Jul 92 23:57:22 bst Message-Id: <9207282251.AA07188@getafix.oasis.icl.co.uk> From: P.V.McMahon.rea0803@oasis.icl.co.uk Date: Tue, 28 Jul 92 23:51:27 BST Reply-To: P.V.McMahon.rea0803@oasis.icl.co.uk Subject: RE: Draft minutes of AAC BOF To: bcn Cc: ietf-aac Priority: URGENT Status: O Cliff, I have a couple of comments on the draft minutes: > The general consensus was that our work in this area should > concentrate on access control list mechanisms, but that support for > capabilities should also be considered. It was also mentioned that > work has gone on in POSIX and elsewhere to specify access control list I recall asking a question about your view of the significance of using the ACL paradigm, and you indicated that you were adopting it as a conceptual (rather than an implementational) model which could be generalised to support the full spectrum of access control methods (including capabilities). I don't think that the question of capabilities being relatively low priority came up during the BOF. (As you taped the proceedings you may be able to prove me wrong here!). > of the named subject to access the protected object. One extension to > the concept important for use on the Internet is that the > identification of the subject should also identify the authentication > method (or set of acceptable methods) to be used in identifying the > subject. I don't remember the subject of ACL restrictions based on authentication methods being discussed. (Again, the tape may show my memory/hearing to be at fault). While I agree that it is important for the Internet that the authentication method (none, password, smart card, or whatever) should influence access control, there are more ways of meeting this requirement than the one you have suggested. Perhaps a decision on the best approach here should await further work on the security model and access control abstractions? > The next topic of discussion was how these mechanism might be used by > applications. In particular, might it be appropriate to develop a > common API within which they might fit. If so, might this API become > part of the common authentication technology (GSSAPI) so that the > programmer only need deal with one mechanism, instead of two. It's also worth mentioning that (my notes from the meeting tell me) that you said that there was a chance at arriving at a solution for common protocols &c due to the fact that the various mechanisms are all at a fairly early stage. On the other hand, Joe Pato commented to the effect that not all mechanisms are so embryonic: some have given birth (and therefore can't be subject to too radical surgery). > It was felt that our immediate goals in the distributed authorization > area should be: > > 1. To look for common characteristics among the mechanisms. > > 2. Decide on a course of action > > The range of possibilities include encouraging the use of a common > credential format, developing other interoperability > mechanism, defining a common API, and unifying the protocols. > > In general, we must decide what the product of a potential working > group would be, and to develop a set of goals and milestones. I think the last paragraph may imply that 1 and 2 happen in parallel - i.e. looking at common characteristics will be likely scoped to certain areas. > It was felt that work is needed in the area of authorization and > access control, and that the group should continue to meet, probably > once more as a BOF, to lay the foundation for the formation of a > working group, and then as a working group. My notes weren't so definite about the second BOF being most likely, and just said that it was agreed to refine the group's objectives over email and to thus decide whether to follow up this meeting with the definition of a working group charter, or with a second BOF. As requested I have written some text on ECMA/SESAME, reflecting the slides that got put up, which I can reduce to a minimum of two paragraphs: one for ECMA and one for SESAME (which is probably an unprecedented feat of miniaturisation in itself). I have edited them into the text which I have attached below. Piers. Ps. Just to be perverse, my name is the English spelling (as in Plowman) rather than the American/Irish (as in Brosnan). --------------------------------------------------- > Pierce, > > Can you help me out by providing a one paragraph descripion > of the ECMA stuff modeled on the descriptions of the other systems? > --- > > The second phase of the meeting concentrated on the evolving > mechanisms and architectures for authorization in distributed systems. > This phase consisted of informal presentations of some of the > mechanisms. > > Joe Pato described the authorization mechanism used by OSF's > Distributed Computing Environment. Authorization in DCE is based on > privilege attribute certificates issued by a privilege server. These > certificates are restricted Kerberos tickets (see restricted proxies > described later) that specify the UID and groups to which a principal > belongs. The privilege attribute certificate is then used by the > principal to assert its membership in groups, and its UID. > > John Linn then described the authorization mechanisms that are part of > the Digital Distributed System Security Architecture (DSSA). One key > aspect of the DSSA is that authorization credentials are pulled by the > server, rather than pushed by the client, though the client provide's > hints suggesting which credentials should be pulled. A second aspect > of the DSSA is that reduced authorization can be granted by > establishing a new role, a new principals with reduced privileges. > Piers McMahon then outlined the main features of the ECMA TC32/TG9 Security Architecture. The ECMA model is that a trusted authentication service authenticates subjects using a suitable authentication method, and that a logically separate privilege attribute server (PAS) grants privileges (e.g.: identity, role, group, capability, clearance) to that subject. The privilege acquisition is constrained by the level to which the subject is authenticated - but is independent of the authentication method. The privileges are cryptographically protected by the PAS and returned in a data element called a Privilege Attribute Certificate (PAC), and are sent (pushed) by the security subject to target systems to inform access control decisions. Methods for protection of PACs, together with controls on their use and delegation are defined by current ECMA work. Piers then described SESAME. Some background information was given to explain that SESAME is a phased project based on ECMA TC32/TG9 work. Phase 1 produced a prototype which showed that the basic model was feasible. Phase 2 is building on this to develop product-level distributed security infrastructure with support for dialogue protection and DCE-interworking. An outline of the SESAME Phase 2 architecture was given to show how it built on the ECMA architecture, and a brief walkthrough of the privilege acquisition protocol was presented. It was stated that SESAME Phase 2 supports a subset of the full ECMA privilege attributes (identity, role, group), and a profile of ECMA PAC protection and controls. > > Next, Clifford Neuman described restricted proxies. A restricted > proxy can be implemented on top of an authentication mechanism by > issuing authentication credentials authorizing a second party (the > grantee) to act as the issuer for the purpose of performing a > restricted set of operations, under specific conditions. These > restrictions are supported by Kerberos V5 in the authorization data > field. It was then described how restricted proxies can be used to > implement a range of authorization mechanisms from capabilities, to > authorization and group servers, and how restricted proxies might > interact with the access control list mechanisms described earlier. > > ------------------------------------------------------- Piers McMahon 28JUL92 Open Distributed Processing, 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 ------------------------------------------------------- From bcn Fri Jul 31 05:01:40 1992 Received: from tgo.isi.edu by venera.isi.edu (5.65c/5.65+local-6) id ; Fri, 31 Jul 1992 12:03:53 -0700 Date: Fri, 31 Jul 1992 12:01:40 -0700 Posted-Date: Fri, 31 Jul 1992 12:01:40 -0700 Message-Id: <199207311901.AA04383@tgo.isi.edu> Received: by tgo.isi.edu (5.65c/4.0.3-4) id ; Fri, 31 Jul 1992 12:01:40 -0700 From: Clifford Neuman To: mdavies@NRI.Reston.VA.US Cc: ietf-aac Subject: Minutes of the Authorization and Access Control BOF (AAC) Status: O Minutes of the Authorization and Access Control BOF (AAC) Cambridge IETF July 15, 1992 7:00 PM Chair: Clifford Neuman USC Information Sciences Institute The first meeting of a new BOF on Authorization and Access Control met at the July IETF. The purpose of the BOF was to discuss authorization and access control issues for the Internet. The discussion centered around two problems: first, the need for a uniform method for specifying access control information, and second on services and mechanisms for distributing authorization in the Internet. The agenda for the meeting was: 1. Discussion of requirements for the specification of access control information. 2. Discussion of existing and evolving distributed authorization mechanisms including: DCE, DSSA, ECMA, Sesame, and Proxies. 3. Discussion of the relationship between this group and the common authentication technology working group. 4. Discussion of our goals. Discussion: The first two items were related and discussion flowed from one into the other and back again. The need for a uniform method of specifying access control information for distributed applications was discussed. One of the motivations for such an interface is to interact with the network authentication methods that are evolving. Such methods identify the subject accessing a service, but service specific methods are then needed to decide whether the subject is authorized access. Most existing applications do not presently maintain the information needed to make such decisions. In the near future, application developers will have a common interface (the GSSAPI) that they can use to add strong authentication to their applications. That solves only half the problem. Ideally there would also be a common set of tools that they can use to decide whether the subject is authorized access. The general consensus was that our work in this area should concentrate on access control lists as a conceptual model. Some of the distributed authorization mechanisms (described later) enable that model to support a full spectrum of access control methods including capabilities. Support for these mechanisms should be considered for inclusion in the model. It was mentioned that work has gone on in POSIX and elsewhere to specify access control list mechanism for Unix. It was felt that we should consider such work, and build upon rather than replace it, but that we must support the needs of network applications. An access control list (ACL) can be associated with objects to be protected. The ACL contains entries that identify subjects, either as individuals, or as members of groups. The entries specify the rights of the named subject to access the protected object. One point of contention was whether each distinct right for an object (read, write, execute, etc) should be represented by a separate ACL (i.e. column in the access matrix), or an ACL should be associated with each object with the entries within the ACL specifying the rights. The two are equivalent, and consensus was that a single ACL per object was the preferred choice. It was also felt that in general the meaning of rights in an ACL entry would be application specific (interpreted by the server), but that the meaning of certain rights, in particular the ability to modify the ACL, should be common across all ACLs. One extension to the ACL concept important for use on the Internet is that the identification of the subject should also identify the authentication method (or set of acceptable methods) to be used in identifying the subject. This is important because of the varying strengths of alternative authentication methods, and perhaps more importantly because the methods might not share a common name space for principals. There was very little discussion on this topic and any decisions here can await further work on the security model and access control abstractions. A less straightforward extension is the addition of an optional field to each ACL entry that would allow restrictions of the authorization to be specified. Examples of restrictions include time of use, the need for additional authentication or authorization (e.g. a cosigner), etc. Steve Crocker pointed out that the mechanism and abstraction must be simple and easy to understand in the common case, a sentiment with which everyone agreed. It was also felt, however, that in the ideal case the mechanism would also be flexible enough to support the needs of most applications, so that developers would not be forced to design their own mechanisms. It was felt that our goals in this area should be to: 1. Identify the target applications from which to draw requirements. e.g. Mailing lists, files, login, X windows. 2. Identify the security models to be supported. e.g We might consider discretionary access control, mandatory access control, capabilities, access control lists, etc. 3. Work out the appropriate access control abstractions. 4. Consider an application programmer interface (API) to support those abstractions (consider POSIX, DCE, our own, etc.). A final issue raised concerned whether our model needed support the needs of licensing and accounting mechanisms. It was felt that we should keep such mechanism in mind, but that it was premature to consider them as an integral part of our current work. The second phase of the meeting concentrated on the evolving mechanisms and architectures for authorization in distributed systems. This phase consisted of informal presentations of some of the mechanisms. Joe Pato described the authorization mechanism used by OSF's Distributed Computing Environment. Authorization in DCE is based on privilege attribute certificates issued by a privilege server. These certificates are restricted Kerberos tickets (see restricted proxies described later) that specify the UID and groups to which a principal belongs. The privilege attribute certificate is then used by the principal to assert its membership in groups, and its UID. The DCE also supports an extensible ACL model for distributed systems based on and extending that in the POSIX draft. Authorization is a combination of privilege attributes and control attributes (e.g., ACLs). Support for delegation is being considered, further exploiting the ability to construct restricted proxies. John Linn then described the authorization mechanisms that are part of the Digital Distributed System Security Architecture (DSSA). One key aspect of the DSSA is that authorization credentials are pulled by the server, rather than pushed by the client, though the client provide's hints suggesting which credentials should be pulled. A second aspect of the DSSA is that reduced authorization can be granted by establishing a new role, a new principals with reduced privileges. The DSSA supports delegation with identifiable intermediaries, but delegation is of all rights possessed by a particular role. Piers McMahon then outlined the main features of the ECMA TC32/TG9 Security Architecture. The ECMA model is that a trusted authentication service authenticates subjects using a suitable authentication method, and that a logically separate privilege attribute server (PAS) grants privileges (e.g.: identity, role, group, capability, clearance) to that subject. The privilege acquisition is constrained by the level to which the subject is authenticated - but is independent of the authentication method. The privileges are cryptographically protected by the PAS and returned in a data element called a Privilege Attribute Certificate (PAC), and are sent (pushed) by the security subject to target systems to inform access control decisions. Methods for protection of PACs, together with controls on their use and delegation are defined by current ECMA work. Piers then described SESAME. Some background information was given to explain that SESAME is a phased project based on ECMA TC32/TG9 work. Phase 1 produced a prototype which showed that the basic model was feasible. Phase 2 is building on this to develop product-level distributed security infrastructure with support for dialogue protection and DCE-interworking. An outline of the SESAME Phase 2 architecture was given to show how it built on the ECMA architecture, and a brief walkthrough of the privilege acquisition protocol was presented. It was stated that SESAME Phase 2 supports a subset of the full ECMA privilege attributes (identity, role, group), and a profile of ECMA PAC protection and controls. Next, Clifford Neuman described restricted proxies. A restricted proxy can be implemented on top of an authentication mechanism by issuing authentication credentials authorizing a second party (the grantee) to act as the issuer for the purpose of performing a restricted set of operations, under specific conditions. These restrictions are supported by Kerberos V5 in the authorization data field. It was then described how restricted proxies can be used to implement a range of authorization mechanisms from capabilities, to authorization and group servers, and how restricted proxies might interact with the access control list mechanisms described earlier. The next topic of discussion was how these mechanism might be used by applications. In particular, might it be appropriate to develop a common API within which they might fit. If so, might this API become part of the common authentication technology (GSSAPI) so that the programmer only need deal with one mechanism, instead of two. Finally, we discussed the possibility of convergence of the various approaches. Some of the approaches are still in their early stages, and it would be helpful if we could encourage, for example, a common certificate structure across mechanisms. However, some of the mechanisms, in particular DCE, are further along, and significant changes would present problems. In any event, where possible, we should try to promote fewer protocols and message formats. It was felt that our immediate goals in the distributed authorization area should be: 1. To look for common characteristics among the mechanisms. 2. Decide on a course of action The range of possibilities include encouraging the use of a common credential format, developing other interoperability mechanism, defining a common API, and unifying the protocols. Finally, It was felt that work is needed in the area of authorization and access control, and that the group should continue to meet. As a potential working group, we must: 1. Decide what the product of the working group would be. 2. Develop a set of goals and milestones. 3. Write a charter It was felt that we should refine the group's objectives though the mailing list. If we can develop a charter in time for the next IETF, we can form a working group. If not, we should meet again as a second BOF, part of the purpose of which will be to agree on a charter. A mailing list has been set up, ietf-aac@ISI.EDU. Requests for addition or deletion should be sent to ietf-aac-request@ISI.EDU. From bcn Wed Oct 14 05:22:41 1992 Received: from tgo.isi.edu by venera.isi.edu (5.65c/5.65+local-6) id ; Wed, 14 Oct 1992 12:23:43 -0700 Date: Wed, 14 Oct 92 12:22:41 PDT Posted-Date: Wed, 14 Oct 92 12:22:41 PDT Message-Id: <9210141922.AA20131@tgo.isi.edu> Received: by tgo.isi.edu (4.1/4.0.3-4) id ; Wed, 14 Oct 92 12:22:41 PDT From: Clifford Neuman To: ietf-aac Subject: BOF on Authorization and Access Control (aac) There will be a second meeting of a BOF on Authorization and Access Control at the November IETF. A description of the BOF follows. FRIDAY, November 20, 1992 9:30-12:00pm Morning Session BOF Authorization and Access Control BOF (aac) (Clifford Neuman/ISI) Authorization and Access Control Mechanisms for the Internet ------------------------------------------------------------ A BOF has been scheduled to discuss authorization and access control issues for the Internet. At the last meeting of the BOF, the discussion centered around two problems: first, the need for a uniform method for specifying access control information, and second on services and mechanisms for managing authorization in the Internet. At this meeting we will continue the discussion, decide on specific goals and milestones for a new working group to address these problems, and discuss a charter, with a goal of establishing a working group by the Spring IETF. Specifying Access Control Information Several authentication mechanisms are now in place on the Internet. These mechanisms include the use of passwords, simple assertion, network addresses, trust in the identification of users by remote hosts, and stronger methods such such as Kerberos and Digital Equipment Corporation's DASS. Authorization mechanisms are usually application specific and rely on a single authentication method. One possible goal for the group will be to define a common method for use by various applications to specify authorization information. Such an approach might allow the specification of the strength of the authentication method to be used, as well as the identity of the individual. Managing and Distributing Authorization Information The second area in which the group can make a contribution relates to evolving mechanisms and architectures for authorization in distributed systems. Among the methods that were discussed at the last meeting were those used by the Open Software Foundation's Distributed Computing Environment, the Digital Distributed System Security Architecture, restricted proxies and Kerberos, and the European Computer Manufacturers Association standards. A goal of the group will be to look for common characteristics among these mechanisms and to help them work together. The best approach to be taken will be one of the topics of discussion for this meeting. From P.Williams@cs.ucl.ac.uk Sat Oct 17 12:37:13 1992 Received: from bells.cs.ucl.ac.uk by venera.isi.edu (5.65c/5.65+local-6) id ; Sat, 17 Oct 1992 03:37:56 -0700 Message-Id: <199210171037.AA15664@venera.isi.edu> Received: from auchentoshan.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Sat, 17 Oct 1992 11:37:17 +0100 To: ietf-aac Cc: Peter Williams Subject: Re: Second Draft of the minutes for the AAC BOF In-Reply-To: Your message of "Thu, 30 Jul 92 11:51:24 PDT." <199207301851.AA03840@tgo.isi.edu> Date: Sat, 17 Oct 92 11:37:13 +0100 From: Peter Williams >From: Clifford Neuman >Subject: Second Draft of the minutes for the AAC BOF >Date: Thu, 30 Jul 1992 11:51:24 -0700 >It was felt that our immediate goals in the distributed authorization >area should be: > > 1. To look for common characteristics among the mechanisms. > > 2. Decide on a course of action > > The range of possibilities include encouraging the use of a common > credential format, developing other interoperability mechanism, > defining a common API, and unifying the protocols. > >Finally, It was felt that work is needed in the area of authorization >and access control, and that the group should continue to meet. As a >potential working group, we must: > > 1. Decide what the product of the working group would be. > > 2. Develop a set of goals and milestones. > > 3. Write a charter > Let me to attempt to suggest some shapes for the potential WG. I start by identitying some criteria and the requirements with which to characterise the BOF/WG's possible output. We might then select those appropriate to the main objective of the group which, for the purpose of this projective analysis, I shall postulate: "Harmonise available A&A technologies to Maximise end-User confidence in the power and flexibility of a Minimal set of personal authentication credentials when using such infrastructure to mediate and effectively guarantee well-defined quality of service parameters serving to realize User and distributed telematic service-provider cooperation in the provision of secured, Internet applications." Its not very beautiful yet, but contains some insights and choices made. The notions of security and protection do not appear; the orientation, and basic evaluation criteria, is end-User centered; "systems" do not appear, being replaced by the more effective "infrastructure" and "user/service-provider interaction" notions. "Secure" applications are replaced by "Secured" applications. Working on the basis of such a theory, the group could steer itself towards a product which overcomes the daily-more apparent need to surmount the barrier of open system "secured" inter-connectivity - across both WAN and WAN/LAN environments. If you accept the thesis that advancement in the deployment of "secured" applications is heldup due to preocupation with the notions of levels of secureness, rather than amount of security _services_, then I could see the outputs being of fundamental importance to the advancement of the Internet. 1. Document Outputs It is an engineering group, so its goal is to produce practical outputs. Some IETF WGs concentrate on producing "implementor-agreement" or "interworking" recommendations, crucial for supporting actual operational pilots of some standard technology. Others concentrate on producing the actual "standard technology" - meeting some service requirements. Yet others work at a yet earlier stage in the engineering cycle in which they seek to consolidate a new technical advance in order to fashion new services. The BOF/WG would seem to be in the second class, where the standard technlogy to be developed is not one of the A&A technologies, but rather the harmonising criteria which enables interworking of confidence and trust. This also makes the first group possible, but without the intention to steer an actual pilot. 2. Distinction from Pilots/Services Product rivalries and attempts to have one A&A technology dominate the market might be actively countered by the group's existence and an active PR and intellectual campaign to combat the current conflicts. The programme would distiguish itself from current products/pilots/deployments, working rather to fashion a harmonised solution for 5 years time. 3. Scalability and technology advancement The BOF/WG agenda would address the explosion in Internet connectivity, cheaper, faster bandwidth, improving distributed database technology, and the expected explosion in smartcards, or the like. The A&A infrastructure would be required to operate world-wide "domains" of naming, authority, and specify the organizational basis of these so as to ensure that (measured) effectiveness of secured interworking would not be unnecessarily hindered by distribution. Ok. Thats enough for now; though I have plenty more if it seems the right approach. On re-reading the above, the language has turned out partially statutory, partially explantory. This is proably because my real object is to effectively stimulate action and discussion, rather than to proscribe, or explain. Disagree with anything; I really do not know what I am doing; I'm just trying to make sense of the area's needs. Peter. From bcn Fri Nov 13 03:42:30 1992 Received: from tgo.isi.edu by venera.isi.edu (5.65c/5.65+local-6) id ; Fri, 13 Nov 1992 11:43:48 -0800 Date: Fri, 13 Nov 92 11:42:30 PST Posted-Date: Fri, 13 Nov 92 11:42:30 PST Message-Id: <9211131942.AA26451@tgo.isi.edu> Received: by tgo.isi.edu (4.1/4.0.3-4) id ; Fri, 13 Nov 92 11:42:30 PST From: Clifford Neuman To: ietf-aac Subject: Agenda - BOF on Authorization and Access Control (aac) There will be a second meeting of a BOF on Authorization and Access Control at the November IETF. A description of the BOF follows. FRIDAY, November 20, 1992 9:00-12:00 noon Morning Sessions SEC Authorization and Access Control BOF (aac) (Clifford Neuman/ISI) ************************* *** NOTE: ROOM CHANGE *** ************************* We will be meeting in the Valley Forge room. The at-a-glance sheet to be distributed with the registration packets incorrectly lists the meeting room as Columbia C. Authorization and Access Control Mechanisms for the Internet ------------------------------------------------------------ A BOF has been scheduled to discuss authorization and access control issues for the Internet. At the last meeting of the BOF, the discussion centered around two problems: first, the need for a uniform method for specifying access control information, and second on services and mechanisms for managing authorization in the Internet. At this meeting we will continue the discussion, decide on specific goals and milestones for a new working group to address these problems, and discuss a charter, with a goal of establishing a working group by the Spring IETF. Specifying Access Control Information Several authentication mechanisms are now in place on the Internet. These mechanisms include the use of passwords, simple assertion, network addresses, trust in the identification of users by remote hosts, and stronger methods such such as Kerberos and Digital Equipment Corporation's DASS. Authorization mechanisms are usually application specific and rely on a single authentication method. One possible goal for the group will be to define a common method for use by various applications to specify authorization information. Such an approach might allow the specification of the strength of the authentication method to be used, as well as the identity of the individual. Managing and Distributing Authorization Information The second area in which the group can make a contribution relates to evolving mechanisms and architectures for authorization in distributed systems. Among the methods that were discussed at the last meeting were those used by the Open Software Foundation's Distributed Computing Environment, the Digital Distributed System Security Architecture, restricted proxies and Kerberos, and the European Computer Manufacturers Association standards. A goal of the group will be to look for common characteristics among these mechanisms and to help them work together. The best approach to be taken will be one of the topics of discussion for this meeting. Agenda ------ 1. Discuss strawman of charter (to be distributed at meeting) 1a. Discuss possible goals of the working group - Common mechanism for specifying local access control information - Improving interoperability for distributed authorization mechanisms - Others 1b. Evaluate each in terms of whether sufficient experience exists, or whether we would be premature in our efforts 1c. Select achievable goals and prepare a timetable 1d. Agree on mechanics for preparation and approval of charter. 2. For the goals selected in 1b 2a Discuss approaches and alternatives 2b. Assign work item to prepare strawman 3. For common mechanisms to specify access control information 3a. Discuss strawman (to be distributed at meeting) 4. Any other business 5. Adjourn From bcn Wed Nov 18 23:01:06 1992 Received: from darkstar.isi.edu by venera.isi.edu (5.65c/5.65+local-6) id ; Thu, 19 Nov 1992 07:02:46 -0800 Received: by darkstar.isi.edu (5.65c/5.61+local-9) id ; Thu, 19 Nov 1992 07:01:06 -0800 Date: Thu, 19 Nov 1992 07:01:06 -0800 Message-Id: <199211191501.AA22700@darkstar.isi.edu> From: Clifford Neuman To: ietf-aac Subject: Draft charter for aac working group Please coment on this draft charter. I will be presenting this at the meeting tomorrow. ~ Cliff -- Authorization and Access Control (aac) Charter Chair(s): B. Clifford Neuman, bcn@isi.edu Mailing Lists: General Discussion: ietf-aac@isi.edu To Subscribe: ietf-aac-request@isi.edu Description of Working Group: Several authentication mechanisms are now in place on the Internet. These mechanisms include the use of passwords, simple assertion, network addresses, trust in the identification of users by remote hosts, and stronger methods such such as Kerberos and Digital Equipment Corporation's DASS. Most applications were written with local applications in mind and no guidelines exist for supporting authorization and access control based on the output of such authentication mechanisms. One purpose of the working group will be to provide guidelines for applications making access control decisions where clients might not be local users, might not be members of a common organization, and will often not be registered with the application in advance. To the extent possible, a common API will be developed that allows applications to pass the output of an authentication mechanism, a reference to the object to be accessed, and an indication of the operation to be performed, and that returns an answer that may be easily used by the application. The second, and longer term purpose of the working group will be to example evolving mechanisms and architectures for authorization in distributed systems and to establish criteria which enables interworking of confidence and trust across systems. To the extent possible we will also encourage evolution toward credential formats that more readily allow support for or translation across multiple mechanisms. Goals and Milestones: Dec 1992 Submit charter and milestones for approval. Jan 1992 Agree on access control models to be supported. Identify target applications from which to draw requirements. Mar 1993 Present draft API, continue discussions, and select prototype applications. Identify common characteristics of evolving distributed authorization mechanisms. Begin discussion on how best to encourage interoperability across mechanisms. Jul 1993 Present examples of the use of the API for the selected applications Nov 1993 Submit specification for access control API to IESG From walker@eider.ENET.dec.com Thu Nov 19 00:15:59 1992 Received: from mts-gw.pa.dec.com by venera.isi.edu (5.65c/5.65+local-6) id ; Thu, 19 Nov 1992 08:17:23 -0800 Received: by mts-gw.pa.dec.com; id AA20833; Thu, 19 Nov 92 08:15:56 -0800 Message-Id: <9211191615.AA20833@mts-gw.pa.dec.com> Received: from eider.enet; by decpa.enet; Thu, 19 Nov 92 08:15:59 PST Date: Thu, 19 Nov 92 08:15:59 PST From: Jesse Walker To: bcn Cc: ietf-aac Apparently-To: bcn, ietf-aac Subject: Re: Draft charter for aac working group >> Cliff: >> >> I like most of what the proposed charter says, but I do have a question >> regarding the actual scope and direction of the work. The question was >> raised by the following excerpt from the draft: One purpose of the working group will be to provide guidelines for applications making access control decisions where clients might not be local users, might not be members of a common organization, and will often not be registered with the application in advance. To the extent possible, a common API will be developed that allows applications to pass the output of an authentication mechanism, a reference to the object to be accessed, and an indication of the operation to be performed, and that returns an answer that may be easily used by the application. >> Are there any performance assumptions being made by this approach? Is this >> "common API" intended to be used by the router/network access server >> community as well as for things like remote login or initiating Telnet >> connections? It seems like routers and network access servers would like to >> authenticate links when they are established, and then get something like a >> packet filter to implement the authorization step, based on the results of >> the authentication. That is, different peers might be permitted to pass >> different sorts of packets. It seems to me the type of clients an API >> addresses is really different, as there is no requirement in the general case >> that the authorization step be accomplished in at most a few microseconds in >> the absolute worst case. >> >> The reason I ask is the AAA working group setting network access server >> requirements has expressed a lively interest in applying the results of the >> AAC WG, but I can't see how they can use the API unless is can meet the >> performance requirements any type of routing imposes. >> >> Is there a need to develop at least two models, one for "user level" >> operation, and a second centering on, e.g., packet filters for routers and >> network access servers? Or will the result be, as they say, one size that can >> gracefully fit everyone? >> >> Jesse Walker >> Digital Equipment Corporation >> Networks and Communications >> Littleton, MA >> (508) 486-7326 From bcn Mon Dec 7 06:34:21 1992 Received: from tgo.isi.edu by venera.isi.edu (5.65c/5.65+local-6) id ; Mon, 7 Dec 1992 14:36:12 -0800 Date: Mon, 7 Dec 92 14:34:21 PST Posted-Date: Mon, 7 Dec 92 14:34:21 PST Message-Id: <9212072234.AA25996@tgo.isi.edu> Received: by tgo.isi.edu (4.1/4.0.3-4) id ; Mon, 7 Dec 92 14:34:21 PST From: Clifford Neuman To: ietf-aac Subject: Minutes of DC meeting The minutes for the DC meeting follow. I will be submitting these to Megan Friday Morning. Please send me any additions or corrections, especially if I attributed something to the wrong person, or failed to attribute something I should have. There were a few comments at the meeting that made more sense when discussed in the context of an earlier item. In those cases I move the discussion up, to keep discussion on a particular item together. ~ Cliff --- Minutes of the Authorization and Access Control BOF (AAC) Washington DC IETF November 20, 1992 9:00 AM Chair: Clifford Neuman USC Information Sciences Institute The second meeting of a BOF on Authorization and Access Control met at the November IETF. The purpose of the BOF was to organize a working group to address authorization and access control issues for the Internet. The discussion was centered primarily around two issues: first, development of a charter and milestones for the working group, and second, initial work to develop an application programmer interface (API) supporting authorization. Though not discussed in depth at this meeting, the group is also concerned with mechanisms for distributed authorization on the Internet. The agenda for the meeting was: 1. Discuss strawman of charter (to be distributed at meeting) . Discuss possible goals of the working group - Common mechanism for specifying local access control information - Improving interoperability for distributed authorization mechanisms - Others . Evaluate each in terms of whether sufficient experience exists, or whether we would be premature in our efforts . Select achievable goals and prepare a timetable . Agree on mechanics for preparation and approval of charter. 2. For the goals selected in 1b . Discuss approaches and alternatives . Assign work item to prepare strawman 3. For common mechanisms to specify access control information . Discuss strawman (to be distributed at meeting) 4. Any other business Charter and Goals of the Group A draft charter for the working group was distributed at the meeting. The charter had been sent to the mailing list a day earlier and was made available by FTP for remote participants at the meeting. The first goal of the working group will be to develop a common mechanism for specifying access control information that will work well with distributed authentication mechanisms that are becoming available. The working group will also examine evolving mechanisms and architectures for authorization in distributed systems and to establish criteria that enables interworking of confidence and trust across systems and to encourage the evolution of (or develop ourselves) credential formats that more readily allow support for or translation across multiple mechanisms. A timetable for these deliverables was discussed. There seemed to be agreement that we could move rapidly toward developing a common mechanism for specifying access control information. Clifford Neuman will submit a draft API for discussion prior to the March IETF. By the July IETF we hope to have examples of its use for selected applications, and the goal is to submit the specification of the API to the IESG by next November. There was considerably less agreement on the timetable for work on distributed authorization mechanism. The original timetable was less specific on the timetable for work on distributed authorization mechanism, initially exploring the area, trying not to constrain evolving implementations until more experience is gained. Several attendees, in particular Steve Crocker and Bill Simpson, felt that we should develop our own protocol and credential formats before incompatible mechanisms arise. There was no resolution on this issue, and it will be discussed further at the next meeting. Piers McMahon will submit specifications for DCE authorization, particularly with respect to work on the ECMA authorization model. Clifford Neuman will submit additional information on authorization through restricted proxies. As part of the discussion, a question was raised about whether the output of the group would be a protocol. Our work on the API will not result in a protocol, instead it will yield a common mechanism for making authorization decisions based on authentication information obtained through other protocols (application protocols, and authentication and authorization protocols). Work on distributed authorization mechanisms, however, would result in a protocol or at least a common credential format to be used by other protocols. Even before distributed authorization mechanism are in place the API together with existing authentication protocols (e.g., CAT) would allow the owner of an object on a server supporting our API to specify fine granted access control information allowing access by specific principals not previously registered (in terms of having an account) on the server. During discussion of the API, Piers McMahon suggested that the scope of the API should support the specification of delegated principal identifiers, though the mechanism for delegation would be the subject of subsequent work. Richard Graveman suggested that the mechanism should support the specification of groups. Mechanism to certify membership in groups would be the subject of the distributed authorization work, but the specification of required group membership does belong in any access control list mechanism, and this should be part of the API. Steve Lunt pointed out that the naming of principals is an important issue that must be addressed by the API. Steve Crocker pointed out that the need for a common naming mechanism is a problem that the IAB is aware of, but that we shouldn't expect such a mechanism to be in place soon, we must support the multiple existing mechanisms for now. John Linn pointed out that the GSSAPI exports names tagged with a type and provides a function to compare two names for equality, and that that mechanism may be sufficient for our needs. Piers McMahon asked about the scope of our mechanism. Is it to be Internet specific, or is it to extend beyond the Internet. The answer was that we would like it to be universal, but to the extent that making it so adds complexity or hinders progress we should restrict it to the Internet. In any event, we will look at mechanisms developed in other contexts, including DCE and Posix. Comments on charter should be sent to ietf-aac@isi.edu. After a couple weeks for discussion, the charter will be submitted for approval by Steve Crocker (the security area director) and the IAB. Authentication Requirements After discussion of the charter, Niel Haller spoke about an Internet draft he and Randall Atkinson submitted on Internet Authentication Requirements. The draft discusses authentication requirements and guidelines for different applications. The mechanism covered include simple password mechanisms, non-disclosing passwords, Kerberos, DASS, and CAT. It is not clear which working group is best for discussion of this document. It was felt that in general that this work item fits best under the common authentication technology (CAT) working group and John Linn indicated his willingness to take it on as a separate work item for the CAT group. Some issues, in particular how authentication requirements interact with authorization mechanisms used by particular applications (the login application was presented as an example) should be considered in this group. Niel Haller did not receive many comments when the Internet draft was first submitted to the SAAG list. He will resubmit it to the CAT list in hope that CAT will provide the input required. Authorization and Access Control API The next topic of discussion was an API for access control. A strawman outline was distributed and made available to remote participants. The strawman called for a function: answer = check_acl(id,(object/acl/multiple_acl),operation) and each input and output was discussed. The first item of discussion was the ID structure. In the strawman: id = user and/or group identification from distributed authentication mechanisms and future authorization mechanisms. We should support the passing of multiple identifiers to support user and group and to support ACL entries naming compound principals (i.e. two principals must be present to perform an operation). John Linn suggested that perhaps there should be separate inputs for the clients identity and other authorization credentials. It was felt that this was a bad idea. It was resolved that there should be a single identifier if at all possible, that this identifier might be a GSSAPI security context, and that the security context might need to be extended to include addition information as required. object/acl/multiple_acl = a reference or identifier for the object to be accessed, or a reference to a specific access control list associated with the object. Multiple acl's might be necessary for example if an acl is associated with both a directory and an object within the directory. The topic of discussion here was whether one names an object whose acl is to be checked, or pass the acl itself. In either case there is an abstraction violation. In once case the application must manage ACLs so that they may be passed to the API. In the other case, the code implementing the API many require knowledge about the application. Steve Lunt suggested that the each ACL should be named, and that the application would decide how to map the object into the name of the appropriate ACL. The name of the ACL might be simply the name of the object. If a system wide authorization database is shared by more than one application, it would be important to make sure that no name conflicts arise. operation = a list of those operations to be performed, or more precisely a list of those rights needed to perform the requested operation. The issue here was whether the operation should be passed as input and checked by the API returning a yes/no answer , or whether the API should return the operations allowed and let the application decide. The resolution is that we should support two calls, one that returns the rights and one that checks them returning yes or no. Sam Sjorgen suggested support for VMS/Tops-20 style enabling and disabling of capabilities during the checking of rights. Unfortunately, it is not clear how such a capability would work in a distributed environment. In particular, the rights that are enabled are simply those passed to the server, and checked by the API. Disabled rights would not be visible to the process checking for access. answer = A yes/no response indicating whether the operation is allowed, and optionally a list of restrictions to be applied by the application. Applications that don't require or can't interpret restrictions in a response would not have an authorization database that provides them. Thus if you don't need this functionality, your ACL mechanism doesn't need to support it. If your ACL mechanism does return a restriction that the application can't understand the response will be treated as not authorized. Discussion on this topic centered around the use of restriction. Does the use of restrictions place too great a burden on the application to understand what they mean? Some restrictions, for example time of day, are relatively common and could be interpreted by the code implementing the API, but some are inherently application specific and could not be interpreted by the code implementing the API. Bill Simpson raised the network access server was raised as an example of an application that could use the API. He wants a mechanism that they can put in their boxes. Restrictions for the network access server might be an address mask restricting where a user can connect. John Linn asked what the objects are that are being protected. The answer is network addresses to which one can connect. Clifford Neuman pointed out that the restrictions allow one to specify ACLs for fewer objects. For the same fine-grained control without restrictions, one would specify an ACL for each address (or at least each subnet). With restrictions, one has a single ACL with an application restriction that provides finer grained control. Whether an application choose to use restrictions is a design decision, we should not make the decision for for them. Piers McMahon asked whether we had considered existing APIs for access control. Posix was looked at, but it is not suited to distributed principals not previously registered as users on a system. Piers asked if we had considered the OSF API for access control. The answer was no, since we were not aware of it. Piers will submit a copy of the OSF access control API to the list. To proceed . Comments on the charter should be sent to ietf-aac@isi.edu . The charter will be submitted for approval in the next few weeks . The ACL API will be refined. Discussion will take place on the ietf-aac mailing list. . Addition information on authorization in DCE, ECMA, and using restricted proxies will be submitted to the list by Piers McMahon and Clifford Neuman. A mailing list has been set up, ietf-aac@ISI.EDU. Requests for addition or deletion should be sent to ietf-aac-request@ISI.EDU. From bcn Mon Dec 7 06:36:22 1992 Received: from tgo.isi.edu by venera.isi.edu (5.65c/5.65+local-6) id ; Mon, 7 Dec 1992 14:38:14 -0800 Date: Mon, 7 Dec 92 14:36:22 PST Posted-Date: Mon, 7 Dec 92 14:36:22 PST Message-Id: <9212072236.AA25999@tgo.isi.edu> Received: by tgo.isi.edu (4.1/4.0.3-4) id ; Mon, 7 Dec 92 14:36:22 PST From: Clifford Neuman To: ietf-aac Subject: Proposed charter The proposed charter for an authorization and access control working group follows. Please provide comments. I would like to submit this charter for approbval by early of next week. ~ Cliff --- Authorization and Access Control (aac) Charter Chair(s): B. Clifford Neuman, bcn@isi.edu Mailing Lists: General Discussion: ietf-aac@isi.edu To Subscribe: ietf-aac-request@isi.edu Description of Working Group: Several authentication mechanisms are now in place on the Internet. These mechanisms include the use of passwords, simple assertion, network addresses, trust in the identification of users by remote hosts, and stronger methods such such as Kerberos and Digital Equipment Corporation's DASS. Most applications were written with local applications in mind and no guidelines exist for supporting authorization and access control based on the output of such authentication mechanisms. One purpose of the working group will be to provide guidelines for applications making access control decisions where clients might not be local users, might not be members of a common organization, and will often not be registered with the application in advance. To the extent possible, a common API will be developed that allows applications to pass the output of an authentication mechanism, a reference to the object to be accessed, and an indication of the operation to be performed, and that returns an answer that may be easily used by the application. The second, and longer term purpose of the working group will be to examine evolving mechanisms and architectures for authorization in distributed systems and to establish criteria which enables interworking of confidence and trust across systems. To the extent possible we will also encourage evolution toward credential formats that more readily allow support for or translation across multiple mechanisms. Goals and Milestones: Dec 1992 Submit charter and milestones for approval. Jan 1992 Agree on access control models to be supported. Identify target applications from which to draw requirements. Mar 1993 Present draft API, continue discussions, and select prototype applications. Identify common characteristics of evolving distributed authorization mechanisms. Begin discussion on how best to encourage interoperability across mechanisms. Jul 1993 Present examples of the use of the API for the selected applications Nov 1993 Submit specification for access control API to IESG From bcn Wed Dec 9 05:33:55 1992 Received: from tgo.isi.edu by venera.isi.edu (5.65c/5.65+local-6) id ; Wed, 9 Dec 1992 13:36:15 -0800 Date: Wed, 9 Dec 92 13:33:55 PST Posted-Date: Wed, 9 Dec 92 13:33:55 PST Message-Id: <9212092133.AA00415@tgo.isi.edu> Received: by tgo.isi.edu (4.1/4.0.3-4) id ; Wed, 9 Dec 92 13:33:55 PST From: Clifford Neuman To: ietf-aac Subject: Comments on minutes and charter I have only received one set of comments/corrections to the minutes to date. As they are due Friday I will be submitting them to Megan Friday morning. If you have comments, please get them to be by Thursday evening. I have not received any suggested changes to the charter. As such, I plan to submit the charter to Steve Crocker at the same time. As there is not a hard deadline for submission of the charter, if anyone has comments but won't have time to get them to me by Thursday evening, send me a message telling me they will be forthcoming, and I hold off until you have time to respond. ~ Cliff From bill.simpson@um.cc.umich.edu Wed Dec 9 20:16:47 1992 Received: from vela.acs.oakland.edu by venera.isi.edu (5.65c/5.65+local-6) id ; Thu, 10 Dec 1992 06:04:22 -0800 Received: from Simpson.DialUp.Merit.edu (via.ws04.merit.edu) by vela.acs.oakland.edu with SMTP id AA13979 (5.65c+/IDA-1.4.4); Thu, 10 Dec 1992 09:02:25 -0500 Date: Thu, 10 Dec 92 00:16:47 EDT From: "William Allen Simpson" Message-Id: <832.bill.simpson@um.cc.umich.edu> To: ietf-aac Reply-To: bsimpson@morningstar.com Subject: Re: Comments on minutes and charter > I have only received one set of comments/corrections to the minutes to > date. As they are due Friday I will be submitting them to Megan > Friday morning. If you have comments, please get them to be by > Thursday evening. > The only thing I noticed was "fine granted" should be "fine grained". Actually, the minutes are so much more formal in language than the meeting; I can barely understand the minutes, but thought that I understood the discussion during the meeting. I suppose that terseness requires the dense terminology, but I'm glad I went to the meeting rather than trying to track progress through the minutes. Bill.Simpson@um.cc.umich.edu From bcn Fri Dec 11 01:19:00 1992 Received: from tgo.isi.edu by venera.isi.edu (5.65c/5.65+local-6) id ; Fri, 11 Dec 1992 09:21:21 -0800 Date: Fri, 11 Dec 92 09:19:00 PST Posted-Date: Fri, 11 Dec 92 09:19:00 PST Message-Id: <9212111719.AA01123@tgo.isi.edu> Received: by tgo.isi.edu (4.1/4.0.3-4) id ; Fri, 11 Dec 92 09:19:00 PST From: Clifford Neuman To: ietf-aac, mdavies@cnri.reston.va.us Subject: November IETF: Final Minutes of the AAC BOF Minutes of the Authorization and Access Control BOF (AAC) Washington DC IETF November 20, 1992 9:00 AM Chair: B. Clifford Neuman University of Southern California Information Sciences Institute The second meeting of a BOF on Authorization and Access Control met at the November IETF. The purpose of the BOF was to organize a working group to address authorization and access control issues for the Internet. The discussion was centered primarily around two issues: first, development of a charter and milestones for the working group, and second, initial work to develop an application programmer interface (API) supporting authorization. Though not discussed in depth at this meeting, the group is also concerned with mechanisms for distributed authorization on the Internet. The agenda for the meeting was: 1. Discuss strawman of charter (to be distributed at meeting) . Discuss possible goals of the working group - Common mechanism for specifying local access control information - Improving interoperability for distributed authorization mechanisms - Others . Evaluate each in terms of whether sufficient experience exists, or whether we would be premature in our efforts . Select achievable goals and prepare a timetable . Agree on mechanics for preparation and approval of charter. 2. For the goals selected in 1b . Discuss approaches and alternatives . Assign work item to prepare strawman 3. For common mechanisms to specify access control information . Discuss strawman (to be distributed at meeting) 4. Any other business Charter and Goals of the Group A draft charter for the working group was distributed at the meeting. The charter had been sent to the mailing list a day earlier and was made available by FTP for remote participants at the meeting. The first goal of the working group will be to develop a common mechanism for specifying access control information that will work well with distributed authentication mechanisms that are becoming available. The working group will also examine evolving mechanisms and architectures for authorization in distributed systems and to establish criteria that enable interworking of confidence and trust across systems and to encourage the evolution of (or develop ourselves) credential formats that more readily allow support for or translation across multiple mechanisms. A timetable for these deliverables was discussed. There seemed to be agreement that we should move rapidly toward developing a common mechanism for specifying access control information. Clifford Neuman will submit a draft API for discussion prior to the March IETF. By the July IETF we hope to have examples of its use for selected applications, and the goal is to submit the specification of the API to the IESG by next November. There was considerably less agreement on the timetable for work on distributed authorization mechanisms. The original timetable was less specific for work on distributed authorization mechanisms, initially exploring the area, trying not to constrain evolving implementations until more experience is gained. Several attendees, in particular Steve Crocker and Bill Simpson, felt that we should develop our own protocol and credential formats before incompatible mechanisms arise. There was no resolution on this issue, and it will be discussed further at the next meeting. Piers McMahon will submit specifications for DCE authorization, particularly with respect to proposed enhancements from SESAME for DCE. Clifford Neuman will submit additional information on authorization through restricted proxies. As part of the discussion, a question was raised about whether the output of the group would be a protocol. Our work on the API will not result in a protocol, instead it will yield a common mechanism for making authorization decisions based on authentication information obtained through other protocols (application protocols, and authentication and authorization protocols). The work on distributed authorization mechanisms, however, would result in a protocol or at least a common credential format to be used by other protocols. Even before distributed authorization mechanism are in place the API together with existing authentication protocols (e.g., CAT) would allow the retrieval and evaluation of fine grained access control information allowing access by specific principals not previously registered (in terms of having an account) on a server. During discussion of the API, Piers McMahon suggested that the scope of the API should support the specification of delegated principal identifiers, though the mechanism for delegation would be the subject of subsequent work. Richard Graveman suggested that the mechanism should support the specification of groups. Mechanism to certify membership in groups would be the subject of the distributed authorization work, but the specification of required group membership does belong in any access control list mechanism, and this should be part of the API. Steve Lunt pointed out that the naming of principals is an important issue that must be addressed by the API. Steve Crocker pointed out that the need for a common naming mechanism is a problem that the IAB is aware of, but that we shouldn't expect such a mechanism to be in place soon, we must support the multiple existing mechanisms for now. John Linn pointed out that the GSSAPI exports names tagged with a type and provides a function to compare two names for equality, and that that mechanism may be sufficient for our needs. Piers McMahon asked about the scope of our mechanism. Is it to be Internet specific, or is it to extend beyond the Internet? The answer was that we would like it to be universal, but to the extent that making it so adds complexity or hinders progress we should restrict it to the Internet. In any event, we will look at mechanisms and APIs developed in other contexts, including DCE and Posix. Comments on charter should be sent to ietf-aac@isi.edu. After a couple weeks for discussion, the charter will be submitted for approval by Steve Crocker (the security area director) and the IAB. Authentication Requirements After discussion of the charter, Neil Haller spoke about an Internet draft he and Randall Atkinson submitted on Internet Authentication Requirements. The draft discusses authentication requirements and guidelines for different applications. The mechanisms covered include simple password mechanisms, non-disclosing passwords, Kerberos, DASS, and CAT. It is not clear which working group is best for discussion of this document. It was felt that in general that this work item fits best under the common authentication technology (CAT) working group and John Linn indicated his willingness to take it on as a separate work item for the CAT group. Some issues, in particular how authentication requirements interact with authorization mechanisms used by particular applications (the login application was presented as an example) should be considered in this (AAC) group. Neil Haller did not receive many comments when the Internet draft was first submitted to the INET-AUTH list. He will resubmit it to the CAT list in hope that CAT will provide the input required. Authorization and Access Control API The next topic of discussion was an API for access control. A strawman outline was distributed and made available to remote participants. The strawman called for a function: answer = check_acl(id,(object/acl/multiple_acl),operation) and each input and output was discussed. The first item of discussion was the ID structure. In the strawman: id = user and/or group identification from distributed authentication mechanisms and future authorization mechanisms. We should support the passing of multiple identifiers to support user and group and to support ACL entries naming compound principals (i.e. two principals must be present to perform an operation). John Linn suggested that perhaps there should be separate inputs for the clients identity and other authorization credentials. It was felt that this was a bad idea. It was resolved that there should be a single identifier if at all possible, that this identifier might be a GSSAPI security context, and that the security context might need to be extended to include addition information as required. object/acl/multiple_acl = a reference or identifier for the object to be accessed, or a reference to a specific access control list associated with the object. Multiple acl's might be necessary for example if an acl is associated with both a directory and an object within the directory. The topic of discussion here was whether one names an object whose acl is to be checked, or pass the acl itself. In either case there is an abstraction violation. In one case the application must manage ACLs so that they may be passed to the API. In the other case, the code implementing the API many require knowledge about the application. Steve Lunt suggested that the each ACL should be named, and that the application would decide how to map the object into the name of the appropriate ACL. The name of the ACL might be simply the name of the object. If a system wide authorization database is shared by more than one application, it would be important to make sure that no name conflicts arise. operation = a list of those operations to be performed, or more precisely a list of those rights needed to perform the requested operation. The issue here was whether the operation should be passed as input and checked by the API returning a yes/no answer , or whether the API should return the operations allowed and let the application decide. The resolution is that we should support two calls, one that returns the rights and one that checks them returning yes or no. Sam Sjorgen suggested support for VMS/Tops-20 style enabling and disabling of capabilities during the checking of rights. Unfortunately, it is not clear how such a capability would work in a distributed environment. In particular, the rights that are enabled are simply those passed to the server, and checked by the API. Disabled rights would not be visible to the process checking for access. answer = A yes/no response indicating whether the operation is allowed, and optionally a list of restrictions to be applied by the application. Applications that don't require or can't interpret restrictions in a response would not have an authorization database that provides them. Thus if you don't need this functionality, your ACL mechanism doesn't need to support it. If your ACL mechanism does return a restriction that the application can't understand the response will be treated as not authorized. Discussion on this topic centered around the use of restrictions. Does the use of restrictions place too great a burden on the application to understand what they mean? Some restrictions, for example time of day, are relatively common and could be interpreted by the code implementing the API, but some are inherently application specific and could not be interpreted by the code implementing the API. Bill Simpson raised the network access server as an example of an application that could use the API. He wants a mechanism that they can put in their boxes. Restrictions for the network access server might be an address mask restricting where a user can connect. John Linn asked what the objects are that are being protected. The answer is network addresses to which one can connect. Clifford Neuman pointed out that the restrictions allow one to specify ACLs for fewer objects. For the same fine-grained control without restrictions, one would specify an ACL for each address (or at least each subnet). With restrictions, one has a single ACL with an application restriction that provides finer grained control. Whether an application choose to use restrictions is a design decision, we should not make the decision for them. Piers McMahon asked whether we had considered existing APIs for access control. Posix was looked at, but it is not suited to distributed principals not previously registered as users on a system. Piers asked if we had considered the OSF API for access control. The answer was no, since we were not aware of it. Conditioned on obtaining OSF approval to do so, Piers will submit a copy of the OSF access control API to the list. To proceed . Comments on the charter should be sent to ietf-aac@isi.edu . The charter will be submitted for approval in the next few weeks . The ACL API will be refined. Discussion will take place on the ietf-aac mailing list. . Addition information on authorization in DCE, ECMA, and using restricted proxies will be submitted to the list by Piers McMahon and Clifford Neuman. A mailing list has been set up, ietf-aac@ISI.EDU. Requests for addition or deletion should be sent to ietf-aac-request@ISI.EDU. From P.V.McMahon@rea0803.wins.icl.co.uk Wed Feb 24 22:28:10 1993 Received: from relay.pipex.net by venera.isi.edu (5.65c/5.65+local-8) id ; Wed, 24 Feb 1993 14:31:00 -0800 X400-Received: by mta relay.pipex.net in /PRMD=pipex/ADMD=cwmail/C=GB/; Relayed; Wed, 24 Feb 1993 22:29:40 +0000 X400-Received: by /PRMD=icl/ADMD=gold 400/C=GB/; converted (ia5 text (2)); Relayed; Wed, 24 Feb 1993 22:28:10 +0000 Date: Wed, 24 Feb 1993 22:28:10 +0000 X400-Originator: P.V.McMahon@rea0803.wins.icl.co.uk X400-Recipients: ietf-aac@isi.edu X400-Mts-Identifier: [/PRMD=icl/ADMD=gold 400/C=GB/;rea0803 0000016300004803] Original-Encoded-Information-Types: undefined (0) X400-Content-Type: P2-1984 (2) Content-Identifier: 4803 Priority: Urgent From: P.V.McMahon@rea0803.wins.icl.co.uk Message-Id: <"4803*/I=PV/S=McMahon/OU=rea0803/O=icl/PRMD=icl/ADMD=gold 400/C=GB/"@MHS> To: ietf-aac Subject: AAC Input documents AAC: As actioned at the last IETF, I am making some DCE and SESAME (and POSIX) background documentation available as input to the initial activities of the WG. The DCE documentation is copied with the permission of OSF for the purposes of this group's work on authorisation APIs. For convenience, it is lifted from the man pages of our DCE1.0.1. These files are available by anonymous ftp from /pub/aac on prospero.isi.edu. The document references and file sizes follow. All are in ASCII. dce_acl_api.txt "Specification of DCE1.0 ACL APIs" OSF (167720 bytes) pos_sec_framework.txt "A Distributed Security Framework for POSIX (NOV92)" POSIX (82408 bytes) ses_dce_enh_overview.txt An overview of proposed security enhancements for DCE1.1 (SEP92) SESAME (17808 bytes) ses_dce_enh.txt DCE-RFC 19: Proposed security enhancments for DCE1.1 (DEC92) SESAME (81228 bytes) Regards, Piers ------------------------------------------------------- Piers McMahon 24FEB93 Open Distributed Processing, 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 ------------------------------------------------------- From P.V.McMahon@rea0803.wins.icl.co.uk Fri Feb 26 19:21:55 1993 Received: from relay.pipex.net by venera.isi.edu (5.65c/5.65+local-8) id ; Fri, 26 Feb 1993 11:23:59 -0800 X400-Received: by mta relay.pipex.net in /PRMD=pipex/ADMD=cwmail/C=GB/; Relayed; Fri, 26 Feb 1993 19:22:44 +0000 X400-Received: by /PRMD=icl/ADMD=gold 400/C=GB/; converted (ia5 text (2)); Relayed; Fri, 26 Feb 1993 19:21:55 +0000 Date: Fri, 26 Feb 1993 19:21:55 +0000 X400-Originator: P.V.McMahon@rea0803.wins.icl.co.uk X400-Recipients: ietf-aac@isi.edu X400-Mts-Identifier: [/PRMD=icl/ADMD=gold 400/C=GB/;rea0803 0000016300004843] Original-Encoded-Information-Types: undefined (0) X400-Content-Type: P2-1984 (2) Content-Identifier: 4843 Priority: Urgent From: P.V.McMahon@rea0803.wins.icl.co.uk Message-Id: <"4843*/I=PV/S=McMahon/OU=rea0803/O=icl/PRMD=icl/ADMD=gold 400/C=GB/"@MHS> To: ietf-aac Subject: AAC Input documents AAC: I have made an additional SESAME document available as input to the WG. This file is available by anonymous ftp from /pub/aac on prospero.isi.edu. The document reference and file size follows. It is in ASCII. ses_intro.txt SESAME: An introduction - describes SESAME architecture (FEB93) (105975 bytes) Regards, Piers ------------------------------------------------------- Piers McMahon 26FEB93 Open Distributed Processing, 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 ------------------------------------------------------- From dcrocker@Mordor.Stanford.EDU Mon Mar 8 02:46:25 1993 Received: from Mordor.Stanford.EDU by venera.isi.edu (5.65c/5.65+local-8) id ; Mon, 8 Mar 1993 10:46:27 -0800 Received: from localhost by Mordor.Stanford.EDU (5.65/inc-1.0) id AA01461; Mon, 8 Mar 93 10:46:26 -0800 Message-Id: <9303081846.AA01461@Mordor.Stanford.EDU> To: Clifford Neuman Cc: Internet Engineering Steering Group , iab, ietf-aac Subject: Re: WG REVIEW: Authorization and Access Control (aac) Org: The Branch Office, Sunnyvale CA Phone: +1 408 246 8253; fax: +1 408 249 6205 In-Reply-To: Your message of Mon, 08 Mar 93 12:57:48 -0500. <9303081257.aa21034@IETF.CNRI.Reston.VA.US> Date: Mon, 08 Mar 93 10:46:25 -0800 From: Dave Crocker X-Mts: smtp Clifford (et al), Stylistic note on charter: The IETF Secretariat tends to use the first paragraph of a charter as the summary. You might want to put less background and more of your intent into that paragraph. Content: The charter describes 4 activities, but only 2 deliverables. The activities are 1) discussion about guidelines, 2) API definitions, 3) develop additional goals and milestone, 4) a study of evolving mechanisms, etc. The deliverables are a) an API spec, and b) more goals & milestones. While I suspect that the first activity could produce and interesting an useful report on guidelines, none is promised. I suggest you add it. The API spec, first draft, is shown as coming out almost immediately. If it isn't already floating around as a draft, or is otherwise a trivial exercise, I'd be surprised if you hit your schedule. Also, having 9 months between milestones is risky. People lose concentration. The additional acitivities and deliverables really sound to me as if they are a new/different working group. (I tend toward fanaticism in believing that working groups should be very highly focussed, so you are likely to get different views from other steering group members.) Dave From gvaudre@CNRI.Reston.VA.US Mon Mar 8 07:57:48 1993 Received: from IETF.nri.reston.VA.US (IETF.CNRI.RESTON.VA.US) by venera.isi.edu (5.65c/5.65+local-8) id ; Mon, 8 Mar 1993 17:10:48 -0800 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa21034; 8 Mar 93 12:57 EST Mime-Version: 1.0 Content-Type: text/plain; Charset="us-ascii" X-Org: Corp. for National Research Initiatives X-Phone: (703) 620-8990 ; Fax: (703) 620-0913 To: Internet Engineering Steering Group Cc: iab Cc: ietf-aac Subject: WG REVIEW: Authorization and Access Control (aac) Date: Mon, 08 Mar 93 12:57:48 -0500 From: Greg Vaudreuil Message-Id: <9303081257.aa21034@IETF.CNRI.Reston.VA.US> This is a re-send of the AAC charter, proposed as a Working Group in the Security Area. (It seems to not have made it the first time) Please review and comment upon this before March 19th. Greg V. Authorization and Access Control (aac) Charter Chair(s): Clifford Neuman Security Area Director(s) Steve Crocker Mailing lists: General Discussion:ietf-aac@isi.edu To Subscribe: ietf-aac-request@isi.edu Archive: prospero.isi.edu:~/pub/acc/* Description of Working Group: Several authentication mechanisms are now in place on the Internet. These mechanisms include the use of passwords, simple assertion, network addresses, trust in the identification of users by remote hosts, and stronger methods such such as Kerberos and Digital Equipment Corporation's DASS. Most applications were written with local applications in mind and no guidelines exist for supporting authorization and access control based on the output of such authentication mechanisms. The initial focus of the working group will be to provide guidelines for applications making access control decisions where clients might not be local users, might not be members of a common organization, and will often not be registered with the application in advance. The working group will develop a common API that accepts the output of an authentication mechanism (for example, the output of the gssapi), a reference to the object to be accessed, and optionally an indication of the operation to be performed. The API will return a list of authorized operations or a yes/no answer that can be easily used by the application. The second, and longer term purpose of the working group will be to examine evolving mechanisms and architectures for authorization in distributed systems and to establish criteria which enable interworking of confidence and trust across systems. The working group will develop additional goals an milestones related to this purpose and will submit a revised charter once the appropriate goals and milestones are determined. To the extent possible this additional work will encourage evolution toward credential formats that more readily allow support for or translation across multiple mechanisms. Goals and Milestones: Done Submit Charter and milestones for approval. Mar 93 Meet at the Columbus IETF to identify common characteristics of evolving distributed authorization mechanisms and begin discussion of approaches for interoperability across mechanisms. Apr 93 Post draft API as an Internet Draft. Jan 94 Submit the AAC API to the IESG for consideration as an experimental RFC. From pgross@ans.net Thu Mar 11 05:55:54 1993 Received: from interlock.ans.net by venera.isi.edu (5.65c/5.65+local-8) id ; Thu, 11 Mar 1993 07:55:20 -0800 Received: by interlock.ans.net id AA03752 (InterLock SMTP Gateway 1.1); Thu, 11 Mar 1993 10:54:30 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 11 Mar 1993 10:54:30 -0500 X-Mailer: InterCon TCP/Connect II 1.1b37 Message-Id: <9303111055.AA54850@anomolocaris.ans.net> Date: Thu, 11 Mar 1993 10:55:54 -0500 From: Phill Gross To: ietf-aac, Internet Engineering Steering Group , iab Subject: Re: WG REVIEW: Authorization and Access Control (aac) > Authorization and Access Control (aac) Steve Crocker, Clifford, How is this related to the CAT and IPSEC WGs? There were several WGs proposed at about the same time that dealt with the structure, storage, retrieval, and usage of "information". Joyce, Russ, and I decided to spend some time to make sure these different WGs worked well together within an overall "information architecture". There was some minor hassle in getting it all together and getting it right, but I think the effort was well worth it. One result was a 1-2 page summary of what the overall goals were for an "information architecture", and how the various WGs were working in a coordinated fashion to pursue those goals. Can we do the same here? Can we take the AAC WG, CAT, IPSEC, and the folks interested in FTP security, and make sure that they fit into an overall "security architecture"? Could someone write down a 1-2 page summary of what we'd like to see in a "security architecture", and how these various WGs are working together to pursue it? (Greg, could you resend the CAT and IPSEC charters for reference? It would be especially interesting to see the CAT goals and milestones. thanks.) > Several authentication mechanisms are now in place on the Internet. For us non-security jocks -- Is there a difference between "authentication" and "authorization and access control" (which is the name of this WG. There is another WG with "authentication" in its name - CAT). > .... no guidelines exist ... > > The initial focus of the working group will be to provide guidelines ... Will the focus of the WG be defining an API or defining "guidelines" (or are these the same thing??) > The > working group will develop a common API that accepts the output of an > authentication mechanism (for example, the output of the gssapi), a > reference to the object to be accessed, and optionally an indication of > the operation to be performed. The API will return a list of > authorized operations or a yes/no answer that can be easily used by the > application. This is probably a naive question, but ... will an API be useful without defining the underlying process? Will you also be defining the underlying process (for at least some of the common authentication mechanisms)? Who will define the underlying process if this WG doesn't? (Would that be required of all future designers of authentication mechanisms, much like we now ask for MIBs for all protocols?) > The second, and longer term purpose of the working group will be to > examine evolving mechanisms and architectures for authorization in > distributed systems Is this goal to be after the Jan 94 milestone of publishing the API paper? That seems pretty far out. Could it be pursued in parallel now by a second WG? > Apr 93 Post draft API as an Internet Draft. > > Jan 94 Submit the AAC API to the IESG for consideration as an > experimental April seems pretty optimistic for a new docment. Does a draft already exist? Are there no intermediate milestones between April and Jan 94? Phill From kent@BBN.COM Mon Mar 15 09:11:36 1993 Received: from CCV1.BBN.COM by venera.isi.edu (5.65c/5.65+local-8) id ; Mon, 15 Mar 1993 11:11:53 -0800 Message-Id: <199303151911.AA18120@venera.isi.edu> To: Phill Gross Cc: ietf-aac, Internet Engineering Steering Group , iab Subject: Re: WG REVIEW: Authorization and Access Control (aac) Date: Mon, 15 Mar 93 14:11:36 -0500 From: Steve Kent Phill, I have not seen a response from Steve Crocker or Cliff, so I thought I'd take a stab at some of the questions you raise. Could someone write down a 1-2 page summary of what we'd like to see in a "security architecture", and how these various WGs are working together to pursue it? The PSRG, of which Cliff is a member, is working on an Internet security architecture document, but it is slow going. It may be possible to have a more narrowly focused, 1-2 page document addressing the subset of the architecture issues here, but it won't be easy and it may not be possible yet. For us non-security jocks -- Is there a difference between "authentication" and "authorization and access control" (which is the name of this WG. There is another WG with "authentication" in its name - CAT). "Authentication" deals with verifying the claimed identity of an entity (person, process, device). "Authorization" or "access control" deals with enforcing a security policy which characterizes what privileges an entity has with regard to a resource. The results of an authentication procedure are often used an input to authorization or access control mechanisms. This is probably a naive question, but ... will an API be useful without defining the underlying process? Will you also be defining the underlying process (for at least some of the common authentication mechanisms)? Who will define the underlying process if this WG doesn't? (Would that be required of all future designers of authentication mechanisms, much like we now ask for MIBs for all protocols?) In the case of CAT, the API work was performed after underlying mechanisms had been developed, but it could be done the other way too. I think there are sufficient examples of authentication and access control mechanisms for the WG to avoid the pitfall of developing an unimplementable or grossly inefficient API. Steve From pgross@ans.net Mon Mar 15 18:03:47 1993 Received: from interlock.ans.net by venera.isi.edu (5.65c/5.65+local-8) id ; Mon, 15 Mar 1993 20:01:52 -0800 Received: by interlock.ans.net id AA29823 (InterLock SMTP Gateway 1.1); Mon, 15 Mar 1993 23:01:02 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 15 Mar 1993 23:01:02 -0500 X-Mailer: InterCon TCP/Connect II 1.1b37 Message-Id: <9303152303.AA47824@pgmac11si.home.ans.net> Date: Mon, 15 Mar 1993 23:03:47 -0500 From: Phill Gross To: Steve Kent Cc: ietf-aac, Internet Engineering Steering Group , iab Subject: Re: WG REVIEW: Authorization and Access Control (aac) > I have not seen a response from Steve Crocker or Cliff, so I > thought I'd take a stab at some of the questions you raise. > > Could someone write down a 1-2 page summary of what we'd like > to see in a "security architecture", and how these various > WGs are working together to pursue it? > > The PSRG, of which Cliff is a member, is working on an Internet > security architecture document, but it is slow going. It may be > possible to have a more narrowly focused, 1-2 page document addressing > the subset of the architecture issues here, but it won't be easy and it > may not be possible yet. SteveK, Thanks for the response. Its very helpful. However, I still have a few boneheaded questions. (Please, remember the spirit of these questions. We are trying to raise the bar a bit on new WGs, and I am trying to play a constructive devil's advocate.) I can well understand that a "security architecture" is a large undertaking, and I'm sure the very notion must both excite and scare the hell out of the security community. But, I'm not necessarily looking for a "security architecture" (especially in 1-2 pages). What I would like to see some sort of overview that addresses the overall goals of these WGs are and how they are working together to solve these goals in some coordinated fashion. That is, are these WGs part of a master plan, or are we just firing buckshot at the problems? I guess my concern is -- how can we be sure we are heading in the right direction if we can't write down a 1-2 page overview of what we think we are doing?? Perhaps what I am really looking for is a security area "plan"? Should we bring the SAAG and/or PSRG into this discussion? Phill From bcn Thu Mar 25 05:07:33 1993 Received: from tgo.isi.edu by venera.isi.edu (5.65c/5.65+local-8) id ; Thu, 25 Mar 1993 13:07:38 -0800 Date: Thu, 25 Mar 93 13:07:33 PST Posted-Date: Thu, 25 Mar 93 13:07:33 PST Message-Id: <9303252107.AA08455@tgo.isi.edu> Received: by tgo.isi.edu (4.1/4.0.3-4) id ; Thu, 25 Mar 93 13:07:33 PST From: Clifford Neuman To: pgross@ans.net, dcrocker@mordor.stanford.edu Cc: ietf-aac, iesg@ietf.cnri.reston.va.us, iab Subject: WG REVIEW: Authorization and Access Control (aac) I have revised the aac charter slightly based on Phill and Dave's comments. The revised charter follows this message. I think that the new charter more clearly indicates the relationship between the CAT and AAC working groups, though it doesn't attempt to provide a tutorial on why authentication and access control are different. It also include several intermediate milestones, some of which were there when I sent the charter to Greg, but which he removed to make things easier to track. It seems that some of you want more detail in the milestone and some less. I can go either way, but please decide. As to the longer term purpose of the working group, the work on distributed authorization and the guidelines and API are closely related, so I think the two belong together in the same group. The work on the guidelines and API should help to determine what those goals should be. It is a little too early to define those goals yet, and that is why the goals with respect to distributed authorization mechanisms are presently only to better define what they should be. Finally, as to attempting to come up with a two page summary of how all the groups in the security area fit together, I think that that is a job for the SAAG, of which I am a member. However, I would prefer to have someone else take the lead on that, instead of my spending too much time on meta-issues. I'd rather get to work on achieving the goals of the AAC working group. -- Authorization and Access Control (aac) Charter Chair: B. Clifford Neuman, bcn@isi.edu Security Area Director: Steve Crocker, crocker@tis.com Mailing Lists: General Discussion: ietf-aac@isi.edu To Subscribe: ietf-aac-request@isi.edu Archive: files in /pub/aac on prospero.isi.edu Description of Working Group: The goal of the working group on authroization and access control is to develop guidelines and an application programmer interface (API) through which network accessible applications can uniformly specify access control information. This API will allow applications to make access control decisions when clients are not local users, might not be members of a common organization, and often not known to the service or application in advance. Several authentication mechanisms are in place on the Internet, but most applications are written with local applications in mind and no guidelines exist for supporting authorization and access control based on the output of such authentication mechanisms. The CAT working group developed the GSSAPI, a common API to support authentication. The AAC working group will develop a common API that accepts the identity of a client (perhaps the output of the GSSAPI), a reference to an object to be accessed, and optionally an indication of the operation to be performed. The API will return a list of authorized operations or a yes/no answer that can be easily used by the application. A second, and longer term purpose of the working group will be to examine evolving mechanisms and architectures for authorization in distributed systems and to establish criteria which enable interworking of confidence and trust across systems. The working group will develop additional goals an milestones related to this purpose and will submit a revised charter once the appropriate goals and milestones are determined. To the extent possible this additional work will encourage evolution toward credential formats that more readily allow support for or translation across multiple mechanisms. Goals and Milestones: Done Submit Charter and milestones for approval. Mar 1993 Meet at the Columbus IETF meeting. Identify common characteristics of evolving distributed authorization mechanisms. Begin discussion on how best to encourage interoperability across mechanisms. May 1993 Release draft guidelines for authroization and access control for network accessible applications. May 1993 Release draft API as an internet draft. Aug 1993 Release revised internet draft and demonstrating examples of the use of the API for selected applications. Aug 1993 Submit revised guidelines document to the IESG for consideration as an informational RFC. Aug 1993 Revised working group charter to address interoperability of distributed authorization mechanisms. Nov 1993 Modify API based on implementation experience and release as a revised internet draft. Jan 1994 Submit specification for access control API to the IESG for consideration as an experimental RFC. From bcn Thu Mar 25 06:44:24 1993 Received: from tgo.isi.edu by venera.isi.edu (5.65c/5.65+local-8) id ; Thu, 25 Mar 1993 14:44:28 -0800 Date: Thu, 25 Mar 93 14:44:24 PST Posted-Date: Thu, 25 Mar 93 14:44:24 PST Message-Id: <9303252244.AA08557@tgo.isi.edu> Received: by tgo.isi.edu (4.1/4.0.3-4) id ; Thu, 25 Mar 93 14:44:24 PST From: Clifford Neuman To: kerberos@mit.edu, ietf-aac Subject: Final version of paper on restricted proxies The final version of my paper on proxy based authorization and accounting is available from prospero.isi.edu in the directory /pub/papers/security/pbaa.ps.Z. This is a revision of the proxy paper that appeared as a University of Washington technical report and it will be presented at the International Conference on Distributed Computing Systems in May. This paper describes restricted proxies, and range of authorization mechanisms that can be implemented using restricted proxies. It discussed how restricted proxies can be implemented using existing authentication methods, and particularly, how the authorization data field in Kerberos version 5 is intended to be used. ~ Cliff From bcn Sat Mar 27 02:23:31 1993 Received: from tgo.isi.edu by venera.isi.edu (5.65c/5.65+local-8) id ; Sat, 27 Mar 1993 10:23:35 -0800 Date: Sat, 27 Mar 93 10:23:31 PST Posted-Date: Sat, 27 Mar 93 10:23:31 PST Message-Id: <9303271823.AA10133@tgo.isi.edu> Received: by tgo.isi.edu (4.1/4.0.3-4) id ; Sat, 27 Mar 93 10:23:31 PST From: Clifford Neuman To: ietf-aac Subject: Proposed agenda for AAC BOF Authorization and Access Control BOF (aac) WEDNESDAY, March 31, 1993 4:00-6:00 pm Afternoon Sessions II SEC Authorization and Access Control BOF (aac) (Cliff Neuman/ISI) - Review aac charter as submitted to IESG for review (30 min) - Review strawman access control API from last meeting in light (45 minutes) of the DCE and Sesame documents made available by Piers McMahon - Identify common characteristics of evolving distributed authorization mechanisms (DCE, Sesame, Proxies). Begin discussion on how best to encourage interoperability across mechanisms. (30 minutes) - Assign work items to generate access control API internet draft, (15 minutes) and other items to be accomplished before the Amsterdam IETF. From bcn Thu Apr 8 13:30:15 1993 Received: from tgo.isi.edu by venera.isi.edu (5.65c/5.61+local-12) id ; Thu, 8 Apr 1993 20:30:27 -0700 Date: Thu, 8 Apr 93 20:30:15 PDT Posted-Date: Thu, 8 Apr 93 20:30:15 PDT Message-Id: <9304090330.AA25703@tgo.isi.edu> Received: by tgo.isi.edu (4.1/4.0.3-4) id ; Thu, 8 Apr 93 20:30:15 PDT From: Clifford Neuman To: ietf-aac Subject: Draft minutes for Columbus AAC BOF The following is a draft of the minutes of the AAC BOF. Please comment. Especially if you feel I left something out, failed to attribute something to someone that I should have, or missattributed or misrepresented someone's position on anything. Please provide comments by Wednesday April 14th after which I will submit the final version. ~ Cliff --- Minutes of the Authorization and Access Control BOF (AAC) Columbus OH IETF March 31, 1993 4:00PM Chair: B. Clifford Neuman University of Southern California Information Sciences Institute The third meeting of a BOF on Authorization and Access Control met at the March IETF. This should be the last meeting as a BOF since the charter had already been submitted to the IESG and is currently under review. The agenda for the meeting was: 1. Review the AAC charter as submitted to IESG for review 2. Identify common characteristics of evolving distributed authorization mechanisms and begin discussion on how best to encourage interoperability across mechanisms. 3. Review the authorization API from last meeting in light of the DCE and Sesame documents made available by Piers McMahon, and considering characteristics identified in (2). 4. Assign work items to generate access control API internet draft, and other items to be accomplished before the Amsterdam IETF. The draft charter, past minutes, mailing-list discussions, and other documents mentioned in these minutes are available by anonymous FTP from prospero.isi.edu in the directory /pub/aac. . Review of charter The working group charter discussed at the previous meeting was submitted to the IESG for approval. Based on several comments from IESG members the charter was revised to make the relationship with other working groups clearer. A new version was provided to the IESG and distributed to the AAC mailing list. Everyone at the meeting seemed comfortable with the revised charter and no additional changes were suggested. The charter is once again in the hands of the IESG, which seems reluctant to form new groups without understanding the big-picture of how all the groups in an area fit together. Steve Crocker, the area director, will provide the IESG with such a statement. . Evolving distributed authorization mechanisms The goal of distributed authorization mechanisms is to allow authorization decisions to be made by an entity other than the end-system. This is useful when a principal can perform the same operations on a large number of end-systems. Instead of duplicating the authorization database, it can be maintained in one place, easing update. Evolving mechanisms for distributed authorization were discussed, including DCE, ECMA/Sesame, and restricted proxies (Kerberos V5). In each of these mechanisms, a certificate grants privileges to a principal, either by explicitly enumerating privileges, or by restricting privileges. Positive privileges are represented in the latter case as the set of rights available to the issuer of the certificate which are not explicitly restricted. Clifford Neuman argued that the restricted forms of credentials are more general since they allow the addition of restrictions during delegation, and also because the rights of the issuer of a certificate naturally limit what can be granted, rather than requiring a separately maintained list of which principals are authorized to grant particular privileges. Piers McMahon and John Linn suggested that the term restriction is a confusing term for permission. It also wasn't clear to them how one could compose privileges from different sources. Cliff responded that the permissions are granted by certificates which provide all rights possessed by the signer and that the restrictions apply to what is granted by a particular certificate, limiting the permissions. By providing multiple certificates one gets a sum of products; i.e. the sum of the remaining rights from each of the restricted certificates. It would improve interoperability across mechanisms if there were a common set of restrictions or privileges. This would make it easier to translate from one mechanism to another (i.e. the translation would be syntactic, rather than semantic). Clifford Neuman will compile a list of restrictions sufficient to represent privileges supported by DCE, Sesame, restricted proxies, and any other mechanisms brought to our attention. He will also accept input from application developers on the restrictions and privileges they require. Submissions can be in either form, restrictions or permissions. They will be represented as restrictions in the compiled list (the representation may be reconsidered later). Example permissions/restrictions: DCE: a way of specifying global userID and groups the user is in DCE: optional restrictions NAS: a way of restricting the subnets to which a user may connect Sesame: a way to represent each of its privilege attributes Others: roles 3. Authorization API (and more) The working group began refining the strawman ACL API presented at the Washington IETF. There is more than just an API involved. In particular, it will be necessary to define the authorization information that can be stored. The API will be designed to allow easy integration with distributed authorization methods, including support for the specification of restrictions on ACL entries. Ted Ts'o suggested that since the API is not restricted to what people normally think of as ACLs, that we should call it an Authorization API, rather than an ACL API. This change in terminology was adopted. The group started to define the input and output arguments to the API. To set the stage for this discussion Piers McMahon and Clifford Neuman described the anticipated flow of control for the end-server. When a request is received, calls are made to the GSSAPI or other authentication routines. The output of the GSSAPI is a security context which contains information about the client. This might then be passed into additional function to verify authorization credentials. The distributed authorization mechanisms might instead be handled as part of the GSSAPI itself. The output of the combined GSSAPI and distributed authorization functions will be a security context which is fed into the authorization API. For simplicity at this point in the discussion, the authorization API will return a yes/no answer indicating whether a particular operation is allowed. We need to define what needs to be part of the security context, an input to the authorization API. It might then be possible to extend the GSSAPI security context definition so that it can be used directly. The diagram below shows the flow of control. This is the security context to be defined / -----+ +---------+ +-------X---------+ +-------> yes/no+restrictions | | | | | | V | V | V | GSSAPI Dist Authorization Authorization API +----possibly combined----+ The authorization API will provide a mechanisms to query a local authorization database to check authorization. answer = check_authorization(sc,target,operation) SC is the security context, containing information about the identity of the client and about authorization credentials that have been received (and possibly verified). Piers McMahon agreed to work on defining the information that needs to be present in the security context. Defining this will require interaction with those defining other parts of the API, and should include consultation with John Linn to make sure that it is consistent with, and perhaps ultimately used by, the GSSAPI. TARGET specifies the target of the attempted access. If the authorization database were represented as a set of access control lists, the target would identify which list is to be consulted. TARGET should have a two part name, one part identifying an application or set of applications that share the same set of objects, and the name of the individual object. This is useful when the authorization database is maintained on a system wide basis (for example by an ACL manager) rather than by individual applications. For now we will define TARGET to be two strings, an identifier for an application and an application specific object name. This can be represented as a single string using a ":" as a separator (this means : can not appear in the identifier of the application). OPERATION identifies the operation to be performed on the target. The definition of this field will correspond to the rights field in the ACLs in the authorization database. We decided that this field would be a bit vector of application specific rights, together with a tag identifying the application (the tag for the operation bit vector should be compared with the tag for the bit vector in the ACL to make sure the bits are interpreted correctly). At this point it was felt that we needed to specify the form of the authorization database. The access control list method was proposed, with rights specified as described in the preceding paragraph, but with the ACL entry extended so entries would include an optional list of restrictions that further specify the conditions under which the operation would be allowed. Among these restrictions might be time of day restrictions, as well as application specific restrictions such as a netmask of network access servers, or perhaps a restriction for a mailing list server that allowed modification of a mailing list, but only to add or delete oneself. These restrictions would exist in the same space as those defined for distributed authorization mechanisms. In fact, it should be possible to apply the restrictions returned from an authorization database directly to distributed authorization credentials issued by security servers (authorization server, privilege attributed servers, etc). If restrictions are supported, the value returned by check_authorization would no longer be yes/no, but instead a list of restrictions. An answer of "no" would be represented by the restriction "not authorized". An answer of "yes" would be represented as an empty list of restrictions. A conditional yes would be represented by the list of conditions/restrictions. Some restrictions, such as time of day, could be checked directly by the authorization API, while application specific restrictions might better be handled by a function wrapped around the API, avoiding the need for the authorization API to understand the needs of all potential applications. For example, consider the pseudo code to check authorization to use a network access server: check_nas_acl(sc, aclid) { resp = check_authorization(sc, "nas:network", 0x1); for restrict in resp { case: net_mask; ... break; case: toll_lines_only; ... break; case: spare_capacity_only; ... break; default: reject; } accept; } Technically, the principal identifier in an entry can be thought of as a restriction on who may use it, but we'll leave it as a separate field since that is what most people expect in an ACL entry. Multiple principal identifiers will be supported for each ACL entry, allowing the specification of compound principals. Principal identifiers will be typed. We considered using the GSSAPI representation for the principal. John Linn pointed out that the opaque nature of GSSAPI names makes them difficult to store in a persistent and shared access control list. Naming issues have been a stumbling block in other groups, and wanting to avoid that issue for now, we decided that we will support typed names. When the GSSAPI naming issues are resolved it might be one of the types. For now, the type would indicate the the namespace (which at the present time is closely tied to the authentication method) from which the name is drawn. The definition of the get_acl call as an alternate interface to the authorization API was deferred until the authorization database itself is better defined. . Work items Clifford Neuman will compile a list of restrictions or privilege attributes addressing the needs of DCE, Sesame, restricted proxies, and various applications. Piers McMahon will define the information that needs to be part of the security context. Piers and Cliff will work to further refine the form of the authorization database. Allan Rubens and John Vollbrecht will provide a description of the authorization needs for the network access server. Sam Sjogren will provide the same for FTP. Cliff will contact Russ Hobby for input on other application requirements. Thanks to Richard Graveman for his notes which were helpful in the preparation of these minutes. From bcn Thu Apr 8 13:39:59 1993 Received: from tgo.isi.edu by venera.isi.edu (5.65c/5.61+local-12) id ; Thu, 8 Apr 1993 20:40:11 -0700 Date: Thu, 8 Apr 93 20:39:59 PDT Posted-Date: Thu, 8 Apr 93 20:39:59 PDT Message-Id: <9304090339.AA25711@tgo.isi.edu> Received: by tgo.isi.edu (4.1/4.0.3-4) id ; Thu, 8 Apr 93 20:39:59 PDT From: Clifford Neuman To: cat-ietf@mit.edu, kerberos@mit.edu, krb-protocol@mit.edu, saag@tis.com, ietf-aac Subject: FINAL CALL: last chance to comment on Kerberos V5 protocol document This is a reminder that comments on the final draft of the Kerberos V5 specification are due by April 10. Late comments may be accepted, but only if sufficient time exists for their consideration. A final internet-draft will be issued on April 15th, at which point the specification will be submitted for publication as an RFC, together with other documents developed in the CAT working group. The latest version of the Kerberos V5 Spec, pre revision 5.2, has been available for a little more than a week from prospero.isi.edu in the file /pub/papers/security/kerberos-pre52.ps.Z and /pub/papers/security/kerberos-pre52.lpt.Z Please review the document and provide comments to me and/or the mailing list krb-protocol@mit.edu. I am particularly interested in comments on improvement of the pseudocode. Also pay particular attention the the definition of the ENC-TIMESTAMP pre-authentication method, and all sections pertaining to the new KRB-CRED message. Thanks, Clifford Neuman From bcn Tue Apr 13 01:27:47 1993 Received: from tgo.isi.edu by venera.isi.edu (5.65c/5.61+local-12) id ; Tue, 13 Apr 1993 08:27:50 -0700 Date: Tue, 13 Apr 93 08:27:47 PDT Posted-Date: Tue, 13 Apr 93 08:27:47 PDT Message-Id: <9304131527.AA05912@tgo.isi.edu> Received: by tgo.isi.edu (4.1/4.0.3-4) id ; Tue, 13 Apr 93 08:27:47 PDT From: Clifford Neuman To: ietf-aac Subject: Final call: comments on minutes Please provide any comments on the draft minutes of the aac meeting in Columbus by tomorrow (Wednesday). ~ Cliff From bcn Fri Apr 16 06:40:13 1993 Received: from tgo.isi.edu by venera.isi.edu (5.65c/5.61+local-12) id ; Fri, 16 Apr 1993 13:40:19 -0700 Date: Fri, 16 Apr 93 13:40:13 PDT Posted-Date: Fri, 16 Apr 93 13:40:13 PDT Message-Id: <9304162040.AA21251@tgo.isi.edu> Received: by tgo.isi.edu (4.1/4.0.3-4) id ; Fri, 16 Apr 93 13:40:13 PDT From: Clifford Neuman To: minutes@cnri.reston.va.us Cc: ietf-aac Subject: Minutes of Columbus Authorization and Access Control BOF Minutes of the Authorization and Access Control BOF (AAC) Columbus OH IETF March 31, 1993 4:00PM Chair: B. Clifford Neuman University of Southern California Information Sciences Institute The third meeting of a BOF on Authorization and Access Control met at the March IETF. This should be the last meeting as a BOF since the charter had already been submitted to the IESG and is currently under review. The agenda for the meeting was: 1. Review the AAC charter as submitted to IESG for review 2. Identify common characteristics of evolving distributed authorization mechanisms and begin discussion on how best to encourage interoperability across mechanisms. 3. Review the authorization API from last meeting in light of the DCE and Sesame documents made available by Piers McMahon, and considering characteristics identified in (2). 4. Assign work items to generate access control API internet draft, and other items to be accomplished before the Amsterdam IETF. The draft charter, past minutes, mailing-list discussions, and other documents mentioned in these minutes are available by anonymous FTP from prospero.isi.edu in the directory /pub/aac. 1. Review of charter The working group charter discussed at the previous meeting was submitted to the IESG for approval. Based on several comments from IESG members the charter was revised to make the relationship with other working groups clearer. A new version was provided to the IESG and distributed to the AAC mailing list. Everyone at the meeting seemed comfortable with the revised charter and no additional changes were suggested. The charter is once again in the hands of the IESG, which seems reluctant to form new groups without understanding the big-picture of how all the groups in an area fit together. Steve Crocker, the area director, will provide the IESG with such a statement. 2. Evolving distributed authorization mechanisms Among the goals of distributed authorization mechanisms are to avoid the need to duplicate common information about principals' access rights on each end-system and to facilitate ease of management, often by enabling centralized maintenance of access control and revocation information. Evolving mechanisms for distributed authorization were discussed, including DCE, ECMA/Sesame, and restricted proxies (Kerberos V5). In each of these mechanisms, a certificate grants privileges to a principal, either by explicitly enumerating privileges, or by restricting privileges. Positive privileges are represented in the latter case as the set of rights available to the issuer of the certificate which are not explicitly restricted. Clifford Neuman argued that the restricted forms of credentials are more general since they allow the addition of restrictions during delegation, and also because the rights of the issuer of a certificate naturally limit what can be granted, rather than requiring a separately maintained list of which principals are authorized to grant particular privileges. Piers McMahon and John Linn suggested that the term restriction is a confusing term for permission. It also wasn't clear to them how one could compose privileges from different sources. Cliff responded that the permissions are granted by certificates which provide all rights possessed by the signer and that the restrictions apply to what is granted by a particular certificate, limiting the permissions. By providing multiple certificates one gets a sum of products; i.e. the sum of the remaining rights from each of the restricted certificates. There was some skepticism about this role of restrictions in the representation of what appear to be positive rights; the issue will be revisited later. It would improve interoperability across mechanisms if there were a common set of restrictions or privileges. This would make it easier to translate from one mechanism to another (i.e. the translation would be syntactic, rather than semantic). Clifford Neuman will compile a list of restrictions sufficient to represent privileges supported by DCE, Sesame, restricted proxies, and any other mechanisms brought to our attention. He will also accept input from application developers on the restrictions and privileges they require. Submissions can be in either form, restrictions or permissions. They will be represented at least initially as restrictions in the compiled list to asses the benefits of such a representation. Example permissions/restrictions: DCE: a way of specifying global userID and groups the user is in DCE: "optional" restrictions NAS: a way of restricting the subnets to which a user may connect Sesame: a way to represent each of its privilege attributes Others: roles 3. Authorization API (and more) The working group began refining the strawman ACL API presented at the Washington IETF. There is more than just an API involved. In particular, it will be necessary to define the authorization information that can be stored. The API will be designed to allow easy integration with distributed authorization methods, including support for the specification of restrictions on ACL entries. Ted Ts'o suggested that since the API is not restricted to what people normally think of as ACLs, that we should call it an Authorization API, rather than an ACL API. This change in terminology was adopted. The group started to define the input and output arguments to the API. To set the stage for this discussion Piers McMahon and Clifford Neuman described the anticipated flow of control for the end-server. When a request is received, calls are made to the GSSAPI or other authentication routines. The output of the GSSAPI is a security context which contains information about the client. This might then be passed into additional function to verify authorization credentials. The distributed authorization mechanisms might instead be handled as part of the GSSAPI itself. The output of the combined GSSAPI and distributed authorization functions will be a security context which is fed into the authorization API. For simplicity at this point in the discussion, the authorization API will return a yes/no answer indicating whether a particular operation is allowed. We need to define what needs to be part of the security context, an input to the authorization API. It might then be possible to extend the GSSAPI security context definition so that it can be used directly. The diagram below shows the flow of control. This is the security context to be defined / -----+ +---------+ +-------X---------+ +-------> yes/no+restrictions | | | | | | V | V | V | GSSAPI Dist Authorization Authorization API +----possibly combined----+ The authorization API will provide mechanisms to query a local authorization database to check authorization. answer = check_authorization(sc,target,operation) SC is the security context, containing information about the identity of the client and about authorization credentials that have been received (and possibly verified). Piers McMahon agreed to work on defining the form of the security context for our present needs, trying to define it in such a way that it will later be able to accommodate information from additional distributed authorization mechanisms. Defining the security context will require interaction with those defining other parts of the API, and should include consultation with John Linn and the CAT WG to make sure that it is consistent with, and perhaps ultimately included in, the GSSAPI. TARGET specifies the target of the attempted access. If the authorization database were represented as a set of access control lists, the target would identify which list is to be consulted. TARGET should have a two part name, one part identifying an application or set of applications that share the same set of objects, and the name of the individual object. This is useful when the authorization database is maintained on a system wide basis (for example by an ACL manager) rather than by individual applications. For now we will define TARGET to be two strings, an identifier for an application and an application specific object name. This can be represented as a single string using a ":" as a separator (this means : can not appear in the identifier of the application). OPERATION identifies the operation to be performed on the target. The definition of this field will correspond to the rights field in the ACLs in the authorization database. We decided that this field would be an extensible bit vector of application specific rights, together with a tag identifying the application (the tag for the operation bit vector should be compared with the tag for the bit vector in the ACL to make sure the bits are interpreted correctly). At this point it was felt that we needed to specify the form of the authorization database. The access control list method was proposed, with rights specified as described in the preceding paragraph, but with the ACL entry extended so entries would include an optional list of restrictions that further specify the conditions under which the operation would be allowed. Among these restrictions might be time of day restrictions, as well as application specific restrictions such as a netmask of network access servers, or perhaps a restriction for a mailing list server that allowed modification of a mailing list, but only to add or delete oneself. These restrictions would exist in the same space as those defined for distributed authorization mechanisms. In fact, it should be possible to apply the restrictions returned from an authorization database directly to distributed authorization credentials issued by security servers (authorization servers, privilege attribute servers, etc). If restrictions are supported, the value returned by check_authorization would no longer be yes/no, but instead a list of restrictions. An answer of "no" would be represented by the restriction "not authorized". An answer of "yes" would be represented as an empty list of restrictions. A conditional yes would be represented by the list of conditions/restrictions. Some restrictions, such as time of day, could be checked directly by the authorization API, while others would be returned by the API as unresolved. These unresolved restrictions might be application specific, and they would be handled by a function wrapped around the API, avoiding the need for the authorization API to understand the needs of all potential applications. For example, consider the pseudo code to check authorization to use a network access server: check_nas_acl(sc, aclid) { resp = check_authorization(sc, "nas:network", 0x1); for restrict in resp { case: net_mask; ... break; case: toll_lines_only; ... break; case: spare_capacity_only; ... break; default: reject; } accept; } Technically, the principal identifier in an entry can be thought of as a restriction on who may use it, but we'll leave it as a separate field since that is what most people expect in an ACL entry. Multiple principal identifiers will be supported for each ACL entry, allowing the specification of compound principals. Principal identifiers will be typed. We considered using the GSSAPI representation for the principal. John Linn pointed out that the opaque nature of GSSAPI names makes them difficult to store in a persistent and shared access control list. Naming issues have been a stumbling block in other groups, and wanting to avoid that issue for now, we decided that we will support typed names. When the GSSAPI naming issues are resolved it might be one of the types. For now, the type would indicate the the namespace (which at the present time is closely tied to the authentication method) from which the name is drawn. The definition of the get_acl call as an alternate interface to the authorization API was deferred until the authorization database itself is better defined. 4. Work items Clifford Neuman will compile a list of restrictions or privilege attributes addressing the needs of DCE, Sesame, restricted proxies, and various applications. Piers McMahon will define the information that needs to be part of the security context. Piers and Cliff will work to further refine the form of the authorization database. Allan Rubens and John Vollbrecht will provide a description of the authorization needs for the network access server. Sam Sjogren will provide the same for FTP. Cliff will contact Russ Hobby for input on other application requirements. Minutes reported by Clifford Neuman. Thanks to Richard Graveman for his notes which were helpful in the preparation of these minutes. From bcn Wed Apr 21 04:52:53 1993 Received: from tgo.isi.edu by venera.isi.edu (5.65c/5.61+local-12) id ; Wed, 21 Apr 1993 11:53:01 -0700 Date: Wed, 21 Apr 93 11:52:53 PDT Posted-Date: Wed, 21 Apr 93 11:52:53 PDT Message-Id: <9304211852.AA25468@tgo.isi.edu> Received: by tgo.isi.edu (4.1/4.0.3-4) id ; Wed, 21 Apr 93 11:52:53 PDT From: Clifford Neuman From: Clifford Neuman To: cat-ietf@mit.edu, kerberos@mit.edu, krb-protocol@mit.edu, ietf-aac Subject: "Final" version of Kerberos V5 Spec now available The final version of the Kerberos V5 protocol spec (revision 5.2) is available from prospero.isi.edu with the pathname: /pub/papers/security/kerberos-5.2.{ps.Z,lpt.Z} There have been no changes to previously specified portions of the protocol. Wording has been clarified, and missing pseudocode has been added. We have specified the encrypted timestamp pre-authentication method and have defined a new protocol message KRB_CRED to be used to pass proxies or forwarded tickets to remote hosts. This latter change provides a well defined procedure so that applications will do it correctly. Note that the format of the KRB_CRED message has changed from that in the pre-release of specification 5.2). This specification has been submitted and will appear as an internet draft shortly. The specification will at that point be submitted for publication as an RFC, together with other documents developed in the CAT working group. Although I expect this is the final version that will appear as an internet draft, it may be possible to make minor changes during final editing as an RFC. As such, please let us know if you discover any problems. Thanks, Clifford Neuman From P.Williams@cs.ucl.ac.uk Thu May 13 13:46:20 1993 Received: from bells.cs.ucl.ac.uk by venera.isi.edu (5.65c/5.61+local-12) id ; Thu, 13 May 1993 04:46:45 -0700 Message-Id: <199305131146.AA20722@venera.isi.edu> Received: from auchentoshan.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 13 May 1993 12:46:26 +0100 To: ietf-aac Subject: AccessControlCertificate-ASN1Module Date: Thu, 13 May 93 12:46:20 +0100 From: Peter Williams Perhaps following DIS status of ISO/IEC JFC 1/SC 21 N7661 CD-10164-9.3 of CCITT Rec X.714, the distributed authorization controls for CMIS might be the subject of study. It references and specializes the the X.acf ISO/IEC 10181-3 access control framework. As usual, no policy or specific mechanisms are mandated, or specified. However, the definitions may be useful reference point, just as X.509 was a useful reference point for the PEM WG. From gvaudre@CNRI.Reston.VA.US Thu Jun 17 13:20:06 1993 Received: from IETF.nri.reston.VA.US (ietf.cnri.reston.va.us) by venera.isi.edu (5.65c/5.61+local-12) id ; Thu, 17 Jun 1993 14:21:57 -0700 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa15771; 17 Jun 93 17:20 EDT To: IETF-Announce: ; Cc: ietf-aac Subject: WG ACTION: Authorization and Access Control (aac) Date: Thu, 17 Jun 93 17:20:06 -0400 From: Greg Vaudreuil Message-Id: <9306171720.aa15771@IETF.CNRI.Reston.VA.US> A new working group has been formed in the Security Area of the IETF. Please contat the working group chair or the Security area director for more information. Greg Vaudreuil IESG Secretary Authorization and Access Control (aac) -------------------------------------- Charter Chair(s): Clifford Neuman Security Area Director(s) Stephen Crocker Mailing lists: General Discussion:ietf-aac@isi.edu To Subscribe: ietf-aac-request@isi.edu Archive: prospero.isi.edu:~/pub/aac/* Description of Working Group: The goal of the working group on authorization and access control is to develop guidelines and an application programmer interface (API) through which network accessible applications can uniformly specify access control information. This API will allow applications to make access control decisions when clients are not local users, might not be members of a common organization, and often not known to the service or application in advance. Several authentication mechanisms are in place on the Internet, but most applications are written with local applications in mind and no guidelines exist for supporting authorization and access control based on the output of such authentication mechanisms. The CAT working group developed the GSSAPI, a common API to support authentication. The AAC working group will develop a common API that accepts the identity of a client (perhaps the output of the GSSAPI), a reference to an object to be accessed, and optionally an indication of the operation to be performed. The API will return a list of authorized operations or a yes/no answer that can be easily used by the application. A second, and longer term purpose of the working group will be to examine evolving mechanisms and architectures for authorization in distributed systems and to establish criteria which enable interworking of confidence and trust across systems. The working group will develop additional goals an milestones related to this purpose and will submit a revised charter once the appropriate goals and milestones are determined. To the extent possible this additional work will encourage evolution toward credential formats that more readily allow support for or translation across multiple mechanisms. Goals and Milestones: Done Submit Charter and milestones for approval. Done Meet at the Columbus IETF to identify common characteristics of evolving distributed authorization mechanisms and begin discussion of approaches for interoperability across mechanisms. June 93 Post draft API as an Internet Draft. June 93 Post an Internet Draft of the guidelines for authorization and access control for network accessible applications. Aug 93 Submit the AAC guidelines document to the IESG for approval as an informational document. Jan 94 Submit the AAC API to the IESG for consideration as an experimental RFC. From bcn Mon Jul 5 03:27:51 1993 Received: from tgo.isi.edu by venera.isi.edu (5.65c/5.61+local-12) id ; Mon, 5 Jul 1993 10:28:00 -0700 Date: Mon, 5 Jul 93 10:27:51 PDT Posted-Date: Mon, 5 Jul 93 10:27:51 PDT Message-Id: <9307051727.AA25147@tgo.isi.edu> Received: by tgo.isi.edu (4.1/4.0.3-4) id ; Mon, 5 Jul 93 10:27:51 PDT From: Clifford Neuman To: ietf-aac Cc: mwalnut@cnri.reston.va.us Subject: Authorization and Access Control - Preliminary July Agenda Authorization and Access Control Working Group (aac) WEDNESDAY, 14 July 1993 1600-1800 Afternoon Sessions II SEC Authorization and Access Control WG (aac) (Clifford Neuman/ISI) Mailing lists: General Discussion:ietf-aac@isi.edu To Subscribe: ietf-aac-request@isi.edu Archive: prospero.isi.edu:~/pub/aac/* There will be a meeting of the Authorization and Access Control working group on Wednesday afternoon at the Amsterdam IETF. The goal of this working group is to develop guidelines, application programmer interfaces, and common credential representations and characteristics through which network accessible applications can specify access control information. AGENDA 1. Report on approval of working group charter. 2. Presentation of a list of restrictions and privilege attributes needed by applications and existing security systems, and a proposed method for representing them. A draft will be submitted before the meeting. 3. Discussion of the intended use of these restrictions by applications, and an API to provide a simple interface for application developers. 4. Discussion of the information maintained in the security context. The security context maintains information about the user that is used to make authorization decisions. 5. Other business 6. Adjourn From ALim@vnpbfpac.telecom.com.au Tue Jul 6 06:39:00 1993 Received: from shiva.trl.OZ.AU ([137.147.20.34]) by venera.isi.edu (5.65c/5.61+local-12) id ; Mon, 5 Jul 1993 18:40:20 -0700 Received: from msmail.trl.OZ.AU by shiva.trl.OZ.AU with SMTP id AA06112 (5.65c/IDA-1.4.4 for ); Tue, 6 Jul 1993 11:39:55 +1000 Received: by msmail.trl.oz.au with Microsoft Mail id <2C39F135@msmail.trl.oz.au>; Tue, 06 Jul 93 11:40:05 EST From: "Lim, Andy" To: Security_discussion_gp Subject: security products for LAN/MAN/ATM? Date: Tue, 06 Jul 93 11:39:00 EST Message-Id: <2C39F135@msmail.trl.oz.au> Encoding: 10 TEXT X-Mailer: Microsoft Mail V3.0 Hi, Could anyone in this discussion group tell me what are the commercially available security products for LAN, MAN (Metropolitan Area Network) and ATM applications and where to get them from. Pls reply via my email address. cheers, andy lim, Principal Engineer, Telecom Australia alim@vnpbfpac.telecom.com.au From aha@apollo.hp.com Wed Jul 7 05:31:34 1993 Received: from amway.ch.apollo.hp.com by venera.isi.edu (5.65c/5.61+local-12) id ; Wed, 7 Jul 1993 06:33:26 -0700 Message-Id: <199307071333.AA19550@venera.isi.edu> Received: from kate.ch.apollo.hp.com by amway.ch.apollo.hp.com id Wed, 7 Jul 93 09:32:19 EDT Received: by kate.ch.apollo.hp.com id ; Wed, 7 Jul 93 09:31:34 -0400 Date: Wed, 7 Jul 93 09:31:34 -0400 From: aha@apollo.hp.com To: ALim@vnpbfpac.telecom.com.au Cc: ietf-aac In-Reply-To: "Lim, Andy"'s message of Tue, 6 Jul 93 12:39:00 EDT Subject: security products for LAN/MAN/ATM? HP sells DCE 1.0.1 (1.0.2 will be out soon) with the DCE Security Service. This works on LAN's, MAN's, or WAN's. The product names are HP DCE Developers Environment (1.0.1 version shipping now), and HP DCE/9000 (1.0.2 version shipping in August). These run on HP 9000 Series 800 Business Servers and HP 9000 Series 700 Workstations, and are compatible with IBM, DEC, SNI, BULL, NCR, USL, SCO, GRADIENT, PYRIMID, STRATUS, and TRANSARC. Some Transarc implementations sold outside the U.S. do not interoperate with other non-U.S. implementations because Transarc just removed all DES encryption rather than just removing data privacy. HP also will be selling DCE on the HP MPE servers soon. This product was demonstrated at the OSF Challenge '93 interoperability festival. The HP Australia/New Zealand sales office is at: Hewlett-Packard Australia Ltd. 31-41 Joseph Street Blackburn, Victoria 3130 Australia (A.C.N. 004 394 763) (03)895-2895 Anne Anderson 1-508-436-5707 Hewlett-Packard, Corp. Open Systems Software Division 300 Apollo Drive,CHR-03-DC HP/CSO/STG/OSSD[/DCP]/CSSL Chelmsford, MA 01824 USA ARPA: aha@apollo.hp.com From bcn Thu Jul 29 03:40:51 1993 Received: from tgo.isi.edu by venera.isi.edu (5.65c/5.61+local-12) id ; Thu, 29 Jul 1993 10:41:19 -0700 Date: Thu, 29 Jul 93 10:40:51 PDT Posted-Date: Thu, 29 Jul 93 10:40:51 PDT Message-Id: <9307291740.AA08186@tgo.isi.edu> Received: by tgo.isi.edu (4.1/4.0.3-4) id ; Thu, 29 Jul 93 10:40:51 PDT From: Clifford Neuman To: ietf-aac Subject: AAC Draft minutes for Amsterdam My apologies for taking so long to get these out. Here are the draft minutes of the authorization and access control working group in Amsterdam. The final minutes are due tomorrow, but I don't think there will be problems if I send the final version in on Sunday evening instead. If you have any comments, I would appreciate them by Saturday evening. Again, sorry for the short notice. ~ Cliff --- Minutes of the Authorization and Access Control WG (AAC) Amsterdam NL IETF July 14, 1993 4:00PM Chair: B. Clifford Neuman University of Southern California Information Sciences Institute The Authorization and Access Control working group met at the July IETF for the first time since the approval of its inception as a working group. The preceding three meetings were birds of a feather sessions. The agenda for the meeting was: . Report on approval of working group charter. . Presentation of a list of restrictions and privilege attributes needed by applications and existing security systems, and a proposed method for representing them. A draft was distributed at the meeting. . Discussion of the intended use of these restrictions by applications, and an API to provide a simple interface for application developers. . Discussion of the information maintained in the security context. The security context maintains information about the user that is used to make authorization decisions. The charter, past minutes, mailing-list discussions, and other documents mentioned in these minutes are available by anonymous FTP from prospero.isi.edu in the directory /pub/aac. Requests to be added to the working group mailing list should be directed to ietf-aac-request@isi.edu. 1. Report on working group charter It was reported that the working group charter was approved by the IESG. Steve Crocker brought up several desires that were raised in the discussion by the IESG. Among these desires as the need for some kind of demo of the technology, in particular, integration with possible applications. 2. Discussion of possible applications (digression) Possible application were discussed. An early test will be the Prospero Directory Service which already has support for access control lists, and an access control list type reserved for the mechanism developed by the working group. Another possible application is in support for cross-site, remote execution. In particular, Tom Hutton of the San Diego Super Computer Center is is looking for a simple way to specify access controls for data and processing resources distributed across several sites. File transfer provides a third set of applications. Steve Crocker pointed out the need for secure file transfer to and between large diverse groups. This is related to the FTP extension in the CAT working group in that those extension make available to the application the authenticated network identity of the client, and that identity might be used as a basis for authorization decision. Some of the extensions to ftpd out of Washington University are also of interest here. A final application that was discussed was network databases. Daisy Rose mentioned that the netdata working group has a need for an authorization mechanism that will allow them to determine which remote principals are authorized to access a database, and which local user ID is to apply to such remote accesses. 3. How it will be used by applications (digression) Throughout the discussion just described the issue of how authorization information would be specified by applications was raised. There seemed to be two classes, applications that are not aware of network identities rely on local authorization, and some mechanism is used that allows network identities to be mapped to local identities. For such applications, authorization is confined to initially establishing who is authorized to assume a particular identity at the time a connection is initiated. It is not clear if this is an authentication issue or an authorization issue. An application that is aware of network identities would make a call to the authorization API for each operation that is to be mediated. The authorization API will return a yes or no answer, or a list of what the principal can do. Access control list entries could identify the type of authentication required, in addition to the name of the principal authorized by an entry. Sam Sjogren suggested allowing the specification of weaker authentication methods including regular expression matches on network address or hostname and usernames in addition to stronger methods. This would allow the authorization API to be used with existing application that don't have support for strong authentication, and would allow easier transition to stronger mechanisms if they are later integrated with the application. There was a brief discussion about whether we need to define an administrative interface to maintain access control lists. It was decided that we could defer this issue, waiting until we decided what an access control list would look like, and the API for checking authorization. The definition of an external representation for an access control list should be enough to get started. 4. Presentation of Restrictions and Privilege Attributes A draft list of restrictions was distributed at the meeting. The list defines some common restrictions that are useful for representing privilege attributes and constraints on the use of credentials in distributed systems. Several restrictions were discussed. Sam Sjogren suggested that it might be useful to think of these in terms of the questions who, what, when, where, and how (why is more appropriate for audit than authorization). With this taxonomy, the restrictions discussed were: who - for_use_by_principal, for_use_by_group; what - local_uid, group_membership, dce_pac, authorized, quota, netmask; when - accept_n_times, authorized_times; where - for_use_on_server, limit-restriction, limit-application; and how - optional (this is stretching the analogy). Even with this breakdown, there was a great deal of confusion about the difference between the "who" restrictions which limit who may exercise the proxy, and the "what" restrictions that seem to assert local uids, and group membership, instead of restrict them. It is clear from the discussion that the model needs to be refined so that this distinction is more understandable, or replaced so that positive and negative attributes are considered separately. During discussion after the meeting, some ideas for addressing this confusion were generated. A revised specification incorporating one of these ideas will be distributed to the mailing list by the third week of August, and we can decide at that time if they address the concerns. 5. Discussion of the security context In the few minutes that remained, Piers McMahon discussed possible information to be included in the security context, a structure that stores information about a principal that is passed as input to the authorization API which uses it to decide which access control list entries are applicable. The presentation outlined the security relevant information about a session maintained by, exported by, or used by several systems. The GSSAPI supports authentication and message protection. AAC does access mediation and enforcement. The network user identity authenticated by the GSSAPI is part of the security context and can be used by the authorization API. In DCE, a set of privileges are added to the security context. These privileges are securely transmitted in privilege attribute certificates signed using Kerberos. These privileges become part of the security context once validate by the end-server. The security context for sesame includes privilege attributes and control attributes that can limit delegation and permissible targets. Max Six includes labels and audit ids in the security contexts. Recommendation: Representation of attributes is likely to be needed in a security context used for access control. We should consider extending the GSSAPI security context to include privilege attributes. John Linn pointed out that if we are to do this, we need a set of attributes that is widely accepted. Thanks to Richard Graveman for his notes which were helpful in the preparation of these minutes. From bcn Sun Aug 1 06:08:52 1993 Received: from darkstar.isi.edu by venera.isi.edu (5.65c/5.61+local-12) id ; Sun, 1 Aug 1993 13:08:53 -0700 Received: by darkstar.isi.edu (5.65c/5.61+local-11) id ; Sun, 1 Aug 1993 13:08:52 -0700 Date: Sun, 1 Aug 1993 13:08:52 -0700 Message-Id: <199308012008.AA17350@darkstar.isi.edu> From: Clifford Neuman To: minutes@cnri.reston.va.us, ietf-aac Subject: Minutes of Authorization and Access Control WG The final minutes for the July 1993 meeting of the IETF Authorization and Access Control Working Group follow. The minutes were prepared by Clifford Neuman. ~ Cliff -- Minutes of the Authorization and Access Control WG (AAC) Amsterdam NL IETF July 14, 1993 4:00PM Chair: B. Clifford Neuman University of Southern California Information Sciences Institute The Authorization and Access Control working group met at the July IETF for the first time since the approval of its charter and official inception as a working group. The preceding three meetings were birds of a feather sessions. The agenda for the meeting was: . Report on approval of working group charter. . Presentation of a list of restrictions and privilege attributes needed by applications and existing security systems, and a proposed method for representing them. A draft was distributed at the meeting. . Discussion of the intended use of these restrictions by applications, and the presentation of an API to provide a simple interface for application developers. . Discussion of the information maintained in the security context. The security context maintains information about the user that is used to make authorization decisions. The charter, past minutes, mailing-list discussions, and other documents mentioned in these minutes are available by anonymous FTP from prospero.isi.edu in the directory /pub/aac. Requests to be added to the working group mailing list should be directed to ietf-aac-request@isi.edu. 1. Report on working group charter It was reported that the working group charter was approved by the IESG. Steve Crocker brought up several desires that were raised in the discussion by the IESG. Among these desires is the need for some kind of demo of the technology, in particular, integration with possible applications. 2. Discussion of possible applications (digression) Possible applications were discussed. An early test will be the Prospero Directory Service which already has support for access control lists, and an access control list type reserved for the mechanism developed by the working group. Another possible application is in support of cross-site, remote execution. In particular, Tom Hutton of the San Diego Super Computer Center is is looking for a simple way to specify access controls for data and processing resources distributed across several sites. File transfer provides a third set of applications. Steve Crocker pointed out the need for secure file transfer to and between large diverse groups. This is related to the FTP extension work in the CAT working group in that those extensions make available to the application the authenticated network identity of the client, and that identity might be used as a basis for authorization decisions. Some of the extensions to ftpd out of Washington University are also of interest here. A final application that was discussed was network databases. Daisy Rose mentioned that the netdata working group has a need for an authorization mechanism that will allow them to determine which remote principals are authorized to access a database, and which local user ID is to apply to such remote accesses. 3. How it will be used by applications Throughout the discussion just described the issue of how authorization information would be specified by applications was raised. There seemed to be two classes, applications that are aware of network identities, and those that aren't. Application that aren't aware of network identities rely on local authorization using local user identities. A separate mechanism is used to map network identities to local identities. For such applications, authorization is confined to initially establishing who is authorized to assume a particular identity at the time a connection is initiated. It is not clear if this is an authentication issue or an authorization issue. An application that is aware of network identities makes a call to the authorization API for each operation that is to be mediated. The authorization API will return a yes or no answer, or a list of what the principal can do, based on the principal's network identity. Access control list entries could identify the type of authentication required, in addition to the name of the principal authorized by an entry. Sam Sjogren suggested allowing the specification of weaker authentication methods including regular expression matches on network address or hostname and usernames in addition to stronger methods. This would allow the authorization API to be used with existing application that don't have support for strong authentication, and would allow easier transition to stronger mechanisms if they are later integrated with the application. There was a brief discussion about whether we need to define an administrative interface to maintain access control lists. It was decided that we could defer this issue, waiting until we decide what access control lists and the API for checking authorization will look like. The definition of an external representation for an access control list should be enough to get started. 4. Presentation of Restrictions and Privilege Attributes A draft list of restrictions was distributed at the meeting. The list defines some common restrictions that are useful for representing privilege attributes and constraints on the use of credentials in distributed systems. Several restrictions were discussed. Sam Sjogren suggested that it might be useful to think of these in terms of the questions who, what, when, where, and how (why is more appropriate for audit than authorization). With this taxonomy, the restrictions discussed were: who - for_use_by_principal, for_use_by_group; what - local_uid, group_membership, dce_pac, authorized, quota, netmask; when - accept_n_times, authorized_times; where - for_use_on_server, limit-restriction, limit-application; and how - connection_type (dialin, hardwired from a secure area, etc), application_name. Even with this breakdown, there was a great deal of confusion about the difference between the "who" restrictions which limit who may exercise the proxy, and the "what" restrictions that seem to assert local uids, and group membership, instead of restrict them. It is clear from the discussion that the model needs to be refined so that this distinction is more understandable, or replaced so that positive and negative attributes are considered separately. During discussion after the meeting, some ideas for addressing this confusion were generated. A revised specification incorporating one of these ideas will be distributed to the mailing list by the third week of August, and we can decide at that time if they address the concerns. 5. Discussion of the security context In the few minutes that remained, Piers McMahon discussed possible information to be included in the security context, a structure that stores information about a principal and is passed as input to the authorization API which uses it to decide which access control list entries are applicable. The presentation outlined the security relevant information about a session maintained by, exported by, or used by several systems. The GSSAPI supports authentication and message protection. Separate authorization mechanisms provide access mediation and enforcement. The network user identity authenticated by the GSSAPI is part of the security context and can be used by the authorization API. In DCE, a set of privileges are added to the security context. These privileges are securely transmitted in privilege attribute certificates signed using Kerberos. These privileges become part of the security context once validate by the end-server. The security context for Sesame includes privilege attributes and control attributes that can limit delegation and permissible targets. Max Six includes labels and audit ids in the security contexts. Recommendation: Representation of attributes is likely to be needed in a security context used for access control. We should consider extending the GSSAPI security context to include privilege attributes. John Linn pointed out that if we are to do this, we need a set of attributes that is widely accepted. Thanks to Richard Graveman for his notes which were helpful in the preparation of these minutes. From ari Tue Aug 17 02:21:20 1993 Received: from gum.isi.edu by venera.isi.edu (5.65c/5.61+local-12) id ; Tue, 17 Aug 1993 09:21:04 -0700 Date: Tue, 17 Aug 93 09:21:20 PDT From: ari Posted-Date: Tue, 17 Aug 93 09:21:20 PDT Message-Id: <9308171621.AA18810@gum.isi.edu> Received: by gum.isi.edu (4.1/4.0.3-4) id ; Tue, 17 Aug 93 09:21:20 PDT To: ietf-aac, imp-interest@thumper.bellcore.com, kerberos@mit.edu Subject: New paper on electronic currency A new paper on electronic currency to appear in the 1st ACM Conference on Computer and Communications Security, Nov. 93 is now available via anonymous FTP from PROSPERO.ISI.EDU as /pub/papers/security/netcash-cccs93.ps.Z NetCash: A design for practical electronic currency on the Internet Gennady Medvinsky and Clifford Neuman NetCash is a framework that supports realtime electronic payments with provision of anonymity over an unsecure network. It is designed to enable new types of services on the Internet which have not been practical to date because of the absence of a secure, scalable, potentially anonymous payment method. NetCash strikes a balance between unconditionally anonymous electronic currency, and signed instruments analogous to checks that are more scalable but identify the principals in a transaction. It does this by providing the framework within which proposed electronic currency protocols can be integrated with the scalable, but non-anonymous, electronic banking infrastructure that has been proposed for routine transactions. From bcn Sun Oct 31 09:37:34 1993 Received: from darkstar.isi.edu by venera.isi.edu (5.65c/5.61+local-13) id ; Sun, 31 Oct 1993 17:37:35 -0800 Received: by darkstar.isi.edu (5.65c/5.61+local-15) id ; Sun, 31 Oct 1993 17:37:34 -0800 Date: Sun, 31 Oct 1993 17:37:34 -0800 Message-Id: <199311010137.AA23482@darkstar.isi.edu> From: Clifford Neuman To: ietf-aac Subject: Revised list of restrictions and privelege attributes I am attaching a revised list of restrictions and privilege attributes. The initial list was distributed at the Amsterdam IETF. I have revised this list and the basic structure to address some of the confusion resulting from the attempt to treat both the same. In the new list, positive and negative attributes (privilege attributes vs. restrictions) are treated separately. If anyone feels that additional attributes need to be defined, please let me know. This is intended only as an initial set to work from. ~ Cliff --- Authorization and Access Control Working Group Proposed list of Restrictions and Privilege Attributes Clifford Neuman USC Information Sciences Institute This document defines common restrictions and attributes that are useful for representing privilege attributes and constraints on the use of credentials in distributed systems. The model for representing privileges is that privileges are conveyed by proxies. A proxy inherently grants certain rights, those rights available to the principal that signed the proxy. Proxies may be restricted to limit the rights that are conveyed. Certain restrictions require the presentation of additional proxies called endorsements before the original proxy may be used. A proxy and all required endorsements together form a proxy chain (a proxy that doesn't require endorsements constitutes a chain by itself). Endorsement may apply additional restrictions. The restrictions specified by each proxy in a chain are applied, resulting in a more restricted set of rights. A principal may collect multiple independent proxy chains, and the rights granted by each chain are added providing additional rights. . Attributes and Restrictions A structured set of authorization attributes are associated with each proxy. Each attribute in the set is typed, and the interpretation of the data associated with the attribute is determined by its type. Some types of attributes are specific to specific servers. A flags field associated with each kind of attribute encodes the appropriate behavior if the interpretation of the attributed is not known. The two possible behaviors are rejection of the request, or ignoring the attribute. Attributes are further divided into three classes: privilege attributes, restrictions, and aggregates. The class is also encoded in the flags field. Privilege attributes identify some operation that is permitted, or assert identifying information such as group information or user identifiers that grant additional rights to the principal that presents a proxy. Privilege attributes may be placed in a proxy only at the time it is created. They may not be added subsequently, and they may not appear in endorsements. Further, in order for a privilege attribute to apply, the principal granting the proxy must possess the ability to grant such an attribute. (though privilege attributes grant rights, they are interpreted as explicitly enumerating the rights that are to be granted by a proxy and all other rights are presumed not to be granted by the proxy). Restrictions specifically remove rights from those conveyed by a proxy, or they place additional constraints on when, how, where, or by whom a proxy may be exercised. Restriction may be present when a proxy is initially created, they may be added subsequently and they may be present in endorsements. Restrictions that are present in a required endorsement are applied in addition to the restrictions present in the proxy that is endorsed. Aggregate attributes may be positive (privilege attributes) or negative (restrictions). The same rules about where each may appear apply to aggregates as well. An aggregate attribute encapsulates a set of attributes and specifies how they are to be interpreted. One form of aggregate limits the application of a set of attributes to a particular end server or a particular application. It is not clear what the meaning should be for an empty set of restrictions. Clearly if the set is empty because positive restrictions were not understood, then no rights are conveyed and the proxy is void. Similarly, one could claim that if positive enumeration of rights is required, then an empty proxy grants nothing. On the other hand, if the proxies are implemented as additional fields in authentication credentials, then leaving out the field might correspond to authentication, and thus grant all rights. One could require a special privilege attribute that means "may assume my identity", but is that redundant? . Access Control Lists When designing an application that relies on such distributed authorization mechanism, certain rights are conveyed by a local access control list to principals that may issue proxies for a particular service. Thus, as mentioned before, the issuer of a proxy must be authorized to grant the rights in the proxy, and that authority is conveyed in an access control list local to the end server. Restrictions on the use of the proxy may be recorded in the local access control list, and these restrictions are added to those present in the proxy, at the time the proxy is used. For example, the access control list for a file server may grant read rights to an authorization server, which can then grant those rights to other users by providing them with proxies. Those proxies might contain privilege attribute identifying which collections of files are accessible to a particular user. Added to such restrictions are the restriction from the local access control list restricting operations authorized by the authorization server to reading only, and not writing. Access control list entries will have a field to encode authorization attributes (restrictions). This field is a sequence of individual attributes, each containing a type, flags, and data specific to the type of the attributed, as defined above. . Attribute types This document defines a set of attributes specifying the type and the data that is associated with each type. This document does not specify the encoding of the sequence of attributes, nor the encoding of the data for each. That is an application specific detail. The document will define an abstract representation for the attribute into and out of which particular implementation encoding can be translated. This will allow for translation across mechanisms using this intermediate abstract format. attributes ::= sequence of attribute attribute ::= sequence {type, flags, adata} type ::= integer -- defined below or ::= octet string -- for non registered attributes flags ::= bit string adata ::= sequence of element -- field defined per type .. Privilege Attributes (answers the question what may be done) ------------------------------------------------------------------------- Authorization attribute class: PRIVILEGE_ATTRIBUTE (1) Authorization attribute type: LOCAL_UID (1) adata ::= sequence of local_uid local_uid ::= sequence {zone, uid} zone ::= sequence of octet string uid ::= integer -- e.g. Unix UID or sequence of octet string -- local username or distinguished value ANY This attribute applies to proxies issued by a local security attribute server (grantor) allowing the grantee to assert a local user ID. This attribute is useful when managing a collection of systems with a common internal user identifier (either a local username or local integer uid) used for local access control. This is particularly important for a collection of workstations sharing files using NFS. The zone is an identifier for the collection of systems that is used to decide if a particular uid applies to a particular end system. ------------------------------------------------------------------------- Authorization attribute class: PRIVILEGE_ATTRIBUTE (1) Authorization attribute type: GROUP_MEMBERSHIP (2) adata ::= sequence of group group ::= sequence of {charter_authority, group_name} charter_authority ::= principal group_name ::= sequence of octet string or distinguished value ANY This attribute applies to proxies issued by a group server (grantor). This attribute specifies a list of groups, limiting the grantee to asserting membership in ONLY those groups explicitly specified and which are managed by the group server. ------------------------------------------------------------------------- Authorization attribute class: PRIVILEGE_ATTRIBUTE (1) Authorization attribute type: DCE_PAC (3) [I have no idea if this is correct, but I throw it out as a starting point for discussion] adata ::= sequence of {uids, groups} uids ::= sequence of integer groups ::= sequence of integer Conceptually, the DCE privilege attribute certificate specifies both group information and the local UID. The name of the privilege server is derived from the name of the principal signing the proxy. Perhaps a better way to represent this is as two separate attributes on the same proxy issued by the privilege attribute server (the grantor). If other information is required that is not supported by those attributes then this separate attribute can be created for DCE, and this attribute is a placeholder for that. To the extent possible, I would prefer to avoid the use of a separate attribute though and encourage the use of GROUP_MEMBERSHIP and LOCAL_UID instead. ------------------------------------------------------------------------- Authorization attribute class: PRIVILEGE_ATTRIBUTE (1) Authorization attribute type: AUTHORIZED (4) adata ::= sequence of obj_rights obj_rights ::= sequence {repository, rsoname, rights} repository ::= principal rsonames ::= sequence of rsoname rsoname ::= sequence of octet string rights ::= sequence { application, rightvec } application ::= octet string rightvec ::= bitstring This attribute enumerates rights that are granted by a proxy. The form of this field is a sequence of object rights. Each set of object rights optionally identifies the specific object repository for the object to which the rights apply. The repository may be left out, in which case restrictions on the proxy may limit the applicability. The rsoname is a name for the object specific to the repository on which it is stored. The contents of the field is opaque, and need only be understood by the repository. The repository and rsoname together uniquely identify the object. Each set of object rights specifies the rights that are authorized by the proxy for operations on the named objects. These rights are contained in the rights field which consists of a bit string, and an application tag that indicates how the bit string is to be interpreted. Where restrictions limit the applicability to specific object, the repository and/or rsoname for the object may be left empty. Wildcards for these fields would be useful. ------------------------------------------------------------------------- Authorization attribute class: PRIVILEGE_ATTRIBUTE (1) Authorization attribute type: QUOTA (5) -- For use in accounting adata ::= sequence of quota_rec quota_rec ::= sequence of { account, currency_type, limit, divisor } account ::= sequence { acct_server, account_name } acct_server ::= principal account_name ::= sequence of octet string currency_type ::= octet_string (why not object identifier) limit ::= integer divisor ::= integer This attribute is used to authorize the transfer of quota or other forms of currency on an accounting server. A check is such a certificate. ------------------------------------------------------------------------- .. Restrictions A large number of restriction types are possible. In the discussion that follows the will be broken into subclasses based on the type of constraint imposed. ... Who ------------------------------------------------------------------------- Authorization attribute class: RESTRICTION (0) Authorization attribute type: FOR_USE_BY_PRINCIPAL (1) [formerly GRANTEE] adata ::= {num_needed, principals} num_needed ::= integer -- number of principals needed to exercise principals ::= sequence of principal -- who is authorized to exercise principal ::= sequence of {atype, princ_name} atype ::= octet string -- authentication type princ_name ::= octet string -- name of principal This restriction identifies the principals that are authorized to exercise a proxy. It does NOT assert the identity of the principal using the proxy, Instead, it requires that in order to exercise the rights granted by a proxy, or exercise rights in the ACL entry, the presenter must additionally authenticate itself as the listed principal(s), or the proxy chain must include endorsements from the principals identified in the list of principals. If num_needed is greater than one, then concurrence (endorsements) by that many principals from the list must be present in the chain. This supports the specification of compound principals when needed. It is expected that in the normal case, though, num_needed will be 1. ------------------------------------------------------------------------- Authorization attribute class: RESTRICTION (0) Authorization attribute type: FOR_USE_BY_GROUP (2) adata ::= {num_needed, groups} num_needed ::= integer -- number of groups needed to exercise groups ::= sequence of group group ::= sequence of {charter_authority, group_name} charter_authority ::= principal group_name ::= sequence of octet string This restriction identifies the groups that are authorized to exercise a proxy. It does NOT assert membership in the groups by the principal to whom the proxy was issued. That is reserved for the GROUP_MEMBERSHIP attribute. Authority to exercise the proxy must be conveyed by endorsements in the chain, signed by a member of the named group, or proven by possession of an appropriate GROUP_MEMBERSHIP proxy. If num_needed is greater than one, then concurrence (endorsements) by membership in that many groups from the list must be present in the chain. This supports the specification of compound group membership when needed. It is expected that in the normal case, though, num_needed will be 1. ------------------------------------------------------------------------- ... When Authorization attribute class: RESTRICTION (0) Authorization attribute type: ACCEPT_N_TIMES (3) adata ::= sequence of {n, identifier} n ::= integer -- number of times to accept identifier ::= sequence of octet string OPTIONAL This restriction indicates that a particular end-server should accept this proxy for authorization only N times. N will usually be 1. If an optional sequence of octet strings are present, the octet strings provide a key that may be used to identify the proxy (e.g. a check number) in conjunction with the name of the grantor, for the purpose of detecting duplicates. Without the optional octet string, then the base information from the the proxy encoding (timestamp, grantor, and other info) must be maintained until the proxy would otherwise expire. ------------------------------------------------------------------------- Authorization attribute class: RESTRICTION (0) Authorization attribute type: VALID_TIME_OF_DAY (4) adata ::= times times ::= sequence of time time ::= sequence {start_tod, end_tod} start_tod ::= sequence of {seconds_from_midnight, timezone} end_tod ::= sequence of {seconds_from_midnight, timezone} This restriction indicates that the authorization granted by a proxy or an access control list entry can only be used between certain times of day. Multiple periods may be specified, and each must specify a start time and end time. Times are specified in seconds from midnight. Timezone identifies the timezone that applies and whether summer time is to be taken into account. ------------------------------------------------------------------------- Authorization attribute class: RESTRICTION (0) Authorization attribute type: VALID_PERIOD (5) adata ::= sequence of start_time, end_time start_time ::= ASN TIME or similar end_time ::= ASN TIME or similar This restriction indicates the period of time during which a proxy is valid, or during which an entry on an access control list is applicable. It might not be needed when the implementation of the proxies already limits their life. If not start time is specified, then the proxy or ACL entry is valid immediately until it expires. If no end time is specified, then the proxy will not be valid until the start time, but does not expire once valid except as required by the implementation of the proxies itself, or by other constraints in the system. ------------------------------------------------------------------------- ... How Authorization attribute class: RESTRICTION (0) Authorization attribute type: NETMASK (6) adata ::= sequence of netmask netmask ::= sequence { inet_mask, operations } inet_mask ::= bitstring operations ::= bitstring This restriction is application specific and would be used for network access servers. Access control list entries for the server would specify the netmask restriction which would then be used to initialize the mask of networks to which packets from the particular port may be sent. ------------------------------------------------------------------------- ... Where Authorization attribute class: RESTRICTION (0) Authorization attribute type: FOR_USE_ON_SERVER (7) [formerly ISSUED_FOR] adata ::= sequence of principal This restrictions lists the services for which a particular proxy or access control list entry applies. It is particularly important in public key proxies that may be verified by any end-server. If this restriction exists, then in addition to being able to verify a proxy chain, the end-server must find its own name in the list of servers for which the proxy was issued. Some method for specifying principal names and wildcards is desirable. ------------------------------------------------------------------------- Authorization attribute class: RESTRICTION (0) Authorization attribute type: FOR_USE_FROM (8) adata ::= TBD This restrictions lists the locations from which a user may exercise a proxy or perform operations specified in an access control list entry. It may include a list of host addresses, host names, or it might specify classed of locations, such as from a dialin, a hardwired line, or a secure area. How to provide assurance that one is in one of these locations is an open problem. ------------------------------------------------------------------------- .. Aggregate Attributes Aggregate attributes specify information about how the encapsulated attributes are to be applied, then include a list of attributes. They may be either positive (grant privileges) or negative (apply restrictions). If positive, then they may only appear in the initial proxy in the chain and must be added at the time the proxy is initially created. If applicable, they add to the set of specifically enumerated rights. Restrictions imposed within a positive aggregate attribute apply only to the enumerated rights also within the same aggregate. If a negative aggregate, and if the attributes are to be applied, they apply to all rights enumerated within the enclosing aggregate, or to all enumerated rights if at the top level, or in an endorsement. ------------------------------------------------------------------------- Authorization attribute class: AGGREGATE (2 negative or 3 positive) Authorization attribute type: UNCONDITIONAL (0) adata ::= sequence {attributes} attributes ::= attributes The attributes in this aggregate are always applied. It is specified solely to allow attributes to be grouped together. For example, it allows restrictions to be applied to a specific set of privilege attributes, but not to others. ------------------------------------------------------------------------- Authorization attribute class: AGGREGATE (2 negative or 3 positive) Authorization attribute type: LIMIT-RESTRICTION (1) adata ::= sequence {end-servers, attributes} end-servers ::= sequence of principal attributes ::= attributes This aggregate is used to encapsulate attributes that are intended to be interpreted by a particular set of end servers. If the end-server is not in the list of end-servers, it will ignore the attributes in the aggregate. If the end-server is in the list of end-servers, the encapsulated list of attributes is added to the set of attributes to be resolved, and processing continues. ------------------------------------------------------------------------- Authorization attribute class: AGGREGATE (2 negative or 3 positive) Authorization attribute type: LIMIT-APPLICATION (2) adata ::= sequence {applications, attributes} applications ::= sequence of octetstring attributes ::= attributes This aggregate is used to encapsulate attributes that are intended to be interpreted by a particular application or class of applications. If the application is not in the list of application, it will ignore the attributes in the aggregate. If the application is in the list of applications, the encapsulated list of attributes is added to the set of attributes to be resolved, and processing continues. ------------------------------------------------------------------------- From bcn Sun Oct 31 22:50:46 1993 Received: from darkstar.isi.edu by venera.isi.edu (5.65c/5.61+local-13) id ; Mon, 1 Nov 1993 06:50:47 -0800 Received: by darkstar.isi.edu (5.65c/5.61+local-15) id ; Mon, 1 Nov 1993 06:50:46 -0800 Date: Mon, 1 Nov 1993 06:50:46 -0800 Message-Id: <199311011450.AA26715@darkstar.isi.edu> From: Clifford Neuman To: ietf-aac Subject: Agenda for AAC working group meeting Authorization and Access Control Working Group (aac) MONDAY, 01 NOVEMBER 1993 1600-1800 Afternoon Sessions II SEC Authorization and Access Control WG (aac) (Clifford Neuman/ISI) Mailing lists: General Discussion:ietf-aac@isi.edu To Subscribe: ietf-aac-request@isi.edu Archive: prospero.isi.edu:~/pub/aac/* There will be a meeting of the Authorization and Access Control working group on Monday afternoon at the Houston IETF. The goal of this working group is to develop guidelines, application programmer interfaces, and common credential representations and characteristics through which network accessible applications can specify access control information. AGENDA 1. Presentation of a revised list of restrictions and privilege attributes needed by applications and existing security systems, and a proposed method for representing them. 2. Discussion of the information maintained in the security context, and where it should come from. The security context maintains information about the user that is used to make authorization decisions. 3. Discussion of the intended use of the attributes by applications, ACL formats for an authorization API, and discussion of an API to provide a simple interface for application developers. 4. Discussion of guidelines for adding authorization to a network accessible applications. These guidelines should be written and released initially as an Internet Draft, and eventually as an informational RFC. 5. Discussion of how to proceed. 6. Other business 7. Adjourn From P.V.McMahon.rea0803@oasis.icl.co.uk Tue Nov 2 14:33:57 1993 Received: from relay1.pipex.net by venera.isi.edu (5.65c/5.61+local-14) id ; Tue, 2 Nov 1993 06:33:03 -0800 Received: from Q.icl.co.uk by relay1.pipex.net with SMTP (PP) id <20782-0@relay1.pipex.net>; Tue, 2 Nov 1993 14:32:35 +0000 Received: from ming.oasis.icl.co.uk by Q.icl.co.uk (4.1/icl-2.9-server) id AA00310; Tue, 2 Nov 93 14:34:29 GMT Received: from trojan.oasis.icl.co.uk on ming.oasis.icl.co.uk id AA21960; Tue, 2 Nov 93 14:33:24 GMT Message-Id: <9311021433.AA04245@getafix.oasis.icl.co.uk> Date: Tue, 2 Nov 93 14:33:57 GMT From: P.V.McMahon.rea0803@oasis.icl.co.uk Reply-To: P.V.McMahon.rea0803@oasis.icl.co.uk Subject: access control framework To: ietf-aac AAC WG: For the work of the AAC in defining an authorisation APi to be successful, and to assist application writers in incorporation of access control into their design, there needs to be a common understanding of access control functionality, and how it relates to authentication, and the run-time and management implications. In an effort to progress this, I have written a short note on the architectural framework within which distributed authorisation fits, the placement of authorisation functionality, and some of the existing experience in this area. I would be interested in feedback on the value (or otherwise) of such a document, whether an I-D covering this area would be useful, as well as any comments on the technical content of the draft. The note is called "Access Control in Distributed Systems" (ref Ses/Paper/015, Draft Issue 3) and I have some paper copies with me which anyone interested can pick up at this afternoon's CAT meeting, and I'll put out a on-line version (POSTSCRIPT only) later this month. Regards, Piers ------------------------------------------------------- P V McMahon 02NOV93 ICL Enterprises 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 ------------------------------------------------------- From rsalz@osf.org Fri Nov 12 10:03:51 1993 Received: from postman.osf.org by venera.isi.edu (5.65c/5.61+local-14) id ; Fri, 12 Nov 1993 12:03:44 -0800 Received: from sulphur.osf.org by postman.osf.org (5.64+/OSF 1.0) id AA14822; Fri, 12 Nov 93 15:03:43 -0500 Received: by sulphur.osf.org (1.37.109.4/4.7) id AA02768; Fri, 12 Nov 93 15:03:51 -0500 Date: Fri, 12 Nov 93 15:03:51 -0500 From: rsalz@osf.org Message-Id: <9311122003.AA02768@sulphur.osf.org> To: bcn, ietf-aac Subject: Re: Revised list of restrictions and privelege attributes I am having a bit of trouble understand this whole first paragraph. Either some ASCII art, or a concrete example showing a user doing something like FTP speaking to an ftp server on another machine? > A proxy inherently grants certain rights The server that controls the data (i.e., the reference monitor) is the entity that actually grants the rights -- it interprets the chain and decide whether or not to satisfy the request. > A flags >field associated with each kind of attribute encodes the appropriate >behavior if the interpretation of the attributed is not known. Reading the next section (Attributes and Restrictions), however, makes me think that I'm reading this wrong and that you do really intend to attach rights to identities, and not attach rights to objects inside the server. Is that right? If so, that's wrong. :-) Can someone explain why the Posix ACL model is not sufficient? >Conceptually, the DCE privilege attribute certificate specifies both >group information and the local UID. The name of the privilege server >is derived from the name of the principal signing the proxy. A DCE pac does not include a local UID. This information is available through the DCE security service, but it is *never* used in making DCE authorization decisions. It is also important to note that a DCE PAC never includes any rights. It contains only a set of DCE UUID's which identify the user and their group membership(s). There are various levels of certification which can be used on this data. The strictest is that a Kerberos-like session key is used to encrypt the PAC so that only the server can decrypt it; as an intermediate level it can be crypto checksum'd just to make it tamperproof. >encourage the use of GROUP_MEMBERSHIP and LOCAL_UID instead. Using LOCAL_UID is probably not a good idea; what does that mean on an MSDOS machine talking to an MVS and Unix server? /r$ From P.V.McMahon@rea0803.wins.icl.co.uk Sat Nov 13 20:32:15 1993 Received: from relay2.pipex.net by venera.isi.edu (5.65c/5.61+local-14) id ; Sat, 13 Nov 1993 12:34:29 -0800 X400-Received: by mta relay2.pipex.net in /PRMD=pipex/ADMD=cwmail/C=GB/; Relayed; Sat, 13 Nov 1993 20:34:12 +0000 X400-Received: by /PRMD=icl/ADMD=gold 400/C=GB/; converted (ia5 text (2)); Relayed; Sat, 13 Nov 1993 20:32:15 +0000 Date: Sat, 13 Nov 1993 20:32:15 +0000 X400-Originator: P.V.McMahon@rea0803.wins.icl.co.uk X400-Recipients: ietf-aac@ISI.EDU X400-Mts-Identifier: [/PRMD=icl/ADMD=gold 400/C=GB/;rea0803 0000016300007703] Original-Encoded-Information-Types: undefined (0) X400-Content-Type: P2-1984 (2) Content-Identifier: 7703 From: P.V.McMahon@rea0803.wins.icl.co.uk Message-Id: <"7703*/I=PV/S=McMahon/OU=rea0803/O=icl/PRMD=icl/ADMD=gold 400/C=GB/"@MHS> To: ietf-aac Subject: RE*2: Revised list of restrictions and privelege attributes I guess Cliff will reply too. Here is my 0.02 on Rich's remarks: > I am having a bit of trouble understand this whole first paragraph. > Either some ASCII art, or a concrete example showing a user doing > something like FTP speaking to an ftp server on another machine? > > > A proxy inherently grants certain rights > > The server that controls the data (i.e., the reference monitor) is > the entity that actually grants the rights -- it interprets the > chain and decide whether or not to satisfy the request. The definition of "rights" you suggest here is (I believe) needlessly narrower that the conventional one, and seems to seek to give new semantics to a normal English term. For most systems including those outside the IT system world it is normal to consider as logically separate the notions of (1) possessing rights, and (2) seeking authorisation for a specific operation. It seems inappropriate to conflate the two concepts. > > > A flags > >field associated with each kind of attribute encodes the appropriate > >behavior if the interpretation of the attributed is not known. > > Reading the next section (Attributes and Restrictions), however, makes me > think that I'm reading this wrong and that you do really intend to attach > rights to identities, and not attach rights to objects inside the server. > Is that right? If so, that's wrong. :-) Possession of a proxy (suggested general term which includes e.g.: DCE privilege attribute cert) permits the assignee to assert privileges granted by the assigner subject to specified restrictions. > > Can someone explain why the Posix ACL model is not sufficient? I assume that by the term "POSIX ACL model", you mean the general concept of POSIX.6 D13 ACLs, ACLEs, and a non-POSIX-specific abstraction of the POSIX.6 ACL evaluation algorithm (as DCE has, give or take the mask which should be back in in the next draft anyway). If so, I would be interested in learning where you see inconsistencies as I believe that what is being proposed in the AAC WG is reasonably compatible with the POSIX ACL model. My view is that while the POSIX ACL model doesn't support restrictions, it otherwise provides a reasonable framework for defining authorisation management information outside the POSIX system, unlike other possible candidates such as say, the X.500 access control model, which is excessively complex and too restrictive, and the Netware NDS model which is not adequately restrictive. > >Conceptually, the DCE privilege attribute certificate specifies both > >group information and the local UID. The name of the privilege server > >is derived from the name of the principal signing the proxy. > > A DCE pac does not include a local UID. This information is available > through the DCE security service, but it is *never* used in making DCE > authorization decisions. It is also important to note that a DCE PAC > never includes any rights. See previous remark about "rights". > It contains only a set of DCE UUID's which > identify the user and their group membership(s). There are various > levels of certification which can be used on this data. The strictest > is that a Kerberos-like session key is used to encrypt the PAC so that > only the server can decrypt it; as an intermediate level it can be crypto > checksum'd just to make it tamperproof. > > >encourage the use of GROUP_MEMBERSHIP and LOCAL_UID instead. > > Using LOCAL_UID is probably not a good idea; what does that mean on > an MSDOS machine talking to an MVS and Unix server? My understanding about DCE1.1 (without posessing the functional spec which you have) is that the legacy system support extension (RFC6) uses a UUID to identity each extended registry attribute type. True? It was suggested during the 01NOV93 AAC meeting that the LOCAL_UID be qualified in an analagous way with the identity of the applicable system so you know whether it applies to UNIX, MVS, or indeed DOS (not). Piers ------------------------------------------------------- P V McMahon 13NOV93 ICL Enterprises 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 ------------------------------------------------------- From bcn Sun Nov 21 09:31:35 1993 Received: from tgo.isi.edu by venera.isi.edu (5.65c/5.61+local-14) id ; Sun, 21 Nov 1993 17:31:41 -0800 Date: Sun, 21 Nov 93 17:31:35 PST Posted-Date: Sun, 21 Nov 93 17:31:35 PST Message-Id: <9311220131.AA02668@tgo.isi.edu> Received: by tgo.isi.edu (4.1/4.0.3-4) id ; Sun, 21 Nov 93 17:31:35 PST From: Clifford Neuman To: ietf-aac Subject: Minutes from Houston Attached is a draft of the minutes from Houston. My apologies for being so late with them. I am sending these minutes in for the proceedings, but if you have suggestions for changes, please let me know, as I will probably be able to send a revised version if they haven't done their editing yet. If you have any comments, I would like them by tomorrow (Monday) night if possible. Thanks, and sorry for the short notice. ~ Cliff --- Minutes of the Authorization and Access Control WG (AAC) Houston, Texas, USA IETF November 1 1993, 4:00 PM Chair: B. Clifford Neuman University of Southern California Information Sciences Institute The Authorization and Access Control working group met at the November IETF. The agenda for the meeting was: . Presentation of a revised list of restrictions and privilege attributes needed by applications and existing security systems, and a proposed method for representing them. . Discussion of the information maintained in the security context, and where it should come from. The security context maintains information about the user that is used to make authorization decisions. . Discussion of the intended use of the authorization attributes by applications, ACL formats for an authorization API, and discussion of an API to provide a simple interface for application developers. . Discussion of guidelines for adding authorization to network accessible applications. These guidelines should be written and released initially as an Internet Draft, and eventually as an informational RFC. The charter, past minutes, mailing-list discussions, and other documents mentioned in these minutes are available by anonymous FTP from prospero.isi.edu in the directory /pub/aac. Requests to be added to the working group mailing list should be directed to ietf-aac-request@isi.edu. The purpose of the the initial work on a framework to represent security attributes and restrictions is to provide a uniform framework for both distributed authorization and local authorization. Local authorization will be based on access control lists. Distributed authorization will be based on proxies. Both have common elements. These elements (or attributes) may be stored on access control list entries on security servers, carried in credentials, and evaluated on the end system the same way they would be evaluated if stored on an access control list maintained by the end system itself. 1. Presentation of a revised list of attributes and restrictions At the Amsterdam IETF, there was concern that the representation of all rights conveyed by a set of credentials as restrictions on rights possessed by the grantor of those credentials was confusing. A revised framework for representing rights and restrictions on those rights was sent to the mailing list and presented at the meeting. In the Amsterdam discussion, the use of the term certificate was also confusing. The revised framework uses the term proxy which is less confusing, though more closely tied to one particular proposed implementation of the framework. In the revised framework for representing privileges, privileges are conveyed by proxies. Proxies enumerate positive rights they convey, but these rights are limited by the rights available to the principal that signed the proxy (the grantor). Some proxies specify that all rights available to the grantor are conveyed, supporting unrestricted delegation or authentication forwarding. Proxies may be further restricted to limit the rights that are conveyed. Certain restrictions require the presentation of additional proxies called endorsements before the original proxy may be used. A proxy and all required endorsements together form a proxy chain (a proxy that doesn't require endorsements constitutes a chain by itself). Endorsement may apply additional restrictions. The restrictions specified by each proxy in a chain are applied, resulting in a more restricted set of rights. A principal may collect multiple independent proxy chains, and the rights granted by each chain are added providing additional rights. . Attributes and Restrictions A structured set of authorization attributes are associated with each proxy. Each attribute in the set is typed, and the interpretation of the data associated with the attribute is determined by its type. Some types of attributes are specific to specific servers. A flags field associated with each kind of attribute encodes the appropriate behavior if the interpretation of the attributed is not known. The two possible behaviors are rejection of the request, or ignoring the attribute. Attributes are further divided into three classes: privilege attributes, restrictions, and aggregates. The class is also encoded in the flags field. Privilege attributes identify some operation that is permitted, or assert identifying information such as group information or user identifiers that grant additional rights to the principal that presents a proxy. Privilege attributes may be placed in a proxy only at the time it is created. They may not be added subsequently, and they may not appear in endorsements. Further, in order for a privilege attribute to apply, the principal granting the proxy must possess the ability to grant such an attribute. (though privilege attributes grant rights, they are interpreted as explicitly enumerating the rights that are to be granted by a proxy and all other rights are presumed not to be granted by the proxy). Restrictions specifically remove rights from those conveyed by a proxy, or they place additional constraints on when, how, where, or by whom a proxy may be exercised. Restriction may be present when a proxy is initially created, they may be added subsequently and they may be present in endorsements. Restrictions that are present in a required endorsement are applied in addition to the restrictions present in the proxy that is endorsed. Aggregate attributes may be positive (privilege attributes) or negative (restrictions). The rules about where each may appear apply to aggregates as well. An aggregate attribute encapsulates a set of attributes and specifies how they are to be interpreted. One form of aggregate limits the application of a set of attributes to a particular end server or a particular application. . Discussion After the initial presentation several questions were raised. Among the questions was how one determines which principals are authorized to issue proxies granting particular rights. The end server will still have to maintain access control lists for this information, but these ACLs only contain the names of the principals that grant rights for an operation, rather than those authorized to perform the operation. Presumably this information changes less frequently, and is more compact. Checking these ACLs would be handled by the authorization API, so the client does not have to worry about it directly. The contents of this ACL might be specified by a configuration option for the local system. This check might be done when establishing a security context for a request or a login session, on the remote machine. Ted T'so commented that the information about the grantor of a privilege should be carried along as extra information in the security context even after verification, so that an application that has special requirements can check it. Another issue raised was concern about placing too of the burden on the application programmer to interpret such proxies and proxy chains. In fact, the interpretation would be handled by two APIs, one of which would be specific to the distributed authorization method in use, and one would be the authorization API which was discussed later in the meeting. This latter API will take several arguments, and answer yes or no indicating whether an operation is to be allowed. . Enumeration of attributes and restrictions An initial set of positive and negative attributes was presented and it was discussed how they fit into the revised framework. Some of the attributes are application specific, and other application specific attributes can be defined. The positive privilege attributes can only be grated in an initial proxy and can not be added subsequently, to augment rights. In enumerating an initial set, a goal was to cover the rights needed and used by various distributed authorization mechanisms including ECMA, DCE, and restricted proxies. Among the positive attributes were: LOCAL-UID - set UID for local system GROUP-MEMBERSHIP - enumerate local groups to be used locally DCE-PAC - globally unique groups and uuids AUTHORIZED - encodes list of objects and rights for objects QUOTA - like authorized, but specifies numeric limit Other suggested positive attributes include ROLE - to include rights of individual in particular role ALL - which might be needed to mean all rights of grantor For the AUTHORIZED attribute, the encoding of the identified objects and the rights on those objects would be application specific, and opaque to other parts of the system. Among the negative attributes were: FOR-USE-BY-PRINCIPAL - who may use a proxy, or compound principal FOR-USE-BY-GROUP - only members of group may use proxy ACCEPT-N-TIMES - can only be exercised N times on a given server VALID-TIME-OF-DAY - e.g. can only be used between 9AM and 5PM VALID-PERIOD - expires after, not good until NETMASK - application specific, used by network access server FOR-USE-ON-SERVER - identifies specific server where proxy is valid FOR-USE-FROM - local terminal, secure area, not sure how to implement Other suggestions for negative attributes included a means to restrict the day of the week (for example, only Monday through Friday). John Linn made the observation that given that time of day is a one time decision, once logged in, one can do whatever one wants. This can be addressed if the application checks periodically, or notes the end time during the initial check and requires reauthorization at that time. We can make it easier for applications to note the end of the authorization period if an expiration time were returned as an additional value by the authorization API. Some applications would use this expiration time, while others might not. Some systems, AFS in particular, do note the expiration of credentials. Finally, though login has a one time authorization check, other operations like file accesses might not. It was also pointed out that the negative attributes did not include the ability to exclude enumerated rights. This might be useful so that one can list a broad class of positive attributes, then enumerate exceptions as negative attributes. Thus, we can add the restriction: EXCLUDE - excludes list of objects and rights for objects The encoding of the objects and rights for EXCLUDE would be application specific. It was suggested that there be a way to combine positive attributes from separate proxies into a single proxy. Unfortunately, this is clearly not possible when the rights conferred are granted by different principals. When granted by a the same principal, a proxy can be granted to enumerates multiple rights. Combining them after multiple proxies have been issued, however, requires the reissuance of the combined proxy by the grantor. There was some discussion of how the attributes are related to the authorization API. This discussion appears later in the minutes. Due to the limited time for the meeting, the aggregate attributes were not discussed at the meeting, but are described in the message sent out to the mailing list. 2. Discussion of information maintained in security context Piers McMahon noted that authorization decisions would be made on two types of application servers: (a) servers which handle multiple requests within a single process (e.g. DCE RPC), and (b) per-request daemons (e.g.: telnet). He concluded that the authorization security context in the authorization API must be able to refer to either a security context (for the former case) or a delegated credential (for the latter case). In order to make the authorization API simpler, he also suggested that the GSS-API gss_accept_sec_context should always return a credential which could then be used consistently to represent the authorization context (in an analogous way to the DCE login context) even if delegation wasn't enabled for this context. Ted T'so warned that this might inappropriately overload the GSS-API credential, as such non-delegated "credentials" couldn't be used to initiate contexts. In response Piers observed that this was also true for acceptor usage credentials, and suggested that the "usage" of the credential could be perhaps extended to include an "accepted security context" type in addition to initiator and acceptor. After some further exchanges, it was agreed that further discussion on this topic should be carried on in the CAT WG. John Linn commented that it might be appropriate to add a primitive inquire_security_context, to to query information from the security context, and perhaps a similar primitive to add information to the security context after it is initially established. 3. Discussion of the authorization API A one page handout was distributed that outlined the arguments to the check_authorization function in the authorization API. Some of the goals in the design of the API were that it be simple to use for simple applications, but extensible and also easily usable by applications that have additional constraints and more advanced requirements for authorization. The arguments to the check authorization function are described below: answer = check_authorization(det_answer,/* Detailed answer (out) */ sc, /* Security context */ target, /* Object to be manipulated */ operation, /* Operation to be performed */ parameters)/* Modifiers to request */ In the interest of providing a simple interface to most applications, the authorization API returns an answer of yes (0), no (2), or maybe (1). Simple applications would treat this as yes, or not yes. Further, the first argument to the API is an out parameter containing extra information that may be used by more advanced applications if the answer is a maybe. This structure might also contain information about when the authorization so granted is due to expire. The form of the security context, the second argument, was already discussed. Ideally, information to be contained in the security context will include the following elements: verified authentication information - gssapi, uuids, groups unverified authentication information - to be checked when needed verified & unverified authorization information - proxies, etc delegated authorization credentials - to be used with other servers It should be possible to add to the security context subsequent to its initial creation. This might allow lazy verification of authorization credentials (i.e. don't verify them until they are needed for an operation), as well as requests for additional credentials from clients for certain operations. The third argument identifies the target of the operation for which authorization is to be checked. This would typically be a null terminated string with the name of the object. The namespace from which the name is drawn can be local to an application. Names for different applications can be made distinct by specifying a namespace identifier in the parameters argument described later. There was a question raised about ACL management. In particular, it wasn't clear where there was one manager for all the ACLs, or whether the application stores the ACL itself. In fact, we want to support both models. For the latter model, one might want to pass in the ACL as an argument, rather than the name of the object which would then be looked up by the ACL manager. One way to support this is using an additional flag in the parameters argument that would indicated that the target argument is a pointer to the actual ACL. There was a suggestion to use object identifiers to identify the target, but the answer is that we really don't need them. If you have them you an use them as one of the name spaces, but you will not always have object identifiers as the names of objects in an application. Only if the application uses OIDs, would this be the name of the targets. A separate name space for OIDs is easily supported in the parameters. The fourth argument is a pointer to a bit vector identifying the operations for which authorization is being checked, or the bit vector itself if less than 32 bits. How the field is interpreted depends on flags in the parameter argument. The parameter argument also tells how the bits are to be interpreted so that privilege bits from one application (meaning certain rights) are not confused with those from other applications that might mean something different. The final argument is the parameters argument. This argument describes the behavior of the API. It is expected that the argument will remain fixed for a particular application. It defines how the other arguments are to be interpreted. It identifies the name space of the object names and the form of the other arguments. The same structure would be passed on all calls to check authorization. . Access control list entries The access control lists used by the API are similar to those in common use today. An access control list will be associated with each object to be protected. Entries in the list will identify the principals or groups authorized access by that entry. The principal and group specified will be matched against the principal and group identifiers in the security context by the authorization API. The rights specifically authorized by the entry will be specified in the entry as a tagged bit vector. The tag indicates how the bits in the bit vector are to be interpreted. The ACLs will be extended beyond those in common use today in that each entry will have an optional additional list of restrictions (the negative attributes described earlier in the minutes). This list of restrictions places additional constraints on the access granted. For example, it might allow access to be granted only between 9AM and 5PM, or the access might expire at a particular date and time. Restrictions in an ACL entry might also encode which intermediaries are allowed to be involved when authenticating principals that use the entry. Simple applications will never see these restrictions. Instead, they will be evaluated by the authorization API itself, and the yes/no answer seen by the application will already reflect the result of that evaluation. . Use of the authorization API by advance applications More advanced applications will rely on additional information returned in the detailed answer argument. Among the information returned will be an expiration time for access so granted if such a restriction in the ACL entry is present or if the expiration time of any authentication or authorization credentials is known. Further, the authorization API can return an answer of maybe, indicating that restrictions (negative attributes) were present in authorization credentials or access control list entries that could not be interpreted directly by the authorization API. This is likely to be the case if application specific restrictions were used. When such an answer is returned, the unresolved restrictions are returned to the application in the detailed answer structure. This list will then be checked by the application using a fairly well defined procedure, plugging local checks into boilerplate restriction checking code that we will provide. The network access server will provide a good example of how such checks are to be performed, and a description of the use of the authorization API by the network access server should be included in documents describing the mechanism. 4. Discussion of guidelines document There was a brief discussion about the development of a set of guidelines for application developers on how to support fine grained authorization for network accessible applications. This document would be released initially as an Internet draft and then as an information RFC. The advice would be basic. For example, advising the developer to first look through the application and identify the objects to be protected, and the granularity of the objects to be protected: is it a file, is it something more general, or more specific. The document would then work through how one would use the API we are developing. The document should also discuss design implications of particular choices, especially with respect to how long authorization continues (i.e. whether you check the returned expiration time), and whether authorizations checks are per session, or per operation, as well as issues related to the granularity of the objects that are protected. The document would give an example of the use of the authorization API for a simple application that just uses the yes/no answer, and for a more advanced application such as the network access server that makes use of application specific restrictions. 5. How to proceed The meeting concluded with a brief discussion of how to proceed. Work items include refining the authorization API and developing real code, coming up with a revised definition of the security context, revising the list of authorization attributes, and writing the guidelines document. Piers will continue his work on the security context in part here, and in part in the CAT working group. Cliff will work with Piers on the security context, and will work on the other work items. John Vollbrecht will work on the section of the guidelines document describing how the network access server uses the authorization API. Minutes submitted by Clifford Neuman with portions provided by Piers McMahon. From rsalz@osf.org Mon Nov 22 04:37:53 1993 Received: from postman.osf.org by venera.isi.edu (5.65c/5.61+local-14) id ; Mon, 22 Nov 1993 06:37:49 -0800 Received: from sulphur.osf.org by postman.osf.org (5.64+/OSF 1.0) id AA06726; Mon, 22 Nov 93 09:37:46 -0500 Received: by sulphur.osf.org (1.37.109.4/4.7) id AA09648; Mon, 22 Nov 93 09:37:53 -0500 Date: Mon, 22 Nov 93 09:37:53 -0500 From: rsalz@osf.org Message-Id: <9311221437.AA09648@sulphur.osf.org> To: P.V.McMahon@rea0803.wins.icl.co.uk, ietf-aac Subject: Re: RE*2: Revised list of restrictions and privelege attributes > I guess Cliff will reply too. Here is my 0.02 on Rich's remarks: He has not. I continue to be very disappointed in the way the IETF security WG's operate in that it is impossible for someone to contribute without attending the meetings in person. This is a shame. I cannot respond in detail to Pier's points because I am still confused. As I said in my first message: > > I am having a bit of trouble understand this whole first paragraph. > > Either some ASCII art, or a concrete example showing a user doing > > something like FTP speaking to an ftp server on another machine? > The definition of "rights" you suggest here is (I believe) needlessly > narrower that the conventional one, and seems to seek to give new > semantics to a normal English term. For most systems including those > outside the IT system world it is normal to consider as logically > separate the notions of (1) possessing rights, and (2) seeking authorisation > for a specific operation. It seems inappropriate to conflate the two > concepts. I disagree that my use of the "rights" is constricted or unusual. My intent is to put things into the simplest possible terms: a client presents a list of "things" which say "I am John. Bob also says I'm his cousin." He presents this list (which is his identity) with his request "I want to read the 'foo' database" to the server. The server decides whether or not John can read 'foo' and takes the appropriate action. As I read the document, the client says "I am John. Bob says I can read 'foo'. I want to read 'foo'". Is that right? If not, what is a right? My model says a client merely has an identity, and the server decides if the client has the correct rights to perform the requested operation. > Possession of a proxy (suggested general term which includes e.g.: DCE > privilege attribute cert) permits the assignee to assert privileges granted > by the assigner subject to specified restrictions. I think proxy is a bad term. When I send a print /tmp/foo request to the printer, then the printer system will be acting as my proxy when, later, it asks the filesystem for the contents of that file. > My understanding about DCE1.1 (without posessing the functional spec > which you have) is that the legacy system support extension (RFC6) uses a > UUID to identity each extended registry attribute type. True? I'm not sure what you mean by "extended registry attribute type." An extended attribute, e.g., MVS login information, is identified by a uuid. The type and value of that data is separate from the attribute; the uuid is basically the name so that attributes are really name/type/value triplets. > It was suggested during the 01NOV93 AAC meeting that the LOCAL_UID be > qualified in an analagous way with the identity of the applicable system > so you know whether it applies to UNIX, MVS, or indeed DOS (not). So I get something like ? Does it really help to know "1440" without, say, qualifying it by sulphur.osf.org? /r$ From bcn Mon Nov 22 13:49:08 1993 Received: from darkstar.isi.edu by venera.isi.edu (5.65c/5.61+local-14) id ; Mon, 22 Nov 1993 21:49:17 -0800 Received: by darkstar.isi.edu (5.65c/5.61+local-16) id ; Mon, 22 Nov 1993 21:49:08 -0800 Date: Mon, 22 Nov 1993 21:49:08 -0800 Message-Id: <199311230549.AA01043@darkstar.isi.edu> From: Clifford Neuman To: rsalz@osf.org Cc: ietf-aac In-Reply-To: rsalz@osf.org's message of Mon, 22 Nov 93 09:37:53 -0500 <9311221437.AA09648@sulphur.osf.org> Subject: RE*2: Revised list of restrictions and privelege attributes From: rsalz@osf.org To: P.V.McMahon@rea0803.wins.icl.co.uk, ietf-aac@ISI.EDU Subject: Re: RE*2: Revised list of restrictions and privelege attributes I continue to be very disappointed in the way the IETF security WG's operate in that it is impossible for someone to contribute without attending the meetings in person. This is a shame. I will respond to your comments. I have been swamped, witness my getting the minutes out so late. It is certainly not my intent to exclude people that don't attend the IETFs. In fact, I want to encourage such participation. If my delay in responding has given another impression, for that I apologize. ~ Cliff From rsalz@osf.org Tue Nov 23 04:04:43 1993 Received: from postman.osf.org by venera.isi.edu (5.65c/5.61+local-14) id ; Tue, 23 Nov 1993 06:04:38 -0800 Received: from sulphur.osf.org by postman.osf.org (5.64+/OSF 1.0) id AA12788; Tue, 23 Nov 93 09:04:36 -0500 Received: by sulphur.osf.org (1.37.109.4/4.7) id AA11354; Tue, 23 Nov 93 09:04:43 -0500 Date: Tue, 23 Nov 93 09:04:43 -0500 From: rsalz@osf.org Message-Id: <9311231404.AA11354@sulphur.osf.org> To: bcn Subject: Re: RE*2: Revised list of restrictions and privelege attributes Cc: ietf-aac > If my delay in responding has given another impression, for that I apologize. It's not (just) you. The CAT list never gets any mail other then one or two messages when I tried to argue against ASN.1. And so on ... /r$ From williams@williams.arc.nasa.gov Wed Dec 15 09:21:34 1993 Received: from williams.arc.nasa.gov by venera.isi.edu (5.65c/5.61+local-14) id ; Wed, 15 Dec 1993 17:21:52 -0800 Received: Wed, 15 Dec 93 17:21:34 PST by williams.arc.nasa.gov (4.1/1.2) Date: Wed, 15 Dec 93 17:21:34 PST From: Peter Williams Message-Id: <9312160121.AA11982@williams.arc.nasa.gov> To: ietf-aac Subject: piers_draft_access_control_frmwk_03.ps.Z -rw------- 1 bcn staff 40280 Nov 16 23:50 piers_draft_access_control_frmwk_03.ps.Z on prospero.isi.edu pub/aac. please could the permission bits be changed to allow greater access? Peter. From Pope@secstan.demon.co.uk Tue Jul 12 21:54:36 1994 Received: from quark.isi.edu by venera.isi.edu (5.65c/5.61+local-14) id ; Tue, 12 Jul 1994 15:06:27 -0700 Received: from post.demon.co.uk by quark.isi.edu (5.65c/5.61+local-16) id ; Tue, 12 Jul 1994 15:06:20 -0700 Received: from secstan.demon.co.uk by post.demon.co.uk id aa14258; 12 Jul 94 22:29 GMT-60:00 Date: Tue, 12 Jul 94 21:54:36 GMT Message-Id: <65@secstan.demon.co.uk> From: Nick Pope Organization: Security and Standards Reply-To: Pope@secstan.demon.co.uk To: ietf-aac Subject: Is this topic dead? X-Mailer: Newswin Alpha 0.6 Lines: 18 Has there been any interest in progressing the proposed API? Has anyone produced any proposals? Or is this activity likely to drop into oblivion. If there are any proposed API specifications can someone give me a FTP reference. Nick Pope Security & Standards Chelmsford England Tel: +44 245 495018 Fax: +44 245 494517 From bcn Tue Jul 12 09:39:14 1994 Received: from darkstar.isi.edu by venera.isi.edu (5.65c/5.61+local-14) id ; Tue, 12 Jul 1994 16:39:27 -0700 Received: by darkstar.isi.edu (5.65c/5.61+local-17) id ; Tue, 12 Jul 1994 16:39:14 -0700 Date: Tue, 12 Jul 1994 16:39:14 -0700 Message-Id: <199407122339.AA24244@darkstar.isi.edu> From: Clifford Neuman To: Pope@secstan.demon.co.uk Cc: ietf-aac In-Reply-To: Nick Pope's message of Tue, 12 Jul 94 21:54:36 GMT <65@secstan.demon.co.uk> Subject: Is this topic dead? Date: Tue, 12 Jul 94 21:54:36 GMT From: Nick Pope Has there been any interest in progressing the proposed API? No, and unfortunately again, it hasn't been done sufficiently far in advance to deal with this at the Toronto IETF. However, I am hoping to get a document together by the IETF even though we won't be meeting. You've heard this before though. ~ Cliff From P.V.McMahon@rea0803.wins.icl.co.uk Wed Jul 13 03:31:18 1994 Received: from relay1.pipex.net by venera.isi.edu (5.65c/5.61+local-14) id ; Wed, 13 Jul 1994 04:48:39 -0700 X400-Received: by mta relay1.pipex.net in /PRMD=pipex/ADMD=pipex/C=gb/; Relayed; Wed, 13 Jul 1994 02:32:40 +0100 X400-Received: by /PRMD=icl/ADMD=gold 400/C=GB/; converted (ia5 text (2)); Relayed; Wed, 13 Jul 1994 02:31:18 +0100 Date: Wed, 13 Jul 1994 02:31:18 +0100 X400-Originator: P.V.McMahon@rea0803.wins.icl.co.uk X400-Recipients: non-disclosure:; X400-Mts-Identifier: [/PRMD=icl/ADMD=gold 400/C=GB/;rea0803 0000016300010321] Original-Encoded-Information-Types: undefined (0) X400-Content-Type: P2-1984 (2) Content-Identifier: 10321 Priority: Urgent From: P.V.McMahon@rea0803.wins.icl.co.uk Message-Id: <"10321*/I=PV/S=McMahon/OU=rea0803/O=icl/PRMD=icl/ADMD=gold 400/C=GB/"@MHS> To: Pope@secstan.demon.co.uk Cc: ietf-aac In-Reply-To: <65@secstan.demon.co.uk> Subject: RE: Is this topic dead? Nick, > Has there been any interest in progressing the proposed API? Has > anyone produced any proposals? Or is this activity likely to drop into > oblivion. I think that there is interest, but other work items have higher priority ... The official status (from the SAAG minutes): * wi029: Authorization and Access Control WG (Updated 04/94) The authorization and access control draft that exists will be revised and get a final working group review in Toronto before being submitted for publication as an informational document. At that time the charter of this working group will be revised. > If there are any proposed API specifications can someone give me a FTP > reference. See the Houston minutes which summarise discussions to date. These were posted to the list and are available on-line and in the proceedings I have been looking at this area in the context of another project. I was holding off posting until I had an implementation which was suitable for wider distribution, however since you asked I would be interested in any comments you (or others) have on the following Piers --- ACCESS DECISION FUNCTION 23MAY94 pvm 1. Summary In support of the goal of a generic access decision function interface, this paper discusses related work in XDSF (POSIX.22), POSIX.6, and DCE, and then proposes a portability model (as considered in IETF AAC). 2. References The following are referenced by this paper: [POSIX.6] Protection, Audit, and Control Interfaces P1003.1e, draft 14, MAR94 [DCE-ACL] DCE RFC 46, OCT93 [XDSF V3] XDSF Version 3 -- P1003.22 D3 [ISO-AC] ISO Access Control Framework [Ex-GSS] An Extended Generic Security Service API, Ses/Paper/010, Issue 5, 25JAN94 3. XDSF XDSF section 4.3 defines a model for access control based on the ISO access control framework. A number of services are identified, namely: * Access decision function - Decide Access (based on initiator, target, and required action) * Management Services - Install ACI - Modify ACI - Revoke ACI - List ACI - Disable Component (i.e. ADF) - Re-enable Component (i.e. ADF) * Other Operational Services - Acquire Initiator ADI - Acquire Target ADI - Generate Data ADI - Generate Action ADI - Revoke ADI - Verify Action ADI - Get Contextual Information - Bind Initiator ADI - Retrieve Initiator ADI The "other operational services" are given in abstract terms, and while some of likely to be of concern to application developers, others are of concern to mechanism-providers. It would be helpful to develop the operational model more completely. 4. POSIX.6 POSIX.6 defines an ACL (access control list) facility for POSIX.1 files which serves to extend the existing POSIX.1 discretionary access control. The draft standard defines - basic concepts: + ACL semantics (though not the internal respresentation), + ACLEs (i.e.: ACL entries) + ACLE tag type, and the standard POSIX.6 types (ACL_USER, ACL_GROUP, ACL_GROUP_OBJ, ACL_USER, ACL_USER_OBJ, ACL_OTHER_OBJ) + ACLE qualifier, and its definition for ACL_USER and ACL_GROUP + [ACLE] permission set - the algorithm for evaluating ACLs, - rules and functions for the association of ACLs with objects, - functions for manipulating ACLs, and - functions for ACL import/export in text and (implementation- defined) binary format. POSIX.6 functions are defined to: - manage the ACL working storage area - manipulate ACLEs - manipulate fields within ACL entries - read/write an ACL on an object - translate an ACL into different formats POSIX.6 functions to manage the ACL working storage area - acl_dup duplicate ACL data object - acl_free release ACL memory data object - acl_init allocate/initialise ACL data object POSIX.6 functions to manipulate ACL entries - acl_copy_entry copies between ACLEs - acl_create_entry create ACLE - acl_delete_entry delete ACLE - acl_first_entry goto 1st ACLE (start of ACL staorage area) - acl_get_entry get ACLE descriptor - acl_valid report duplicate, missing, ill-formed ACLEs POSIX.6 functions to manipulate fields in an ACL entries - acl_add_perm add permission to permission set - acl_calc_mask initialise ACL_MASK ACLE - acl_check_perm check permission in permission set - acl_clear_perm check all permissions in permission set - acl_delete_perm delete a permissions in permission set - acl_get_qualifier get ACLE qualifier - acl_get_tag_type get ACLE tag type - acl_acl_set_permset get ACLE permission set - acl_set_qualifier set ACLE qualifier - acl_set_tag_type set ACLE tag type POSIX.6 functions to read/write an ACL on an object - acl_delete_def_fd delete default ACL asscciated with fd - acl_delete_def_file delete default ACL associated with file - acl_get_fd get ACL associated with fd - acl_get_file get ACL associated with file - acl_set_fd set ACL assciated with fd - acl_set_file set ACL associated with file POSIX.6 functions to translate an ACL into different formats - acl_copy_ext export ACL in implementation-defined format - acl_copy_int import ACL in implementation-defined format - acl_from_text import ACL in text format - acl_size size implementation-defined format - acl_to_text export ACL in text format 5. DCE DCE 1.0 currently provides an example authorisation facility which is intended to be supplanted in DCE 1.1 by a standard DCE ACL library which includes backing store. DCE 1.0 (and, it is expected, DCE 1.1) implements a generalisation of the POSIX.6 ACL model such that POSIX.6 concepts and POSIX.6 D12 ACL evaluation semantics are followed, but POSIX.6 functions aren't supported. Unlike POSIX.6 (which defines ACLs for POSIX.1 files), DCE defines a set of ACL types for use within DCE, and enables applications to invent their own types (and the different associated "ACL Managers"). However, this means that applications must maintain the link between application objects and ACLs. Like POSIX.6, DCE defines a set of ACLE types (effectively a superset of POSIX.6). DCE ACLEs, again like POSIX.6, contain a type (like the .6 qualifier), type-specific data, and a permission set. The APIs intended to be supported by DCE1.1 are: - dce_acl_register_object_type called to register ACL type - dce_acl_is_client_authorised decide access based on ACL and permissions - dce_acl_inq_client_permissions get initiator permissions - dce_acl_inq_permset_for_PAC get POSIX subset of above - dce_acl_inq_client_pac get (DCE1.0) PAC - dce_acl_obj_create create ACL - dce_acl_obj_free free ACL - dce_acl_obj_add_user_entry add ACLE for user - dce_acl_obj_add_group_entry add ACLE for group - dce_acl_obj_add_id_entry add ACLE for other id - dce_acl_obj_add_unauth_entry add "unauthenticated" ACLE - dce_acl_obj_add_obj_entry add general ACLE - dce_acl_obj_add_foreign_entry add "foreign" ACLE In order to enable the ACL manager to get the ACL associated with an object, each application developer must use a default "resolver" function, or specify its own 6. General Portability Model For maximum applicability, an authorisation facility and the associated interfaces should be able to work in a number of different distributed environments. The mechanism for retrieval of the client's ADI and its representation may, and in practice do, differ between mechanisms such as: - Kerberos - DCE - X.500 - Netware - NT/Cairo - SESAME - TMACH (see Ex-GSS for an overview of these mechanisms) Furthermore, a model is needed which allows for existing distributed applications to use authorisation services independent of how the acquisition of client ADI is achieved such that application logic is unaffected by migration towards distribited systems. Given that applications may implement complex access control mechanisms, it is important to separate out generic ADF functions from applications-specific ones. The following figure identifies the main interfaces associated with general model for software access decision functionality: +----------------------+----------------------+ +-----------------+ | | | | | | Application Service | Application Resource | | Application | | Instance | Access | | Resource | | Initialisation | | | Management | | | | | (including | | | | | possible app- | | | | | specific ADF) | | | | | | +----------------------+----------------------+ +-----------------+ | | | | | | | 2 V 4 V | ========================== ===================== | | | | | | | Access Decision | | ADF SMIB | | | Function (ADF) | | | | | | | | | +----------------------+ +-----------------+ | | | | 1 V 3 V ==================....========================== | | | | | Secure | | Client ADI Retrieval | | Association | | | | | | | +--------------+......+----------------------+ The proposed interfaces are as follows: 1. Secure association The could be implicit for simple applications, or GSS-API (etc) for distributed applications, or an equivalent store-and-forward security API for messaging applications. 2. Access decision function A general interface is needed, this could be of the form developed by the AAC WG: check-authorisation [OUT] output, - boolean or application- specific response [IN] security context, - reference to authentication context (if not defaulted) [IN] target, - objectname with namespace specified in control- parameters [IN] operation, - requested permission (subject to namespace in control parameters) [IN] control-parameters - where control-parameters indicates the name-space and form of the other arguments 3. Attribute retrieval API Insulates whether attributes are obtained from a PAC, local file, or directory. Possibly gss_get_attributes from Ex-GSS. 4. Management API Interface to the ADF SMIB. While different name-spaces can be supported, the complete portability of the above interfaces are dependent on a naming convention being agreed (perhaps based on XFN) which insulates applications from the naming used by specific distributed environments. 7. Conclusions Its is proposed that the following follow-on activities are required: (1) XDSF improvements The XDSF model needs some additional material to: * separate out services of concern to application developers and mechanism providers * provide concrete examples for services identified, in particular the operational services identifier (2) Portability Model Definition of a complete mechanism-independent authorisation facility portability model which takes the best of DCE and POSIX, but doesn't preclude applicability to other environments such as existing application servers, X.500 DSA implementations, and Netware NDS. Section 6, above, is suggested as a starting point with the next steps being: - refinement of specification to a set of C bindings for interfaces 2 and 4 above - agreement of external ACL format - agreement of attribute types and syntaxes (and a registration procedure for new ones) - implementations for stand-alone systems (using either password or Kerberos authentication mechanisms), and distributed authorisation systems (such as DCE, Restricted Proxies, SESAME) ------------------------------------------------------- P V McMahon 23MAY94 ICL Enterprises 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 634882 fax: +44 734 855106 ------------------------------------------------------- From rsalz@osf.org Wed Jul 13 05:58:20 1994 Received: from postman.osf.org by venera.isi.edu (5.65c/5.61+local-14) id ; Wed, 13 Jul 1994 07:00:23 -0700 Received: from sulphur.osf.org (sulphur.osf.org [130.105.5.36]) by postman.osf.org (8.6.9/8.6.x) with SMTP id KAA21425; Wed, 13 Jul 1994 10:00:17 -0400 From: Rich Salz Received: by sulphur.osf.org (1.37.109.4/4.7) id AA02466; Wed, 13 Jul 94 09:58:20 -0400 Date: Wed, 13 Jul 94 09:58:20 -0400 Message-Id: <9407131358.AA02466@sulphur.osf.org> To: P.V.McMahon@rea0803.wins.icl.co.uk, Pope@secstan.demon.co.uk Subject: RE: Is this topic dead? Cc: ietf-aac > DCE 1.0 currently provides an example authorisation facility which > is intended to be supplanted in DCE 1.1 by a standard DCE ACL > library which includes backing store. I'll be more then happy to answer any questions about DCE ACL's. (I designed the ACL and backing store libraries; you can call the ACL evaluation routines without using the storage model). I can probably also make specs available if there is interest. The most interesting thing that will be in DCE 1.1 is a delegation facility. You send your credentials to the printer along with a "you can add yourself" indication. The printer adds itself, and then asks the filesystem for a file so it can print it. > Unlike POSIX.6 (which defines ACLs for POSIX.1 files), DCE defines a > set of ACL types for use within DCE, and enables applications to > invent their own types (and the different associated "ACL > Managers"). However, this means that applications must maintain the > link between application objects and ACLs. It's a little more strong then this: DCE says "if you have these kinds of permissions -- read, write, modify-acl, etc then you *should* use these specific bits to indicate said permissions." I continue to be very disappointed in this mailing list; this note here will be about the fifth message in six months. /r$ From ejw@Direct.CA Sat Nov 19 04:52:45 1994 Received: from mail.Direct.CA (fun.Direct.CA) by venera.isi.edu (5.65c/5.61+local-19) id ; Sat, 19 Nov 1994 12:52:48 -0800 Received: (ejw@localhost) by mail.Direct.CA (8.6.9/8.6.9) id MAA09186; Sat, 19 Nov 1994 12:52:45 -0800 Date: Sat, 19 Nov 1994 12:52:45 -0800 (PST) From: Eric Woodward Subject: subscribe To: ietf-aac Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII subscribe ejw@direct.ca ------------------------------------------------------------------------ Eric Woodward | Pager: +1 (604) 258-4673 Internet Direct, Inc. | Office: +1 (604) 691-1607 Vancouver, BC | Fax: +1 (604) 691-1605 NIC Handle : EW15 | E-mail: ejw@Direct.CA.