Issue 3577: No Standard Authentication Mechanism Specification for Kerberos (sec-rev) Source: Syracuse University (Dr. Polar Humenn, polar(at)adiron.com) Nature: Revision Severity: Significant Summary: There is no standard specification for the process of authenticating a Kerberos principal in the PrincipalAuthenticator::authenticate call. We need specifications of authentication method constants, and a specification for the combined authetication_method, security_name, authentication_data, and continuation_data parameters of the authenticate call. Resolution: No Change and close issue. Revised Text: Actions taken: April 25, 2000: received issue August 3, 2001: closed issue Discussion: It is generally considered that with the new CSIv2 protocol that working on this subject will not benefit the workablity of security service. It is better left to a new RFP. End of Annotations:===== X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Tue, 25 Apr 2000 09:18:37 -0400 (EDT) From: Polar Humenn To: issues@omg.org cc: secrev@omg.org Subject: No Standard Authentication Mechanism for Kerberos Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: 4nOe98H:e9fl7!!#lid9 Issue ####: No Standard Authentication Mechanism Specification for Kerberos Source: Adiron ( Polar Humenn polar@adiron.com ) Nature: Revision Severity: Significant Summary: There is no standard specification for the process of authenticating a Kerberos principal in the PrincipalAuthenticator::authenticate call. We need specifications of authentication method constants, and a specification for the combined authetication_method, security_name, authentication_data, and continuation_data parameters of the authenticate call. Resolution: Revised Text: Actions Taken: April 25, 2000: received issue ------------------------------------------------------------------- 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: Tue, 25 Apr 2000 09:50:28 -0400 (EDT) From: Polar Humenn To: secrev@omg.org Subject: Re: No Standard Authentication Mechanism Specification for Kerberos Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: G/W!!88@!!=f'e9J!F!! Issue ####: No Standard Authentication Mechanism Specification for Kerberos Discussion: Not sure if we should add all this to security, or have a special module such as module Kerberos: I would suggest a new type: CredentialsUsage: These enumerated types indicate the way in which the Credentials are to be used. enum CredentialsUsage { // GSS-API SecInitiateOnly, SecAcceptOnly, SecInitiateAndAccept }; The range of values are: SecInitiateOnly These Credentials may only be use to initiate secure associations. SecAcceptOnly These Credentials may only be used to accept (on the server side) secure associations SecInitiateAndAccept These Credentials may be used to initiate and accept a secure association. In anycase, I think that type should be in "Security" module, since it is a fundemental concept. Next we can build a Kerberos module with the following? A specification of authentication mechanisms that are for the "mechanism_type" parameter would be const MechanismType SecMT_KerberosV5 = "17"; Three authentication mechanisms for Kerberos shall exist (all prefixed with the OMG VMCID): const AuthenticationMethod SecKerberosSession = 0x4f4d0001; const AuthenticationMethod SecKerberosService = 0x4frd0002; const AuthenticationMethod SecKerberosPassword = 0x4f4d0003; The KerberosSession Authentication Method This authentication method should be used when the user wishes to use his or her previously established Kerberos Credentials (for example, via the "kinit" program) for secure CORBA associations. Since Kerberos Session Credentials are used, this authentication method can only be used to authenticate CORBA clients. I.e., processes authenticated with this authentication method cannot use the Credentials acquired to accept secure associations. auth_method: The auth_method argument must contain the SecKerberosSession value. security_name: The "security_name" argument of the authenticate call must be empty, (i.e. ""), or it must match the principal name found in the credentials cache, or a system BAD_PARAM exception will be raised. auth_data: The auth_data arugment is an any containing the following structure: struct KerberosSession { string config; string cache_name; }; The fields of this structure and their meanings are as follows. config The path of the Kerberos configuration specification. A prefix of "FILE:" designates that the specification is a file. An empty value ("") tells the Kerberos mechanism to use the default configuration file for the system (FILE:/etc/krb5_config on UNIX MIT Kerberos installations, for example). cache_name The path of the users Kerberos Credentials Cache. This credentials cache has already been initialized and is available by virtue of some cache initialization function, such as "kinit" in some Kerberos implementations. An empty value ("") tells the Kerberos mechanism to use the default Credentials cache for the system. The KerberosService Authentication Method This authentication method authenticates credentials for a principal by using a named principal key from a kerberos keytab file. auth_method: The "auth_method" argument to the authenticate call must contain the SecKerberosService value; security_name: The "security_name" argument to the authenticate call must contain the intended Kerberos principal. auth_data: The auth_data argument must contain a CORBA "any" with the following contents: struct KerberosService { string config; string keytab; }; The values of the fields are: config The path of the Kerberos configuration specification. A prefix of "FILE:" designates that the specification is a file. An empty value ("") tells the Kerberos mechanism to use the default configuration file for the system (i.e. FILE:/etc/krb5_config on UNIX MIT Kerberos installations). keytab The path of the Kerberos "keytab" file containing the Kerberos key for the principal named in the "security_name" argument. A prefix of "FILE:" designates that the keytab is a file. An empty value ("") signifies the default for the system, (i.e. FILE:/etc/krb5.keytab on UNIX MIT Kerberos installations). The Kerberos Password Authentication Method This authentication method handles the case when the principal needs to be authenticated by virtue of the principal's password. auth_method: The auth_method argument must contain the SecKerberosPassword value. security_name: The "security_name" argument must contain the intended Kerberos principal name. auth_data: The auth_data argument is a CORBA "any" containing the following structure: struct KerberosPassword { string config; string password; string lifetime; boolean proxiable; boolean forwardable; string renewablelife; CredentialsUsage usage; }; The fields of this structure are: config The path of the Kerberos configuration specification. A prefix of "FILE:" designates that the specification is a file. An empty value ("") tells the Kerberos mechanism to use the default configuration file for the system (i.e. FILE:/etc/krb5_config on UNIX MIT Kerberos installations). password This field specifies the kerberos password to be used for authentication. This field must have a non-empty value. lifetime This field specifies the lifetime of the Credentials. Its value is the formation of an integer immediately suffixed with one of "m", "s", "h", or "d". The suffixes each specify seconds, minutes, hours, or days, respectively. An empty value ("") tells the Kerberos mechanism to use the system default. proxiable This field specifies whether the Credentials created may be forwarded to the target on an invocation for the target to create authentication tickets on your behalf. forwardable This field specifies whether the Credentials created may be forwarded to the target on an invocation for the target to create authentication tickets on your behalf, and further propigate them to other targets. renewable_life This field specifies the lifetime of a renewable ticket. It has the same format as the lifetime field. usage This field designates the way in which the Credentials will be used. ------------------------------------------------------------------- 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 From: "Dushin, Fred" To: secrev@omg.org Subject: RE: No Standard Authentication Mechanism Specification for Kerber os Date: Tue, 25 Apr 2000 10:53:26 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="ISO-8859-1" X-UIDL: 2fkd9'Gbd98XT!!9=9e9 Folks, FYI, I'm on the secrev mailinglist but not (currently) a voting member. First, a minor point: could we label this issue "No standard authentication method specification for Kerberos"? Auth methods are relative to mechanisms, right? The mechanisms are specified (well enough, for now...). It's the Kerberos-specific authentication methods we are after here. > CredentialsUsage: > > These enumerated types indicate the way in which the > Credentials are to be > used. > > enum CredentialsUsage { // GSS-API > SecInitiateOnly, > SecAcceptOnly, > SecInitiateAndAccept > }; > > The range of values are: > > SecInitiateOnly These Credentials may only be use to > initiate secure > associations. > SecAcceptOnly These Credentials may only be used to > accept (on the > server side) secure associations > SecInitiateAndAccept These Credentials may be used to > initiate and accept > a secure association. Good idea. Only one concern. Believe it or not, some less sophisticated security services don't even have the notion of server-side credentials (and some even store them in a remote object, if you can believe that); on this view, credentials are just used for invocations. How such security services deal with accepting options in credentials, is, well, another matter (can you say "punt"?). So I'm not sure how useful a CredsUsage concept is for such "vendors". Still, it's the Right Way (r). > In anycase, I think that type should be in "Security" module, > since it is > a fundemental concept. Yes! Good luck convincing everyone else, though. On the KerberosSession struct: > cache_name > The path of the users Kerberos Credentials Cache. This > credentials > cache has already been initialized and is available > by virtue of > some cache initialization function, such as "kinit" in some > Kerberos implementations. > > An empty value ("") tells the Kerberos mechanism to use the > default Credentials cache for the system. This is fine, as long as it is not too MIT Kerberos-centric. I'm sure Windows 2000 has a different way of storing session credentials (xor'd with SWODNIW and in the registry, per chance? :), so as long as we have a way of specifying a resource that designates the cache, that's fine. Hopefully, we do not need to resort to another CORBA::any... On the KerberosService struct: > keytab The path of the Kerberos "keytab" file containing the Kerberos > key for the principal named in the "security_name" argument. > A prefix of "FILE:" designates that the keytab is a file. > An empty value ("") signifies the default for the > system, (i.e. > FILE:/etc/krb5.keytab on UNIX MIT Kerberos installations). > Again, is a keytab file part of the Kerberos spec, or can we come up with an implementation-neutral way of locating keys for kerberized services? I guess the same could be said for the kerberos config file: are these standard kerberos features? What is Gradient's take on this, for example? Fred Dushin Hitachi Computer Products fadushin@hi.com X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Tue, 25 Apr 2000 11:46:21 -0400 (EDT) From: Polar Humenn To: "Dushin, Fred" cc: secrev@omg.org Subject: RE: No Standard Authentication Mechanism Specification for Kerber os In-Reply-To: <79A16E359785D311A36C0090279369B41DAB45@mars.hi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: S7Pd98! Folks, > > FYI, I'm on the secrev mailinglist but not (currently) a voting > member. > > First, a minor point: could we label this issue "No standard > authentication > method > specification for Kerberos"? Auth methods are relative to > mechanisms, > right? The mechanisms are specified (well enough, for now...). > It's the > Kerberos-specific authentication methods we are after here. > > > CredentialsUsage: > > > > These enumerated types indicate the way in which the > > Credentials are to be > > used. > > > > enum CredentialsUsage { // GSS-API > > SecInitiateOnly, > > SecAcceptOnly, > > SecInitiateAndAccept > > }; > > > > The range of values are: > > > > SecInitiateOnly These Credentials may only be use to > > initiate secure > > associations. > > SecAcceptOnly These Credentials may only be used to > > accept (on the > > server side) secure associations > > SecInitiateAndAccept These Credentials may be used to > > initiate and accept > > a secure association. > > Good idea. Only one concern. Believe it or not, some less > sophisticated > security services don't even have the notion of server-side > credentials (and > some even store them in a remote object, if you can believe that); > on this > view, credentials are just used for invocations. How such security > services > deal with accepting options in credentials, is, well, another matter > (can > you say "punt"?). So I'm not sure how useful a CredsUsage concept > is for > such "vendors". Still, it's the Right Way (r). > > > In anycase, I think that type should be in "Security" module, > > since it is > > a fundemental concept. > > Yes! Good luck convincing everyone else, though. > > On the KerberosSession struct: > > > cache_name > > The path of the users Kerberos Credentials Cache. This > > credentials > > cache has already been initialized and is available > > by virtue of > > some cache initialization function, such as "kinit" in > some > > Kerberos implementations. > > > > An empty value ("") tells the Kerberos mechanism to use > the > > default Credentials cache for the system. > > This is fine, as long as it is not too MIT Kerberos-centric. I'm > sure > Windows 2000 has a different way of storing session credentials > (xor'd with > SWODNIW and in the registry, per chance? :), so as long as we have a > way of > specifying a resource that designates the cache, that's fine. > Hopefully, we > do not need to resort to another CORBA::any... > > On the KerberosService struct: > > > keytab The path of the Kerberos "keytab" file containing the > Kerberos > > key for the principal named in the "security_name" > argument. > > A prefix of "FILE:" designates that the keytab is a file. > > An empty value ("") signifies the default for the > > system, (i.e. > > FILE:/etc/krb5.keytab on UNIX MIT Kerberos > installations). > > > > Again, is a keytab file part of the Kerberos spec, or can we come up > with an > implementation-neutral way of locating keys for kerberized services? > > I guess the same could be said for the kerberos config file: are > these > standard kerberos features? What is Gradient's take on this, for > example? > > Fred Dushin > Hitachi Computer Products > fadushin@hi.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