Issue 2028: own-cedentials model (sec-rev) Source: (, ) Nature: Uncategorized Issue Severity: Summary: Summary: I"m having real problems trying to interpret the specification on the own_credentials list. I"m working from the Security Spec 1.2, 5 Jan 1998 It seems to be implied by paragraph 4 of 15.5.4.1 Description of Facilities on page 15-87, which says: Credential objects are created as a result of: o Authentication (see Section 15.5.3, "Authentication of Principals", on page 15-85. o Copying an existing Credentials Object o Asking for a Credentials object via Current (see Section 15.5.6, "Security Operations on Current" on page 15-97). and, by paragraph 7 of section 15.5.6.3 SecurityLevel2::Current Interface: own_credentials Any application owns a set of credentials which it obtains through the process of authentication of the principal that initiates the execution of the program, and further from other credentials that such a principal might bestow upon the application. This attribute returns this set of credentials. Okay, so the problem is that these statements imply, but do not explicitly stipulate that the PrincipalAuthenticator puts Credentials objects on the "own_credentials" list. Resolution: Revised Text: Actions taken: October 2, 1998: received issue November 13, 1998: closed issue Discussion: End of Annotations:===== Return-Path: X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Fri, 2 Oct 1998 10:32:25 -0400 (EDT) From: Polar Humenn Reply-To: Polar Humenn To: secsig@omg.org, sec-rev@omg.org Subject: own-credentials model. I'm having real problems trying to interpret the specification on the own_credentials list. I'm working from the Security Spec 1.2, 5 Jan 1998 It seems to be implied by paragraph 4 of 15.5.4.1 Description of Facilities on page 15-87, which says: Credential objects are created as a result of: o Authentication (see Section 15.5.3, "Authentication of Principals", on page 15-85. o Copying an existing Credentials Object o Asking for a Credentials object via Current (see Section 15.5.6, "Security Operations on Current" on page 15-97). and, by paragraph 7 of section 15.5.6.3 SecurityLevel2::Current Interface: own_credentials Any application owns a set of credentials which it obtains through the process of authentication of the principal that initiates the execution of the program, and further from other credentials that such a principal might bestow upon the application. This attribute returns this set of credentials. Okay, so the problem is that these statements imply, but do not explicitly stipulate that the PrincipalAuthenticator puts Credentials objects on the "own_credentials" list. It would almost seem that the PrincipalAuthenticator can indeed just create a Credentials object and use it in an InvocationCredentialsPolicy, but it doesn't have to go on the own_credentials list. However, there is no explicit way to create a Credentials object and place it on the own_credentials list. I seem to remember we had that capability, but we nixed it for some reason. Bob, help me on this, I remember nixing the SecOwnCredentials CredentialsType identifier so you couldn't explicity set_credentials on own_credentials, basically because we thought that could be a bad thing. All in all, how should we go about this? If we let the PrincipalAuthenticator put the credentials on the own_credentials list, how do we manage the list. What gets added, what gets removed, what gets replaced? Currently, this is what we do at Adiron: In the list of own_credentials a Credentials object can be identified soley by its mechanism, and credentials are specific to the mechanism. Therefore if the PrincipalAuthenticator creates new credentials for a particular mechanism, and there already exists a Credentials object on own_credentials for that mechanism, it is replaced with the newly created Credentials object. Any implementers or architects care to share their thoughts on this topic so we can get the spec to say something definite? Thanks, -Polar ------------------------------------------------------------------- Polar Humenn Adiron, LLC President 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 Return-Path: Date: Fri, 2 Oct 1998 14:01:36 -0400 (EDT) From: Polar Humenn X-Sender: polar@serval.cat.syr.edu To: secsig@omg.org, sec-rev@omg.org Subject: Principal Authenticator and own_credentials. The following description would apply if you take the notion that one Credentials object represents only one security mechanism. Any comments on the following description? The Principal Authenticator object creates a Credentials object and places it on the Current objects own_credentials list only after authenticate or continue_authentication returns a value of SecAuthSuccess. A Credentials object is created specific to the mechanism selected in authenticate. During creation of a Credentials object of a certain mechanism, if a Credentials object with that specific mechanism already exists on the Current objects own_credentials list, the Principal Authenticator object replaces that Credentials object with the newly created Credentials object. This restriction mantains a one-to-one relationship bewteen mechanisms and Credentials objects on the Current objects own_credentials list. The one-to-one relationship facilitates the use of MechanismPolicy to select the proper Credentials object from the own_credentials list for an invocation should a list of Credentials be used for InvocationCredentialsPolicy. The caller of authenticate must know that a particular Credentials object will be replaced if a new Credentials object is successfully created. The caller must manage any existing references to the old Credentials object (perhaps by calling destroy). For example, an old Credentials object may be specified in previously created InvocationCredentialsPolicy object attached to some target object reference. ------------------------------------------------------------------- Polar Humenn BlackWatch Technology, Inc. Chief Science Officer 2-212 Center for Science & Technology mailto:polar@blackwatch.com CASE Center/Syracuse University Phone: 315-443-3171 Syracuse, NY 13244-4100 Fax: 315-443-4745 http://www.blackwatch.com Return-Path: X400-Received: by mta tutartis in /PRMD=ICL/ADMD=GOLD 400/C=GB/ ; Relayed ; Mon, 05 Oct 98 10:32:36 +0100 X400-Received: by mta man23xc in /PRMD=ICL/ADMD=GOLD 400/C=GB/ ; converted (IA5-Text) ; Relayed ; Mon, 05 Oct 98 10:20:55 +0100 X400-Received: by mta man0506 in /PRMD=icl/ADMD=gold 400/C=GB/ ; converted ({ 1 3 12 2 1001 1 0 4 300 0 507 }) ; Relayed ; Mon, 05 Oct 98 10:30:04 +0100 X400-Received: by /PRMD=icl/ADMD=gold 400/C=GB/ ; converted (IA5-Text) ; Relayed ; Mon, 05 Oct 98 10:30:04 +0100 Date: Mon, 05 Oct 98 10:30:04 +0100 X400-MTS-Identifier: [/PRMD=icl/ADMD=gold 400/C=GB/;man0506 0000042400015187] X400-Originator: "NC Battle" X400-Recipients: non-disclosure:; X400-Content-Type: P2-1984 (2) Original-Encoded-Information-Types: { 1 3 12 2 1001 1 0 4 300 0 707 } Content-Identifier: 15187 Priority: normal From: "NC Battle" To: polar@adiron.com Cc: secsig@omg.org, sec-rev@omg.org References: Importance: normal Subject: RE: own-credentials model. > Currently, this is what we do at Adiron: In the list of own_credentials a Credentials object can be identified soley by its mechanism, and credentials are specific to the mechanism. Can I just clarify the situation you're describing? You're saying that an application representing the user makes multiple calls to the PrincipalAuthenticator, quoting a different authentication mechanism each time - say once using Kerberos, once using SKMP etc. Do you quote a different principal name each time? In what sense (if any) are they the same principal? I've always thought of the PrincipalAuthenticator as something a client uses to prove who they are (which they only have to do once), and then by means of copying and set_attributes clones of the original owner credentials are obtained to assert specific "sides" of the same principal to various targets. So you only have one (original) "own" credentials, though possibly many derivations of it. Are you saying you have many principals operating concurrently, or just that you want various mechanisms for the same principal operating concurrently? Perhaps this is the problem you have discovered: is there an implicit assumption that a principal has an identity that is associated with one authentication mechanism (rightly or wrongly)? -nick Return-Path: X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Mon, 5 Oct 1998 10:19:34 -0400 (EDT) From: Polar Humenn To: NC Battle cc: secsig@omg.org, sec-rev@omg.org Subject: RE: own-credentials model. Nick thatks for the comments. The fun is begining. On Mon, 5 Oct 1998, NC Battle wrote: > > Currently, this is what we do at Adiron: In the list of own_credentials a > Credentials object can be identified soley by its mechanism, and > credentials are specific to the mechanism. > > Can I just clarify the situation you're describing? You're saying that an > application representing the user makes multiple calls to the > PrincipalAuthenticator, quoting a different authentication mechanism each time > - say once using Kerberos, once using SKMP etc. Do you quote a different > principal name each time? In what sense (if any) are they the same principal? I am say emphatically, they do not have to be the same "principal". You cannot enforce that a name "polar@ADIRON.COM" and secret key for kerberos/DCE mechanims and the the name "O=ADIRON LLC, DN=Polar Humenn" and public key for an X.500 based mechanism actually represent the same "principal". You can also imagine, not so much a user, but one server servicing different objects, each which may need its own credentials. That's why I believe we have this list of own credentials. Or the model would be restricted to just one. However, for one credential object to represent different mechanism, it really gets hairy trying to figure out which attributes are what, some attributes may only be associated with one mechanism. Other questions: How to you rectify a kerberos name and a X.500 directory name to have the same AccessId? What does it mean to have two AccessId attributes? There is no way of really figuring this stuff out. Unless: ith one mechanism per Credentials object, which is what is not stated, but implied by the CSI specification anyway, we can sort this out much better. (I wouldn't say it still clear. A better Credentials model is still needed). > I've always thought of the PrincipalAuthenticator as something a client uses > to prove who they are (which they only have to do once), and then by means of > copying and set_attributes clones of the original owner credentials are > obtained to assert specific "sides" of the same principal to various targets. > So you only have one (original) "own" credentials, though possibly many > derivations of it. Yes, but what if the requirement is that you must use a public key mechanism on one object and kerberos on the other? You would need a way to discern which mechanism, keys, ids to use. > Are you saying you have many principals operating concurrently, or just that > you want various mechanisms for the same principal operating concurrently? Yes, you can think of it your first way. A capsule may be a servicer of different objects each being represented by its own credentials. This could be a trusted situation, and be a single capsule for effieciency of resources. I guess you might consider a server something like the Unix INETD program which farms off connections to be serviced by different processes. So, this hypothetical server would negotiate secure associations with clients based on the principals in own_credentials and dispatch requests to objects using different principals, eforcing integrity of the princpal/object association. > Perhaps this is the problem you have discovered: is there an implicit > assumption that a principal has an identity that is associated with one > authentication mechanism (rightly or wrongly)? Well, I doubt I can take credit for discovering that problem. It's been there all along and we've known it for a long time. In computing systems there is no provable notion of identities of principals beyond their name (and possible association with a secret or public key). We can get into the arguments of Liebniz into the Identity of Indiscernables, and Kripke's argument about names (i.e. a name is meaningless without its referant). So, currently a mechanism stipulates a name and for the most part references some key (which produces evidence). No doubt that some security mechanisms use the the same "security_name", but it is currently not and hope for in and API is that the under lying system enforces that the name references some key and the evidence provided under the sheets proves it. Until, you can provide proof in CORBA, of Liebniz's argument, ("objects" are indicernable, iff all their properties are the same, and therefore identicial, then you can say that two principal names refer to the same "principal". We can't even do this for object, let alone hairy bearded individuals behind the idea of principal. It's a philosophical argument, really. That proof cannot be emphatically be done. You cannot enforce that model that multiple mechanisms must represent the same object that is the referant of the principal. You must trust the application to do the right thing if this is to be the case. However, it is not practical, still not provable, and we must be practical. Regards, -Polar ------------------------------------------------------------------- Polar Humenn Adiron, LLC President 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 Return-Path: X400-Received: by mta tutartis in /PRMD=ICL/ADMD=GOLD 400/C=GB/ ; Relayed ; Mon, 05 Oct 98 16:15:55 +0100 X400-Received: by mta man23xc in /PRMD=ICL/ADMD=GOLD 400/C=GB/ ; converted (IA5-Text) ; Relayed ; Mon, 05 Oct 98 16:01:06 +0100 X400-Received: by mta man0506 in /PRMD=icl/ADMD=gold 400/C=GB/ ; converted ({ 1 3 12 2 1001 1 0 4 300 0 507 }) ; Relayed ; Mon, 05 Oct 98 16:10:18 +0100 X400-Received: by /PRMD=icl/ADMD=gold 400/C=GB/ ; converted (IA5-Text) ; Relayed ; Mon, 05 Oct 98 16:10:18 +0100 Date: Mon, 05 Oct 98 16:10:18 +0100 X400-MTS-Identifier: [/PRMD=icl/ADMD=gold 400/C=GB/;man0506 0000042400015188] X400-Originator: "NC Battle" X400-Recipients: non-disclosure:; X400-Content-Type: P2-1984 (2) Original-Encoded-Information-Types: { 1 3 12 2 1001 1 0 4 300 0 707 } Content-Identifier: 15188 Priority: normal From: "NC Battle" To: polar@adiron.com Cc: secsig@omg.org, sec-rev@omg.org References: Importance: normal Subject: RE(2): own-credentials model. Polar, > > In what sense (if any) are they the same principal? > I am say emphatically, they do not have to be the same > "principal". You cannot enforce that a name "polar@ADIRON.COM" and secret key for kerberos/DCE mechanims and the the name "O=ADIRON LLC, DN=Polar Humenn" and public key for an X.500 based mechanism actually represent the same "principal". Agreed. > You can also imagine, not so much a user, but one server servicing different objects, each which may need its own credentials. That sounds useful, though if the objects are running untrusted code this would have to be implemented in such a way that the operating system would partition access to the various credentials - ie. there is nothing to stop a rogue object stealing its neighbour's credentials and using them. I think this is what Trusted Identity Domains (TID) are for in the spec. In DAIS Security, we said that all objects within a capsule (process) have to run in the same TID simply because we could not enforce the trust at a lower level of granularity (we assume untrusted code). With trusted code this is different of course. We equated TID name with Security Name for simplicity. But this is nothing to do with different *mechanisms* for each object though, just different own-credentials, right? > However, for one credential object to represent different mechanism, it really gets hairy trying to figure out which attributes are what... Agreed. But isn't this what Security Technology Domains (STDs) and interdomain bridges are for (section 15.3.8 in my spec)? It's impossible to make general interpretations about the meaning of attributes if you can say nothing about the mechanisms enforcing their use. If you require communication between different STDs, then you need some sort of bridge or gateway to make a conversion - and I note that the spec writers avoided actually specifying how such a bridge might work! So we have islands of technology, within which everything is OK, and between which communication is mediated by something. Sounds good to me. > Yes, but what if the requirement is that you must use a public key mechanism on one object and kerberos on the other? You would need a way to discern which mechanism, keys, ids to use. Or always use the same mechanism as a client, and have the STD bridge convert it? I've only briefly thought about how one might construct such a bridge, but it looks very difficult - or requires the bridge to have a terrifying amount of knowledge about the principals and keys identifying the peers. Are you saying that the "domains & bridges" approach is flawed in some way? Is it provably impossible to make bridges that link STDs, or do you rather see the need for a very fine grain mixture of objects and mechanisms that the spec doesn't seem to address? -nick Return-Path: X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Mon, 5 Oct 1998 16:07:49 -0400 (EDT) From: Polar Humenn To: NC Battle cc: secsig@omg.org, sec-rev@omg.org Subject: Re: RE(2): own-credentials model. On Mon, 5 Oct 1998, NC Battle wrote: > > You can also imagine, not so much a user, but one server servicing > different objects, each which may need its own credentials. > > That sounds useful, though if the objects are running untrusted code this > would have to be implemented in such a way that the operating system would > partition access to the various credentials - ie. there is nothing to stop a > rogue object stealing its neighbour's credentials and using them. Of course. I think I stated that kind of situation would be a trusted situation with trusted code. > I think this is what Trusted Identity Domains (TID) are for in the spec. In > DAIS Security, we said that all objects within a capsule (process) have to run > in the same TID simply because we could not enforce the trust at a lower level > of granularity (we assume untrusted code). With trusted code this is different > of course. We equated TID name with Security Name for simplicity. Yes, of course, that makes sense and that's why own Credentials are said to be only capsule specific. Now the single TID really implies one Security Techonology Domain. Okay that TID can use STDs that are associated with some common identity. The TID restriction can be enforced by the ORB in the case when code is not trusted. How would you do this restriction? I believe this approach would mean that only one "own" Credentials object can be created exist (not counting its copy()'d derivatives). Hmmm, sound like what you were getting at. But Hey! we have a list for "own" credentials? The upshot is that we would have to spec that restrictions out, and maybe a service type indicator stating if you are restricted to a single TID/STD. But, then someone would have to build the bridge you allude to below. It wouldn't be able to be built in a standard CORBA fashion. > But this is nothing to do with different *mechanisms* for each object though, > just different own-credentials, right? > > > However, for one credential object to represent different mechanism, it > really gets hairy trying to figure out which attributes are what... > > Agreed. But isn't this what Security Technology Domains (STDs) and interdomain > bridges are for (section 15.3.8 in my spec)? Agreed. However, how would you build one? > It's impossible to make general > interpretations about the meaning of attributes if you can say > nothing about > the mechanisms enforcing their use. If you require communication > between > different STDs, then you need some sort of bridge or gateway to make > a > conversion - and I note that the spec writers avoided actually > specifying how > such a bridge might work! Yeah, this is what we yanks term a "punt". Although I agree that we maybe we shouldn't specify how a bridge like that should be implemented. We should still to have enough functionality in CORBA to be able to actually build one. (That's just my philosophy of not always going outside of the CORBA domain to build needed functionality, like saying "Its an administrative detail."). > So we have islands of technology, within which everything is OK, and between > which communication is mediated by something. Sounds good to me. > > > Yes, but what if the requirement is that you must use a public key > mechanism on one object and kerberos on the other? You would need a way to > discern which mechanism, keys, ids to use. > > Or always use the same mechanism as a client, and have the STD bridge convert > it? I've only briefly thought about how one might construct such a bridge, but > it looks very difficult - or requires the bridge to have a terrifying amount > of knowledge about the principals and keys identifying the peers. Yeah, I would say so. Also, it would be very inefficient, especially if the client had to log on different times with different mechanisms. Hmmm, that's what we have single sign-on technology for because that causes too many headaches. So much for the client. I do agree your approach would work, perhaps not using CORBA, and not some wierd proprietary underling? You wouldn't be able to use a Secure ORB, because it would have to service two or more TIDs as well as two or more STDs. If you take the approach where you call the PrincipalAuthenticator for "polar@ADIRON.COM" for kerberos and call it again for "O=ADIRON LLC DN=Polar Humenn" for X.509, given that my application is trusted as a bridge (FOR ME) and as I have given it the "secret" information necessary to authenticate and create both these credentials, you can see very quickly how to implement this STD bridge that you talk about, all with a standard security implementation. Voila! Granted a solution such as that is quite limited to bridging between two or more identities using respective mechanisms, but it is extremely more trusted than the bridge you talk of knowing alot about everything. However, I agree we should be able to handle the "everything" case to handle scaleability, which would slightly alter my one-to-one mechanism restriction for the list of "own" credentials maintained on the Current object. However, there is no operations for manipulating the own_credentials list, other than having the PA put a Credentials object on it. I'll have to think about this, get it implemented, and get back to you. > Are you saying that the "domains & bridges" approach is flawed in some way? I think they are fine. It depends on how you interpret them, and by god, how you "can" implement them. Remember, we must be able to implement them as well as talk about them. (So much for the interceptor spec, and say, persistent object services?) > Is > it provably impossible to make bridges that link STDs, or do you > rather see > the need for a very fine grain mixture of objects and mechanisms > that the spec > doesn't seem to address? I think to make the domains & bridges like what you say are hard to implement effciently one way or the other. I'd rather not have to get to the case where I need two domains and a bridge for every pair of objects, although I wouldn't proclude the possiblility. It's not just liking STDs it's liking both TIDs and STDs simultaneously. It looks like there are always some trade offs between "trustedness" (amount of secrets and knowledge kept about identities by an "everything" bridge) and resources (my two identity example above). Thanks for the input, Nick! -Polar All you people who speak up at the RTF meetings, anybody like to comment? That is, get involved in the discussions? I'd rather you comment/argue here than just at the meetings. ------------------------------------------------------------------- Polar Humenn Adiron, LLC President 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 Return-Path: X400-Received: by mta tutartis in /PRMD=ICL/ADMD=GOLD 400/C=GB/ ; Relayed ; Tue, 06 Oct 98 13:25:10 +0100 X400-Received: by mta man23xc in /PRMD=ICL/ADMD=GOLD 400/C=GB/ ; converted (IA5-Text) ; Relayed ; Tue, 06 Oct 98 13:13:57 +0100 X400-Received: by mta man0506 in /PRMD=icl/ADMD=gold 400/C=GB/ ; converted ({ 1 3 12 2 1001 1 0 4 300 0 507 }) ; Relayed ; Tue, 06 Oct 98 13:22:53 +0100 X400-Received: by /PRMD=icl/ADMD=gold 400/C=GB/ ; converted (IA5-Text) ; Relayed ; Tue, 06 Oct 98 13:22:53 +0100 Date: Tue, 06 Oct 98 13:22:53 +0100 X400-MTS-Identifier: [/PRMD=icl/ADMD=gold 400/C=GB/;man0506 0000042400015191] X400-Originator: "NC Battle" X400-Recipients: non-disclosure:; X400-Content-Type: P2-1984 (2) Original-Encoded-Information-Types: { 1 3 12 2 1001 1 0 4 300 0 707 } Content-Identifier: 15191 Priority: normal From: "NC Battle" To: polar@adiron.com Cc: secsig@omg.org, sec-rev@omg.org References: Importance: normal Subject: RE(4): own-credentials model. Polar, > > the bridge [would] have a terrifying amount of knowledge about the > principals and keys identifying the peers. Yeah, I would say so. Also, it would be very inefficient, especially if the client had to log on different times with different mechanisms. Hmmm, that's what we have single sign-on technology for because that causes too many headaches. But if we require the client to authenticate with different mechanisms to make the bridge's job easier, we're back where we started! > If you take the approach where [...] I have given it the "secret" information necessary to authenticate and create both these credentials, you can see very quickly how to implement this STD bridge that you talk about, all with a standard security implementation. Voila! That pushes the "clientness" out to the bridge so that it can proxy for you. An alternative would be to pull the "serverness" into the bridge as a proxy object that authenticates itself (twice - say as two objects sharing a message protection domain, one in each STD) and forwards requests/responses between the STDs. If you did this with DII/DSI, then the proxy object could stand in for any (of a controllable set of) different objects in the target domain. I haven't thought about this very deeply, but perhaps it isn't as bad as I'd first thought. The client would have to realise the target was in a different STD (via the IOR) and therefore change the immediate target to the STD's proxy. This then looks similar to the way CSI-ECMA does hybrid interdomain: get the request "near" to the target under the protection of a "domain key" and then convert it to a local request (if it checks out) using the target domain's "authority". I guess we're still left with the problem of proxying (delegating and converting) the client's credential attributes. Perhaps we should just come clean and make the bridge the "authority" for proxied attributes it creates - eg. if I turn a Kerberos identity into a SESAME PAC, I'll sign the PAC with a key indicating that *the bridge* created it, after checking that it was correctly formed when presented to the bridge. Some indication that it came originally from a particular Kerberos realm would be useful too. > I'll have to think about this, get it implemented, and get back to you. Don't forget to get it patented too! -nick Return-Path: X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Tue, 6 Oct 1998 09:16:53 -0400 (EDT) From: Polar Humenn To: NC Battle cc: secsig@omg.org, sec-rev@omg.org Subject: Re: RE(4): own-credentials model. On Tue, 6 Oct 1998, NC Battle wrote: > > > the bridge [would] have a terrifying amount of knowledge about the > > principals and keys identifying the peers. > > Yeah, I would say so. Also, it would be very inefficient, especially if > the client had to log on different times with different mechanisms. Hmmm, > that's what we have single sign-on technology for because that causes too > many headaches. > > But if we require the client to authenticate with different mechanisms to make > the bridge's job easier, we're back where we started! Ney, I say. We do not "require" the client to authenticate with different mechanisms, but we can support it. Nothing here actually requires it to have the client authenticate all the mechanisms he wants to use. But we shouldn't proclude it either. The bridge can still be built using a standard system and API. On another note, I guess I just feel more warm and fuzzy with if I as a client provide through my applccation all my authentication information (secrets, passwords, smartcards, what have you) for all my mechanisms, instead of relying on a know-it-all bridge to proxy for me and keeps all my keys, secrets and just translates mechanisms for me. Or as you say, I maintain a "bridge" that maintains that inforamation for me, but it's mine, it authenicates all my invocations and proxy's for me. I don't share it with anybody else. However, I can still implement it using a standard API. > > If you take the approach where [...] I have given it the "secret" > information necessary to authenticate and create both these credentials, > you can see very quickly how to implement this STD bridge that you talk > about, all with a standard security implementation. Voila! > > That pushes the "clientness" out to the bridge so that it can proxy for you. I don't see what you mean. A bridge proxying objects still needs to authenticate itself. > An alternative would be to pull the "serverness" into the bridge as a proxy > object that authenticates itself (twice - say as two objects sharing a message > protection domain, one in each STD) and forwards requests/responses between > the STDs. If you did this with DII/DSI, then the proxy object could stand in > for any (of a controllable set of) different objects in the target domain. How is this any different than what I described in an earlier message? i.e. calling on the PA twice to create two different credentials objects, each with different mechanisms (STDs)? And then gets into the business of using the DII/DSI to do the same? > I haven't thought about this very deeply, but perhaps it isn't as bad as I'd > first thought. The client would have to realise the target was in a different > STD (via the IOR) and therefore change the immediate target to the STD's > proxy. I see what you mean there. Currently, FYI we actually punt on this one. If the target doesn't understand any mechanisms (STD) (i.e security components in the IOR) the client can't talk to it - result is an exception. If there was a mechanism by which we direct the invocation to a proxy that (may) be able to use the right mechanism and act on our behalf, I say that would be cool. However, I wouldn't want to see that as a model requirement. aka its gotta be done that way. Like I said before, it doesn't give me a warm and fuzzy feeling. (Delegation BTW, doesn't make me feel warm and fuzzy either). > This then looks similar to the way CSI-ECMA does hybrid interdomain: > get the request "near" to the target under the protection of a > "domain key" > and then convert it to a local request (if it checks out) using the > target > domain's "authority". > I guess we're still left with the problem of proxying (delegating and > converting) the client's credential attributes. Perhaps we should just come > clean and make the bridge the "authority" for proxied attributes it creates - > eg. if I turn a Kerberos identity into a SESAME PAC, I'll sign the PAC with a > key indicating that *the bridge* created it, after checking that it was ented to the bridge. Some indication that it came > originally from a particular Kerberos realm would be useful too. Oh boy, now how the hell to do represent that with the current credentials model? Does this mean I have two Security Attributes of type AccessId, one with the bridge's and the other with the orginiator? Or I guess, I would end up with two "chained" credentials objects. All very vague. We really need a new credentials model. > > I'll have to think about this, get it implemented, and get back to you. > > Don't forget to get it patented too! Okay. -Polar ------------------------------------------------------------------- Polar Humenn Adiron, LLC President 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 Return-Path: X400-Received: by mta tutartis in /PRMD=ICL/ADMD=GOLD 400/C=GB/ ; Relayed ; Tue, 06 Oct 98 15:09:43 +0100 X400-Received: by mta man23xc in /PRMD=ICL/ADMD=GOLD 400/C=GB/ ; converted (IA5-Text) ; Relayed ; Tue, 06 Oct 98 14:58:27 +0100 X400-Received: by mta man0506 in /PRMD=icl/ADMD=gold 400/C=GB/ ; converted ({ 1 3 12 2 1001 1 0 4 300 0 507 }) ; Relayed ; Tue, 06 Oct 98 15:07:33 +0100 X400-Received: by /PRMD=icl/ADMD=gold 400/C=GB/ ; converted (IA5-Text) ; Relayed ; Tue, 06 Oct 98 15:07:33 +0100 Date: Tue, 06 Oct 98 15:07:33 +0100 X400-MTS-Identifier: [/PRMD=icl/ADMD=gold 400/C=GB/;man0506 0000042400015192] X400-Originator: "NC Battle" X400-Recipients: non-disclosure:; X400-Content-Type: P2-1984 (2) Original-Encoded-Information-Types: { 1 3 12 2 1001 1 0 4 300 0 707 } Content-Identifier: 15192 Priority: normal From: "NC Battle" To: polar@adiron.com Cc: secsig@omg.org, sec-rev@omg.org References: Importance: normal Subject: RE(6): own-credentials model. Hi Polar, > On another note, I guess I just feel more warm and fuzzy with if I as a client provide through my applccation all my authentication information (secrets, passwords, smartcards, what have you) for all my mechanisms, instead of relying on a know-it-all bridge to proxy for me and keeps all my keys, secrets and just translates mechanisms for me. Oh yes, I agree. But the bridge I was proposing doesn't have any of *your* private secrets, just its own. > > That pushes the "clientness" out to the bridge so that it can proxy > for you. I don't see what you mean. A bridge proxying objects still needs to authenticate itself. Yes, but if I understand what you meant, you were describing a proxy that represented *you* out to the other STD. I'm suggesting you could equally have a proxy that represents the target STD objects, which is more like the server coming to meet you (rather than you going to meet it). You would have one (or a small number) of such proxies per STD, rather than per principal. > > An alternative would be to pull the "serverness" into the bridge as a > proxy object that authenticates itself How is this any different than what I described in an earlier message? i.e. calling on the PA twice to create two different credentials objects, each with different mechanisms (STDs)? And then gets into the business of using the DII/DSI to do the same? But in your previous message, I thought you were talking about the target itself authenticating twice? Here, I'm talking about all that multi- credentials stuff *only* occurring at the proxy, and the targets having a nice simple single-own-cred, single STD view of their world. If the proxy comprises two loosely coupled objects, one in each STD, then neither of them has to have multiple own-creds. They pass messages between themselves in an "environment protected" way (eg. some OS secured channel on the machine), which means that the bridge can be built with standard CORBA single-STD code. It could even be constructed from two different ORBs - which is the likely cause for all this trouble in the first place. > If there was a mechanism by which we direct the invocation to a proxy that (may) be able to use the right mechanism and act on our behalf, I say that would be cool. However, I wouldn't want to see that as a model requirement. aka its gotta be done that way. Like I said before, it doesn't give me a warm and fuzzy feeling. (Delegation BTW, doesn't make me feel warm and fuzzy either). But the proxy wouldn't have any of *your* secrets - is that what bothers you? It would handle your credentials (which is enough to give anyone a fuzzy feeling!), and possibly map and re-package them in a target STD specific way, by the authority we give it. It is obviously therefore a very trusted piece of code. Do you know what it is about this (and/or delegation) that bothers you? Don't you trust anyone except yourself :^) > > I guess we're still left with the problem of proxying (delegating and > converting) the client's credential attributes. Oh boy, now how the hell to do represent that with the current credentials model? Does this mean I have two Security Attributes of type AccessId, one with the bridge's and the other with the orginiator? Or I guess, I would end up with two "chained" credentials objects. All very vague. We really need a new credentials model. I guess I'm with you on that one - we've been here before haven't we? I did have the feeling that it would involve chained credentials, though the bridge is mapping and translating attributes as well as merely delegating them from the initiator, so that would have to be recorded in the target STD creds somewhere. -nick Return-Path: X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Tue, 6 Oct 1998 11:14:14 -0400 (EDT) From: Polar Humenn To: NC Battle cc: secsig@omg.org, sec-rev@omg.org Subject: Re: RE(6): own-credentials model. On Tue, 6 Oct 1998, NC Battle wrote: > Hi Polar, > > > On another note, I guess I just feel more warm and fuzzy with if > I as a > client provide through my applccation all my authentication > information > (secrets, passwords, smartcards, what have you) for all my > mechanisms, > instead of relying on a know-it-all bridge to proxy for me and > keeps all > my keys, secrets and just translates mechanisms for me. > > Oh yes, I agree. But the bridge I was proposing doesn't have any of > *your* > private secrets, just its own. Well, then it is not so much a bridge, but truly a delgating proxy. I don't have a problem with this. > > > That pushes the "clientness" out to the bridge so that it can proxy > > for you. > > I don't see what you mean. A bridge proxying objects still needs to > authenticate itself. > > Yes, but if I understand what you meant, you were describing a proxy that > represented *you* out to the other STD. I'm suggesting you could equally have > a proxy that represents the target STD objects, which is more like the server > coming to meet you (rather than you going to meet it). You would have one (or > a small number) of such proxies per STD, rather than per principal. Okay, I see what you are getting at. However, I don't really see the difference. Looks like pretty much the same mechanism, I am an object and I throw up a bunch of proxyies in front me that forward requests to me from objects in other STDs, instead of the other way around. Same kind of thing, really, I would think. Each of those proxies of course would still have to reside in at least two STDs: mine and whatever. > > > An alternative would be to pull the "serverness" into the bridge as a > > proxy object that authenticates itself > > How is this any different than what I described in an earlier message? > i.e. calling on the PA twice to create two different credentials objects, > each with different mechanisms (STDs)? And then gets into the business of > using the DII/DSI to do the same? > > But in your previous message, I thought you were talking about the target > itself authenticating twice? Here, I'm talking about all that multi- > credentials stuff *only* occurring at the proxy, and the targets having a nice > simple single-own-cred, single STD view of their world. Well, I assume the proxy is an object, maybe a proxy for the intedend target object, but it is still an object nonetheless. > If the proxy comprises > two loosely coupled objects, one in each STD, then neither of them > has to have > multiple own-creds. I'm assuming you mean, one object receives requests from clients in a single STD, forwards the request to another object which forwards the request again to the target in its STD. (overhead, but for play, lets go with it). > They pass messages between themselves in an "environment > protected" way (eg. some OS secured channel on the machine), which > means that > the bridge can be built with standard CORBA single-STD code. It > could even be > constructed from two different ORBs - which is the likely cause for > all this > trouble in the first place. I'd say that this resource intensive way is one way of implementing this. However, something puzzles me. if you have this two object proxy, how does the second object know the credentials of the client so it can pass that information onto the target? That would mean both of those objects would have to reside in some third STD as well so that information can be passed. Client --STD1--> P1 ---STD3--> P2 --STD2-> Target \---OS Enviroment--/ Otherwise, we've done something out of the realm of CORBA, no? > > If there was a mechanism by which we direct the invocation to > a proxy that (may) be able to use the right mechanism and act on > our > behalf, I say that would be cool. However, I wouldn't want to > see that as > a model requirement. aka its gotta be done that way. Like I > said before, > it doesn't give me a warm and fuzzy feeling. (Delegation BTW, > doesn't make fuzzy either). > > But the proxy wouldn't have any of *your* secrets - is that what > bothers you? > It would handle your credentials (which is enough to give anyone a > fuzzy > feeling!), and possibly map and re-package them in a target STD > specific way, > by the authority we give it. It is obviously therefore a very > trusted piece of > code. Then that is a target proxy without implicit delegation. And I'll say Horray! Its a different protected object. By identifying the principal of the proxy object you can make trust descisions or arguments based on the relationship of the proxy object to the target. However, if the proxy needs my name on it, it must have my secrets to accept the secure association. Otherwise, the client must emphatically know that it is talking to a principal that in a different TID's than the target, i.e. the client knows its my proxy and not me. This I don't have a problem with. The delegation is handled explicitly, can be traced, etc. Like I said, the client knows about it as well. > Do you know what it is about this (and/or delegation) that bothers you? Don't > you trust anyone except yourself :^) What I don't like about delegation, is what I hear most non-security people scream for when they hear the buzz word delegation. They want an object to "impersonate" a principal, so it looks like the request came from that principal. So where you have the case: Client -----> P1 --> .. --> P2 ---> Target The problem I have with that is that it looks like Client ----> P1 to the client and Client ----> Target at the target. Ouch! What they really want is trust in the intermediate objects and some non-repudiable evidence that the Client made the call. And perhaps that the intermediate objects made the calls in sequence, as well. This can be handled with some sort of traced delegation mechanism (where the service information could be bigger than the request itself, and makes the access decision computationally complex), or the target just accept requests from P2 _trusting_ P2 to do the right thing, and so on, and it all can be proved with NR or audit records. > > > I guess we're still left with the problem of proxying (delegating and > > converting) the client's credential attributes. > > Oh boy, now how the hell to do represent that with the current credentials > model? Does this mean I have two Security Attributes of type AccessId, one > with the bridge's and the other with the orginiator? Or I guess, I would > end up with two "chained" credentials objects. All very vague. We really > need a new credentials model. > > I guess I'm with you on that one - we've been here before haven't we? I did > have the feeling that it would involve chained credentials, though the bridge > is mapping and translating attributes as well as merely delegating them from > the initiator, so that would have to be recorded in the target STD creds > somewhere. Yeah, I'll figure something out one of these days. -Polar ------------------------------------------------------------------- Polar Humenn Adiron, LLC President 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 Return-Path: X400-Received: by mta tutartis in /PRMD=ICL/ADMD=GOLD 400/C=GB/ ; Relayed ; Tue, 06 Oct 98 16:48:49 +0100 X400-Received: by mta man23xc in /PRMD=ICL/ADMD=GOLD 400/C=GB/ ; converted (IA5-Text) ; Relayed ; Tue, 06 Oct 98 16:37:27 +0100 X400-Received: by mta man0506 in /PRMD=icl/ADMD=gold 400/C=GB/ ; converted ({ 1 3 12 2 1001 1 0 4 300 0 507 }) ; Relayed ; Tue, 06 Oct 98 16:46:26 +0100 X400-Received: by /PRMD=icl/ADMD=gold 400/C=GB/ ; converted (IA5-Text) ; Relayed ; Tue, 06 Oct 98 16:46:26 +0100 Date: Tue, 06 Oct 98 16:46:26 +0100 X400-MTS-Identifier: [/PRMD=icl/ADMD=gold 400/C=GB/;man0506 0000042400015193] X400-Originator: "NC Battle" X400-Recipients: non-disclosure:; X400-Content-Type: P2-1984 (2) Original-Encoded-Information-Types: { 1 3 12 2 1001 1 0 4 300 0 707 } Content-Identifier: 15193 Priority: normal From: "NC Battle" To: polar@adiron.com Cc: secsig@omg.org, sec-rev@omg.org References: Importance: normal Subject: RE(8): own-credentials model. Hi Polar, I guess we've got about as far as we can on this without input from others... it's suspiciously quiet :) > Okay, I see what you are getting at. However, I don't really see the difference. Looks like pretty much the same mechanism OK, I suppose I was just quibbling. It's basically the same as you said, yes. > However, something puzzles me. if you have this two object proxy, how does the second object know the credentials of the client so it can pass that information onto the target? [...] we've done something out of the realm of CORBA, no? Yes, it would be outside the realm of CORBA (though we could claim it was comminication within a message protection domain). I'm just trying to keep the solution simple - if we try to pass the credentials via some sort of 3rd STD between the two via CORBA Security, then we're into multi-mech own-creds. If you "flatten" the credential attributes somehow (eg. pass a raw sequence of Security::Attribute) and have them protected implicitly by the environment, then the two parts of the bridge can be mechanism-separated cleanly, as in the case of two different ORB vendors' products. That has to be worth something? > Then that is a target proxy without implicit delegation. I can't decide whether it's delegation or not. It is a simple translation on the one hand, but on the other hand the bridge itself is likely to have to put its approval on the translated credentials, and so there is an element of "Bridge says Client has " which sounds like delegation to me. But perhaps I'm just quibbling again! -nick Return-Path: From: "David M. Chizmadia" To: "NC Battle" , Cc: , Subject: Re: RE(8): own-credentials model. Date: Tue, 6 Oct 1998 23:20:33 -0400 X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 -----Original Message----- From: NC Battle To: polar@adiron.com Cc: secsig@omg.org ; sec-rev@omg.org Date: Tuesday, October 06, 1998 4:36 PM Subject: RE(8): own-credentials model. > >I guess we've got about as far as we can on this without input from others... >it's suspiciously quiet :) dmc>> Ok, I'll bite :-) > >> Okay, I see what you are getting at. However, I don't really see the > difference. Looks like pretty much the same mechanism > >OK, I suppose I was just quibbling. It's basically the same as you said, yes. > >> However, something puzzles me. if you have this two object proxy, how does > the second object know the credentials of the client so it can pass that > information onto the target? [...] we've done something out of the realm > of CORBA, no? > >Yes, it would be outside the realm of CORBA (though we could claim it was >comminication within a message protection domain). I'm just trying to keep the >solution simple - if we try to pass the credentials via some sort of 3rd STD >between the two via CORBA Security, then we're into multi-mech own-creds. If >you "flatten" the credential attributes somehow (eg. pass a raw sequence of >Security::Attribute) and have them protected implicitly by the environment, >then the two parts of the bridge can be mechanism-separated cleanly, as in the >case of two different ORB vendors' products. That has to be worth something? dmc>> Actually, as part of an organization working on high-assurance OSes, dmc>> this looks pretty neat to me. An interesting possibility in some dmc>> cases would be autogeneration of the proxy so that it runs at full dmc>> compiled speed, with the credentials passed as a program data structure dmc>> or object. > >> Then that is a target proxy without implicit delegation. > >I can't decide whether it's delegation or not. It is a simple >> translation on >the one hand, but on the other hand the bridge itself is likely to >> have to put >its approval on the translated credentials, and so there is an >> element of >"Bridge says Client has " which sounds like delegation to >> me. But >perhaps I'm just quibbling again! dmc>> While I aggree that it looks like delegation, wouldn't the semantics dmc>> actually be: "Bridge received authenticated for Client dmc>> from <>". I make the distinction because the Bridge really dmc>> isn't saying that the client has those privileges, but rather just dmc>> attests to the fact that it received those attributes (or more dmc>> correctly, a semantically equivalent version of them) from the dmc>> originating STD. The other interpretation might be "Bridge says dmc>> <> said Client has " > >-nick -DMC (Dave Chizmadia) Return-Path: X400-Received: by mta tutartis in /PRMD=ICL/ADMD=GOLD 400/C=GB/ ; Relayed ; Wed, 07 Oct 98 09:51:36 +0100 X400-Received: by mta man23xc in /PRMD=ICL/ADMD=GOLD 400/C=GB/ ; converted (IA5-Text) ; Relayed ; Wed, 07 Oct 98 09:39:57 +0100 X400-Received: by mta man0506 in /PRMD=icl/ADMD=gold 400/C=GB/ ; converted ({ 1 3 12 2 1001 1 0 4 300 0 507 }) ; Relayed ; Wed, 07 Oct 98 09:49:04 +0100 X400-Received: by /PRMD=icl/ADMD=gold 400/C=GB/ ; converted (IA5-Text) ; Relayed ; Wed, 07 Oct 98 09:49:04 +0100 Date: Wed, 07 Oct 98 09:49:04 +0100 X400-MTS-Identifier: [/PRMD=icl/ADMD=gold 400/C=GB/;man0506 0000042400015195] X400-Originator: "NC Battle" X400-Recipients: non-disclosure:; X400-Content-Type: P2-1984 (2) Original-Encoded-Information-Types: { 1 3 12 2 1001 1 0 4 300 0 707 } Content-Identifier: 15195 Priority: normal From: "NC Battle" To: davidch@ccpl.carr.lib.md.us To: polar@adiron.com Cc: secsig@omg.org, sec-rev@omg.org References: <000201bdf1a3$1f84c4c0$34183390@roamer3.tycho.ncsc.mil> Importance: normal Subject: RE(10): own-credentials model. Dave, dmc>> While I aggree that it looks like delegation, wouldn't the semantics dmc>> actually be: "Bridge received authenticated for Client dmc>> from <>". I make the distinction because the Bridge really dmc>> isn't saying that the client has those privileges, but rather just dmc>> attests to the fact that it received those attributes (or more dmc>> correctly, a semantically equivalent version of them) from the dmc>> originating STD. The other interpretation might be "Bridge says dmc>> <> said Client has " The worry for me is that the bridge has to become the authority for the creation of the equivalent privileges in the target domain - presumably there is a perfectly good privilege authority (or several) in the target domain (like the Privilege Attribute Service in SESAME), but that *isn't* being used by the bridge. I guess this really isn't delegation in the normal sense. I like your 2nd interpretation best, though perhaps it's more like: "Bridge says STDx says Client has what you would know as " to really bring out that the privileges have been translated by the bridge as well (I quibble as a profession :). I think the preservation of privilege semantics (or even just the meaning of a single attribute) is going to be quite a challenge! We also have to be careful about interdomain trust - whether particular STD- STD calls are permitted and the control of which other STDs' mapped attributes are trusted, and to what degree. A bridge-made privilege isn't precisely equivalent to a locally made one because they are made by different authorities (on the basis of different evidence of authenticity), and one of them has been translated (perhaps imperfectly). -nick Return-Path: Date: Wed, 07 Oct 1998 09:34:32 -0400 From: henryr@mitre.org (Henry C. Rothkopf) To: efeustel@ida.org (Edward Feustel) cc: davidch@ccpl.carr.lib.md.us, polar@adiron.com, nick.battle@x400.icl.co.uk, secsig@omg.org, sec-rev@omg.org Subject: Re: own-credentials model. References: <199810071250.IAA09212@cs.ida.org> I agree - this is something that I've brought up in several briefings, including one on C4I Collaborative Environments at the OMG C4I Coalition Day in Manchester, last spring. One should have the ability to work with others on "n" different subjects or sessions. Also, consider the need for being spontaneously invited to participate in a secure session - that while participating in "n" others. H Edward Feustel wrote: > > I began to consider why one might have different authentication > algorithms > (or encryption) in the communicating objects. If one looks at the > problem > through the RM-ODP, one sees that one might have different security > technologies > or more interestingly, one might have different security policies as > suggested > by Winfried E. K"uhnhauser in his ACM Operating Systems Review paper > Volume 32, > Number 4, October 1998, p. 47-61. > > Imagine a user who must operate in not just two, but N security > domains. Further > imagine that the user delegates his rights to others in different > domains who > wish to interoperate with him in still other domains. The solution > for > credentials whether own, or a chain, needs to deal with this sort of > thing. > > Ed Feustel Return-Path: X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Wed, 7 Oct 1998 12:29:17 -0400 (EDT) From: Polar Humenn To: NC Battle cc: davidch@ccpl.carr.lib.md.us, secsig@omg.org, sec-rev@omg.org Subject: Re: RE(10): own-credentials model. On Wed, 7 Oct 1998, NC Battle wrote: > Dave, > > dmc>> While I aggree that it looks like delegation, wouldn't the > semantics > dmc>> actually be: "Bridge received authenticated for > Client > dmc>> from <>". I make the distinction because the Bridge > really > dmc>> isn't saying that the client has those privileges, but rather > just > dmc>> attests to the fact that it received those attributes (or more > dmc>> correctly, a semantically equivalent version of them) from the > dmc>> originating STD. The other interpretation might be "Bridge > says > dmc>> <> said Client has " David, when you say < says Client has , the STD becomes an authority. How do you check that? It must be the bridge that does the translation, its basically Bridge says Client says Request, which formally is must be stated that the client trusts the bridge and you as a target trust both the client and the bridge. If the client doesn't issue a statement such as: Client says Bridge speaks for Client somewhere then your hosed. (BTW, that is a delegation statement modulo privilege translation). However, to say what you are trying to stay boils down to we have all these statements that can be said, yet not one of them can really be stated with any integrity in the current Credentials model. > The worry for me is that the bridge has to become the authority for the > creation of the equivalent privileges in the target domain - presumably there > is a perfectly good privilege authority (or several) in the target domain > (like the Privilege Attribute Service in SESAME), but that *isn't* being used > by the bridge. I guess this really isn't delegation in the normal sense. Well, what's normal delegation? However I will agree with you in the scenario that the Client may not know about the bridge. But when its all said an done, it must be delegation. Bridge STD1 STD2 Client == Client' Target == Target' PAC == PAC' Make a request from Client in STD1 to Target in STD2? Client -> Target' PAC = PAS says Client has P1..Pn Client says Request, with PAC, intended for Target' Now, the request gets intercepted and thrown to the bridge. One of two things must happen. The request cannot be encrypted for Target' so it must be forwared to a bridge with appropriate information by the ORB, or for credentials sake,lets say the Client. Client says Request, with PAC, intented for Target' encrypted for the Bridge. This basically says Client says Bridge speaks for Client. That is a delegation statement. Client -> STD1-Bridge-STD2 -> Target' Hmmm, Bridge must know Target'(public) key. Anyway, this means that target trust's Bridge to do the right thing. Bridge converts PAC to PAC'. PAC' says PAS says Client' has P1'..Pn' (of course this is the tricy bit for STD2, eh?) Now, if Bridge doesn't know Client'(private) key for STD2 then, Bridge quoting Client' says Request, with PAC' intended for Target' Target' must trust Bridge to say the right thing. Now, if Bridge has Client'(private) key (ugh!) then Bridge could impersonate Client. Bridge delivers (perhaps unprotected) Client' says Request, with PAC' intended for Target' It's still delegation because the Target' must have an implicit trust of the bridge. I guess the only point you are really worryabout nick, is somewhere Something says PAC == PAC' That is the hard part. Also, if you want traceablity Something says Client == Client' That something would most likely be the bridge. I don't think you can get around that. > I like your 2nd interpretation best, though perhaps it's more like: "Bridge > says STDx says Client has what you would know as " to really bring > out that the privileges have been translated by the bridge as well (I quibble > as a profession :). I think the preservation of privilege semantics (or even > just the meaning of a single attribute) is going to be quite a challenge! Okay enough about semantics. Do you think you can represent a statment such as "Bridge says STDx says...." representation from Credentials::get_attributes()? :) > We also have to be careful about interdomain trust - whether particular STD- > STD calls are permitted and the control of which other STDs' mapped attributes > are trusted, and to what degree. A bridge-made privilege isn't precisely > equivalent to a locally made one because they are made by different > authorities (on the basis of different evidence of authenticity), and one of > them has been translated (perhaps imperfectly). This can be taken care of, almost autmoatically through some negoitation, and third party approval mechanism, say a dweeb at a terminal. Later, -Polar ------------------------------------------------------------------- Polar Humenn Adiron, LLC President 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 Return-Path: X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Wed, 7 Oct 1998 14:44:04 -0400 (EDT) From: Polar Humenn To: Edward Feustel cc: davidch@ccpl.carr.lib.md.us, nick.battle@x400.icl.co.uk, secsig@omg.org, sec-rev@omg.org Subject: Re: RE(10): own-credentials model. On Wed, 7 Oct 1998, Edward Feustel wrote: > I began to consider why one might have different authentication algorithms > (or encryption) in the communicating objects. If one looks at the problem > through the RM-ODP, one sees that one might have different security technologies > or more interestingly, one might have different security policies as suggested > by Winfried E. K"uhnhauser in his ACM Operating Systems Review paper Volume 32, > Number 4, October 1998, p. 47-61. yep. > Imagine a user who must operate in not just two, but N security domains. Further > imagine that the user delegates his rights to others in different domains who > wish to interoperate with him in still other domains. The solution for > credentials whether own, or a chain, needs to deal with this sort of thing. Thats what I've been get at. I believe we need that control. ------------------------------------------------------------------- Polar Humenn Adiron, LLC President 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 Return-Path: X400-Received: by mta tutartis in /PRMD=ICL/ADMD=GOLD 400/C=GB/ ; Relayed ; Thu, 08 Oct 98 09:47:21 +0100 X400-Received: by mta man23xc in /PRMD=ICL/ADMD=GOLD 400/C=GB/ ; converted (IA5-Text) ; Relayed ; Thu, 08 Oct 98 09:35:55 +0100 X400-Received: by mta man0506 in /PRMD=icl/ADMD=gold 400/C=GB/ ; converted ({ 1 3 12 2 1001 1 0 4 300 0 507 }) ; Relayed ; Thu, 08 Oct 98 09:44:55 +0100 X400-Received: by /PRMD=icl/ADMD=gold 400/C=GB/ ; converted (IA5-Text) ; Relayed ; Thu, 08 Oct 98 09:44:55 +0100 Date: Thu, 08 Oct 98 09:44:55 +0100 X400-MTS-Identifier: [/PRMD=icl/ADMD=gold 400/C=GB/;man0506 0000042400015200] X400-Originator: "NC Battle" X400-Recipients: non-disclosure:; X400-Content-Type: P2-1984 (2) Original-Encoded-Information-Types: { 1 3 12 2 1001 1 0 4 300 0 707 } Content-Identifier: 15200 Priority: normal From: "NC Battle" To: polar@adiron.com Cc: davidch@ccpl.carr.lib.md.us, secsig@omg.org, sec-rev@omg.org References: Importance: normal Subject: RE(12): own-credentials model. Polar, > > The worry for me is that the bridge has to become the authority for the > creation of the equivalent privileges in the target domain Well, what's normal delegation? However I will agree with you in the scenario that the Client may not know about the bridge. But when its all said an done, it must be delegation. Perhaps we're just arguing about the nature of delegation. My current view of delegation (as in what SESAME does) is that Client (with the aid of its PAS service) constructs credentials that can be re-expressed by an Intermediate as though they were that Intermediate's credentials (traced delegation makes both the Client and the Intermediate's credentials available a the target). But note that, within one STD, the original Client's credentials arrive at the target without change - they can be interpreted against the same privilege authority that the Client used to obtain them. In the inter-STD case, the Client's credentials have been changed by the bridge (by a semantics-preserving transformation, one trusts) before being re- expressed by the bridge. It's this transformation that makes it different - the interpretation of the privileges is now under a different authority to that which the Client used to obtained them. (Alarm bell rings in head here... so I get worried). So perhaps what we have is delegation *plus* translation here? > Okay enough about semantics. Do you think you can represent a statment such as "Bridge says STDx says...." representation from Credentials::get_attributes()? :) I think you previously convinced us all that this wasn't the case! > > We also have to be careful about interdomain trust This can be taken care of, almost autmoatically through some negoitation, and third party approval mechanism, say a dweeb at a terminal. Dweeb is what I'd call "Administrator" then? :) I agree that the mechanics of the trust management just comes down to protocol and administrative action. I just wanted to point out that we have to *have* trust management, since we're crossing domains where (probably) different policies hold (in the most general sense), and something has to be controlled about what you trust and what you don't trust in/from foreign domains. -nick Return-Path: X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Thu, 8 Oct 1998 09:39:29 -0400 (EDT) From: Polar Humenn To: NC Battle cc: efeustel@ida.org, davidch@ccpl.carr.lib.md.us, secsig@omg.org, sec-rev@omg.org Subject: Re: RE(12): own-credentials model. On Thu, 8 Oct 1998, NC Battle wrote: > But perhaps you were rather thinking of the basic peer authentication > protocol? Here I now believe there is a big problem. Consider the case of a > mutual authentication exchange (ie. EstablishTrustInTarget with multiple > SECIOP EstablishContext messages exchanged between peers before the final > CompleteEstablishContext). In this case, the end-to-end exchange of several > authentication tokens must complete *before* the Client sends the first > MessageInContext to the bridge. That means the bridge would have to be more of > a low level SECIOP mechanism gateway. I will agree with that. > It would even be difficult to arrange for the Client-bridge association to > complete only if/when the bridge-Target association had completed - ie. let > the Client target-authenticate the bridge only if the bridge can target > authenticate the Target. This would require SECIOP state information to be > made available between the two halves of the bridge. Yes, this does seem like a problem. Authenticating the bridge and sending the request when the bridge cannot authenticate the client would probably be a bad thing, ESPECIALLY if the client has no visible knowledge of the bridge. The bridge would have to be a seciop processor, however as you said in your previous email, should be subject to the "policies of the bridge", in this case. It wouldn't be a CORBA thing at all, it would be a lowlevel SECIOP processor with a lot of low level garbage to support what we can already do at a higher level. As you point out below: > Unless this is wrong, it looks like inter-STD working is a swine after all. > The bridge would have to be a specifically constructed low level multi- > mechanism SECIOP machine. So tell me again how multi-mech own creds would work > again, Polar! Okay, but one small point unless I'm misreading. The thing I'm proposing is multiple "own" credentials each with its own supported mechanism (support a principal in an STD, if you will). Basically, the Vault supports a number of mechanisms. The vault can be replaced. The vault can act as a registry for a conglomoration of other vaults, each of which already has an operation "get_supported_mechanisms". The Vault authenticates and creates credentials by way of the PA, and the PA puts them on the own_credentials list for use by the application. As far as the Credentials object goes, it only represents a principal in one STD, and therefore its attributes may be able to have some meaning within that STD. This is so you can get a comprehendable view of what the attributes mean for a principal. Anyway, I think that is the way to go (for now), and it works quite nicely. You don't really need this bridge; however, you can easily build this "translation" delegation bridge using CORBA without any underlying low-level stuff, complex and adminstratively nasty as it might be, not to mention the whopping trust issue. I say for now, because if I don't have to beat on this dead horse some more until it becomes mince: We need a better credentials model, because this one isn't sufficient. (For the recent lurkers out there not joining in the discussion and who are watching Nick and I sling this stuff across 5 timezones, it has only been Nick and I on this one for months, with a short contribution from Belinda and a couple questions from Jim Williams and DMC). So, does it all matter? Who really cares? Anybody out there confident and assured that their applications are safe? Anybody out there using/want security for their applications? Anybody out there just rely on SSL to take care of their security problems? (Well, it does say the word "Security" on the side of the box!). Andybody out there got a bottlenecking Firewall with bidirectional GIOP? heh heh. 8^O Anybody else want more than SSL? Anybody else want standard working interoperable secure ORBs? Anybody want secure distributed security policy (or any policy for that matter) enforcement for the enterprise? I leave you with those questions and thoughts. Later, -Polar ------------------------------------------------------- Polar Humenn Adiron, LLC President 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 Return-Path: Date: Thu, 08 Oct 1998 10:30:14 -0400 From: "gene.jarboe" Subject: Re: RE(12): own-credentials model. To: NC Battle , Polar Humenn Cc: John Mullen , Larry Kline , Troy Caldwell , Ray Granvold , sec-rev@omg.org, secsig@omg.org, davidch@ccpl.carr.lib.md.us, efeustel@ida.org Reply-to: "gene.jarboe" X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Polar Humenn and NC Battle, Please see my personal comments inserted herein which may or may not reflect those of my company or other CORBA vendors!!! Best Regards, Gene Jarboe Promia, Inc. (SmalltalkBroker/SecureBroker) -----Original Message----- From: Polar Humenn To: NC Battle Cc: efeustel@ida.org ; davidch@ccpl.carr.lib.md.us ; secsig@omg.org ; sec-rev@omg.org Date: Thursday, October 08, 1998 9:56 AM Subject: Re: RE(12): own-credentials model. >On Thu, 8 Oct 1998, NC Battle wrote: > >> But perhaps you were rather thinking of the basic peer authentication >> protocol? Here I now believe there is a big problem. Consider the case of a >> mutual authentication exchange (ie. EstablishTrustInTarget with multiple >> SECIOP EstablishContext messages exchanged between peers before the final >> CompleteEstablishContext). In this case, the end-to-end exchange of several >> authentication tokens must complete *before* the Client sends the first >> MessageInContext to the bridge. That means the bridge would have to be more of >> a low level SECIOP mechanism gateway. > >I will agree with that. > >> It would even be difficult to arrange for the Client-bridge association to >> complete only if/when the bridge-Target association had completed - ie. let >> the Client target-authenticate the bridge only if the bridge can target >> authenticate the Target. This would require SECIOP state information to be >> made available between the two halves of the bridge. > >Yes, this does seem like a problem. Authenticating the bridge and sending >the request when the bridge cannot authenticate the client would probably >be a bad thing, ESPECIALLY if the client has no visible knowledge of the >bridge. The bridge would have to be a seciop processor, however as you >said in your previous email, should be subject to the "policies of the >bridge", in this case. It wouldn't be a CORBA thing at all, it would be a >lowlevel SECIOP processor with a lot of low level garbage to support what >we can already do at a higher level. As you point out below: > >> Unless this is wrong, it looks like inter-STD working is a swine after all. >> The bridge would have to be a specifically constructed low level multi- >> mechanism SECIOP machine. So tell me again how multi-mech own creds would work >> again, Polar! > >Okay, but one small point unless I'm misreading. The thing I'm proposing >is multiple "own" credentials each with its own supported mechanism >(support a principal in an STD, if you will). Basically, the Vault >supports a number of mechanisms. The vault can be replaced. The vault can >act as a registry for a conglomoration of other vaults, each of which >already has an operation "get_supported_mechanisms". The Vault >authenticates and creates credentials by way of the PA, and the PA puts >them on the own_credentials list for use by the application. > >As far as the Credentials object goes, it only represents a principal in >one STD, and therefore its attributes may be able to have some meaning >within that STD. This is so you can get a comprehendable view of what the >attributes mean for a principal. > >Anyway, I think that is the way to go (for now), and it works quite >nicely. You don't really need this bridge; however, you can easily build >this "translation" delegation bridge using CORBA without any underlying >low-level stuff, complex and adminstratively nasty as it might be, not to >mention the whopping trust issue. > >I say for now, because if I don't have to beat on this dead horse some >more until it becomes mince: We need a better credentials model, because >this one isn't sufficient. (For the recent lurkers out there not joining >in the discussion and who are watching Nick and I sling this stuff across >5 timezones, it has only been Nick and I on this one for months, with a >short contribution from Belinda and a couple questions from Jim Williams >and DMC). > >So, does it all matter? Who really cares? MY COMPANY (Promia) CARES since we have real customers needing more CORBA security than what is available today! > >Anybody out there confident and assured that their applications are safe? As far as applications that are confident and assured, I do NOT think so without SECURE ORBs supporting "tested domain security policies" at what is called CORBASEC Level 2!! > >Anybody out there using/want security for their applications? Good question! Has any organization or body ever asked the Information Technology (IT) industry this question? > > >Anybody out there just rely on SSL to take care of their security >problems? (Well, it does say the word "Security" on the side of >the box!). If they do, will they "TRUST" all of their company's IT assets on what the vendor says about "security" on the side of the box? > >Andybody out there got a bottlenecking Firewall with bidirectional GIOP? >heh heh. 8^O Humm...ask the OMG firewall submitters this question? :-)) > >Anybody else want more than SSL? Again...will IT organizations bet their whole distributed environment on SSL? I hope not!!! > >Anybody else want standard working interoperable secure ORBs? As an ORB vendor who has customers with usually two or more heterogeneous ORB vendor's products in place, I foresee the need for "standard working interoperable secure ORBs." But, IT customers have to start requiring their favorite ORB vendor supply "secure interoperability" before any movement in this direction, in my view!! > >Anybody want secure distributed security policy (or any policy for that >matter) enforcement for the enterprise? Polar asks the right question here which is what CORBASEC Level 2 ultimately is all about and very few ORB vendors have supplied (i.e., distributed-heterogeneous-enterprise wide security policies). > >I leave you with those questions and thoughts. > >Later, >-Polar > >------------------------------------------------------- >Polar Humenn Adiron, LLC >President 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 > Return-Path: Sender: dchang@austin.ibm.com Date: Fri, 09 Oct 1998 09:33:17 -0500 From: David Chang To: Polar Humenn Cc: NC Battle , efeustel@ida.org, davidch@ccpl.carr.lib.md.us, secsig@omg.org, sec-rev@omg.org Subject: Re: RE(12): own-credentials model. References: Polar, We are very interested about your proposal. As matter of fact, we have discovered that the current OMG Security Interfaces are not sufficient to support multiple secuirty mechanisms for the same object in a mutiple security mechanism domain environment before we see your proposal. We will work IBM's OMG representative, Bob Blakley, to comment on your proposal. Your proposal is very interested to us. David Chang IBM OMG Security Service Development team Polar Humenn wrote: > > On Thu, 8 Oct 1998, NC Battle wrote: > > > But perhaps you were rather thinking of the basic peer > authentication > > protocol? Here I now believe there is a big problem. Consider the > case of a > > mutual authentication exchange (ie. EstablishTrustInTarget with > multiple > > SECIOP EstablishContext messages exchanged between peers before > the final > > CompleteEstablishContext). In this case, the end-to-end exchange > of several > > authentication tokens must complete *before* the Client sends the > first > > MessageInContext to the bridge. That means the bridge would have > to be more of > > a low level SECIOP mechanism gateway. > > I will agree with that. > > > It would even be difficult to arrange for the Client-bridge > association to > > complete only if/when the bridge-Target association had completed > - ie. let > > the Client target-authenticate the bridge only if the bridge can > target > > authenticate the Target. This would require SECIOP state > information to be > > made available between the two halves of the bridge. > > Yes, this does seem like a problem. Authenticating the bridge and > sending > the request when the bridge cannot authenticate the client would > probably > be a bad thing, ESPECIALLY if the client has no visible knowledge of > the > bridge. The bridge would have to be a seciop processor, however as > you > said in your previous email, should be subject to the "policies of > the > bridge", in this case. It wouldn't be a CORBA thing at all, it would > be a > lowlevel SECIOP processor with a lot of low level garbage to support > what > we can already do at a higher level. As you point out below: > > > Unless this is wrong, it looks like inter-STD working is a swine > after all. > > The bridge would have to be a specifically constructed low level > multi- > > mechanism SECIOP machine. So tell me again how multi-mech own > creds would work > > again, Polar! > > Okay, but one small point unless I'm misreading. The thing I'm > proposing > is multiple "own" credentials each with its own supported mechanism > (support a principal in an STD, if you will). Basically, the Vault > supports a number of mechanisms. The vault can be replaced. The > vault can > act as a registry for a conglomoration of other vaults, each of > which > already has an operation "get_supported_mechanisms". The Vault > authenticates and creates credentials by way of the PA, and the PA > puts > them on the own_credentials list for use by the application. > > As far as the Credentials object goes, it only represents a > principal in > one STD, and therefore its attributes may be able to have some > meaning > within that STD. This is so you can get a comprehendable view of > what the > attributes mean for a principal. > > Anyway, I think that is the way to go (for now), and it works quite > nicely. You don't really need this bridge; however, you can easily > build > this "translation" delegation bridge using CORBA without any > underlying > low-level stuff, complex and adminstratively nasty as it might be, > not to > mention the whopping trust issue. > > I say for now, because if I don't have to beat on this dead horse > some > more until it becomes mince: We need a better credentials model, > because > this one isn't sufficient. (For the recent lurkers out there not > joining > in the discussion and who are watching Nick and I sling this stuff > across > 5 timezones, it has only been Nick and I on this one for months, > with a > short contribution from Belinda and a couple questions from Jim > Williams > and DMC). > > So, does it all matter? Who really cares? > > Anybody out there confident and assured that their applications are > safe? > > Anybody out there using/want security for their applications? > > Anybody out there just rely on SSL to take care of their security > problems? (Well, it does say the word "Security" on the side of > the box!). > > Andybody out there got a bottlenecking Firewall with bidirectional > GIOP? > heh heh. 8^O > > Anybody else want more than SSL? > > Anybody else want standard working interoperable secure ORBs? > > Anybody want secure distributed security policy (or any policy for > that > matter) enforcement for the enterprise? > > I leave you with those questions and thoughts. > > Later, > -Polar > > ------------------------------------------------------- > Polar Humenn Adiron, LLC > President 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 Return-Path: Sender: jis@fpk.hp.com Date: Fri, 09 Oct 1998 11:38:42 -0400 From: Jishnu Mukerji Organization: Hewlett-Packard New Jersey Laboratories To: Polar Humenn Cc: NC Battle , efeustel@ida.org, davidch@ccpl.carr.lib.md.us, secsig@omg.org, sec-rev@omg.org Subject: Re: own-credentials model. References: Polar Humenn wrote: > > So, does it all matter? Who really cares? Polar, All this matters a lot, and I am glad someone is pursuing this with diligence. I can appreciate your frustrations, having been there myself when I was embarked on a much simpler project of modifying the Security IDL so that it would at least compile. If I could clone myself a couple of times, I would spend much more time helping you. Unfortunately, right now I am buried in getting CORBA Core straightened out (after all you want something there to secure to start with, no?) with all these new additions to it in the form of OBV, Messaging and soon to arrive Components. As soon as I can come up for air after getting the Core 2.3a drafts out, I will engage in the Policy management related discussion with much greater enthusiasm than I have shown so far (some thoughts on this a little later in this message). But due to time pressures of getting Core revision drafts out before the next OMG meeting, I am a bit preoccupied for the next couple of weeks. hope you will understand and excuse me. > > Anybody out there confident and assured that their applications are > safe? > > Anybody out there using/want security for their applications? > > Anybody out there just rely on SSL to take care of their security > problems? (Well, it does say the word "Security" on the side of > the box!). > > Andybody out there got a bottlenecking Firewall with bidirectional > GIOP? > heh heh. 8^O > > Anybody else want more than SSL? > > Anybody else want standard working interoperable secure ORBs? > > Anybody want secure distributed security policy (or any policy for > that > matter) enforcement for the enterprise? > > I leave you with those questions and thoughts. Following up from a different message, I agree with you that the Policy Domain stuff needs considerable work to make it solid, and it needs to be integrated into the POA architecture while we are at it. You have to remember that the Security spec was done before the ORB vendors even dreamed that they might agree to have a Portable OA, so naturally POA was not taken into consideration in the design of Security, and as is won't to happen occasionally, Gene was unable to beat the POA submitters into submission to have them address Security completely (or even partially):-). The reason that the Security policies are more complex than what the POA and later policies, is that the Security ones came first and they were designed more in terms of a computational viewpoint rather than in terms of an engineering viewpoint. The latter is the general level of the POA and Messaging specifiations. When POA came out the only alignment with POA that was done was to restate the requirements about the point at which object references are associated with security domains. This whole area falls within the domain of the Domain Management RFP that is floating around, and perhaps it should be augmented to require addressing of the realtionship between POA and Domain Managers and even the whole Security policy management paradigm more completely. Anyway, that is my quick thoughts on this matter for now. hope to be of more help in the near future. Jishnu. -- Jishnu Mukerji Systems Architect Advanced Development Enterprise Internet Solution Center Enterprise Systems Group Email: jis@fpk.hp.com Hewlett-Packard New Jersey Labs, Tel: +1 973 443 7528 300 Campus Drive, 2E-62, Fax: +1 973 443 7422 Florham Park, NJ 07932, USA. Return-Path: Date: Tue, 13 Oct 1998 10:41:34 -0400 (EDT) From: Edward Feustel Reply-To: Edward Feustel Subject: Re: 98-10-02: Control by credentials To: polar@adiron.com, Darrel Sell , dmc@tycho.ncsc.mil Cc: secsig@omg.org, sec-rev@omg.org Content-MD5: ieAMZ/IOgNEHuw97WEu4lQ== I would prefer to see a slightly different solution (which may represent my overly naieve view). Eventualy the Policy module instance describing the security to be achieved should provide the transport layer with instructions about what kind of Privacy, Integrity, and Availability are required. This will be the only reasonable way to implement multiple policies which will be required for enterprise solutions. If the policy permits some applications to change mechanisms, I would prefer to see an Application Policy instance which reflects the policy that the application must live under. If the application wishes to change the security mechanisms, then it should request that the policy instance controling it to be changed. The transport mechanisms can then interogate the policy to determine what mechanisms they are required to use. This would tie in well with Security unaware applications. If the application is not "privileged" then it should not be able to change the policy and the standard policy driven mechanisms should be used. Ed Edward A. Feustel, Research Staff Member Phone: (703)-845-6657 Institute for Defense Analyses FAX: (703)-845-6848 Computer and Software Engineering Division 1801 N. Beauregard Street email: efeustel@ida.org Alexandria, VA 22311-1772 Return-Path: X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Tue, 13 Oct 1998 11:42:18 -0400 (EDT) From: Polar Humenn To: Edward Feustel cc: Darrel Sell , dmc@tycho.ncsc.mil, secsig@omg.org, sec-rev@omg.org Subject: Re: 98-10-02: Control by credentials Ed, thanks for you input! I think you just need a couple of clarifications. On Tue, 13 Oct 1998, Edward Feustel wrote: > I would prefer to see a slightly different solution (which may represent my > overly naieve view). > > Eventualy the Policy module instance describing the security to > be achieved should provide the transport layer with instructions > about what kind of Privacy, Integrity, and Availability are > required. This will be the only reasonable way to implement multiple policies > which will be required for enterprise solutions. This already happens by putting policy objects onto object references. The transport mechanism queries the policies on object references when setting up the secure assoication with that object. It is only the policy objects that govern the mechanisms, qop, credentials, delegation, and (authentication) trust establishment. > If the policy permits some applications to change mechanisms, I would prefer to > see an Application Policy instance which reflects the policy that the > application must live under. If the application wishes to change the security > mechanisms, then it should request that the policy instance controling it to be > changed. This would be done using the applications domain manager. A proper bind interceptor would intercept "set_policy_overrides" because it is creating a new object reference. A good security interceptor would check the policies being set and see if they conform to a broader security policy, such as the SecureInvocationPolicy from the domain manager. On the server side, a proper bind interceptor would intercept POA::create_referenece, and examine policy objects according to a certain domain policy, and the same thing happens. > The transport mechanisms can then interogate the policy to determine > what mechanisms they are required to use. This would tie in well > with > Security unaware applications. Like I said above. It's already there. > If the application is not "privileged" then it should not be able to change > the policy and the standard policy driven mechanisms should be used. Like I said above as well, if the service is a good one, then prevention of setting policies inconsistent with some broader policy would, in fact, not be allowed. Hope this clears things up to your satifaction. -Polar ------------------------------------------------------------------- Polar Humenn Adiron, LLC President 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 Return-Path: Date: Tue, 13 Oct 1998 12:06:42 -0400 (EDT) From: Edward Feustel Reply-To: Edward Feustel Subject: Re: 98-10-02: Control by credentials To: efeustel@ida.org, polar@adiron.com Cc: dgs@tycho.ncsc.mil, dmc@tycho.ncsc.mil, secsig@omg.org, sec-rev@omg.org Content-MD5: pvXM+pMRcQAsyKCBVN43SA== Polar: Thanks for the clarifications. I recognize that changing the Credentials could automatically change the policy and that the policy might not let you change the credentials. It just seems that the focus of what is being done is to change the policy, and not to change the credentials. If an application changes its credentials, are the same credentials used for each communication with all clients? Or will there be a different set of credentials for each different client? I guess I still see what the application is trying to do is to change the policy that is used to govern it. I think both the management interfaces and the client/application interfaces should reference the policy object instance and not the credentials (unless you are trying to have the application operate under a different security policy for each client who is trying to use it.) This would create a more uniform way of dealing with security, particularily in those instances when we require access mediation, cryptography services, etc. in the Application itself. What it probably will require is thinking about the Security Policy Object in more detail. A list won't hack it. Ed Feustel Return-Path: X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Tue, 13 Oct 1998 12:50:44 -0400 (EDT) From: Polar Humenn To: Edward Feustel cc: dgs@tycho.ncsc.mil, dmc@tycho.ncsc.mil, secsig@omg.org, sec-rev@omg.org Subject: Re: 98-10-02: Control by credentials On Tue, 13 Oct 1998, Edward Feustel wrote: > Polar: > > Thanks for the clarifications. I recognize that changing the > Credentials could automatically change the policy and that the > policy > might not let you change the credentials. Well, this is something that should be looked at, because the spec is really explicit on things about "changing" credentials without stipulating the consequences of such operations. It says that you can change features of credentials directly, or copy credentials and change them. Depends on the implementation of the Vault, I suppose. Anyway, this "feature" opens up a bag of worms, I will admit. The copy() does a "deep" copy, whatever that means. For example, does a copy() operation on Credentials that represent a day long session copy its session cache file as well? Does destroy() do a "deep" destroy and erase the cache file? What happens if there were copies laying around? Issues like these haven't been though about really hard. And there is this notiion of session credentials all over the spec, as well. > It just seems that the focus of what is being done is to change the > policy, and not to change the credentials. If an application > changes > its credentials, are the same credentials used for each > communication > with all clients? This I am sorry to admit is really implementation specific. Depends on the way the application used policy objects by either applying them to object references or Current (for default). We have a chicken/egg problem here. For the vault to be replaceable, the credentials it creates needs to be able to advertise and direct the credentials capabilities. This direction should really be done by Policies, and not by the application. However, to be replaceable, the operations must be there, so the Policy objects may manipulate them, which means by virtue of the IDL that the application may be able to as well. > Or will there be a different set of credentials for > each different client? They could very well be. > I guess I still see what the application is > trying to do is to change the policy that is used to govern it. > I think > both the management interfaces and the client/application interfaces > should reference the policy object instance and not the credentials > (unless you are trying to have the application operate under a > different > security policy for each client who is trying to use it.) This > would > create a more uniform way of dealing with security, particularily in > those instances when we require access mediation, cryptography > services, > etc. in the Application itself. I think that is the basic trust. However, the interfaces are needed to make SecurityReplaceable replaceable. > What it probably will require is thinking about the Security Policy Object > in more detail. A list won't hack it. Well, I would agree with you on that one. -Polar ------------------------------------------------------------------- Polar Humenn Adiron, LLC President 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