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

[Derek Atkins <derek@xxxxxxxxx>]

So have we come to consensus on how to handle these issues?
If there was a misunderstanding from the reading of the text,
then we should add some additional text to help ensure that
the same misunderstanding does not occur again.

We should rev the draft one last time with these clarifications
and then I'll pass the draft up to the IESG.

-derek

"KAMADA Ken'ichi" <kamada@xxxxxxxxxx> writes:

> 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>
>
>
>

-- 
       Derek Atkins                 617-623-3745
       derek@xxxxxxxxx             www.ihtfp.com
       Computer and Internet Security Consultant