[krbwg-51] [grand.central.org #273] Re: submit comments on GSSAPI names

[John Brezak via RT]

<URL: http://new-grand.central.org//rt//Ticket/Display.html?id=273 >

[hartmans - Sun May 13 17:53:19 2001]:

> I think that we need to come up with a more clear cut explanation of
> the problem here.  I left the Wednesday meeting convinced that there
> were significant problems with GSSAPI name canonicalization regardless
> of whether we had multiple client names.  I wanted to reply to
> Martin's latest message but didn't really know how to explain the
> problem.
> 

Here is my scenario:

You have a front-end server that has 3 Kerberos principal names 
corresponding to 3 different DNS names.

1) a.foo.com (External name 1)
2) b.bar.com (External name 2)
3) c.baz.com (Internal name)

This front-end server accesses a database on another server. The admin 
needs to grant access to the front-end server's principal, but it is 
known as 3 different names (principals).

If you were to use the names "host@a.foo.com", "host@b.bar.com" 
and "host@c.baz.com" in gss_name_canonicalize, each is a different 
principal that would be placed on the ACL.

To get this to work right the admin must:

1) Know the name that the front-end server will use to authenticate to 
the database, or
2) Add all of the names that the front-end server is known as to the 
database ACL

(1) is not always possible. And (2) bloats the ACL.
(1) is a human form of name-canonicalization


[Other examples?]
The premise what that a server can already have multiple identities and 
that a server can use these identities to contact other servers. The 
issue is that the cname can be different for the same identity. The 
current approach with gss_name_canonicalize is based on the assumption 
that a cname==identity.




--