Re: Name canon/secure name service (Re: kink-09)

["KAMADA Ken'ichi" <kamada@xxxxxxxxxx>]

At Tue, 13 Sep 2005 04:09:44 -0400,
Ken Raeburn <raeburn@xxxxxxx> wrote:
> 
> > - For IP address resolution (binding hostname and selector),
> >   DNSSEC may not always be enough.
> >   e.g., If somehost.good.example.com resolves to 10.0.0.1 and
> >     anotherhost.bad.example.com also resolves to 10.0.0.1,
> >     which do you believe?
> 
> If you're doing host->address mapping, then DNSSEC for the domain  
> you're querying should be fine.  If you're doing address->host  
> mapping, then the mappings in {good,bad}.example.com don't matter,  
> what matters is DNSSEC protection for 1.0.0.10.in-addr.arpa.

host->address was in my mind.
Suppose an environment where the granularity of SA or principal
is hosts.
Two users are on sharedhost.example.com, which has 10.0.0.9.
They wanted to be protected by KINK and typed somehost.good.example.com
and anotherhost.bad.example.com respectively.
And if, both hostnames were resolved to 10.0.0.1...

Then, what the KINK daemon on the sharedhost.example.com should do?
Which key should be used to protect the SAs between 10.0.0.9 and
10.0.0.1?

I don't think this is a KINK/Kerberos specific matter, though.


> >> So there may be cases where kink/fqdn is not the real principal name
> >> used by the service.  What if kink/foo.dom.ain@REALM is an alias for
> >> host/FOO$@REALM, or a little trickier, host/FOO$@REALM2?
> >
> > You seems to have interpreted "obtained from some name services" as
> > "canonicalizing a name".  My intention was "getting an FQDN from an IP
> > address"; of course this isn't referring insecure DNS reverse
> > resolution.  There was no intention to forbid names that are not
> > beginning with "kink/".
> 
> Sorry if I was reading this incorrectly.

No, that was a problem of my writing, sorry.

-- 
KAMADA Ken'ichi <kamada@xxxxxxxxxx>