Issue 2800: Public Attribute extraneous and inefficient (sec-rev) Source: (, ) Nature: Uncategorized Issue Severity: Significant Summary: Summary: The Public attribute is said to exist for the mere purpose of having at least one credentials object with at least one attribute, if no user has authenticated. (It is entirely debateable of whether a credentials object should exist at all if a prinicpal does not authenticate). It appears the only purpose for this public attribute, which is said to exist in *every* Credentials instance regardless of authentication, is to be able to "grant" rights to *EVERY* principal in a Domain Access Policy. Access Policies (AP), as opposed to Domain Access Policies(DAP) (is an extension of AP) do not have to follow the "grant/revoke/replace" scheme of DAP. Therefore, the Public attribute permiates the entire system just to support an optional Domain Access Policy. In fact that most access decisions will ignore the Public attribute if access is based on other attributes. This situation reveals unecessary copying of data and checking for it. Therefore the public attribute is extraneous and causes inefficiences. A better solution would be to confine the problem of "granting" rights (which is in DAP only) to every principal in a "domain" to the Domain Access Policy interface itself, such as an operation of "void set_base_rights(RightsList rights);" and not permiate the entire system with a useless attribute. And of course, eliminate the Public Security Attribute all together, and all refernces to it. Resolution: Close Issue 2800 _Public Revised Text: Actions taken: July 12, 1999: received issue May 4, 2000: closed issue Discussion: Discussion: Specifying the value of the _Public attribute to have a defining_authority and value as an empty sequence<octet>, and also to stipulate that every Credentials object must have one and only one _Public Attribute. ++Add after paragraph [484], starting with "A Credentials object represents a particular principal’s credentials....." Each Credentials object is mandated to carry at least one and only one attribute of type Public. The Public attribute has a defining authority of OMG, its value is empty, and it serves only to mark the credentials with an attribute stipulating that the principal, authenticated or not, is a member of the "general public". This requirement allows access policies to be specified for the general public in much the same way as policies based on other attributes are specified. ++Change paragraph [574], removing the last two sentences of the first bullet, "If the principal was ... meaningful value", leaving the following: o Privilege attributes for use in access control decisions. o Other attributes, such as authid or charging identities, if available. ++Remove last two sentences of paragraph [1088], starting with "This specification allows unauthenticated...", leaving the following: This specification allows unauthenticated and authenticated users. End of Annotations:===== Reply-To: "Bob Blakley" From: "Bob Blakley" To: , "Juergen Boldt" Cc: "Bob Blakley" Subject: Re: issue 2800 -- Security RTF Issue Date: Mon, 9 Aug 1999 13:15:21 -0500 X-Mailer: Microsoft Outlook Express 4.72.3110.1 >This is issue # 2800 > > Public Attribute extraneous and inefficient I recommend we close this issue with no action taken. >The Public attribute is said to exist for the mere purpose of having at >least one credentials object with at least one attribute, if no user has >authenticated. Agree with everything here except "mere". >(It is entirely debateable of whether a credentials object >should exist at all if a prinicpal does not authenticate). It may be debatable, but the debate has nothing to do with the authorization model being used. The reason credentials objects always exist in CORBAsecurity is that authorization (and some other services such as auditing) assume that a credential is present and act on that assumption. You can think of the existence of a credential as a precondition (in the Hoare-logic or Meyer assertion sense) for calling many of the security interfaces. >It appears the >only purpose for this public attribute, which is said to exist in *every* >Credentials instance regardless of authentication, is to be able to >"grant" rights to *EVERY* principal in a Domain Access Policy. This isn't the case at all. The purpose for this attribute is to not allow a situation in which there is no credential for the currently active context. This is a perfectly sensible requirement, and eliminates the need to create a non-credential-based special case of authorization processing to deal with situations in which a user hasn't authenticated and attempts to access resources. Furthermore, the "public" attribute has nothing whatsoever to do with the DomainAccessPolicy. It's simply a privilege attribute, and should be dealt with properly by all AccessPolicy objects. The CORBA philosophy is that privilege attributes *describe* security-relevant characteristics of their possessors. The "public" attribute describes the known attribute of an unauthenticated user -- namely, that he/she/it is a "member of the general public". AccessPolicy objects are free to make any determination they wish on the basis of possession of this attribute, including that access should be denied (if desired). Not all policies need to do what the DomainAccessPolicy object . >Access Policies (AP), as opposed to Domain Access Policies(DAP) (is an >extension of AP) do not have to follow the "grant/revoke/replace" scheme >of DAP. True, but this has nothing to do with whether the "public" attribute is useful. If it isn't useful for a particular policy object implementation, that implementation is free to ignore the attribute. >Therefore, the Public attribute permiates the entire system just to >support an optional Domain Access Policy. In fact that most access >decisions will ignore the Public attribute if access is based on other >attributes. This situation reveals unecessary copying of data and checking >for it. Therefore the public attribute is extraneous and causes >inefficiences. If it were possible to come up with an attribute set which were the one unique set which is both necessary and sufficient to support ALL policy object types, this might be a reasonable argument. However it is clearly NOT possible to come up with such a set, and the "public" attribute clearly IS very useful to a broad set of useful policies - namely discretionary, privilege-attribute based policies, of which DomainAccessPolicy, currently the ONLY explicitly specified policy available to the OMG community, is an example. >A better solution would be to confine the problem of "granting" rights >(which is in DAP only) to every principal in a "domain" to the Domain >Access Policy interface itself, such as an operation of "void >set_base_rights(RightsList rights);" and not permiate the entire system >with a useless attribute. And of course, eliminate the Public Security >Attribute all together, and all refernces to it. I don't think this even works! The whole point of "public" is that you don't know whether the caller is even a *member* of the domain, because he/she/it hasn't identified itself *or* authenticated. I propose we close this issue immediately and retain the public attribute. --bob Bob Blakley (blakley@dascom.com) Chief Scientist, Dascom X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Mon, 9 Aug 1999 15:50:09 -0400 (EDT) From: Polar Humenn To: Bob Blakley cc: sec-rev@emerald.omg.org, Juergen Boldt Subject: Re: issue 2800 -- Security RTF Issue On Mon, 9 Aug 1999, Bob Blakley wrote: > >This is issue # 2800 > > > > Public Attribute extraneous and inefficient > > I recommend we close this issue with no action taken. I do not agree with several of your points. > >The Public attribute is said to exist for the mere purpose of having at > >least one credentials object with at least one attribute, if no user has > >authenticated. > > Agree with everything here except "mere". > > >(It is entirely debateable of whether a credentials object > >should exist at all if a prinicpal does not authenticate). > > It may be debatable, but the debate has nothing to do with the > authorization model being used. The reason credentials objects always > exist in CORBAsecurity is that authorization (and some other services > such as auditing) assume that a credential is present and act on that > assumption. You can think of the existence of a credential as a > precondition (in the Hoare-logic or Meyer assertion sense) for calling > many of the security interfaces. The fact is that you already know that at least one, and only one, credentials object exists, i.e. the RecievedCredentials object which is made available to AccessDecision during a request. A "Public" attribute has nothing to do with guaranteeing that there is a Credentials object present when the request on "get_effective_attributes" is made. Apparently, the implied implementation of AccessDecision is to take the list of attributes from the ReceivedCredentials to ask the question. The Public attribute is superflous at this point, if the list *ALWAYS* contains the "public" attribute (authenticated user or not). > >It appears the > >only purpose for this public attribute, which is said to exist in *every* > >Credentials instance regardless of authentication, is to be able to > >"grant" rights to *EVERY* principal in a Domain Access Policy. > > This isn't the case at all. The purpose for this attribute is to not allow > a situation in which there is no credential for the currently active context. See above. > This is a perfectly sensible requirement, and eliminates the need to > create a non-credential-based special case of authorization processing > to deal with situations in which a user hasn't authenticated and attempts > to access resources. There is always a Credentials object. > Furthermore, the "public" attribute has nothing whatsoever to do with the > DomainAccessPolicy. It's simply a privilege attribute, and should be > dealt with properly by all AccessPolicy objects. Oh yes it does, you said so yourself in previous emails. It was so that you can "grant" rights to every entity (unauthencticated and authenticated) by "grant"ing rights to the "public" attribute. This purpose is solely DomainAccessPolicy specific! > The CORBA philosophy is that privilege attributes *describe* > security-relevant characteristics of their possessors. The "public" > attribute describes the known attribute of an unauthenticated user -- > namely, that he/she/it is a "member of the general public". > AccessPolicy objects are free to make any determination they wish on > the basis of possession of this attribute, including that access > should be denied (if desired). Not all policies need to do what the > DomainAccessPolicy object . Now this does not make sense if you say that the "public" attribute is present in ALL credentials objects. IF so, it means that EVERY prinicpal is "a member of the general public". If that is the case, then the attribute is largely ignored, other than the fact that in the DomainAccessPolicy there is no way to grant a base set of rights to anybody/everybody in the Access Policy domain. Now, if change th philosophy of the "public" attribute so that it IS NOT PRESENT for an authenticated principal, then there is no way to "grant" rights to "everybody authenticated or not" in the domain, which is the exact question that spured the issue! > >Access Policies (AP), as opposed to Domain Access Policies(DAP) (is an > >extension of AP) do not have to follow the "grant/revoke/replace" scheme > >of DAP. > > True, but this has nothing to do with whether the "public" attribute > is useful. If it isn't useful for a particular policy object > implementation, that implementation is free to ignore the attribute. I'm not saying that the implemenation is free do with it what it pleases, however, if the "public" attribute is guaranteed to be *ALWAYS* present, it's superflous. > >Therefore, the Public attribute permiates the entire system just to > >support an optional Domain Access Policy. In fact that most access > >decisions will ignore the Public attribute if access is based on other > >attributes. This situation reveals unecessary copying of data and checking > >for it. Therefore the public attribute is extraneous and causes > >inefficiences. > > If it were possible to come up with an attribute set which were the one > unique set which is both necessary and sufficient to support ALL policy > object types, this might be a reasonable argument. However it is clearly > NOT possible to come up with such a set, and the "public" attribute clearly > IS very useful to a broad set of useful policies - namely discretionary, > privilege-attribute > based policies, of which DomainAccessPolicy, currently the ONLY explicitly > specified policy available to the OMG community, is an example. > > >A better solution would be to confine the problem of "granting" rights > >(which is in DAP only) to every principal in a "domain" to the Domain > >Access Policy interface itself, such as an operation of "void > >set_base_rights(RightsList rights);" and not permiate the entire system > >with a useless attribute. And of course, eliminate the Public Security > >Attribute all together, and all refernces to it. > > I don't think this even works! The whole point of "public" is that > you don't know whether the caller is even a *member* of the domain, > because he/she/it hasn't identified itself *or* authenticated. Whaddya mean "set_base_rights" doesn't work? It's equivalent. If the "public" attribute is *ALWAYS* present in every credentials object what does it matter? The only thing differentiating it between a non-authenticated and authenticated user, is the ADDITIONAL presence of some other attribute. So, why not subtract the "public" attribute out of the equation. Now, if you take the tact that the "public" attribute is NOT PRESENT in the Credentials for an AUTHENTICATED principal, then we have other problems. Then we can "grant" rights to unauthenticated users, but *ANY* authenticated user. Which policy do you want? > I propose we close this issue immediately and retain the public attribute. I disagree entirely. Sincerely, -Polar ------------------------------------------------------------------- Polar Humenn Adiron, LLC Principal 2-212 Center for Science & Technology mailto:polar@adiron.com CASE Center/Syracuse University Phone: 315-443-3171 Syracuse, NY 13244-4100 Fax: 315-443-4745 http://www.adiron.com Reply-To: "Bob Blakley" From: "Bob Blakley" To: "Polar Humenn" Cc: , "Juergen Boldt" Subject: Re: issue 2800 -- Security RTF Issue Date: Mon, 9 Aug 1999 15:16:56 -0500 X-Mailer: Microsoft Outlook Express 4.72.3110.1 Polar, >The fact is that you already know that at least one, and only one, >credentials object exists, i.e. the RecievedCredentials object which is >made available to AccessDecision during a request. A "Public" attribute >has nothing to do with guaranteeing that there is a Credentials object >present when the request on "get_effective_attributes" is made. >Apparently, the implied implementation of AccessDecision is to take the >list of attributes from the ReceivedCredentials to ask the question. The >Public attribute is superflous at this point, if the list *ALWAYS* >contains the "public" attribute (authenticated user or not). This simply isn't true. The problem is that the ReceivedCredentials object has to *come* from somewhere. Where it comes from is the client. If the client fails to authenticate before making a request, then what comes in is (in the current spec.) not defined if we don't have a public attribute. We *could* change the spec. to say that what the client builds before authentication is a credential with no security attributes, which could be made (by implementors) into a functional equivalent for a credential with ONLY the public attribute. However this would not even allow the OPTION of permitting a user to keep the "public" attribute and also authenticated privilege attributes. See below for why this is important (I'll mark the continuation with "***"). ... (snip snip) >> Furthermore, the "public" attribute has nothing whatsoever to do with the >> DomainAccessPolicy. It's simply a privilege attribute, and should be >> dealt with properly by all AccessPolicy objects. > >Oh yes it does, you said so yourself in previous emails. It was so that >you can "grant" rights to every entity (unauthencticated and >authenticated) by "grant"ing rights to the "public" attribute. This >purpose is solely DomainAccessPolicy specific! No, this is the use to which the DomainAccessPolicy puts the public attribute, which is (of course!) DomainAccessPolicy specific. The public attribute wasn't intended to be specific to DomainAccessPolicy -- it was intended to solve a problem which arises in all distributed discretionary access control schemes, namely the necessity of distinguishing unauthenticated from authenticated users. >> The CORBA philosophy is that privilege attributes *describe* >> security-relevant characteristics of their possessors. The "public" >> attribute describes the known attribute of an unauthenticated user -- >> namely, that he/she/it is a "member of the general public". >> AccessPolicy objects are free to make any determination they wish on >> the basis of possession of this attribute, including that access >> should be denied (if desired). Not all policies need to do what the >> DomainAccessPolicy object . > >Now this does not make sense if you say that the "public" attribute is >present in ALL credentials objects. IF so, it means that EVERY prinicpal >is "a member of the general public". If that is the case, then the >attribute is largely ignored, other than the fact that in the >DomainAccessPolicy there is no way to grant a base set of rights to >anybody/everybody in the Access Policy domain. The claim that it "doesn't make sense" is clearly wrong; security attributes in a credential are logically additive; that is, if you have ROLE=VP and ACCESS_ID=Polar, then you're Polar and a VP. Similarly, if you have both these attributes and PUBLIC, then you're Polar, a VP, and a member of the public. *** (continuation from first paragraph) Even though you're Polar and a VP, you should still be able to get access to resources which are accessible to everyone (i.e. the public) without having to have a special "Polar" or "VP" ACL entry created for you. >Now, if change th philosophy of the "public" attribute so that it IS NOT >PRESENT for an authenticated principal, then there is no way to "grant" >rights to "everybody authenticated or not" in the domain, which is the >exact question that spured the issue! Correct, and I don't think we should make this change. >> >Access Policies (AP), as opposed to Domain Access Policies(DAP) (is an >> >extension of AP) do not have to follow the "grant/revoke/replace" scheme >> >of DAP. >> >> True, but this has nothing to do with whether the "public" attribute >> is useful. If it isn't useful for a particular policy object >> implementation, that implementation is free to ignore the attribute. > >I'm not saying that the implemenation is free do with it what it pleases, >however, if the "public" attribute is guaranteed to be *ALWAYS* present, >it's superflous. I think you meant "I'm not saying that the implementation is **NOT** free to do what it pleases...". Re: superfluity, I disagree as illustrated above. >> >Therefore, the Public attribute permiates the entire system just to >> >support an optional Domain Access Policy. In fact that most access >> >decisions will ignore the Public attribute if access is based on other >> >attributes. This situation reveals unecessary copying of data and checking >> >for it. Therefore the public attribute is extraneous and causes >> >inefficiences. >> >> If it were possible to come up with an attribute set which were the one >> unique set which is both necessary and sufficient to support ALL policy >> object types, this might be a reasonable argument. However it is clearly >> NOT possible to come up with such a set, and the "public" attribute clearly >> IS very useful to a broad set of useful policies - namely discretionary, >> privilege-attribute >> based policies, of which DomainAccessPolicy, currently the ONLY explicitly >> specified policy available to the OMG community, is an example. >> >> >A better solution would be to confine the problem of "granting" rights >> >(which is in DAP only) to every principal in a "domain" to the Domain >> >Access Policy interface itself, such as an operation of "void >> >set_base_rights(RightsList rights);" and not permiate the entire system >> >with a useless attribute. And of course, eliminate the Public Security >> >Attribute all together, and all refernces to it. >> >> I don't think this even works! The whole point of "public" is that >> you don't know whether the caller is even a *member* of the domain, >> because he/she/it hasn't identified itself *or* authenticated. > >Whaddya mean "set_base_rights" doesn't work? It's equivalent. > >If the "public" attribute is *ALWAYS* present in every credentials object >what does it matter? The only thing differentiating it between a >non-authenticated and authenticated user, is the ADDITIONAL presence of >some other attribute. So, why not subtract the "public" attribute out of >the equation. The reason not to do this is inhomogeneity of processing - you have to add some special-case code to translate "no security attributes" to the condition "unauthenticated" (which is what appears in the rules). Having "public" allows you to check for this condition using exactly the same code you use for every other access-decision check: comparing security attributes. In ACL-based AccessPolicy implementations, this is especially important, since the privilege attributes appear lexically in the ACL entries, and omitting public as a security attribute requires you to put some non-attribute (hence non-type-correct) thing into the ACL to deal with this case. This not only complicates processing, it makes it difficult to compare policies against the attributes coming in in the credentials. >Now, if you take the tact that the "public" attribute is NOT PRESENT in >the Credentials for an AUTHENTICATED principal, then we have other >problems. Then we can "grant" rights to unauthenticated users, but *ANY* >authenticated user. I agree with this; public should be present in authenticated as well as unauthenticated credentials, and would be happy to change the current issue to propose this change instead. >Which policy do you want? I failed to parse this; what are my options. >> I propose we close this issue immediately and retain the public attribute. > >I disagree entirely. So do I (still) :-) --bob Bob Blakley (blakley@dascom.com) Chief Scientist, Dascom X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Mon, 9 Aug 1999 15:50:09 -0400 (EDT) From: Polar Humenn To: Bob Blakley cc: sec-rev@emerald.omg.org, Juergen Boldt Subject: Re: issue 2800 -- Security RTF Issue On Mon, 9 Aug 1999, Bob Blakley wrote: > >This is issue # 2800 > > > > Public Attribute extraneous and inefficient > > I recommend we close this issue with no action taken. I do not agree with several of your points. > >The Public attribute is said to exist for the mere purpose of having at > >least one credentials object with at least one attribute, if no user has > >authenticated. > > Agree with everything here except "mere". > > >(It is entirely debateable of whether a credentials object > >should exist at all if a prinicpal does not authenticate). > > It may be debatable, but the debate has nothing to do with the > authorization model being used. The reason credentials objects always > exist in CORBAsecurity is that authorization (and some other services > such as auditing) assume that a credential is present and act on that > assumption. You can think of the existence of a credential as a > precondition (in the Hoare-logic or Meyer assertion sense) for calling > many of the security interfaces. The fact is that you already know that at least one, and only one, credentials object exists, i.e. the RecievedCredentials object which is made available to AccessDecision during a request. A "Public" attribute has nothing to do with guaranteeing that there is a Credentials object present when the request on "get_effective_attributes" is made. Apparently, the implied implementation of AccessDecision is to take the list of attributes from the ReceivedCredentials to ask the question. The Public attribute is superflous at this point, if the list *ALWAYS* contains the "public" attribute (authenticated user or not). > >It appears the > >only purpose for this public attribute, which is said to exist in *every* > >Credentials instance regardless of authentication, is to be able to > >"grant" rights to *EVERY* principal in a Domain Access Policy. > > This isn't the case at all. The purpose for this attribute is to not allow > a situation in which there is no credential for the currently active context. See above. > This is a perfectly sensible requirement, and eliminates the need to > create a non-credential-based special case of authorization processing > to deal with situations in which a user hasn't authenticated and attempts > to access resources. There is always a Credentials object. > Furthermore, the "public" attribute has nothing whatsoever to do with the > DomainAccessPolicy. It's simply a privilege attribute, and should be > dealt with properly by all AccessPolicy objects. Oh yes it does, you said so yourself in previous emails. It was so that you can "grant" rights to every entity (unauthencticated and authenticated) by "grant"ing rights to the "public" attribute. This purpose is solely DomainAccessPolicy specific! > The CORBA philosophy is that privilege attributes *describe* > security-relevant characteristics of their possessors. The "public" > attribute describes the known attribute of an unauthenticated user -- > namely, that he/she/it is a "member of the general public". > AccessPolicy objects are free to make any determination they wish on > the basis of possession of this attribute, including that access > should be denied (if desired). Not all policies need to do what the > DomainAccessPolicy object . Now this does not make sense if you say that the "public" attribute is present in ALL credentials objects. IF so, it means that EVERY prinicpal is "a member of the general public". If that is the case, then the attribute is largely ignored, other than the fact that in the DomainAccessPolicy there is no way to grant a base set of rights to anybody/everybody in the Access Policy domain. Now, if change th philosophy of the "public" attribute so that it IS NOT PRESENT for an authenticated principal, then there is no way to "grant" rights to "everybody authenticated or not" in the domain, which is the exact question that spured the issue! > >Access Policies (AP), as opposed to Domain Access Policies(DAP) (is an > >extension of AP) do not have to follow the "grant/revoke/replace" scheme > >of DAP. > > True, but this has nothing to do with whether the "public" attribute > is useful. If it isn't useful for a particular policy object > implementation, that implementation is free to ignore the attribute. I'm not saying that the implemenation is free do with it what it pleases, however, if the "public" attribute is guaranteed to be *ALWAYS* present, it's superflous. > >Therefore, the Public attribute permiates the entire system just to > >support an optional Domain Access Policy. In fact that most access > >decisions will ignore the Public attribute if access is based on other > >attributes. This situation reveals unecessary copying of data and checking > >for it. Therefore the public attribute is extraneous and causes > >inefficiences. > > If it were possible to come up with an attribute set which were the one > unique set which is both necessary and sufficient to support ALL policy > object types, this might be a reasonable argument. However it is clearly > NOT possible to come up with such a set, and the "public" attribute clearly > IS very useful to a broad set of useful policies - namely discretionary, > privilege-attribute > based policies, of which DomainAccessPolicy, currently the ONLY explicitly > specified policy available to the OMG community, is an example. > > >A better solution would be to confine the problem of "granting" rights > >(which is in DAP only) to every principal in a "domain" to the Domain > >Access Policy interface itself, such as an operation of "void > >set_base_rights(RightsList rights);" and not permiate the entire system > >with a useless attribute. And of course, eliminate the Public Security > >Attribute all together, and all refernces to it. > > I don't think this even works! The whole point of "public" is that > you don't know whether the caller is even a *member* of the domain, > because he/she/it hasn't identified itself *or* authenticated. Whaddya mean "set_base_rights" doesn't work? It's equivalent. If the "public" attribute is *ALWAYS* present in every credentials object what does it matter? The only thing differentiating it between a non-authenticated and authenticated user, is the ADDITIONAL presence of some other attribute. So, why not subtract the "public" attribute out of the equation. Now, if you take the tact that the "public" attribute is NOT PRESENT in the Credentials for an AUTHENTICATED principal, then we have other problems. Then we can "grant" rights to unauthenticated users, but *ANY* authenticated user. Which policy do you want? > I propose we close this issue immediately and retain the public attribute. I disagree entirely. Sincerely, -Polar ------------------------------------------------------------------- Polar Humenn Adiron, LLC Principal 2-212 Center for Science & Technology mailto:polar@adiron.com CASE Center/Syracuse University Phone: 315-443-3171 Syracuse, NY 13244-4100 Fax: 315-443-4745 http://www.adiron.com Reply-To: "Bob Blakley" From: "Bob Blakley" To: "Polar Humenn" Cc: , "Juergen Boldt" Subject: Re: issue 2800 -- Security RTF Issue Date: Mon, 9 Aug 1999 15:16:56 -0500 X-Mailer: Microsoft Outlook Express 4.72.3110.1 Polar, >The fact is that you already know that at least one, and only one, >credentials object exists, i.e. the RecievedCredentials object which is >made available to AccessDecision during a request. A "Public" attribute >has nothing to do with guaranteeing that there is a Credentials object >present when the request on "get_effective_attributes" is made. >Apparently, the implied implementation of AccessDecision is to take the >list of attributes from the ReceivedCredentials to ask the question. The >Public attribute is superflous at this point, if the list *ALWAYS* >contains the "public" attribute (authenticated user or not). This simply isn't true. The problem is that the ReceivedCredentials object has to *come* from somewhere. Where it comes from is the client. If the client fails to authenticate before making a request, then what comes in is (in the current spec.) not defined if we don't have a public attribute. We *could* change the spec. to say that what the client builds before authentication is a credential with no security attributes, which could be made (by implementors) into a functional equivalent for a credential with ONLY the public attribute. However this would not even allow the OPTION of permitting a user to keep the "public" attribute and also authenticated privilege attributes. See below for why this is important (I'll mark the continuation with "***"). ... (snip snip) >> Furthermore, the "public" attribute has nothing whatsoever to do with the >> DomainAccessPolicy. It's simply a privilege attribute, and should be >> dealt with properly by all AccessPolicy objects. > >Oh yes it does, you said so yourself in previous emails. It was so that >you can "grant" rights to every entity (unauthencticated and >authenticated) by "grant"ing rights to the "public" attribute. This >purpose is solely DomainAccessPolicy specific! No, this is the use to which the DomainAccessPolicy puts the public attribute, which is (of course!) DomainAccessPolicy specific. The public attribute wasn't intended to be specific to DomainAccessPolicy -- it was intended to solve a problem which arises in all distributed discretionary access control schemes, namely the necessity of distinguishing unauthenticated from authenticated users. >> The CORBA philosophy is that privilege attributes *describe* >> security-relevant characteristics of their possessors. The "public" >> attribute describes the known attribute of an unauthenticated user -- >> namely, that he/she/it is a "member of the general public". >> AccessPolicy objects are free to make any determination they wish on >> the basis of possession of this attribute, including that access >> should be denied (if desired). Not all policies need to do what the >> DomainAccessPolicy object . > >Now this does not make sense if you say that the "public" attribute is >present in ALL credentials objects. IF so, it means that EVERY prinicpal >is "a member of the general public". If that is the case, then the >attribute is largely ignored, other than the fact that in the >DomainAccessPolicy there is no way to grant a base set of rights to >anybody/everybody in the Access Policy domain. The claim that it "doesn't make sense" is clearly wrong; security attributes in a credential are logically additive; that is, if you have ROLE=VP and ACCESS_ID=Polar, then you're Polar and a VP. Similarly, if you have both these attributes and PUBLIC, then you're Polar, a VP, and a member of the public. *** (continuation from first paragraph) Even though you're Polar and a VP, you should still be able to get access to resources which are accessible to everyone (i.e. the public) without having to have a special "Polar" or "VP" ACL entry created for you. >Now, if change th philosophy of the "public" attribute so that it IS NOT >PRESENT for an authenticated principal, then there is no way to "grant" >rights to "everybody authenticated or not" in the domain, which is the >exact question that spured the issue! Correct, and I don't think we should make this change. >> >Access Policies (AP), as opposed to Domain Access Policies(DAP) (is an >> >extension of AP) do not have to follow the "grant/revoke/replace" scheme >> >of DAP. >> >> True, but this has nothing to do with whether the "public" attribute >> is useful. If it isn't useful for a particular policy object >> implementation, that implementation is free to ignore the attribute. > >I'm not saying that the implemenation is free do with it what it pleases, >however, if the "public" attribute is guaranteed to be *ALWAYS* present, >it's superflous. I think you meant "I'm not saying that the implementation is **NOT** free to do what it pleases...". Re: superfluity, I disagree as illustrated above. >> >Therefore, the Public attribute permiates the entire system just to >> >support an optional Domain Access Policy. In fact that most access >> >decisions will ignore the Public attribute if access is based on other >> >attributes. This situation reveals unecessary copying of data and checking >> >for it. Therefore the public attribute is extraneous and causes >> >inefficiences. >> >> If it were possible to come up with an attribute set which were the one >> unique set which is both necessary and sufficient to support ALL policy >> object types, this might be a reasonable argument. However it is clearly >> NOT possible to come up with such a set, and the "public" attribute clearly >> IS very useful to a broad set of useful policies - namely discretionary, >> privilege-attribute >> based policies, of which DomainAccessPolicy, currently the ONLY explicitly >> specified policy available to the OMG community, is an example. >> >> >A better solution would be to confine the problem of "granting" rights >> >(which is in DAP only) to every principal in a "domain" to the Domain >> >Access Policy interface itself, such as an operation of "void >> >set_base_rights(RightsList rights);" and not permiate the entire system >> >with a useless attribute. And of course, eliminate the Public Security >> >Attribute all together, and all refernces to it. >> >> I don't think this even works! The whole point of "public" is that >> you don't know whether the caller is even a *member* of the domain, >> because he/she/it hasn't identified itself *or* authenticated. > >Whaddya mean "set_base_rights" doesn't work? It's equivalent. > >If the "public" attribute is *ALWAYS* present in every credentials object >what does it matter? The only thing differentiating it between a >non-authenticated and authenticated user, is the ADDITIONAL presence of >some other attribute. So, why not subtract the "public" attribute out of >the equation. The reason not to do this is inhomogeneity of processing - you have to add some special-case code to translate "no security attributes" to the condition "unauthenticated" (which is what appears in the rules). Having "public" allows you to check for this condition using exactly the same code you use for every other access-decision check: comparing security attributes. In ACL-based AccessPolicy implementations, this is especially important, since the privilege attributes appear lexically in the ACL entries, and omitting public as a security attribute requires you to put some non-attribute (hence non-type-correct) thing into the ACL to deal with this case. This not only complicates processing, it makes it difficult to compare policies against the attributes coming in in the credentials. >Now, if you take the tact that the "public" attribute is NOT PRESENT in >the Credentials for an AUTHENTICATED principal, then we have other >problems. Then we can "grant" rights to unauthenticated users, but *ANY* >authenticated user. I agree with this; public should be present in authenticated as well as unauthenticated credentials, and would be happy to change the current issue to propose this change instead. >Which policy do you want? I failed to parse this; what are my options. >> I propose we close this issue immediately and retain the public attribute. > >I disagree entirely. So do I (still) :-) --bob Bob Blakley (blakley@dascom.com) Chief Scientist, Dascom X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Mon, 9 Aug 1999 17:04:35 -0400 (EDT) From: Polar Humenn To: Bob Blakley cc: sec-rev@emerald.omg.org, Juergen Boldt Subject: Re: issue 2800 -- Security RTF Issue On Mon, 9 Aug 1999, Bob Blakley wrote: > Polar, > > >The fact is that you already know that at least one, and only one, > >credentials object exists, i.e. the RecievedCredentials object which is > >made available to AccessDecision during a request. A "Public" attribute > >has nothing to do with guaranteeing that there is a Credentials object > >present when the request on "get_effective_attributes" is made. > >Apparently, the implied implementation of AccessDecision is to take the > >list of attributes from the ReceivedCredentials to ask the question. The > >Public attribute is superflous at this point, if the list *ALWAYS* > >contains the "public" attribute (authenticated user or not). > > This simply isn't true. The problem is that the ReceivedCredentials object > has to *come* from somewhere. Where it comes from is the client. Lets get the terminology and its interpretation straight. The ReceivedCredentials object is locality constrained object which is created at the hands of the security mechanism on the server which is servicing a client authentication request. It (as an object) does not come from the client. > If the > client fails to authenticate before making a request, then what comes in > is (in the current spec.) not defined if we don't have a public attribute. Even if the security mechanism allows the request to be made even in the event of an authentication failure (note in some mechanisms this is impossible), we might have other attributes, such as IP address, etc. In anycase, the Credentials object is there, and it has a list of attributes, empty or not. > We *could* change the spec. to say that what the client builds before > authentication is a credential with no security attributes, which could be > made (by implementors) into a functional equivalent for a credential with > ONLY the public attribute. > However this would not even allow the OPTION > of permitting a user to keep the "public" attribute and also authenticated > privilege attributes. See below for why this is important (I'll mark the > continuation > with "***"). Okay, so now we are getting to the point where the "public" attribute is now optional?!?! This of course changes *EVERYTHING* I've been aruing about. And of course this point is not clearly defined in the specification. > ... (snip snip) > > >> Furthermore, the "public" attribute has nothing whatsoever to do with the > >> DomainAccessPolicy. It's simply a privilege attribute, and should be > >> dealt with properly by all AccessPolicy objects. > > > >Oh yes it does, you said so yourself in previous emails. It was so that > >you can "grant" rights to every entity (unauthencticated and > >authenticated) by "grant"ing rights to the "public" attribute. This > >purpose is solely DomainAccessPolicy specific! > > > No, this is the use to which the DomainAccessPolicy puts the public > attribute, which is (of course!) DomainAccessPolicy specific. The public > attribute wasn't intended to be specific to DomainAccessPolicy -- it was > intended to solve a problem which arises in all distributed discretionary > access control schemes, namely the necessity of distinguishing > unauthenticated from authenticated users. I still do not see the difference. This is only able to be true if indeed the public attribute is NOT present in the Credentials when the principal is authenticated. > >> The CORBA philosophy is that privilege attributes *describe* > >> security-relevant characteristics of their possessors. The "public" > >> attribute describes the known attribute of an unauthenticated user -- > >> namely, that he/she/it is a "member of the general public". > >> AccessPolicy objects are free to make any determination they wish on > >> the basis of possession of this attribute, including that access > >> should be denied (if desired). Not all policies need to do what the > >> DomainAccessPolicy object . > > > >Now this does not make sense if you say that the "public" attribute is > >present in ALL credentials objects. IF so, it means that EVERY prinicpal > >is "a member of the general public". If that is the case, then the > >attribute is largely ignored, other than the fact that in the > >DomainAccessPolicy there is no way to grant a base set of rights to > >anybody/everybody in the Access Policy domain. > > > The claim that it "doesn't make sense" is clearly wrong; security attributes > in a credential are logically additive; that is, if you have ROLE=VP and > ACCESS_ID=Polar, then you're Polar and a VP. Similarly, if you have > both these attributes and PUBLIC, then you're Polar, a VP, and a member > of the public. Well, First of all, there is nothing in the specification that says attributes are "logically additive". Perhaps this is a bit of the rigor and mathematics the specification needs! Second of all, if *EVERYBODY* is a "memeber of the general" public, then there is no need to have an attribute stating so. > *** (continuation from first paragraph) Even though you're Polar and a VP, > you should still be able to get access to resources which are accessible to > everyone (i.e. the public) without having to have a special "Polar" or "VP" > ACL entry created for you. Exactly, and this comes into play only with (one of) the defficiencies of the DomainAccessPolicy in which there is no way to "grant" rights to everybody, unless *EVERYBODY* has a "public" attribute. I keep saying that there is a better way to handle that. > >Now, if change th philosophy of the "public" attribute so that it IS NOT > >PRESENT for an authenticated principal, then there is no way to "grant" > >rights to "everybody authenticated or not" in the domain, which is the > >exact question that spured the issue! > > > Correct, and I don't think we should make this change. Then the attribute is NOT needed. > >> >Access Policies (AP), as opposed to Domain Access Policies(DAP) (is an > >> >extension of AP) do not have to follow the "grant/revoke/replace" scheme > >> >of DAP. > >> > >> True, but this has nothing to do with whether the "public" attribute > >> is useful. If it isn't useful for a particular policy object > >> implementation, that implementation is free to ignore the attribute. > > > >I'm not saying that the implemenation is free do with it what it pleases, > >however, if the "public" attribute is guaranteed to be *ALWAYS* present, > >it's superflous. > > > I think you meant "I'm not saying that the implementation is **NOT** free to > do > what it pleases...". Re: superfluity, I disagree as illustrated above. What I mean to say is that the implemenation of an AccessPolicy, at the point of "get_effective_rights" can, regardless of the argument of an attribute list it is given, asscertain that the "prinicpal" is a "member of the general public" without even looking at the attributes! > >> >Therefore, the Public attribute permiates the entire system just to > >> >support an optional Domain Access Policy. In fact that most access > >> >decisions will ignore the Public attribute if access is based on other > >> >attributes. This situation reveals unecessary copying of data and checking > >> >for it. Therefore the public attribute is extraneous and causes > >> >inefficiences. I still do not budge from this statement. > >> If it were possible to come up with an attribute set which were the one > >> unique set which is both necessary and sufficient to support ALL policy > >> object types, this might be a reasonable argument. However it is clearly > >> NOT possible to come up with such a set, and the "public" attribute clearly > >> IS very useful to a broad set of useful policies - namely discretionary, > >> privilege-attribute > >> based policies, of which DomainAccessPolicy, currently the ONLY explicitly > >> specified policy available to the OMG community, is an example. > >> > >> >A better solution would be to confine the problem of "granting" rights > >> >(which is in DAP only) to every principal in a "domain" to the Domain > >> >Access Policy interface itself, such as an operation of "void > >> >set_base_rights(RightsList rights);" and not permiate the entire system > >> >with a useless attribute. And of course, eliminate the Public Security > >> >Attribute all together, and all refernces to it. > >> > >> I don't think this even works! The whole point of "public" is that > >> you don't know whether the caller is even a *member* of the domain, > >> because he/she/it hasn't identified itself *or* authenticated. > > > >Whaddya mean "set_base_rights" doesn't work? It's equivalent. > > > >If the "public" attribute is *ALWAYS* present in every credentials object > >what does it matter? The only thing differentiating it between a > >non-authenticated and authenticated user, is the ADDITIONAL presence of > >some other attribute. So, why not subtract the "public" attribute out of > >the equation. > > The reason not to do this is inhomogeneity of processing - you > have to add some special-case code to translate "no security attributes" > to the condition "unauthenticated" (which is what appears in the rules). > Having "public" allows you to check for this condition using exactly the > same code you use for every other access-decision check: comparing > security attributes. This is implemenation specific that causes more data to be passed around marshalled and unmarshelled, is more computation than a simple if statement on the length of the attributes. And furthermore, there is no check involved!!!!! To get the condition "Unauthenticated" from this scheme, you must check to see if there are no other "attributes of authentication" that exist in the list of attributes!. The conditions you really are looking for with this scheme is: A. Is he a member of the general public ( *ALWAYS* true ) B. Is he authenticated ( true only if an authenticing attribute exists ). > In ACL-based AccessPolicy implementations, this is especially important, > since the privilege attributes appear lexically in the ACL entries, and > omitting public as a security attribute requires you to put some non-attribute > (hence non-type-correct) thing into the ACL to deal with this case. This > not only complicates processing, it makes it difficult to compare policies > against the attributes coming in in the credentials. The ACL implementation should have someway of expressing its needs that conforms to the functionality of the system. The system should NOT have to conform to the expresssability limitations of some particular inferior ACL implementation. > >Now, if you take the tact that the "public" attribute is NOT PRESENT in > >the Credentials for an AUTHENTICATED principal, then we have other > >problems. Then we can "grant" rights to unauthenticated users, but *ANY* > >authenticated user. > > I agree with this; public should be present in authenticated as well as > unauthenticated credentials, and would be happy to change the current issue > to propose this change instead. > > >Which policy do you want? > > > I failed to parse this; what are my options. The choices were. A. "public" attribute is only present in absence of an authenticated principal. B. "public" attribute is *ALWAYS* present With reference to the DomainAccessPolicy, option A allows you to write policies such that you can "grant" rights to unauthenticated users, but NOT *ANY* authenticated user, thereby making the difference known to the access control system. option B yields no difference to the access control system of whether the principal is authenticated or not, but one CAN grant rights to *EVERYBODY* in that domain. Option B is equivalent to eliminating the public attribute and being able to set a base set of rights in the domain granted to EVERYBODY. > >> I propose we close this issue immediately and retain the public attribute. > > > >I disagree entirely. > > So do I (still) :-) You are still not budging me. I'll repeat: The ACL implementation should have someway of expressing its needs that conforms to the functionality of the system. The system should NOT have to conform to the expresssability limitations of some particular inferior ACL implementation. Anybody else like to get into this discussion? I can tell this one is going to take a few more beers at the office :) Cheers, -Polar ------------------------------------------------------------------- Polar Humenn Adiron, LLC Principal 2-212 Center for Science & Technology mailto:polar@adiron.com CASE Center/Syracuse University Phone: 315-443-3171 Syracuse, NY 13244-4100 Fax: 315-443-4745 http://www.adiron.com Reply-To: "Bob Blakley" From: "Bob Blakley" To: "Polar Humenn" Cc: , "Juergen Boldt" Subject: Re: issue 2800 -- Security RTF Issue Date: Mon, 9 Aug 1999 16:36:13 -0500 X-Mailer: Microsoft Outlook Express 4.72.3110.1 >> This simply isn't true. The problem is that the ReceivedCredentials object >> has to *come* from somewhere. Where it comes from is the client. > >Lets get the terminology and its interpretation straight. The >ReceivedCredentials object is locality constrained object which is created >at the hands of the security mechanism on the server which is servicing a >client authentication request. It (as an object) does not come from the >client. Yeah, but this isn't the point. The way the target ORB builds the ReceivedCredential is by looking in a (unspecified, since it isn't IDL) context establishment token. This token contains the list of security attributes which the client's credential object (which was also locality constrained) contained. If the target doesn't receieve a security attribute in the context establishment token, it shouldn't put it into the ReceivedCredential. Conversely, if it does receive an attribute, it should put it in. So although the *credential* doesn't come from the client, the security attribute list in it does. > >> We *could* change the spec. to say that what the client builds before >> authentication is a credential with no security attributes, which could be >> made (by implementors) into a functional equivalent for a credential with >> ONLY the public attribute. > >> However this would not even allow the OPTION >> of permitting a user to keep the "public" attribute and also authenticated >> privilege attributes. See below for why this is important (I'll mark the >> continuation >> with "***"). > >Okay, so now we are getting to the point where the "public" attribute is >now optional?!?! No!! I think it should always be in every cred. (Actually, right now you could take the position that it's already optional, since the spec. as it stands is ambiguous) >> No, this is the use to which the DomainAccessPolicy puts the public >> attribute, which is (of course!) DomainAccessPolicy specific. The public >> attribute wasn't intended to be specific to DomainAccessPolicy -- it was >> intended to solve a problem which arises in all distributed discretionary >> access control schemes, namely the necessity of distinguishing >> unauthenticated from authenticated users. > >I still do not see the difference. This is only able to be true if indeed >the public attribute is NOT present in the Credentials when the principal >is authenticated. No; I disagree. The point I'm making here is that it should be possible for the target to figure out everything about the client's authentication and privilege attribute status by examining the privilege attribute set the client passes. Presence of any authenticated attribute means the client authenticated that attribute; the fact that the public attribute is (also) there doesn't confuse the target about the fact that the other attributes were authenticated. >> The claim that it "doesn't make sense" is clearly wrong; security attributes >> in a credential are logically additive; that is, if you have ROLE=VP and >> ACCESS_ID=Polar, then you're Polar and a VP. Similarly, if you have >> both these attributes and PUBLIC, then you're Polar, a VP, and a member >> of the public. > >Well, First of all, there is nothing in the specification that says >attributes are "logically additive". Perhaps this is a bit of the rigor >and mathematics the specification needs! I don't think this needs to be clarified. It *does* need to be said, for a particular policy object type, whether policy entries are additive or not. However I can't think of another interpretation of attributes which makes any sense. Attributes are just adjectives. A large, red barn is large AND red. I don't think anyone is in any doubt about this, nor is anyone likely to interpret a set of attributes differently, though some people may want to make sure that only one of the client's ROLE attributes (for example) can be used in a single access decision. But that's a policy thing, not an attribute assertion thing. >Second of all, if *EVERYBODY* is a "memeber of the general" public, then >there is no need to have an attribute stating so. > >> *** (continuation from first paragraph) Even though you're Polar and a VP, >> you should still be able to get access to resources which are accessible to >> everyone (i.e. the public) without having to have a special "Polar" or "VP" >> ACL entry created for you. > >Exactly, and this comes into play only with (one of) the defficiencies of >the DomainAccessPolicy in which there is no way to "grant" rights to >everybody, unless *EVERYBODY* has a "public" attribute. Right, but there are lots of policies which have exactly this same deficiency. And we ought to make sure that it's possible for them to function in the environment we define. >I keep saying that there is a better way to handle that. There may be, but we should also observe "stare decisus" to some extent; the spec. already exists and has been (to varying extents) implemented, and we shouldn't change things just because they're not perfect, especially in pursuit of small benefits. Sometimes good enough is good enough. >> >Now, if change th philosophy of the "public" attribute so that it IS NOT >> >PRESENT for an authenticated principal, then there is no way to "grant" >> >rights to "everybody authenticated or not" in the domain, which is the >> >exact question that spured the issue! >> >> Correct, and I don't think we should make this change. > >Then the attribute is NOT needed. Don't agree... >> >> True, but this has nothing to do with whether the "public" attribute >> >> is useful. If it isn't useful for a particular policy object >> >> implementation, that implementation is free to ignore the attribute. >> > >> >I'm not saying that the implemenation is free do with it what it pleases, >> >however, if the "public" attribute is guaranteed to be *ALWAYS* present, >> >it's superflous. >> >> >> I think you meant "I'm not saying that the implementation is **NOT** free to >> do >> what it pleases...". Re: superfluity, I disagree as illustrated above. > >What I mean to say is that the implemenation of an AccessPolicy, at the >point of "get_effective_rights" can, regardless of the argument >of an attribute list it is given, asscertain that the "prinicpal" is a >"member of the general public" without even looking at the attributes! Yeah, but this makes it more difficult to audit what happened, because the credential only implicitly indicates the information which forms the basis for the access decision. >> >> >Therefore, the Public attribute permiates the entire system just to >> >> >support an optional Domain Access Policy. In fact that most access >> >> >decisions will ignore the Public attribute if access is based on other >> >> >attributes. This situation reveals unecessary copying of data and checking >> >> >for it. Therefore the public attribute is extraneous and causes >> >> >inefficiences. > >I still do not budge from this statement. And I still disagree. Access policies which allow "public" access will always check (and grant) access on the basis of this attribute, and they'll be able to do so without special-case code for handling non-attribute-based properties of the client subject. >> >> >A better solution would be to confine the problem of "granting" rights >> >> >(which is in DAP only) This isn't really true in general, and with a small change it's never true. While you don't "grant" *rights* in many policy regimes, you still "grant access". What I'm arguing here is that the CORBAsecurity model is currently completely syntactically and semantically pure in this regard: *access* is always granted (or denied) on the basis of explicit security attributes, one of which is "public". I don't want to contaminate this model either with *implicit* security attributes or with non-security-attribute-based mechanisms. >> >If the "public" attribute is *ALWAYS* present in every credentials object >> >what does it matter? The only thing differentiating it between a >> >non-authenticated and authenticated user, is the ADDITIONAL presence of >> >some other attribute. So, why not subtract the "public" attribute out of >> >the equation. >> >> The reason not to do this is inhomogeneity of processing - you >> have to add some special-case code to translate "no security attributes" >> to the condition "unauthenticated" (which is what appears in the rules). >> Having "public" allows you to check for this condition using exactly the >> same code you use for every other access-decision check: comparing >> security attributes. > >This is implemenation specific that causes more data to be passed around >marshalled and unmarshelled, is more computation than a simple if >statement on the length of the attributes. I disagree that this is implementation-specific. It's a model issue. Clients communicate subject security attribute information explicitly to target ORBs via context establishment tokens. Subject security attribute information is always explicit and always expressed as security attributes. Hence, of course, it's always marshalled and unmarshalled. By the way, I think the efficiency argument here is entirely a red herring. The public security attribute doesn't even have a meaningful value. The type data is a very simple numeric data structure, and any processing overhead for this tiny piece of data will be completely negligible. >And furthermore, there is no check involved!!!!! > >To get the condition "Unauthenticated" from this scheme, you must check to >see if there are no other "attributes of authentication" that exist in the >list of attributes!. No you don't!! All you have to do is to see whether access is granted based on the *presence* of the "public" attribute. Schemes other than DomainAccessPolicy could deny access based on the presence of this attribute, if they support explicit denial. In no case is it necessary to infer authentication state by examining other attributes. >The conditions you really are looking for with this scheme is: > >A. Is he a member of the general public ( *ALWAYS* true ) >B. Is he authenticated ( true only if an authenticing attribute exists ). > >> In ACL-based AccessPolicy implementations, this is especially important, >> since the privilege attributes appear lexically in the ACL entries, and >> omitting public as a security attribute requires you to put some non-attribute >> (hence non-type-correct) thing into the ACL to deal with this case. This >> not only complicates processing, it makes it difficult to compare policies >> against the attributes coming in in the credentials. > >The ACL implementation should have someway of expressing its needs that >conforms to the functionality of the system. The system should NOT have to >conform to the expresssability limitations of some particular inferior ACL >implementation. I'm not sure what conclusion I'm supposed to draw from this. Lots of organizations want to have policies whose functionality includes: the ability to grant access by the general public (i.e. anyone) to some set of resources the ability to restrict access (e.g. to employees only) to another set of resources the ability nevertheless to allow access by employees to publicly-accessible resources the ability to do all the above without defining employees as members of the public, and without having to explicitly authorize employees to the publicly-accessible resources It seems to me (and to them, if I've been listening) perfectly natural to express this as: files in /pub are accessible to the public files in /usr/bob are accessible only to bob files in /usr/polar are accessible only to polar This is an explicit use of "public" in the sense in which CORBA intends it. I can't see a problem here.... >> >Which policy do you want? >> >> I failed to parse this; what are my options. > >The choices were. > >A. "public" attribute is only present in absence of an authenticated > principal. >B. "public" attribute is *ALWAYS* present B. >With reference to the DomainAccessPolicy, option A allows you to write >policies such that you can "grant" rights to unauthenticated users, but >NOT *ANY* authenticated user, thereby making the difference known to the >access control system. > >option B yields no difference to the access control system of whether the >principal is authenticated or not, but one CAN grant rights to *EVERYBODY* >in that domain. > >Option B is equivalent to eliminating the public attribute and being able >to set a base set of rights in the domain granted to EVERYBODY. Not quite; you can only do this by either: 1. Inferring a "public" security attribute from "any credential" when you make an access check, or 2. Adding a non-attribute-based entry to the ACL I don't like either of these. >> >> I propose we close this issue immediately and retain the public attribute. >> > >> >I disagree entirely. >> >> So do I (still) :-) > >You are still not budging me. I'll repeat: > >The ACL implementation should have someway of expressing its needs that >conforms to the functionality of the system. The system should NOT have to >conform to the expresssability limitations of some particular inferior ACL >implementation. > >Anybody else like to get into this discussion? > >I can tell this one is going to take a few more beers at the office :) Dang! You all know how much I hate the office :) --bob Bob Blakley (blakley@dascom.com) Chief Scientist, Dascom X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Mon, 9 Aug 1999 18:44:56 -0400 (EDT) From: Polar Humenn To: Bob Blakley cc: sec-rev@emerald.omg.org, Juergen Boldt Subject: Re: issue 2800 -- Security RTF Issue On Mon, 9 Aug 1999, Bob Blakley wrote: > >> This simply isn't true. The problem is that the ReceivedCredentials object > >> has to *come* from somewhere. Where it comes from is the client. > > > >Lets get the terminology and its interpretation straight. The > >ReceivedCredentials object is locality constrained object which is created > >at the hands of the security mechanism on the server which is servicing a > >client authentication request. It (as an object) does not come from the > >client. > > Yeah, but this isn't the point. The way the target ORB builds the > ReceivedCredential is by looking in a (unspecified, since it isn't > IDL) context establishment token. This token contains the list of > security attributes which the client's credential object (which was > also locality constrained) contained. If the target doesn't receieve > a security attribute in the context establishment token, it shouldn't > put it into the ReceivedCredential. Conversely, if it does receive an > attribute, it should put it in. So although the *credential* doesn't > come from the client, the security attribute list in it does. Not so in all mechanisms, or even any of the mechanisms I am familiar with. The Kerberos system especially, the "public" attribute, is not present. I'm not even sure if that attribute gets shipped with the Sesame PAC. What about DCE; is there a "public" attribute shipped in its context establishment token? Other than it just being implied? Attributes need not come from the context establishment token, either. Since it is unspecified where they come from, they can come from some external service in conjunction and based the authentication context establishment token. This is the scenario we are trying to get to with CSIv2, I might add. > >> We *could* change the spec. to say that what the client builds before > >> authentication is a credential with no security attributes, which could be > >> made (by implementors) into a functional equivalent for a credential with > >> ONLY the public attribute. > > > >> However this would not even allow the OPTION > >> of permitting a user to keep the "public" attribute and also authenticated > >> privilege attributes. See below for why this is important (I'll mark the > >> continuation > >> with "***"). > > > >Okay, so now we are getting to the point where the "public" attribute is > >now optional?!?! > > No!! I think it should always be in every cred. (Actually, right now > you could take the position that it's already optional, since the > spec. as it stands is ambiguous) Okay, So it adds zero value. (In fact the damn thing has NO value of significance). > >> No, this is the use to which the DomainAccessPolicy puts the public > >> attribute, which is (of course!) DomainAccessPolicy specific. The public > >> attribute wasn't intended to be specific to DomainAccessPolicy -- it was > >> intended to solve a problem which arises in all distributed discretionary > >> access control schemes, namely the necessity of distinguishing > >> unauthenticated from authenticated users. > > > >I still do not see the difference. This is only able to be true if indeed > >the public attribute is NOT present in the Credentials when the principal > >is authenticated. > > No; I disagree. The point I'm making here is that it should be > possible for the target to figure out everything about the client's > authentication and privilege attribute status by examining the > privilege attribute set the client passes. Presence of any > authenticated attribute means the client authenticated that attribute; > the fact that the public attribute is (also) there doesn't confuse the > target about the fact that the other attributes were authenticated. Given that, I'm at a loss of whether the presence of the public attribute leads to any confusion about "other" attributes. Especially, since you imply that they are additive with respect to rights (i.e. without relation to each other). Can you explain with an example? > >> The claim that it "doesn't make sense" is clearly wrong; security > attributes > >> in a credential are logically additive; that is, if you have ROLE=VP and > >> ACCESS_ID=Polar, then you're Polar and a VP. Similarly, if you have > >> both these attributes and PUBLIC, then you're Polar, a VP, and a member > >> of the public. > > > >Well, First of all, there is nothing in the specification that says > >attributes are "logically additive". Perhaps this is a bit of the rigor > >and mathematics the specification needs! > > I don't think this needs to be clarified. It *does* need to be said, > for a particular policy object type, whether policy entries are > additive or not. However I can't think of another interpretation of > attributes which makes any sense. Attributes are just adjectives. A > large, red barn is large AND red. I don't think anyone is in any > doubt about this, nor is anyone likely to interpret a set of > attributes differently, though some people may want to make sure that > only one of the client's ROLE attributes (for example) can be used in > a single access decision. But that's a policy thing, not an attribute > assertion thing. Hey, you may think their additive, and I might think their additive, but not everybody will think so. Believe me on this one! There is no harm, and perhaps *helpful* to lay down the semantics of attributes in such a way that it is not implied, but explicit. I think we agree, it does *need* to be said. However, a little clarification wouldn't hurt. :) The mere fact that we have a little comment on this "_Public" attribute stating that the user is not authenticated blows that "implication" away. Yes, the additive property *needs* to be clarified. > >Second of all, if *EVERYBODY* is a "memeber of the general" public, then > >there is no need to have an attribute stating so. > > > >> *** (continuation from first paragraph) Even though you're Polar and a VP, > >> you should still be able to get access to resources which are accessible to > >> everyone (i.e. the public) without having to have a special "Polar" or "VP" > >> ACL entry created for you. > > > >Exactly, and this comes into play only with (one of) the defficiencies of > >the DomainAccessPolicy in which there is no way to "grant" rights to > >everybody, unless *EVERYBODY* has a "public" attribute. > > Right, but there are lots of policies which have exactly this same > deficiency. And we ought to make sure that it's possible for them to > function in the environment we define. No, this is a problem with the DomainAccessPolicy's "grant" mechanism. > >I keep saying that there is a better way to handle that. > > There may be, but we should also observe "stare decisus" to some > extent; the spec. already exists and has been (to varying extents) > implemented, and we shouldn't change things just because they're not > perfect, especially in pursuit of small benefits. Sometimes good > enough is good enough. I still say it bogs down the system in order to support an inferior policy object, and I would like to fix the defficiency before it gets too "implemented". > >> >Now, if change th philosophy of the "public" attribute so that it IS NOT > >> >PRESENT for an authenticated principal, then there is no way to "grant" > >> >rights to "everybody authenticated or not" in the domain, which is the > >> >exact question that spured the issue! > >> > >> Correct, and I don't think we should make this change. > > > >Then the attribute is NOT needed. > > Don't agree... Okay, mathematically it has the additive value of ZERO. > >> >> True, but this has nothing to do with whether the "public" attribute > >> >> is useful. If it isn't useful for a particular policy object > >> >> implementation, that implementation is free to ignore the attribute. > >> > > >> >I'm not saying that the implemenation is free do with it what it pleases, > >> >however, if the "public" attribute is guaranteed to be *ALWAYS* present, > >> >it's superflous. > >> > >> > >> I think you meant "I'm not saying that the implementation is **NOT** free > to > >> do > >> what it pleases...". Re: superfluity, I disagree as illustrated above. > > > >What I mean to say is that the implemenation of an AccessPolicy, at the > >point of "get_effective_rights" can, regardless of the argument > >of an attribute list it is given, asscertain that the "prinicpal" is a > >"member of the general public" without even looking at the attributes! > > Yeah, but this makes it more difficult to audit what happened, because the > credential only implicitly indicates the information which forms the basis for > the access decision. What??!?! First of all to make any sense of some log that says some rights were issued due to these attributes can make no conclusion without the definition of the AccessPolicy object (DomainAccessPolicy or not), whether or not the "public" attribute existed in the list of attributes. > >> >> >Therefore, the Public attribute permiates the entire system just to > >> >> >support an optional Domain Access Policy. In fact that most access > >> >> >decisions will ignore the Public attribute if access is based on other > >> >> >attributes. This situation reveals unecessary copying of data and > checking > >> >> >for it. Therefore the public attribute is extraneous and causes > >> >> >inefficiences. > > > >I still do not budge from this statement. > > And I still disagree. Access policies which allow "public" access will > always check (and grant) access on the basis of this attribute, and they'll > be able to do so without special-case code for handling non-attribute-based > properties of the client subject. Noway Jose! If I write an AccessPolicy, and I want to grant rights to *everybody* and then grant rights to individual attributes. Then I would write: rights = ; // for everybody in domain for (i = 0;i < attrs.length; i++) rights = rights ++ get_rights_for(attrs[i]); Pretty simple, eh? Where is the special case? And, I've got one less call to "get_rights_for". > >> >> >A better solution would be to confine the problem of "granting" rights > >> >> >(which is in DAP only) > > This isn't really true in general, and with a small change it's never > true. While you don't "grant" *rights* in many policy regimes, you > still "grant access". What I'm arguing here is that the CORBAsecurity > model is currently completely syntactically and semantically pure in > this regard: *access* is always granted (or denied) on the basis of > explicit security attributes, one of which is "public". I don't want > to contaminate this model either with *implicit* security attributes > or with non-security-attribute-based mechanisms. There aren't any implicit security attributes. However, the fact that the "public" attribute exists in the first place is "implied" and not explicit. > >> >If the "public" attribute is *ALWAYS* present in every credentials object > >> >what does it matter? The only thing differentiating it between a > >> >non-authenticated and authenticated user, is the ADDITIONAL presence of > >> >some other attribute. So, why not subtract the "public" attribute out of > >> >the equation. > >> > >> The reason not to do this is inhomogeneity of processing - you > >> have to add some special-case code to translate "no security attributes" > >> to the condition "unauthenticated" (which is what appears in the rules). > >> Having "public" allows you to check for this condition using exactly the > >> same code you use for every other access-decision check: comparing > >> security attributes. > > > >This is implemenation specific that causes more data to be passed around > >marshalled and unmarshelled, is more computation than a simple if > >statement on the length of the attributes. > > I disagree that this is implementation-specific. It's a model issue. > Clients communicate subject security attribute information explicitly > to target ORBs via context establishment tokens. Subject security > attribute information is always explicit and always expressed as > security attributes. Hence, of course, it's always marshalled and > unmarshalled. I disagree since the "public" attribute is not explicitly passed in context establishment tokens, and is therefore "implied". > By the way, I think the efficiency argument here is entirely a red > herring. The public security attribute doesn't even have a meaningful > value. The type data is a very simple numeric data structure, and any > processing overhead for this tiny piece of data will be completely > negligible. Tell that to anybody who wants to do 10000 tranactions a second. > >And furthermore, there is no check involved!!!!! > > > >To get the condition "Unauthenticated" from this scheme, you must check to > >see if there are no other "attributes of authentication" that exist in the > >list of attributes!. > > No you don't!! All you have to do is to see whether access is granted > based on the *presence* of the "public" attribute. But then what the hell to you need to check for at all, if you are guaranteed that that attribute is *ALWAYS* there!?!?! > Schemes other than DomainAccessPolicy could deny access based on the > presence of this attribute, if they support explicit denial. In no > case is it necessary to infer authentication state by examining other > attributes. That would make sense, since the "public" attribute is *ALWAYS* there. Wouldn't get you anything meaningfull by doing an explict denial on the "public" attribute, then you just might as well say "NO" without even looking. Hmmmm, guess we really didn't even need the "public" attribute in that case either, eh? > >The conditions you really are looking for with this scheme is: > > > >A. Is he a member of the general public ( *ALWAYS* true ) > >B. Is he authenticated ( true only if an authenticing attribute exists ). > > > >> In ACL-based AccessPolicy implementations, this is especially important, > >> since the privilege attributes appear lexically in the ACL entries, and > >> omitting public as a security attribute requires you to put some > non-attribute > >> (hence non-type-correct) thing into the ACL to deal with this case. This > >> not only complicates processing, it makes it difficult to compare policies > >> against the attributes coming in in the credentials. > > > >The ACL implementation should have someway of expressing its needs that > >conforms to the functionality of the system. The system should NOT have to > >conform to the expresssability limitations of some particular inferior ACL > >implementation. > > I'm not sure what conclusion I'm supposed to draw from this. Lots of > organizations want to have policies whose functionality includes: > > the ability to grant access by the general public (i.e. anyone) to > some set of resources DAP::set_base_rights("RightsList [Use]"); > the ability to restrict access (e.g. to employees only) to another > set of resources DAP::grant_rights("Attribute Group Employee", "RightList [Get]"); > the ability nevertheless to allow access by employees to > publicly-accessible resources given the above, nothing needs to be done. > the ability to do all the above without defining employees as members of > the public, given the above, nothing needs to be done. > and without having to explicitly authorize employees to the > publicly-accessible resources given the above, nothing needs to be done. > It seems to me (and to them, if I've been listening) perfectly natural to > express this as: > > files in /pub are accessible to the public DAP_1::set_base_rights("[Get]"); > files in /usr/bob are accessible only to bob DAP_2::grant_rights("Attribute AccessId bob", "[Get]"); > files in /usr/polar are accessible only to polar DAP_3::grant_rights("Attribute AccessId polar", "[Get]"); > > This is an explicit use of "public" in the sense in which CORBA intends it. I > can't see a problem here.... If all you are saying is that you want the "public" attribute to exist throughout the entire security system just so the DAP has the same call: > files in /pub are accessible to the public DAP_1::grant_rights("Attribute _Public ?, "[Get]"); Then I say the the whole system suffers just because of the DAP interface specification. > >> >Which policy do you want? > >> > >> I failed to parse this; what are my options. > > > >The choices were. > > > >A. "public" attribute is only present in absence of an authenticated > > principal. > >B. "public" attribute is *ALWAYS* present > > B. > > >With reference to the DomainAccessPolicy, option A allows you to write > >policies such that you can "grant" rights to unauthenticated users, but > >NOT *ANY* authenticated user, thereby making the difference known to the > >access control system. > > > >option B yields no difference to the access control system of whether the > >principal is authenticated or not, but one CAN grant rights to *EVERYBODY* > >in that domain. > > > >Option B is equivalent to eliminating the public attribute and being able > >to set a base set of rights in the domain granted to EVERYBODY. > > Not quite; you can only do this by either: > > 1. Inferring a "public" security attribute from "any credential" when you > make an access check, or > 2. Adding a non-attribute-based entry to the ACL In answer to 1. The "public" security attribute must be "inferred" by the ORB. Which is better, "inferring" and "creating" the public attribute by the ORB to be passed to an AccessPolicy; or having the AccessPolicy service make its own decisions based on truths of the system more efficiently? To number 2. It only implies that your ACL system is defficient in its expressability. Something I don't like. And it also implies that attributes are additive with respect to rights something else I don't like. Attributes being additive with respect to rights is only implied by the DomainAccessPolicy, of which I'd like to keep that contained to where it is, in the DAP, and not have it implied for general AccessPolicy or other AccessDecision objects (ones that don't even care about AccessPolicy). > I don't like either of these. > > >> >> I propose we close this issue immediately and retain the public > attribute. > >> > > >> >I disagree entirely. > >> > >> So do I (still) :-) > > > >You are still not budging me. I'll repeat: > > > >The ACL implementation should have someway of expressing its needs that > >conforms to the functionality of the system. The system should NOT have to > >conform to the expresssability limitations of some particular inferior ACL > >implementation. > > > >Anybody else like to get into this discussion? > > > >I can tell this one is going to take a few more beers at the office :) > > Dang! You all know how much I hate the office :) Okay who's got the first round? Cheers, -Polar ------------------------------------------------------------------- Polar Humenn Adiron, LLC Principal 2-212 Center for Science & Technology mailto:polar@adiron.com CASE Center/Syracuse University Phone: 315-443-3171 Syracuse, NY 13244-4100 Fax: 315-443-4745 http://www.adiron.com Reply-To: "Bob Blakley" From: "Bob Blakley" To: "Polar Humenn" Cc: , "Juergen Boldt" Subject: Re: issue 2800 -- Security RTF Issue Date: Wed, 11 Aug 1999 09:57:20 -0500 X-Mailer: Microsoft Outlook Express 4.72.3110.1 Polar, >Not so in all mechanisms, or even any of the mechanisms I am familiar >with. The Kerberos system especially, the "public" attribute, is not >present. I'm not even sure if that attribute gets shipped with the Sesame >PAC. What about DCE; is there a "public" attribute shipped in its context >establishment token? Other than it just being implied? This isn't a mechanism issue; it's a CORBA credential issue. This is the way the behavior of the security services is spec'd in CORBA and it needs to be supported on *all* mechanisms. Neither Kerberos nor SESAME support transmission of clearance attributes, either, but CORBA does. >Attributes need not come from the context establishment token, either. >Since it is unspecified where they come from, they can come from some >external service in conjunction and based the authentication context >establishment token. This is the scenario we are trying to get to with >CSIv2, I might add. This isn't the case; in fact this is why the RAD service had to be defined. There was until HRAC/RAD no way to go to an external service to get security attributes not provided as a part of the context establishment token. CSIv2 is trying to separate authentication and authorization services, but that doesn't mean that the authorization service doesn't pass security attribute information from client ORB to target ORB in authorization context establishment tokens (or if it does, I claim that it doesn't support the CORBAsecurity model, which is a problem). >> No; I disagree. The point I'm making here is that it should be >> possible for the target to figure out everything about the client's >> authentication and privilege attribute status by examining the >> privilege attribute set the client passes. Presence of any >> authenticated attribute means the client authenticated that attribute; >> the fact that the public attribute is (also) there doesn't confuse the >> target about the fact that the other attributes were authenticated. > >Given that, I'm at a loss of whether the presence of the public attribute >leads to any confusion about "other" attributes. Especially, since you >imply that they are additive with respect to rights (i.e. without relation >to each other). Can you explain with an example? See below for additivity confusion. I'm not claiming that security attributes are additive with respect to rights in all policy mechanisms. >> I don't think this needs to be clarified. It *does* need to be said, >> for a particular policy object type, whether policy entries are >> additive or not. However I can't think of another interpretation of >> attributes which makes any sense. Attributes are just adjectives. A >> large, red barn is large AND red. I don't think anyone is in any >> doubt about this, nor is anyone likely to interpret a set of >> attributes differently, though some people may want to make sure that >> only one of the client's ROLE attributes (for example) can be used in >> a single access decision. But that's a policy thing, not an attribute >> assertion thing. > >Hey, you may think their additive, and I might think their additive, but >not everybody will think so. Believe me on this one! There is no harm, and >perhaps *helpful* to lay down the semantics of attributes in such a way >that it is not implied, but explicit. I think we agree, it does *need* to >be said. However, a little clarification wouldn't hurt. :) I don't object to clarification, even if it shouldn't be strictly necessary. >> There may be, but we should also observe "stare decisus" to some >> extent; the spec. already exists and has been (to varying extents) >> implemented, and we shouldn't change things just because they're not >> perfect, especially in pursuit of small benefits. Sometimes good >> enough is good enough. > >I still say it bogs down the system in order to support an inferior policy >object, and I would like to fix the defficiency before it gets too >"implemented". And I say it doesn't bog the system down in any significant way whatsoever. >> Yeah, but this makes it more difficult to audit what happened, because the >> credential only implicitly indicates the information which forms the basis for >> the access decision. > >What??!?! First of all to make any sense of some log that says some rights >were issued due to these attributes can make no conclusion without the >definition of the AccessPolicy object (DomainAccessPolicy or not), whether >or not the "public" attribute existed in the list of attributes. Yes, but this is true in any case - you always need to know what the policy was before you know whether the "right" decision was made. What I'm saying here is that it's much easier (even if you know what the policy is) to analyze what happened if you know what the *inputs* to the policy decision were. Implicit inputs are harder to detect.... >> And I still disagree. Access policies which allow "public" access will >> always check (and grant) access on the basis of this attribute, and they'll >> be able to do so without special-case code for handling non-attribute-based >> properties of the client subject. > >Noway Jose! > >If I write an AccessPolicy, and I want to grant rights to *everybody* and >then grant rights to individual attributes. Then I would write: > > rights = ; // for everybody in domain > for (i = 0;i < attrs.length; i++) > rights = rights ++ get_rights_for(attrs[i]); > >Pretty simple, eh? > >Where is the special case? The special case is > rights = ; // for everybody in domain With a public attribute, the code is even simpler -- just: > for (i = 0;i < attrs.length; i++) > rights = rights ++ get_rights_for(attrs[i]); >And, I've got one less call to "get_rights_for". This is exactly my problem; in your example, "rights = " is, from the CORBA point of view, a policy without a subject. I don't want to have us wedded to DAP or even ACLs, but we do have a subject/object/action model, and I don't want to do away with subjects. >> I disagree that this is implementation-specific. It's a model issue. >> Clients communicate subject security attribute information explicitly >> to target ORBs via context establishment tokens. Subject security >> attribute information is always explicit and always expressed as >> security attributes. Hence, of course, it's always marshalled and >> unmarshalled. > >I disagree since the "public" attribute is not explicitly passed in >context establishment tokens, and is therefore "implied". This is an implementation specific. I'd claim that it should be passed in context establishment tokens, along with all the other attributes. >> By the way, I think the efficiency argument here is entirely a red >> herring. The public security attribute doesn't even have a meaningful >> value. The type data is a very simple numeric data structure, and any >> processing overhead for this tiny piece of data will be completely >> negligible. > >Tell that to anybody who wants to do 10000 tranactions a second. Anybody who wants to do this isn't going to authenticate all of them individually anyway, so it doesn't matter whether the context establishment token is 32 bits longer or 3200. >> >The ACL implementation should have someway of expressing its needs that >> >conforms to the functionality of the system. The system should NOT have to >> >conform to the expresssability limitations of some particular inferior ACL >> >implementation. >> >> I'm not sure what conclusion I'm supposed to draw from this. Lots of >> organizations want to have policies whose functionality includes: >> >> the ability to grant access by the general public (i.e. anyone) to >> some set of resources > > DAP::set_base_rights("RightsList [Use]"); As I explained above, this is the part I don't like. >> the ability to restrict access (e.g. to employees only) to another >> set of resources > > DAP::grant_rights("Attribute Group Employee", "RightList [Get]"); > >> the ability nevertheless to allow access by employees to >> publicly-accessible resources > > given the above, nothing needs to be done. > >> the ability to do all the above without defining employees as members of >> the public, > > given the above, nothing needs to be done. > >> and without having to explicitly authorize employees to the >> publicly-accessible resources > > given the above, nothing needs to be done. > > >> It seems to me (and to them, if I've been listening) perfectly natural to >> express this as: >> >> files in /pub are accessible to the public > DAP_1::set_base_rights("[Get]"); >> files in /usr/bob are accessible only to bob > DAP_2::grant_rights("Attribute AccessId bob", "[Get]"); >> files in /usr/polar are accessible only to polar > DAP_3::grant_rights("Attribute AccessId polar", "[Get]"); >> >> This is an explicit use of "public" in the sense in which CORBA intends it. I >> can't see a problem here.... > >If all you are saying is that you want the "public" attribute to exist >throughout the entire security system just so the DAP has the same call: > >> files in /pub are accessible to the public > > DAP_1::grant_rights("Attribute _Public ?, "[Get]"); > >Then I say the the whole system suffers just because of the DAP interface >specification. Again I disagree. You seem to be saying that any subject-based policy scheme is DAP. This simply isn't true. >> >Option B is equivalent to eliminating the public attribute and being able >> >to set a base set of rights in the domain granted to EVERYBODY. >> >> Not quite; you can only do this by either: >> >> 1. Inferring a "public" security attribute from "any credential" when you >> make an access check, or >> 2. Adding a non-attribute-based entry to the ACL > >In answer to 1. The "public" security attribute must be "inferred" by the >ORB. Which is better, "inferring" and "creating" the public attribute by >the ORB to be passed to an AccessPolicy; or having the AccessPolicy >service make its own decisions based on truths of the system more >efficiently? I'm a little confused about what's being said here. However I would like to repeat that I think ALL AccessDecision mechanisms should be making their decisions based on the *same*, explicit, view of the requester's cred. >To number 2. It only implies that your ACL system is defficient in its >expressability. Something I don't like. And it also implies that >attributes are additive with respect to rights something else I don't >like. > >Attributes being additive with respect to rights is only implied by the >DomainAccessPolicy, of which I'd like to keep that contained to where it >is, in the DAP, and not have it implied for general AccessPolicy or other >AccessDecision objects (ones that don't even care about AccessPolicy). I'm not talking about attributes being additive "with respect to rights". What I'm talking about is attributes being additive "with respect to subject possession"; that is, that a user whose credential asserts more than one security attribute, is considered to be simultaneously described by all those attributes. Different mechanisms can choose to do whatever they wish about rights (including not use them at all) - however they have to combine the *consequences* of subjects having multiple attributes at the same time. In some cases this will be subtractive rather than additive -- e.g. when you have several roles which are mutually exclusive you'll only get the rights associated with one. The DomainAccessPolicy has both rights and union semantics, which means that in systems using DAP to enforce policy, the FACT that attributes are additive with respect to subject possession implies that policy is additive with respect to the rights contingent upon possession of attributes. CORBA *IS* additive with respect to attribute possession. You can like or dislike this, but that's the way it is. A credential is the SET defined by the union of (in some implementations possibly a subset of) the entitled security attributes of the requesting subject. >> >I can tell this one is going to take a few more beers at the office :) >> >> Dang! You all know how much I hate the office :) > >Okay who's got the first round? Hmmm... I think if you raise an issue, you have to buy a round! --bob Bob Blakley (blakley@dascom.com) Chief Scientist, Dascom X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Wed, 11 Aug 1999 12:00:46 -0400 (EDT) From: Polar Humenn To: Bob Blakley cc: sec-rev@emerald.omg.org, Juergen Boldt Subject: Re: issue 2800 -- Security RTF Issue Bob, On Wed, 11 Aug 1999, Bob Blakley wrote: > Polar, > > >Not so in all mechanisms, or even any of the mechanisms I am familiar > >with. The Kerberos system especially, the "public" attribute, is not > >present. I'm not even sure if that attribute gets shipped with the Sesame > >PAC. What about DCE; is there a "public" attribute shipped in its context > >establishment token? Other than it just being implied? > > This isn't a mechanism issue; it's a CORBA credential issue. This is the > way the behavior of the security services is spec'd in CORBA and it needs > to be supported on *all* mechanisms. Neither Kerberos nor SESAME > support transmission of clearance attributes, either, but CORBA does. No, it is a mechanism issue. The is nothing stating, other than in the specific mechanism, that any "attributes" are transmitted at all! > >Attributes need not come from the context establishment token, either. > >Since it is unspecified where they come from, they can come from some > >external service in conjunction and based the authentication context > >establishment token. This is the scenario we are trying to get to with > >CSIv2, I might add. > > This isn't the case; in fact this is why the RAD service had to be defined. > There was until HRAC/RAD no way to go to an external service to get > security attributes not provided as a part of the context establishment > token. Okay, not until HRAC/RAD, there was a standard for such a thing. But internal to the mechanism provided there is nothing stoping that security mechanism of the ORB from getting a context establishment token that says the client is "X", and that is all, and then, the security mechanism, may go off to its own external service and ask for X's privileges. Granted this may have to do specifically with a particular mechanism, but it has nothing to do with attributes being transmitted in the SECIOP context establishment token. > CSIv2 is trying to separate authentication and authorization services, > but that doesn't mean that the authorization service doesn't pass > security attribute information from client ORB to target ORB in authorization > context establishment tokens (or if it does, I claim that it doesn't support > the CORBAsecurity model, which is a problem). I'm having trouble parsing. You mean to say that the authorization server *CAN* pass security attribute information crom client ORB to target ORB. Yes, I agree with *CAN*, but it doesn't have to. If you claim, if it gets that authorization information (attributes) from somewhere else other than the client directly (on the server side), that it doesn't support the CORBA security model, then I say you are laying down a needless implementation constraint. In CSIv2, Abby as a client may pass Bob, a context establishment token claiming to be Abbey, and that is all. Nothing more. Later after the context is established, Abby sends a whole list of attributes to be used for authorization to Bob. However, to Bob, the server, it is completely a different trust matter of whether I even pay attention to those attributes. Bob just may go ask Bob's trust service, such questions as what attributes does Abby really have in my universe of discourse. It's all still legal in CORBA security. And definately, should not be procluded. Otherwise servers are at the totally at mercy of their clients. > >> No; I disagree. The point I'm making here is that it should be > >> possible for the target to figure out everything about the client's > >> authentication and privilege attribute status by examining the > >> privilege attribute set the client passes. Presence of any > >> authenticated attribute means the client authenticated that attribute; > >> the fact that the public attribute is (also) there doesn't confuse the > >> target about the fact that the other attributes were authenticated. > > > >Given that, I'm at a loss of whether the presence of the public attribute > >leads to any confusion about "other" attributes. Especially, since you > >imply that they are additive with respect to rights (i.e. without relation > >to each other). Can you explain with an example? > > See below for additivity confusion. I'm not claiming that security attributes > are additive with respect to rights in all policy mechanisms. > > >> I don't think this needs to be clarified. It *does* need to be said, > >> for a particular policy object type, whether policy entries are > >> additive or not. However I can't think of another interpretation of > >> attributes which makes any sense. Attributes are just adjectives. A > >> large, red barn is large AND red. I don't think anyone is in any > >> doubt about this, nor is anyone likely to interpret a set of > >> attributes differently, though some people may want to make sure that > >> only one of the client's ROLE attributes (for example) can be used in > >> a single access decision. But that's a policy thing, not an attribute > >> assertion thing. > > > >Hey, you may think their additive, and I might think their additive, but > >not everybody will think so. Believe me on this one! There is no harm, and > >perhaps *helpful* to lay down the semantics of attributes in such a way > >that it is not implied, but explicit. I think we agree, it does *need* to > >be said. However, a little clarification wouldn't hurt. :) > > I don't object to clarification, even if it shouldn't be strictly necessary. > > >> There may be, but we should also observe "stare decisus" to some > >> extent; the spec. already exists and has been (to varying extents) > >> implemented, and we shouldn't change things just because they're not > >> perfect, especially in pursuit of small benefits. Sometimes good > >> enough is good enough. > > > >I still say it bogs down the system in order to support an inferior policy > >object, and I would like to fix the defficiency before it gets too > >"implemented". > > And I say it doesn't bog the system down in any significant way whatsoever. Like I said, tell that to somebody who wants to make 10000 transactions a second. Paul? Comment? > >> Yeah, but this makes it more difficult to audit what happened, because the > >> credential only implicitly indicates the information which forms the basis > for > >> the access decision. > > > >What??!?! First of all to make any sense of some log that says some rights > >were issued due to these attributes can make no conclusion without the > >definition of the AccessPolicy object (DomainAccessPolicy or not), whether > >or not the "public" attribute existed in the list of attributes. > > Yes, but this is true in any case - you always need to know what the policy > was > before you know whether the "right" decision was made. What I'm saying here > is that it's much easier (even if you know what the policy is) to analyze what > happened if you know what the *inputs* to the policy decision were. Implicit > inputs are harder to detect.... They are not implicit. If you specify every potential client of a domain has a base set of rights, it is just as explicit as giving rights to the "Public" attribute that is supposedly already and always there. (It's pretty fragile policy statement). Do you think it should be possible to "drop" the PUBLIC attribute from the "get_effective_rights" call? > >> And I still disagree. Access policies which allow "public" access will > >> always check (and grant) access on the basis of this attribute, and they'll > >> be able to do so without special-case code for handling non-attribute-based > >> properties of the client subject. > > > >Noway Jose! > > > >If I write an AccessPolicy, and I want to grant rights to *everybody* and > >then grant rights to individual attributes. Then I would write: > > > > rights = ; // for everybody in domain > > for (i = 0;i < attrs.length; i++) > > rights = rights ++ get_rights_for(attrs[i]); > > > >Pretty simple, eh? > > > >Where is the special case? > > The special case is > > > rights = ; // for everybody in domain > > With a public attribute, the code is even simpler -- just: > > > for (i = 0;i < attrs.length; i++) > > rights = rights ++ get_rights_for(attrs[i]); > > >And, I've got one less call to "get_rights_for". > > This is exactly my problem; in your example, "rights = rights>" is, from the CORBA point of view, a policy without a subject. > I don't want to have us wedded to DAP or even ACLs, but we do have a > subject/object/action model, and I don't want to do away with > subjects. I should have been clearer: You wrote: > > for (i = 0;i < attrs.length; i++) > > rights = rights ++ get_rights_for(attrs[i]); You still need initialization, "rights = []" at the begining. Which can very easily be rights = get_base_rights(); for(i=0; i < attrs.length; i++) rights = rights ++ get_rights_for(attrs[i]); What I meant, is there is one less iteration in the loop. Plus the fact that you didn't have to marshal and unmarshal the PUBLIC attribute. > >> I disagree that this is implementation-specific. It's a model issue. > >> Clients communicate subject security attribute information explicitly > >> to target ORBs via context establishment tokens. Subject security > >> attribute information is always explicit and always expressed as > >> security attributes. Hence, of course, it's always marshalled and > >> unmarshalled. > > > >I disagree since the "public" attribute is not explicitly passed in > >context establishment tokens, and is therefore "implied". > > This is an implementation specific. I'd claim that it should be passed > in context establishment tokens, along with all the other attributes. I'm sorry Bob, but just plain and simple. Some mechanims just DO NOT PASS any SecAttribute(s) (other than implied attributes). If you claim it a constraint that SecAttributes are passed in the context establishment token, then you must get rid of Kerberos, DCE, SSL, SPKM, and everything but ECMA-Sesame from the CORBA security protocol suite. Square 1. > > By the way, I think the efficiency argument here is entirely a red > >> herring. The public security attribute doesn't even have a meaningful > >> value. The type data is a very simple numeric data structure, and any > >> processing overhead for this tiny piece of data will be completely > >> negligible. > > > >Tell that to anybody who wants to do 10000 tranactions a second. > > Anybody who wants to do this isn't going to authenticate all of them > individually anyway, so it doesn't matter whether the context > establishment token is 32 bits longer or 3200. So, what's the point about transmitting superfluous and uneeded data? Is there anybody in the performance groups, or the high troughput groups have any comments about this? > >> >The ACL implementation should have someway of expressing its needs that > >> >conforms to the functionality of the system. The system should NOT have to > >> >conform to the expresssability limitations of some particular inferior ACL > >> >implementation. > >> > >> I'm not sure what conclusion I'm supposed to draw from this. Lots of > >> organizations want to have policies whose functionality includes: > >> > >> the ability to grant access by the general public (i.e. anyone) to > >> some set of resources > > > > DAP::set_base_rights("RightsList [Use]"); > > As I explained above, this is the part I don't like. what's the frigging difference? You are not "implying" anything. It's explicit! Setting rights on the PUBLIC attribute, only states that you "hope" the PUBLIC attribute makes it across the wire to the AccessPolicy. > >> the ability to restrict access (e.g. to employees only) to another > >> set of resources > > > > DAP::grant_rights("Attribute Group Employee", "RightList [Get]"); > > > >> the ability nevertheless to allow access by employees to > >> publicly-accessible resources > > > > given the above, nothing needs to be done. > > > >> the ability to do all the above without defining employees as members > of > >> the public, > > > > given the above, nothing needs to be done. > > > >> and without having to explicitly authorize employees to the > >> publicly-accessible resources > > > > given the above, nothing needs to be done. > > > > > >> It seems to me (and to them, if I've been listening) perfectly natural to > >> express this as: > >> > >> files in /pub are accessible to the public > > DAP_1::set_base_rights("[Get]"); > >> files in /usr/bob are accessible only to bob > > DAP_2::grant_rights("Attribute AccessId bob", "[Get]"); > >> files in /usr/polar are accessible only to polar > > DAP_3::grant_rights("Attribute AccessId polar", "[Get]"); > >> > >> This is an explicit use of "public" in the sense in which CORBA intends it. > I > >> can't see a problem here.... > > > >If all you are saying is that you want the "public" attribute to exist > >throughout the entire security system just so the DAP has the same call: > > > >> files in /pub are accessible to the public > > > > DAP_1::grant_rights("Attribute _Public ?, "[Get]"); > > > >Then I say the the whole system suffers just because of the DAP interface > >specification. > > Again I disagree. You seem to be saying that any subject-based policy > scheme is DAP. This simply isn't true. No!!!!! That is NOT what I am saying!!!! I'm saying the entire SYSTEM suffers just to support current the DAP interface, because the current DAP interface doesn't have a way to specify rights for every subject in a domain unless the PUBLIC attribute always exists in a credentials object. Any other AccessPolicy in its right mind and worth its salt in implemenation would just ignore the PUBLIC attribute, because it already knows the damn thing is there! > >> >Option B is equivalent to eliminating the public attribute and being able > >> >to set a base set of rights in the domain granted to EVERYBODY. > >> > >> Not quite; you can only do this by either: > >> > >> 1. Inferring a "public" security attribute from "any credential" when > you > >> make an access check, or > >> 2. Adding a non-attribute-based entry to the ACL > > > >In answer to 1. The "public" security attribute must be "inferred" by the > >ORB. Which is better, "inferring" and "creating" the public attribute by > >the ORB to be passed to an AccessPolicy; or having the AccessPolicy > >service make its own decisions based on truths of the system more > >efficiently? > > I'm a little confused about what's being said here. However I would like > to repeat that I think ALL AccessDecision mechanisms should be making > their decisions based on the *same*, explicit, view of the requester's cred. And they do, I just point out, that first of all you must infer that the public attribute exists and if it is actually created. Just where to you do that inference and creation? In the ORB, at context establishment, put it into a Credentials object, and then pass it needlessly to an AccessPolicy, or just have the access policy know that every subject has an explicit set of rights to start with. The second way is more efficient, and less fragile. > >To number 2. It only implies that your ACL system is defficient in its > >expressability. Something I don't like. And it also implies that > >attributes are additive with respect to rights something else I don't > >like. > > > >Attributes being additive with respect to rights is only implied by the > >DomainAccessPolicy, of which I'd like to keep that contained to where it > >is, in the DAP, and not have it implied for general AccessPolicy or other > >AccessDecision objects (ones that don't even care about AccessPolicy). > > I'm not talking about attributes being additive "with respect to > rights". What I'm talking about is attributes being additive "with > respect to subject possession"; that is, that a user whose credential > asserts more than one security attribute, is considered to be > simultaneously described by all those attributes. Different mechanisms > can choose to do whatever they wish about rights (including not use > them at all) - however they have to combine the *consequences* of > subjects having multiple attributes at the same time. In some cases > this will be subtractive rather than additive -- e.g. when you have > several roles which are mutually exclusive you'll only get the rights > associated with one. The DomainAccessPolicy has both rights and union > semantics, which means that in systems using DAP to enforce policy, > the FACT that attributes are additive with respect to subject > possession implies that policy is additive with respect to the rights > contingent upon possession of attributes. > CORBA *IS* additive with respect to attribute possession. You can > like or dislike this, but that's the way it is. A credential is the > SET defined by the union of (in some implementations possibly a subset > of) the entitled security attributes of the requesting subject. Okay fair enough. I'll agree with that the additivness of "possesion". Never disagreed with that. But that doesn't mean I agree with this PUBLIC attribute existing. If it exists EVERWHERE, ALL THE TIME, and UNCONDITIONALLY, the it's redundant and a pretty useless piece of information. In fact, it is NO information. If we stick with this, I'm just sorry that CORBA security systems will suffer performance wise by passing around a bit of useless information. BTW, what is the value of the PUBLIC attribute? I know you say that it has "no value of significance", but the spec doesn't explicitly say what its value is. So does that mean it can have a 3000 byte character string in its value? Yet we ignore its value, and just play with its existance. Oh, BTW, it ALWAYS exists! And we got to pass it around. I still think this subject warrants discussion in San Jose. > Hmmm... I think if you raise an issue, you have to buy a round! Fair enough. :) But you an me, since nobody else has entered the argument! -Polar ------------------------------------------------------------------- Polar Humenn Adiron, LLC Principal 2-212 Center for Science & Technology mailto:polar@adiron.com CASE Center/Syracuse University Phone: 315-443-3171 Syracuse, NY 13244-4100 Fax: 315-443-4745 http://www.adiron.com