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

On Sep 13, 2005, at 01:56, KAMADA Ken'ichi 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.

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

> # BTW, how other protocols define their naming convention?
> # (e.g. "host/", "ftp/")

They do host/fqdn@REALM, but with referrals in place, it'll be okay  
if these names are just aliases.  None of the current protocols (that  
I'm aware of) for these service names do user-to-user, so there's no  
request for a TGT using a principal name that the KDC wouldn't get  
the chance to alter.

> To meet above comments, how about this for section 4.2.1:

That looks pretty good.

>>   - While canonicalization hasn't been published yet, the KINK draft
>> should allow for it.  In particular, when asking for a TGT for a
>> particular principal, after we've tried non-u2u authentication and
>> gotten referral data back and then been told that we have to do u2u,
>> the canonical name is the one we should be asking for.  I haven't
>> figured out good wording yet that allows for canonicalization without
>> mentioning it explicitly, but I don't think we want to wait for
>> referrals to get published first.
>>
>
> Does anyone have any idea on this?

Not yet. :-(  It may be enough to use the text you suggested in 4.2.1  
as the way of initially generating the principal name, and have  
something in the referrals draft describe how changes to the name by  
the KDC should be handled in cases like this...

Ken