Issue 2260: accept_security_contect() creds parameter (sec-rev) Source: (, ) Nature: Uncategorized Issue Severity: Summary: Summary: Should Vault::accept_security_context() take a CredentialsList parameter or a Credentials (not a list) like every other operations in Vault? Resolution: Close issue 2260: accept_security_context() creds parameter Revised Text: Reason: We agreed to close this issue because it the list of credentials is needed. This issue is a question that was answered on secsig. Actions taken: December 16, 1998: received issue April 20, 1999: closed issue Discussion: End of Annotations:===== Return-Path: Date: Tue, 15 Dec 1998 18:40:01 -0500 From: Nick Brachet Organization: Gradient Technologies, Inc. X-Accept-Language: en To: sec-rev@omg.org Subject: Issue: accept_security_context() creds parameter Should Vault::accept_security_context() take a CredentialsList parameter or a Credentials (not a list) like every other operations in Vault? -- Nick -- Aintitawfuller! X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Mon, 1 Feb 1999 16:56:52 -0500 (EST) From: Polar Humenn To: sec-rev@omg.org Subject: Re: Issue: accept_security_context() creds parameter Bob Blakely wrote: > "accept" has to take a credentials (not a list) given our resolution at > the last meeting of the singleton vs. list issue. No, that is not the case with this one Bob. The one credential thing we agreed on is for "init_security_context" for the "selected" invocation credential, basically because it being a list really didn't make sense, and was a kludge because of this received credentials list we had (and thank god, got rid of). The accept needs to take a list of credentials, because it is not yet known which credentials will be needed. Selection of credentials *may* depend on the OID of the mechanism identifier of the GSS-INITIAL-TOKEN, or some other vault specific mechanism. I am assuming that the "own" credentials list will be given to "accept" unless some other way (possibly with the POA, which we need to get straightened out) allows association of some credentials with a particular servant. The credentials object(s) associated with that servant will be the ones given to accept security context. Based on this description I believe the specification is 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 Date: Wed, 03 Feb 1999 15:57:12 -0500 From: Nick Brachet Organization: Gradient Technologies, Inc. X-Accept-Language: en To: sec-rev@omg.org Subject: Re: Issue: accept_security_context() creds parameter References: Polar Humenn wrote: > Bob Blakely wrote: > > > "accept" has to take a credentials (not a list) given our resolution at > > the last meeting of the singleton vs. list issue. > > No, that is not the case with this one Bob. The one credential thing we > agreed on is for "init_security_context" for the "selected" invocation > credential, basically because it being a list really didn't make sense, > and was a kludge because of this received credentials list we had (and > thank god, got rid of). > > The accept needs to take a list of credentials, because it is not yet > known which credentials will be needed. Selection of credentials *may* > depend on the OID of the mechanism identifier of the GSS-INITIAL-TOKEN, or > some other vault specific mechanism. > > I am assuming that the "own" credentials list will be given to "accept" > unless some other way (possibly with the POA, which we need to get > straightened out) allows association of some credentials with a particular > servant. The credentials object(s) associated with that servant will be > the ones given to accept security context. > > Based on this description I believe the specification is okay. accept_security_context() returns one, and only one, ServerSecurityContext. I don't see how one ServerSecurityContext can be used for multiple mechanisms... You're right, Polar, that the "own" credentials list will be given to "accept" but each credentials in the "own" list should be given one at a time to "accept", thus creating a list of ServerSecurityContext. Also credentials might be added (or removed) later on to the "own" list, the corresponding contexts must in turn be added (or removed) from the list of ServerSecurityContext. Again, you're right that we need a way to associate a mechanism OID to a ServerSecurityContext so we can choose which context to use upon receipt of a GSS-INITIAL-TOKEN. -- Nick -- Certified Aintitawfuller!