Issue 2259: del parameter of set_delegation should be Security::DelegationDirective (sec-rev) Source: (, ) Nature: Uncategorized Issue Severity: Summary: Summary: t is possible that in the final resolutions document we forgot to say that the type of the "del" parameter of set_delegation should be Security::DelegationDirective and not SecurityLevel2::DelegationMode. This change was not specified either for the IDL or for the description of the set_credentials operation. Also DelegationMode should be removed from SecurityLevel2. Resolution: Close issue 2259: del parameter ..... Revised Text: We agreed to Remove get/set_credential operations on Current in favor of the new policy oriented way of setting thread specific policies. Page 15-60 Change picture "set_credentials(invocation credentials)" to ’InvocationCredentialsPolicy". Replace paragraph 323 on page 15-60 with: When all required changes have been made the credentials may be specified as the credentials for all subsequent invocations by the setting of an InvocationCredentialsPolicy on PolicyCurrent. Para 345 on page 15-65: Change entire end of paragraph starting with "Finally it can call Current::set_credentials..." with:Finally, the intermediate object can place the received credentials in an InvocationCredentialsPolicy for use in making subsequent invocations. Para 347. Remove entire end of paragraph starting with "After doing this, ...." (It’s objective has been stated before, and is overly stated). Remove paragraph 349 as we have no idea how this works. Remove last two bullets of paragraph 568 (set_credentials and get_credentials). Remove paragraph 570 talking about set* and get* operations as they have no significance any more. Change the initial wording of paragraph 571 by removing the word "further". Remove paragraph 579 on page 15-113 through 583 on page 15-114. (Definintions of get_credentials, set_credentials.) Appendix A.1: Remove the definition of "enum CredentialType". beginning with comment "// Credential types which ....." Appendix A.4: Remove definition of "enum DelegationMode". Remove the definitions of get/set_credentials on Current. Actions taken: December 16, 1998: received issue April 20, 1999: closed issue Discussion: End of Annotations:===== Return-Path: Date: Tue, 15 Dec 1998 18:31:06 -0500 From: Nick Brachet Organization: Gradient Technologies, Inc. X-Accept-Language: en To: sec-rev@omg.org Subject: Issue: del parameter of set_delegation should be Security::DelegationDirective Let me quote Jishnu who perfectly captured the problem: This is another one where we (the RTF goofed). It is possible that in the final resolutions document we forgot to say that the type of the "del" parameter of set_delegation should be Security::DelegationDirective and not SecurityLevel2::DelegationMode. This change was not specified either for the IDL or for the description of the set_credentials operation. Sigh.... Also DelegationMode should be removed from SecurityLevel2. -- Nick -- Aintitawfuller! X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Wed, 10 Mar 1999 10:29:30 -0500 (EST) From: Polar Humenn To: sec-rev@omg.org Subject: Re: Open Issues On 9 Mar 1999, Andre Srinivasan wrote: > Issue 2086: Yuck. Any constructive comments? > Issue 2259: More discussion About the delegation mode parameter on set_credentials. I'm confused on this one. For a credentials object there is no way to change the delegation mode of the credentials. So this operation doesn't make sense, since you would need special access into the Vault that created the credentials, destroying the replaceable piece. The Vault creates Credentials, and Security Contexts to run in the SECIOP machine. DelegationMode is the delegation capability of the credentials object when it is created by the vault. The DelegationDirective states whether to actually delegate the credentials, and this parameter is given in the Vault to init_security_context. This parameter is currently supplied by using an DelegationDirective Policy. For SSL, Delegation is not an issue. For mechanisms built on top of SSL, or other security mechanisms, it might be, but what are the issues? -Polar To: Polar Humenn Cc: sec-rev@omg.org Subject: Re: Issue 2259 References: X-Disclaimer: These are my statements and opinions. Mine Mine Mine Mine. X-Disclaimer: To assume or infer that these statements represent X-Disclaimer: Inprise Corporation would be, without a doubt, your error. From: "Andre Srinivasan" Date: 15 Mar 1999 11:59:01 -0800 Lines: 53 PH> About the delegation mode parameter on set_credentials. PH> I'm confused on this one. PH> For a credentials object there is no way to change the PH> delegation mode of the credentials. So this operation doesn't make sense, PH> since you would need special access into the Vault that created the PH> credentials, destroying the replaceable piece. PH> The Vault creates Credentials, and Security Contexts to run in the PH> SECIOP machine. DelegationMode is the delegation capability of PH> the credentials object when it is created by the vault. PH> The DelegationDirective states whether to actually delegate the PH> credentials, and this parameter is given in the Vault to PH> init_security_context. This parameter is currently supplied by using an PH> DelegationDirective Policy. Is this accurate? I think this is where we have disagreement about the Vault and the PrincipalAuthenticator. Currently, you can create a Credentials using PrincipalAuthenticator and make it your invocation credentials via set_credentials. The init_security_context sets delegation_mode parameter basd on the "client policy and application preferences" according to the 1.5 spec. It would seem that the delegation parameter to set_credentials would be used. PH> For SSL, Delegation is not an issue. This is sort of true. Remember when we (the firewall submission group that is) were pragmatic about forwarding credentials from a firewall? [Now all of you who are about to go on a tirade about firewall/credentials/SECIOP just post your issues to the firewall-rtf and issues. Let's stay focused on issue 2259] It was assumed that set_credentials/get_credentials would be the API that was used. Technically speaking, the delegation_mode for forwarded credentials should be Delegate since its sorta-kinda-like impersonation. PH> For mechanisms built on top of SSL, or other security mechanisms, PH> it might be, but what are the issues? I'm not sure what you're asking. As we move toward the model described by the CSIv2 RFP, the credentialing mechanism gets separated from the secure transport mechanism and we have actual delegation issues. -andre. X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Thu, 18 Mar 1999 11:37:08 -0500 (EST) From: Polar Humenn To: Andre Srinivasan cc: sec-rev@omg.org Subject: Re: Issue 2259 On 15 Mar 1999, Andre Srinivasan wrote: > > PH> About the delegation mode parameter on set_credentials. > > PH> I'm confused on this one. > > PH> For a credentials object there is no way to change the > PH> delegation mode of the credentials. So this operation doesn't > make sense, > PH> since you would need special access into the Vault that created > the > PH> credentials, destroying the replaceable piece. > > PH> The Vault creates Credentials, and Security Contexts to run in > the > PH> SECIOP machine. DelegationMode is the delegation capability of > PH> the credentials object when it is created by the vault. > > PH> The DelegationDirective states whether to actually delegate the > PH> credentials, and this parameter is given in the Vault to > PH> init_security_context. This parameter is currently supplied by > using an > PH> DelegationDirective Policy. > > Is this accurate? I think this is where we have disagreement about > the Vault and the PrincipalAuthenticator. Currently, you can create > a > Credentials using PrincipalAuthenticator and make it your invocation > credentials via set_credentials. Or, I suppose by setting the InvocationCredentials Policy on Current, or also by attaching the policy to an object reference. > The init_security_context sets > delegation_mode parameter basd on the "client policy and application > preferences" according to the 1.5 spec. It would seem that the > delegation parameter to set_credentials would be used. The original purpose for the delegation parameter on set_credentials was because, DCE credentials mechanisms needed a jump to get delegation credentials. However, this needs to be done when getting a ticket for a specific server, therefore the delegation parameter is in init_security_context. The problem we have is that there are too many ways of doing things. Personally, I think whole *separate* policies (runtime, i.e. MechanismsPolicy,DelegationDirective,InvocationCredentials,EstablishTrust) should be scrapped, and there should be one policy that you can attach to an object reference which states the credentials and the characteristics you want to use (like the previous policies), instead of having the Service run though the decision procedure. Stuff of that complexity should be application layer, or value added toolkit stuff. We should be defining primitives. Set_credentials and get_credentials would be fine. However, we still need away to associate the credentials with object references. We did that with policy objects. It just got running and away from us. The problem I have with it, is the delegation parameter, which apparently changes the state (or adds to the state) of the Credentials object. The Credentials interface has no support for this operation. Therefore if you had a Vault that generates Credentials, there is no way of changing the delegation state of the Credentials from the application layer without the ORB knowing the internals of the Credentials. This can be solved with a well thought out process for chaning the delegation state of the credentials. > PH> For SSL, Delegation is not an issue. > > This is sort of true. Remember when we (the firewall submission > group > that is) were pragmatic about forwarding credentials from a > firewall? I'm not sure how this is done currently. > It was assumed that set_credentials/get_credentials would be the > API that was used. Technically speaking, the delegation_mode for > forwarded credentials should be Delegate since its sorta-kinda-like > impersonation. Right, but how do you change the delegation on received credentials when they are not yet specifically delegatable by the client first? That would mean that a client would always have to use delegatable credentials when talking with anything that had the potential to be behind a firewall. Is this the intent?!?!? -Polar