Issue 4277: New minor codes for NO_PERMISSION Exception in CSIv2 (csiv2-ftf) Source: International Business Machines (Dr. Daniel T. Chang, dtchang(at)us.ibm.com) Nature: Uncategorized Issue Severity: Summary: Don, > > Although the minor codes of the NO_PERMISSION exception have been defined > in Table 4-7, Section 4.5, of the 7/21/2000 version of the CSIv2 > Specification, in order > for the server to properly communicate the caused of the NO_PERMISSION > exception > to the client, we would like to propose the additional minor codes to the > NO_PERMISSION > exception. > > *********************************************************************** > NO_PERMISSION authentication error minor codes: range 1-100 > (Note: The following minor codes are defined in the current CSIv2 spec: > > 1 - Invalid evidence > 2 - Invalid mechanism > 3 - Conflicting evidence > 4- No Context > ) > The new proposed minor codes for NO_PERMISSION exception: The numbering > scheme was chosen to group errors into areas of > similarity. > > 5 - user id not defined to security system - the user may select another > userid > 6 - user id revoked by security system - the user may select > another userid > > 11 - password invalid for this userid - the user may correct the password > 12 - password expired - the user may select another userid > > 20 - credentials expired - the user may select different credentials or > renew them(e.g. by reissuing kinit) > 22 - credentials invalid - the user may select different > credentials, (e.g. > by kinit, or specifying a different PKCS certificate handle) > > 52 - new password doesn't meet installation requirements > > 60 - general authentication error - the user should resubmit his > credentials, but not additional information as to what is in error is > provided. > ****** Resolution: Close issue with revised text. Revised Text: Base document: http://cgi.omg.org/pub/csiv2-ftf/csiv2-031401.pdf [1] In para 21, change the bullet about error_token to the following * error_token A GSS mechanism-specific error token. When an EstablishContext message is rejected because it contains a client_authentication_token (a GSS initial context token) that is invalidated by the TSS, then depending on the mechanism, the TSS may return a CDR encapsulation of a mechanism-specific GSS error token in this field. Not all GSS mechanisms produce error tokens in response to initial context token validation failures. [2] Add a new section after para 49 GSSUP Mechanism-Specific Error Token The GSSUP mechanism-specific error token contains a GSSUP fatal error code. typedef unsigned long ErrorCode; // GSSUP Mechanism-Specific Error Token struct ErrorToken { ErrorCode error_code; }; The following fatal error codes are defined by the GSSUP mechanism: // the context validator has chosen not to reveal // the GSSUP specific cause of the failure. const ErrorCode GSS_UP_S_G_UNSPECIFIED = 1; // the user identified in the username field of // the GSSUP::InitialContextToken is unknown to the target const ErrorCode GSS_UP_S_G_NOUSER = 2; // the password supplied in the GSSUP::InitialContextToken // was incorrect const ErrorCode GSS_UP_S_G_BAD_PASSWORD = 3; // the target_name supplied in the GSSUP::InitialContextToken // does not match a target_name in a mechanism definition of // the target const ErrorCode GSS_UP_S_G_BAD_TARGET = 4; A TSS is under no obligation to return a GSSUP error token; however, returning this token may facilitate the transition of the client-side GSS state machine through error processing. Accordingly, a TSS may indicate that SAS context validation failed in GSSUP client authentication by returning a GSSUP error token in a SAS ContextError message. In this case, a TSS that choses not to reveal specific information as to the cause of the failed GSSUP authentication shall return a status value of GSS_UP_S_G_UNSPECIFIED. [3] change table 16-9 in section 16.3.5 ContextError Values and Exceptions as follows (ignoring the first and last columns which will remain unchanged). Event Semantic Major Minor accept_context returned failure Invalid evidence 1 1 Invalid mechanism 2 1 Conflicting evidence 3 1 reference_context (N) returned false No Context 4 1 [4] Add the following IDL to section 16.9.2 Module GSSUP - Username/Password GSSAPI Token Formats typedef unsigned long ErrorCode; // the context validator has chosen not to reveal // the GSSUP specific cause of the failure. const ErrorCode GSS_UP_S_G_UNSPECIFIED = 1; // the user identified in the username field of // the GSSUP::InitialContextToken is unknown to the target const ErrorCode GSS_UP_S_G_NOUSER = 2; // the password supplied in the GSSUP::InitialContextToken // was incorrect const ErrorCode GSS_UP_S_G_BAD_PASSWORD = 3; // the target_name supplied in the GSSUP::InitialContextToken // does not match a target_name in a mechanism definition of // the target const ErrorCode GSS_UP_S_G_BAD_TARGET = 4; // GSSUP Mechanism-Specific Error Token struct ErrorToken { ErrorCode error_code; }; Actions taken: April 18, 2001: received issue October 3, 2001: closed issue Discussion: CSIv2 will not define a new exception minor code. The CSIv2 ContextError codes will be modified to support future inclusion of additional and optional error codes in the point-to-point, wire-level exchange between TSS and CSS. An error token and minor status codes will be defined for the GSSUP mechanism. Communicating error status from the CSS to the client app, will be defined in the context of APIs (that is, above the wire-level interoperability defined by the current specification). End of Annotations:===== From: "Don Flinn" To: "issues" , "csiv2-ftf" , "David Chang" Cc: "Gary Puchkoff" Subject: RE: New minor codes for NO_PERMISSION Exception in CSIv2 Date: Wed, 18 Apr 2001 08:29:27 -0400 Message-ID: <000401c0c803$35aa3c60$2302a8c0@boston.amer.iona.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: Importance: Normal Content-Type: text/plain; charset="iso-8859-1" X-UIDL: epCe93igd9gGP!!H:D!! Jurgen Enclosed is a new issue for the CSIv2 FTF, please post it. Thanks Don > -----Original Message----- > From: David Chang [mailto:dyc@us.ibm.com] > Sent: Thursday, April 12, 2001 2:54 PM > To: dflinn@iona.com > Cc: Gary Puchkoff > Subject: New minor codes for NO_PERMISSION Exception in CSIv2 > > > Don, > > Although the minor codes of the NO_PERMISSION exception have been defined > in Table 4-7, Section 4.5, of the 7/21/2000 version of the CSIv2 > Specification, in order > for the server to properly communicate the caused of the NO_PERMISSION > exception > to the client, we would like to propose the additional minor codes to the > NO_PERMISSION > exception. > > *********************************************************************** > NO_PERMISSION authentication error minor codes: range 1-100 > (Note: The following minor codes are defined in the current CSIv2 spec: > > 1 - Invalid evidence > 2 - Invalid mechanism > 3 - Conflicting evidence > 4- No Context > ) > The new proposed minor codes for NO_PERMISSION exception: The numbering > scheme was chosen to group errors into areas of > similarity. > > 5 - user id not defined to security system - the user may select another > userid > 6 - user id revoked by security system - the user may select > another userid > > 11 - password invalid for this userid - the user may correct the password > 12 - password expired - the user may select another userid > > 20 - credentials expired - the user may select different credentials or > renew them(e.g. by reissuing kinit) > 22 - credentials invalid - the user may select different > credentials, (e.g. > by kinit, or specifying a different PKCS certificate handle) > > 52 - new password doesn't meet installation requirements > > 60 - general authentication error - the user should resubmit his > credentials, but not additional information as to what is in error is > provided. > ************************************************************************ > > Gary Puchkoff of IBM has proposed this request in the OMG Irvine Security > SIG meeting. It was recommended by the Security > SIG to propose the new NO_PERMISSION minor codes in the CSIv2 FTF meeting. > > Please distribute this issue to the CSIv2 FTF mail distribution list. > > > Thanks > > David Chang > > WebSphere Security Architect & Team Lead > IBM SWS Division, Internal Mail Stop 9131 > Austin, Tx 78758 > E-Mail:dyc@us.ibm.com > Phone:(512)838-0559, T/L 678-0559 > Fax: (512)838-1032 > X-Authentication-Warning: emerald.omg.org: hobbit.omg.org [192.67.184.3] didn't use HELO protocol Received: from e21.nc.us.ibm.com (32.97.136.227) by hobbit.omg.org asmtp(1.0) id 12147; Wed, 16 May 2001 12:04:42 -0400 (EDT) Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by e21.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id LAA37826; Wed, 16 May 2001 11:53:32 -0500 Received: from d04nm203.raleigh.ibm.com (d04nm203.raleigh.ibm.com [9.67.228.40]) by southrelay02.raleigh.ibm.com (8.11.1/NCO v4.96) with ESMTP id f4GFxe759138; Wed, 16 May 2001 11:59:40 -0400 Importance: Normal Subject: Define "Authentication Failure minor code for NO_PERMISSION To: "Don Flinn" Cc: "csiv2-ftf" X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "David Chang" Date: Wed, 16 May 2001 10:59:38 -0500 X-MIMETrack: Serialize by Router on D04NM203/04/M/IBM(Release 5.0.6 |December 14, 2000) at 05/16/2001 11:59:40 AM MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-UIDL: W8[!!o@6!!RX-e9S?/e9 Don, I have revised IBM's Minor Code proposal for NO_PERMISSION exception as follows in the CSIv2 Issue format: Issue XXXXX: Need Authentication Error Minor Code for ContextError Values and Exceptions Source: IBM (David Chang, dyc@us.ibm.com) Document: Nature: Uncategorized Issue Severity: Critical Summary: The error values and exceptions returned by a server(TSS)does not provide sufficient information for client(CSS) to identify the authentication error. Discussion: When accept_context returns Invalid evidence, the server(TSS) shall reject and send a NO_PERMISSION exception containing a ContextError service context element with the major error code 1 and the minor error code 1. Note that the major error code and the minor error code are the error codes defined in the ContextError service context. The Invalid evidence error covers a wide range of possible error conditions including Client Authentication failure, Identity Assertion failure, or Invalid Privilege Attribute, etc.. It is necessary for the Client to identify the Client Authentication failure so that clients can resend a correct client identity such as user ID and password to the server for re-authentication. Resolution: It is recommend to define the Client Authentication with the major code = 1 and minor code = 1 of the NO_PERMISSION exception when the Invalid evidence error scenario is returned in the returned ContextError service context in the CSIv2 specification. With this proposal, the client program can identify the Client Authentication error condition and prompt users to enter correct user ID and password to retry the authentication operation in the server(TSS). Revised Text: Action Taken: David Chang WebSphere Security Architect & Team Lead IBM SWS Division, Internal Mail Stop 9131 Austin, Tx 78758 E-Mail:dyc@us.ibm.com Phone:(512)838-0559, T/L 678-0559 Fax: (512)838-1032 "Don Flinn" on 05/16/2001 08:22:58 AM To: "csiv2-ftf" cc: Subject: No Telecom Today I don't know of any issues that can't be covered by e-mail. So in order to save peoples' time we'll skip the telecom today. On the other hand, lets get the e-mail flowing again. Polar has sent out some comments on issue 3906, which I haven't had time to read yet. I promise to get to that today. If someone wants to bring up issues for which a telecom are necessary, please bring them up to the mailing list. In that way if there are such issues we can plan them for next week. Also, David Chang has said that he will send out a proposed resolution for IBM's issue on minor codes. Don ======================== Down the mid-tier Over the Firewall Nothing but Net ======================== Don Flinn Iona Technologies don.flinn@iona.com Tel: 781-902-8559 FAX: 781-902-8001 X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Wed, 16 May 2001 12:30:04 -0400 (EDT) From: Polar Humenn To: David Chang cc: Don Flinn , csiv2-ftf Subject: Re: Define "Authentication Failure minor code for NO_PERMISSION In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: F=*e9kl%"!Xc]d9]a8e9 David, I have a problem with a TSS being mandated to send a NO_PERMISSION exception with a particluar minor code if a ClientAuthentication fails. First, of all, such an inndication, should be a part of a TSS policy that governs whether that the indication of client authentication should be revealed. Otherwise, dictionary attacks can prevail. Next, is that it is a CSIv2 error, and perhaps there should be a CSIv2 Error code that is more specific, and not a NO_PERMISSION error. The problem with this may be that a CSIv2 context error is local to the CSS that is talking to the TSS whereas the NO_PERMISSION exception can be thrown by an object down on a chain of invocations. The result is that the client gets an indication that the request he made on an intermediate object results in a NO_PERMISSION exception from some object the intermedate. If the CSIv2 error is contained to the service context, then the intermediate CSS can filter the service context out before passing the NO_PERMISSION statement up the invocation chain. Alternatively, getting an indication that an intermediate's client authentication failed at the client, will make the client confused having got the client authentication correct for the intermediate object. Cheers, -Polar On Wed, 16 May 2001, David Chang wrote: > Don, > > I have revised IBM's Minor Code proposal for NO_PERMISSION exception >as > follows in the CSIv2 Issue format: > > Issue XXXXX: Need Authentication Error Minor Code for ContextError >Values > and Exceptions > Source: IBM (David Chang, dyc@us.ibm.com) > Document: > Nature: Uncategorized Issue > Severity: Critical > Summary: > The error values and exceptions returned by a server(TSS)does not >provide > sufficient information for client(CSS) to identify > the authentication error. > > Discussion: > > When accept_context returns Invalid evidence, the server(TSS) shall >reject > and send a NO_PERMISSION exception > containing a ContextError service context element with the major >error code > 1 and the minor error code 1. Note that the major > error code and the minor error code are the error codes defined in >the > ContextError service context. > > The Invalid evidence error covers a wide range of possible error >conditions > including Client Authentication failure, > Identity Assertion failure, or Invalid Privilege Attribute, etc.. >It is > necessary for the Client to identify the Client Authentication > failure so that clients can resend a correct client identity such as >user > ID and password to the server for re-authentication. > > Resolution: > > It is recommend to define the Client Authentication with the major >code = 1 > and minor code = 1 of the NO_PERMISSION > exception when the Invalid evidence error scenario is returned in >the > returned ContextError service context in the CSIv2 > specification. > > With this proposal, the client program can identify the Client > Authentication error condition and prompt users to enter correct > user ID and password to retry the authentication operation in the > server(TSS). > > Revised Text: > > Action Taken: > > > > > David Chang > > WebSphere Security Architect & Team Lead > IBM SWS Division, Internal Mail Stop 9131 > Austin, Tx 78758 > E-Mail:dyc@us.ibm.com > Phone:(512)838-0559, T/L 678-0559 > Fax: (512)838-1032 > > > "Don Flinn" on 05/16/2001 08:22:58 AM > > To: "csiv2-ftf" > cc: > Subject: No Telecom Today > > > > I don't know of any issues that can't be covered by e-mail. So in >order to > save peoples' time we'll skip the telecom today. On the other hand, >lets > get the e-mail flowing again. Polar has sent out some comments on >issue > 3906, which I haven't had time to read yet. I promise to get to >that > today. > > If someone wants to bring up issues for which a telecom are >necessary, > please bring them up to the mailing list. In that way if there are >such > issues we can plan them for next week. > > Also, David Chang has said that he will send out a proposed >resolution for > IBM's issue on minor codes. > > Don > > ======================== > Down the mid-tier > Over the Firewall > Nothing but Net > ======================== > > Don Flinn > Iona Technologies > don.flinn@iona.com > Tel: 781-902-8559 > FAX: 781-902-8001 > > > ------------------------------------------------------------------- Polar Humenn Adiron, LLC mailto:polar@adiron.com 2-212 CST Phone: 315-443-3171 Syracuse, NY 13244-4100 Fax: 315-443-4745 http://www.adiron.com Importance: Normal Subject: Re: Define "Authentication Failure minor code for NO_PERMISSION To: Polar Humenn Cc: Don Flinn , csiv2-ftf From: "David Chang" Date: Wed, 16 May 2001 14:08:22 -0400 Message-ID: X-MIMETrack: Serialize by Router on D04NM203/04/M/IBM(Release 5.0.6 |December 14, 2000) at 05/16/2001 02:08:23 PM MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-UIDL: ScHe9LmWd94d1!!cm on 05/16/2001 11:30:04 AM To: David Chang/Austin/IBM@IBMUS cc: Don Flinn , csiv2-ftf Subject: Re: Define "Authentication Failure minor code for NO_PERMISSION >Polar write: >David, >I have a problem with a TSS being mandated to send a NO_PERMISSION >exception with a particluar minor code if a ClientAuthentication >fails. >First, of all, such an inndication, should be a part of a TSS policy that >governs whether that the indication of client authentication should be >revealed. Otherwise, dictionary attacks can prevail. >> David write: >> TSS policy configuration is acceptable. In other words, the >> ClientAuthentication Error return code can be turned off by the >> TSS policy. >Next, is that it is a CSIv2 error, and perhaps there should be a CSIv2 >Error code that is more specific, and not a NO_PERMISSION error. >> David write: >> Since both ContxtError and NO_PERMISSION exception are returned >> from TSS, >> the ClientAuthentication error can be indicated via either CSIv2 >> Error code >> or NO_PERPERMISSION exception. If we fix this problem through NO_PERMISSION >> exception minor code, CSS can propagate the NO_PERMISSION minor >> code the >> client application program without interpreting the CSIv2 error >> code. >> >The problem with this may be that a CSIv2 context error is local to the >CSS that is talking to the TSS whereas the NO_PERMISSION exception can be >thrown by an object down on a chain of invocations. >The result is that the client gets an indication that the request he made >on an intermediate object results in a NO_PERMISSION exception from some >object the intermedate. If the CSIv2 error is contained to the service >context, then the intermediate CSS can filter the service context out >before passing the NO_PERMISSION statement up the invocation chain. >> David write: >> It seems to me the problem to use the NO_PERMISSION exception to >> report >> error is not unique to the CSIv2 error scenario. Is it part of the >> CORBA >> architecture to use exception such as NO_PERMISSION to pass error condition >> between client and server? >Alternatively, getting an indication that an intermediate's client >authentication failed at the client, will make the client confused >having >got the client authentication correct for the intermediate object. Cheers, -Polar On Wed, 16 May 2001, David Chang wrote: > Don, > > I have revised IBM's Minor Code proposal for NO_PERMISSION exception >as > follows in the CSIv2 Issue format: > > Issue XXXXX: Need Authentication Error Minor Code for ContextError >Values > and Exceptions > Source: IBM (David Chang, dyc@us.ibm.com) > Document: > Nature: Uncategorized Issue > Severity: Critical > Summary: > The error values and exceptions returned by a server(TSS)does not >provide > sufficient information for client(CSS) to identify > the authentication error. > > Discussion: > > When accept_context returns Invalid evidence, the server(TSS) shall reject > and send a NO_PERMISSION exception > containing a ContextError service context element with the major >error code > 1 and the minor error code 1. Note that the major > error code and the minor error code are the error codes defined in >the > ContextError service context. > > The Invalid evidence error covers a wide range of possible error conditions > including Client Authentication failure, > Identity Assertion failure, or Invalid Privilege Attribute, etc.. >It is > necessary for the Client to identify the Client Authentication > failure so that clients can resend a correct client identity such as >user > ID and password to the server for re-authentication. > > Resolution: > > It is recommend to define the Client Authentication with the major >code = 1 > and minor code = 1 of the NO_PERMISSION > exception when the Invalid evidence error scenario is returned in >the > returned ContextError service context in the CSIv2 > specification. > > With this proposal, the client program can identify the Client > Authentication error condition and prompt users to enter correct > user ID and password to retry the authentication operation in the > server(TSS). > > Revised Text: > > Action Taken: > > > > > David Chang > > WebSphere Security Architect & Team Lead > IBM SWS Division, Internal Mail Stop 9131 > Austin, Tx 78758 > E-Mail:dyc@us.ibm.com > Phone:(512)838-0559, T/L 678-0559 > Fax: (512)838-1032 > > > "Don Flinn" on 05/16/2001 08:22:58 AM > > To: "csiv2-ftf" > cc: > Subject: No Telecom Today > > > > I don't know of any issues that can't be covered by e-mail. So in >order to > save peoples' time we'll skip the telecom today. On the other hand, >lets > get the e-mail flowing again. Polar has sent out some comments on >issue > 3906, which I haven't had time to read yet. I promise to get to >that > today. > > If someone wants to bring up issues for which a telecom are >necessary, > please bring them up to the mailing list. In that way if there are >such > issues we can plan them for next week. > > Also, David Chang has said that he will send out a proposed >resolution for > IBM's issue on minor codes. > > Don > > ======================== > Down the mid-tier > Over the Firewall > Nothing but Net > ======================== > > Don Flinn > Iona Technologies > don.flinn@iona.com > Tel: 781-902-8559 > FAX: 781-902-8001 > > > ------------------------------------------------------------------- Polar Humenn Adiron, LLC mailto:polar@adiron.com 2-212 CST Phone: 315-443-3171 Syracuse, NY 13244-4100 Fax: 315-443-4745 http://www.adiron.com X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Wed, 16 May 2001 14:37:03 -0400 (EDT) From: Polar Humenn To: David Chang cc: Don Flinn , csiv2-ftf Subject: Re: Define "Authentication Failure minor code for NO_PERMISSION In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: 5D/!!e%-!!Hd9e9L/De9 Hi David, I think I didn't outline the scenario well enough. I think in the OMA, the following must happen. Take this request scenario between a client, and intermediate object, and a final target object. Yes, familiar, isn't it :) Client ---> Intermediate --- | |--->---| | TSS -dispatch- Target | |<------| | <---------------------- Not even considering CSIv2, if the target side throws a NO_PERMISSION exception (whether its the TSS or the target itself) and the intermediate doesn't catch it, then the intermediate ORB is required to pass the exception back up the chain. Somebody please correct me if I am wrong! If the NO_PERMISSION exception carries an explicit minor code indicating a failed CSIv2 ClientAuthentication, the Client can only assume that the failure was at its object of invocation, which is the intermediate. This assumption is wrong. If an error code signifying a client authentication level failure is in the CSIv2 ErrorMessage, it goes no further up the chain. The service context is not required to be lifted up with the exception. Especially, since it wouldn't make sense beyond a single CSS-TSS exchange, and of course, would reak complete havoc with the Client's CSS context management. I think the only acceptable solution is to create a CSIv2 error code that is an extension of "invalid evidence", which is a client authentication layer failure. I do see your problem. It's with the API. Given things today, you are only really allowed to look at a reply's service context in an interceptor, and not back up at the client implementation, which needs to do a retry. The CSS has to figure that out and somehow tell the client implementation that it failed because of a CSIv2 client authentication failure from the immediate target. I don't know yet how you can do this. Cheers, -Polar On Wed, 16 May 2001, David Chang wrote: > Polar, > > Thanks for your quick reply. > > Please see my comments in your note. > > Regards, > > David Chang > > WebSphere Security Architect & Team Lead > IBM SWS Division, Internal Mail Stop 9131 > Austin, Tx 78758 > E-Mail:dyc@us.ibm.com > Phone:(512)838-0559, T/L 678-0559 > Fax: (512)838-1032 > > > Polar Humenn on 05/16/2001 11:30:04 AM > > To: David Chang/Austin/IBM@IBMUS > cc: Don Flinn , csiv2-ftf > Subject: Re: Define "Authentication Failure minor code for >NO_PERMISSION > > > > >Polar write: > >David, > > >I have a problem with a TSS being mandated to send a NO_PERMISSION > >exception with a particluar minor code if a ClientAuthentication >fails. > > >First, of all, such an inndication, should be a part of a TSS >policy that > >governs whether that the indication of client authentication should >be > >revealed. Otherwise, dictionary attacks can prevail. > > >> David write: > >> TSS policy configuration is acceptable. In other words, the > >> ClientAuthentication Error return code can be turned off by the > >> TSS policy. > > >Next, is that it is a CSIv2 error, and perhaps there should be a >CSIv2 > >Error code that is more specific, and not a NO_PERMISSION error. > > >> David write: > >> Since both ContxtError and NO_PERMISSION exception are returned >from > TSS, > >> the ClientAuthentication error can be indicated via either CSIv2 >Error > code > >> or NO_PERPERMISSION exception. If we fix this problem through > NO_PERMISSION > >> exception minor code, CSS can propagate the NO_PERMISSION minor >code the > >> client application program without interpreting the CSIv2 error >code. > >> > > >The problem with this may be that a CSIv2 context error is local to >the > >CSS that is talking to the TSS whereas the NO_PERMISSION exception >can be > >thrown by an object down on a chain of invocations. > > >The result is that the client gets an indication that the request >he made > >on an intermediate object results in a NO_PERMISSION exception from >some > >object the intermedate. If the CSIv2 error is contained to the >service > >context, then the intermediate CSS can filter the service context >out > >before passing the NO_PERMISSION statement up the invocation chain. > > >> David write: > >> It seems to me the problem to use the NO_PERMISSION exception to >report > >> error is not unique to the CSIv2 error scenario. Is it part of >the CORBA > >> architecture to use exception such as NO_PERMISSION to pass error > condition > >> between client and server? > > >Alternatively, getting an indication that an intermediate's client > >authentication failed at the client, will make the client confused >having > >got the client authentication correct for the intermediate object. > > Cheers, > -Polar > > > > > > On Wed, 16 May 2001, David Chang wrote: > > > Don, > > > > I have revised IBM's Minor Code proposal for NO_PERMISSION >exception as > > follows in the CSIv2 Issue format: > > > > Issue XXXXX: Need Authentication Error Minor Code for ContextError >Values > > and Exceptions > > Source: IBM (David Chang, dyc@us.ibm.com) > > Document: > > Nature: Uncategorized Issue > > Severity: Critical > > Summary: > > The error values and exceptions returned by a server(TSS)does not >provide > > sufficient information for client(CSS) to identify > > the authentication error. > > > > Discussion: > > > > When accept_context returns Invalid evidence, the server(TSS) >shall > reject > > and send a NO_PERMISSION exception > > containing a ContextError service context element with the major >error > code > > 1 and the minor error code 1. Note that the major > > error code and the minor error code are the error codes defined in >the > > ContextError service context. > > > > The Invalid evidence error covers a wide range of possible error > conditions > > including Client Authentication failure, > > Identity Assertion failure, or Invalid Privilege Attribute, etc.. >It is > > necessary for the Client to identify the Client Authentication > > failure so that clients can resend a correct client identity such >as user > > ID and password to the server for re-authentication. > > > > Resolution: > > > > It is recommend to define the Client Authentication with the major >code > = 1 > > and minor code = 1 of the NO_PERMISSION > > exception when the Invalid evidence error scenario is returned in >the > > returned ContextError service context in the CSIv2 > > specification. > > > > With this proposal, the client program can identify the Client > > Authentication error condition and prompt users to enter correct > > user ID and password to retry the authentication operation in the > > server(TSS). > > > > Revised Text: > > > > Action Taken: > > > > > > > > > > David Chang > > > > WebSphere Security Architect & Team Lead > > IBM SWS Division, Internal Mail Stop 9131 > > Austin, Tx 78758 > > E-Mail:dyc@us.ibm.com > > Phone:(512)838-0559, T/L 678-0559 > > Fax: (512)838-1032 > > > > > > "Don Flinn" on 05/16/2001 08:22:58 AM > > > > To: "csiv2-ftf" > > cc: > > Subject: No Telecom Today > > > > > > > > I don't know of any issues that can't be covered by e-mail. So in >order > to > > save peoples' time we'll skip the telecom today. On the other >hand, lets > > get the e-mail flowing again. Polar has sent out some comments on >issue > > 3906, which I haven't had time to read yet. I promise to get to >that > > today. > > > > If someone wants to bring up issues for which a telecom are >necessary, > > please bring them up to the mailing list. In that way if there >are such > > issues we can plan them for next week. > > > > Also, David Chang has said that he will send out a proposed >resolution > for > > IBM's issue on minor codes. > > > > Don > > > > ======================== > > Down the mid-tier > > Over the Firewall > > Nothing but Net > > ======================== > > > > Don Flinn > > Iona Technologies > > don.flinn@iona.com > > Tel: 781-902-8559 > > FAX: 781-902-8001 > > > > > > > > ------------------------------------------------------------------- > Polar Humenn Adiron, LLC > mailto:polar@adiron.com 2-212 CST > Phone: 315-443-3171 Syracuse, NY 13244-4100 > Fax: 315-443-4745 http://www.adiron.com > > > ------------------------------------------------------------------- Polar Humenn Adiron, LLC mailto:polar@adiron.com 2-212 CST Phone: 315-443-3171 Syracuse, NY 13244-4100 Fax: 315-443-4745 http://www.adiron.com Date: Wed, 16 May 2001 15:18:59 -0400 From: Ron Monzillo X-Mailer: Mozilla 4.76 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Polar Humenn CC: David Chang , Don Flinn , csiv2-ftf Subject: Re: Define "Authentication Failure minor code for NO_PERMISSION References: Content-Type: multipart/mixed; boundary="------------7C86E176E23530EA3F228453" X-UIDL: EDbd9j@?e9JZm!! error_token A GSS mechanism-specific error token. When an EstablishContext message is rejected because it contains a client_authentication_token (a GSS initial context token) that is invalidated by the TSS, then depending on the mechanism, the TSS may return a mechanism-specific GSS error token in this field. Not all GSS mechanisms produce error tokens in response to initial context token validation failures. // GSSUP Error token struct ErrorToken { unsigned long major; unsigned long minor; }; See the attacment for a synopsis of gss status reporting from RFC 2743 I would suggest that a TSS return a major value of GSS_S_FAILURE (athough it would be free to return a more explicit major code if it chose to), but that it also return one of the following GSSUP mechanism specific minor codes. Note that returning an error token is and would remain optional. and then some mechanism specific MINOR codes GSS_UP_S_G_NOUSER /* username unknown */ GSS_UP_S_G_BAD_PASSWORD /* invalid password */ GSS_UP_S_G_BAD_TARGET /* target name not in target's mechanism definitions */ By the way, we currently don't explicitly say whether invalid evidence or invalid mechanism should be returned if the target name in the ICT doesn't match a target name in a mechanism supported by the target. 2. Alternatively, we could revamp our error tables (which currently are as follows) Table 16-9 ContextError Codes and Exceptions State Event Semantic Major Minor Exception EstabCtxt accept_context failure Invalid evidence 1 1 NO_PERMISSION Invalid mechanism 1 2 NO_PERMISSION Conflicting evid. 1 3 NO_PERMISSION ReqInCtxt reference_context(N)false No Context 1 4 NO_PERMISSION Perhaps to something like (I've left off the first columns to fit it here) Semantic Major Minor Exception Invalid evidence (Reason unspecified) 1 0 NO_PERMISSION Invalid evidence (client auth failed) 1 1 N0_PERMISSION Invalid evidence (untrusted identity assertion) 1 2 N0_PERMISSION Invalid evidence (untrusted privilege authority)1 3 N0_PERMISSION Invalid evidence (authn authz subject mismatch) 1 4 N0_PERMISSION Invalid mechanism (Reason unspecified) 2 0 NO_PERMISSION Conflicting evid. (Reason unspecified) 3 0 NO_PERMISSION No Context (Reason unspecified) 4 0 NO_PERMISSION All but the "reason unspecified" cases would be optional, that is a TSS would not be required to provide this level of feedback. We could also combine these two approaches. That is, define the error token for gssup, and move the minor codes up to the major codes in the table, and maybe or maybe not, define specific (optional) minor codes. Ron > The problem with this may be that a CSIv2 context error is local to the > CSS that is talking to the TSS whereas the NO_PERMISSION exception can be > thrown by an object down on a chain of invocations. > > The result is that the client gets an indication that the request he made > on an intermediate object results in a NO_PERMISSION exception from some > object the intermedate. If the CSIv2 error is contained to the service > context, then the intermediate CSS can filter the service context out > before passing the NO_PERMISSION statement up the invocation chain. > > Alternatively, getting an indication that an intermediate's client > authentication failed at the client, will make the client confused having > got the client authentication correct for the intermediate object. > > Cheers, > -Polar > > On Wed, 16 May 2001, David Chang wrote: > > > Don, > > > > I have revised IBM's Minor Code proposal for NO_PERMISSION exception as > > follows in the CSIv2 Issue format: > > > > Issue XXXXX: Need Authentication Error Minor Code for ContextError Values > > and Exceptions > > Source: IBM (David Chang, dyc@us.ibm.com) > > Document: > > Nature: Uncategorized Issue > > Severity: Critical > > Summary: > > The error values and exceptions returned by a server(TSS)does not provide > > sufficient information for client(CSS) to identify > > the authentication error. > > > > Discussion: > > > > When accept_context returns Invalid evidence, the server(TSS) shall reject > > and send a NO_PERMISSION exception > > containing a ContextError service context element with the major error code > > 1 and the minor error code 1. Note that the major > > error code and the minor error code are the error codes defined in the > > ContextError service context. > > > > The Invalid evidence error covers a wide range of possible error conditions > > including Client Authentication failure, > > Identity Assertion failure, or Invalid Privilege Attribute, etc.. It is > > necessary for the Client to identify the Client Authentication > > failure so that clients can resend a correct client identity such as user > > ID and password to the server for re-authentication. > > > > Resolution: > > > > It is recommend to define the Client Authentication with the major code = 1 > > and minor code = 1 of the NO_PERMISSION > > exception when the Invalid evidence error scenario is returned in the > > returned ContextError service context in the CSIv2 > > specification. > > > > With this proposal, the client program can identify the Client > > Authentication error condition and prompt users to enter correct > > user ID and password to retry the authentication operation in the > > server(TSS). > > > > Revised Text: > > > > Action Taken: > > > > > > > > > > David Chang > > > > WebSphere Security Architect & Team Lead > > IBM SWS Division, Internal Mail Stop 9131 > > Austin, Tx 78758 > > E-Mail:dyc@us.ibm.com > > Phone:(512)838-0559, T/L 678-0559 > > Fax: (512)838-1032 > > > > > > "Don Flinn" on 05/16/2001 08:22:58 AM > > > > To: "csiv2-ftf" > > cc: > > Subject: No Telecom Today > > > > > > > > I don't know of any issues that can't be covered by e-mail. So in order to > > save peoples' time we'll skip the telecom today. On the other hand, lets > > get the e-mail flowing again. Polar has sent out some comments on issue > > 3906, which I haven't had time to read yet. I promise to get to that > > today. > > > > If someone wants to bring up issues for which a telecom are necessary, > > please bring them up to the mailing list. In that way if there are such > > issues we can plan them for next week. > > > > Also, David Chang has said that he will send out a proposed resolution for > > IBM's issue on minor codes. > > > > Don > > > > ======================== > > Down the mid-tier > > Over the Firewall > > Nothing but Net > > ======================== > > > > Don Flinn > > Iona Technologies > > don.flinn@iona.com > > Tel: 781-902-8559 > > FAX: 781-902-8001 > > > > > > > > ------------------------------------------------------------------- > Polar Humenn Adiron, LLC > mailto:polar@adiron.com 2-212 CST > Phone: 315-443-3171 Syracuse, NY 13244-4100 > Fax: 315-443-4745 http://www.adiron.com 1.2.1.1: Status Reporting Each GSS-API call provides two status return values. Major_status values provide a mechanism-independent indication of call status (e.g., GSS_S_COMPLETE, GSS_S_FAILURE, GSS_S_CONTINUE_NEEDED), sufficient to drive normal control flow within the caller in a generic fashion. Table 1 summarizes the defined major_status return codes in tabular fashion. Sequencing-related informatory major_status codes (GSS_S_DUPLICATE_TOKEN, GSS_S_OLD_TOKEN, GSS_S_UNSEQ_TOKEN, and GSS_S_GAP_TOKEN) can be indicated in conjunction with either GSS_S_COMPLETE or GSS_S_FAILURE status for GSS-API per-message calls. For context establishment calls, these sequencing-related codes will be indicated only in conjunction with GSS_S_FAILURE status (never in conjunction with GSS_S_COMPLETE or GSS_S_CONTINUE_NEEDED), and, therefore, always correspond to fatal failures if encountered during the context establishment phase. Table 1: GSS-API Major Status Codes FATAL ERROR CODES GSS_S_BAD_BINDINGS channel binding mismatch GSS_S_BAD_MECH unsupported mechanism requested GSS_S_BAD_NAME invalid name provided GSS_S_BAD_NAMETYPE name of unsupported type provided GSS_S_BAD_STATUS invalid input status selector GSS_S_BAD_SIG token had invalid integrity check GSS_S_BAD_MIC preferred alias for GSS_S_BAD_SIG GSS_S_CONTEXT_EXPIRED specified security context expired GSS_S_CREDENTIALS_EXPIRED expired credentials detected GSS_S_DEFECTIVE_CREDENTIAL defective credential detected GSS_S_DEFECTIVE_TOKEN defective token detected GSS_S_FAILURE failure, unspecified at GSS-API level GSS_S_NO_CONTEXT no valid security context specified GSS_S_NO_CRED no valid credentials provided GSS_S_BAD_QOP unsupported QOP value GSS_S_UNAUTHORIZED operation unauthorized GSS_S_UNAVAILABLE operation unavailable GSS_S_DUPLICATE_ELEMENT duplicate credential element requested GSS_S_NAME_NOT_MN name contains multi-mechanism elements INFORMATORY STATUS CODES GSS_S_COMPLETE normal completion GSS_S_CONTINUE_NEEDED continuation call to routine required GSS_S_DUPLICATE_TOKEN duplicate per-message token detected GSS_S_OLD_TOKEN timed-out per-message token detected GSS_S_UNSEQ_TOKEN reordered (early) per-message token detected GSS_S_GAP_TOKEN skipped predecessor token(s) detected Minor_status provides more detailed status information which may include status codes specific to the underlying security mechanism. Minor_status values are not specified in this document. GSS_S_CONTINUE_NEEDED major_status returns, and optional message outputs, are provided in GSS_Init_sec_context() and GSS_Accept_sec_context() calls so that different mechanisms' employment of different numbers of messages within their authentication sequences need not be reflected in separate code paths within calling applications. Instead, such cases are accommodated with sequences of continuation calls to GSS_Init_sec_context() and GSS_Accept_sec_context(). The same facility is used to encapsulate mutual authentication within the GSS-API's context initiation calls. For mech_types which require interactions with third-party servers in order to establish a security context, GSS-API context establishment calls may block pending completion of such third-party interactions. On the other hand, no GSS-API calls pend on serialized interactions with GSS-API peer entities. As a result, local GSS-API status returns cannot reflect unpredictable or asynchronous exceptions occurring at remote peers, and reflection of such status information is a caller responsibility outside the GSS-API. error_token A GSS mechanism-specific error token. When an EstablishContext message is rejected because it contains a client_authentication_token (a GSS initial context token) that is invalidated by the TSS, then depending on the mechanism, the TSS may return a CDR encapsulation of a mechanism-specific GSS error token in this field. Not all GSS mechanisms produce error tokens in response to initial context token validation failures. [2] Add a new section after para 49 GSSUP Mechanism-Specific Error Token The GSSUP mechanism-specific error token contains a GSSUP fatal error code. typedef unsigned long ErrorCode; // GSSUP Mechanism-Specific Error Token struct ErrorToken { ErrorCode error_code; }; The following fatal error codes are defined by the GSSUP mechanism: // the context validator has chosen not to reveal // the GSSUP specific cause of the failure. const ErrorCode GSS_UP_S_G_UNSPECIFIED = 1; // the user identified in the username field of // the GSSUP::InitialContextToken is unknown to the target const ErrorCode GSS_UP_S_G_NOUSER = 2; // the password supplied in the GSSUP::InitialContextToken // was incorrect const ErrorCode GSS_UP_S_G_BAD_PASSWORD = 3; // the target_name supplied in the GSSUP::InitialContextToken // does not match a target_name in a mechanism definition of // the target const ErrorCode GSS_UP_S_G_BAD_TARGET = 4; A TSS is under no obligation to return a GSSUP error token; however, returning this token may facilitate the transition of the client-side GSS state machine through error processing. Accordingly, a TSS may indicate that SAS context validation failed in GSSUP client authentication by returning a GSSUP error token in a SAS ContextError message. In this case, a TSS that choses not to reveal specific information as to the cause of the failed GSSUP authentication shall return a status value of GSS_UP_S_G_UNSPECIFIED. [3] change table 16-9 in section 16.3.5 ContextError Values and Exceptions as follows (ignoring the first and last columns which will remain unchanged). Event Semantic Major Minor accept_context returned failure Invalid evidence 1 1 Invalid mechanism 2 1 Conflicting evidence 3 1 reference_context (N) returned false No Context 4 1 [4] Add the following IDL to section 16.9.2 Module GSSUP - Username/Password GSSAPI Token Formats typedef unsigned long ErrorCode; // the context validator has chosen not to reveal // the GSSUP specific cause of the failure. const ErrorCode GSS_UP_S_G_UNSPECIFIED = 1; // the user identified in the username field of // the GSSUP::InitialContextToken is unknown to the target const ErrorCode GSS_UP_S_G_NOUSER = 2; // the password supplied in the GSSUP::InitialContextToken // was incorrect const ErrorCode GSS_UP_S_G_BAD_PASSWORD = 3; // the target_name supplied in the GSSUP::InitialContextToken // does not match a target_name in a mechanism definition of // the target const ErrorCode GSS_UP_S_G_BAD_TARGET = 4; // GSSUP Mechanism-Specific Error Token struct ErrorToken { ErrorCode error_code; }; [%G!! While I was writing this some more traffic has occurred onm this thread. I still think the following is relevant, however; with the additional considertion that > Given things today, you are only > really allowed to look at a reply's service context in an > interceptor, and > not back up at the client implementation, which needs to do a retry. Perhaps this can be handled by modifying the gss client side state (by posting the error token to it). If the client can get a handle on its gssup context, it could subsequently look at its state. below, you will see why I am focusing on gss stuff. 7. I think we need to have more discussion on Issue 4277: New minor > codes for NO_PERMISSION Exception in CSIv2. In talking with David, I > think he is open > to deferring this issue pending the definition of a means to use an > exception to > convey failed authentication information to the client. This is an > acceptable > outcome (for me). I would also consider adding a GSSUP error token, and > rules > for its use to the specification. Here is a start at a proposed > reolution > (i'll flesh it out if we decide to go this route). > > [1] Add the definition of a GSS error token as a new section after para > 49 > > GSSUP Error Token > > When a TSS rejects a client authentication token containing a GSSUP > Initial Context Token, the TSS may include a GSSUP error token defined > by the type GSSUP::ErrorToken in Section 16.9.2. "Module GSSUP - > Username/Password GSSAPI token Formats," on page 16-59 (and repeated > below). > > // GSSUP::Error token > struct ErrorToken { > unsigned long major; > unsigned long minor; > }; > > The value assigned to the major field shall be selected from the > GSSAPI major status codes as defined in [IETF RFC 2743]. The > recommended value to be returned in the major field is GSS_S_FAILURE. > > The value returned in the minor field shall be one of the GSSUP > mechanism specific minor codes as defined in Section 16.9.2. > "Module GSSUP - Username/Password GSSAPI token Formats," on > page 16-59 (and repeated below). > > const unsigned long GSS_UP_S_G_FAILURE = GSS_S_FAILURE; > const unsigned long GSS_UP_S_G_NOUSER > const unsigned long GSS_UP_S_G_BAD_PASSWORD > const unsigned long GSS_UP_S_G_BAD_TARGET_NAME Date: Tue, 29 May 2001 17:43:58 -0400 From: Ron Monzillo X-Mailer: Mozilla 4.76 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: csiv2-ftf@omg.org Subject: Issue 4277: Proposed Resolution - New Minor Codes for NO_PERMISSION Exception in CSIv2 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=iso-8859-1 X-UIDL: 5jDe9n*?!!=K:!!@$4e9 base document: http://cgi.omg.org/pub/csiv2-ftf/csiv2-031401.pdf discussion: CSIv2 will not define a new exception minor code. The CSIv2 ContextError codes will be modified to support future inclusion of additional and optional error codes in the point-to-point, wire-level exchange between TSS and CSS. An error token and minor status codes will be defined for the GSSUP mechanism. Communicating error status from the CSS to the client app, will be defined in the context of APIs (that is, above the wire-level interoperability defined by the current specification). proposed resolution: [1] In para 21, change the bullet about error_token to the following