Subject: RE: Soliciting additional GSS/Kerberos interoperability results

From: "John Brezak" <[email-masked]>
Date: Fri, 11 May 2001 13:08:57 -0700

> -----Original Message-----
> From: Martin Rex [mailto:[email-masked]] 
> Sent: Friday, May 11, 2001 12:50 PM
> To: John Brezak
> Cc: [email-masked]
> Subject: Re: Soliciting additional GSS/Kerberos 
> interoperability results
> 
> 
> John Brezak wrote:
> > 
> > So in the case where a "client" is known by multiple names, one and 
> > only one name can be used for authentication to the server for the 
> > purposes of gss_canonicalize_name?
> > 
> > What if the admin of the database were handed all of the 
> known names 
> > for the front-end server in my example? How does the admin of the 
> > database get the correct name to put on the ACL?
> > 
> > Ideally each of the inputs to gss_canonicalize_name of 
> > [email-masked], [email-masked] and [email-masked] all end up 
> > with the same canonical name of "[email-masked]".
> > 
> > Also multi-homed hosts do not need to have the same names - 
> then can 
> > exist in different DNS zones and frequently do.
> 
> That's what I've been telling you all the time.
> 
> Traditional Kerberos hostbased service names are not really 
> compatible with GSS-API, and the approach that Microsoft has 
> taken to implement is clearly incompatible with GSS-API.

[JBrezak] My example has nothing to do with Kerberos referrals and
canonicalization. This is done with just multiple principal names as
would commonly be done in deploying an application on a multi-homed
server that would access another tier.

> 
> The flaw is not with GSS-API here.  GSS-API is really and 
> truely generic. However GSS-API doesn't promise that it can 
> cover every conceivable gssapi mechanisms' characteristics.  
> Some of the vendors of security and authentication toolkits 
> that approached finally added GSS-API to their mechanism 
> because it was required for interoperability with our 
> application.  However some had "features" that they weren't 
> able to carry through.
[JBrezak] It appears to me that the gss_canonicalize_name issue that
You brought up in the discussions about referrals is present in the
Kerberos GSSAPI implementations without referrals.

> 
> One example was a provider who offered user-specific configuration 
> of what "data protection" level was required when the user 
> communicated. Well, such a policy can not be enforced by a 
> gssapi mechanism onto a gssapi-based application.  In the 
> initial test protocols I noticed the same performance during 
> gss_wrap for message protection with and without 
> confidentiality and I asked them for the cause. They told me 
> about their policy settings in their user management and I laughed.
> 
> When our application is configured to use "integrity 
> protection", it uses gss_getmic() instead of gss_wrap(), so 
> their attempt to force confidentiality upon our application 
> failed.  You can configure our application to use 
> authentication only, then it will not do any message 
> protection call at all ...
> 
> 
> No, really: the approach how Microsoft implemented hostbased 
> service name is wrong because it is not possible to create a 
> GSS-API level abstraction for it.  Premature optimization.

[JBrezak] There is a problem with multiple host names as clients without
The introduction of Kerberos referrals and name-canonicalization.

> -Martin