[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



Thank you very much for the review.

At Wed, 7 Sep 2005 15:08:29 -0400,
Ken Raeburn <raeburn@xxxxxxx> wrote:
> 
> Name canonicalization:
> 
> Section 4.2.1 says that the principal name that SHOULD be used for  
> the service is kink/fqdn@REALM, with fqdn "obtained from some name  
> services".  (It also says, "but see the Security Considerations  
> section"; that section does touch on the binding between principal  
> names and SA selectors, but it's not at all clear that that's what  
> this is referring to.)
> 
> An insecure name service must not be consulted in determining the  
> FQDN; otherwise, a spoofed DNS (or whatever) reply could tell the  
> client, "that's an alias for server-1.black-hats.con", and the client  
> would happily authenticate to that server.

Yes, "but see the Security Considerations section" is referring to
the first paragraph of the section.

- An insecure name service must not be consulted, without doubt.
- For name canonicalization (CNAME resolution), DNSSEC should be "secure".
- 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?


> In the Kerberos working group, there's a draft in the works to  
> address this problem, draft-ietf-krb-wg-kerberos-referrals-06.txt.   
> However, there may be some less than wonderful interactions.  For  
> example, you make a request for a service name which may be an alias,  
> and (if it's an alias in the realm of the KDC you're talking to, and  
> if you requested canonicalization) you get back a ticket either for  
> the correct service principal name, or (if the canonical name is not  
> in the same realm as the alias) for a remote-realm TGS.  But the  
> current draft is a bit fuzzy in the user-to-user case.
> 
>     The AP-REQ MUST request mutual authentication.  The principal name
>     that the KINK service SHOULD use is "kink/fqdn@REALM", where "kink"
>     is for the KINK IPsec service, "fqdn" is the fully qualified domain
>     name of the service host, and "REALM" is the Kerberos realm of the
>     service.  A principal name is case sensitive, and "fqdn" part  
> MUST be
>     lower case as described in [KERBEROS].  This document does not
>     specify how to generate the principal name; complete principal names
>     are stored in local policy, hostnames are obtained from some name
>     services, etc; but see the Security Considerations section.
> 
> We've been considering some cases where aliases are entered in one  
> realm, pointing to a principal in another realm, when there is no  
> overlap between the administration of the two realms.  The type of  
> example I keep bringing up is a DNS CNAME record added for  
> convenience at one site, e.g., "gftp" in the local domain points to  
> ftp.gnu.org, but requires less typing.  If you want to make Kerberos- 
> authenticated connections to that host, either you need to  
> canonicalize the hostname through secure DNS, which we can't just  
> assume will happen, or the KDC needs to be able to tell the client  
> the real realm and principal name to authenticate to.  A key point in  
> this example is that the software on ftp.gnu.org has *no knowledge*  
> of the other name assigned by some random site.
> 
> 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/".

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



> Non-PKINIT cases:
> 
> Can we describe a use case or two that doesn't involve PKINIT but  
> does do user-to-user authentication?  They don't need to go into the  
> document, but if we want to support them, we should make sure they  
> don't have some ramifications we haven't allowed for.
> 
> I've come up with some possibilities:
> 
> 1) User walks up to a public workstation (hardware reasonably  
> protected, software completely hackable) and boots it off a CD  
> (bypassing the workstation's possibly-hacked software) which contains  
> a NetBSD Live! (or Knoppix or whatever) image, including Kerberos and  
> IPsec software.  No secret key data here, but CA info and server  
> names for the {company, university, secret government organization}  
> are included in this customized version.  The user types in  
> "nikita@xxxxxxxxxxxx" and a password, Kerberos tickets are acquired,  
> and an IPsec session is established to the user's file/mail/ldap/ 
> whatever server.
> 
> 2) Some kind of multiuser variant of case #1, with different SAs for  
> different users on the same client host, simultaneously.  Gets into  
> some of the channel binding stuff Nico Williams has been working on.   
> Probably not something we need to dig into much, as long as KINK  
> allows for multiple SAs.
> 
> 3) Imagine two instances of case #2 (or #1), where users on the two  
> systems want to communicate peer-to-peer, not via some central  
> server.  Now neither one has a kink/foo principal available.  In this  
> case, I think it's okay to assume that at least one of the users will  
> have to type in the name of the other, or at least be prompted to  
> select "accept".  (Section 4.2.4 supports this.)  Probably on both  
> sides.
> 
> 4) Case #3, but to make it worse, put name canonicalization in the  
> picture, and the two users have exchanged NT-ENTERPRISE principal  
> names alice@xxxxxx and bob@xxxxxx, rather than  
> Alice_Jones@xxxxxxxxxxxx and Robert_Smith@WORLD-DOMINATION-STRATEGIC- 
> PLANNING.MS.COM, because the short names are what they log in with,  
> use for email, etc.  Can they establish an IPsec session between  
> them, securely?  Actually, this probably belongs on the krb-wg list;  
> I'll bring it up there.
> 
> 
> I *think* the upshot of these is:
>   - SHOULD for using "kink/fqdn" may be too strong.  It's the name  
> that should be started with (but canonicalization may change it) in  
> the normal host-to-host case.  When users are involved (or maybe  
> services acting as users or clients), the users' principals would be  
> the logical choice.

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

   This document does not specify how to generate the principal name.
   That is, complete principal names may be stored in local policy,
   FQDNs may be converted to principal names, IP addresses may be
   converted to principal names by secure name services, etc; but see
   the first paragraph of the Security Considerations section.

   If the peer's principal name for the KINK service is generated from
   an FQDN, the principal name, which the initiator starts from, will
   be "kink/fqdn@REALM"; where "kink" is a literal string for the KINK
   IPsec service, "fqdn" is the fully qualified domain name of the
   service host, and "REALM" is the Kerberos realm of the service.  A
   principal name is case sensitive, and "fqdn" part MUST be lower
   case as described in [KERBEROS].

And the first paragraph of Security Consideration:

   The principal names are the identities of the KINK services, but
   the traffic protected by SAs are identified by DOI specific
   selectors (IP addresses, port numbers, etc).  This may lead to a
   breakaway of SA-protected data from authentication.  For example,
   if two different host claims that they have the same IP address, it
   may be impossible to predict which principal's key protect the
   data.  Thus, an implementation must take care for the binding
   between principal names and the SA selectors.


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


Thanks,
-- 
KAMADA Ken'ichi <kamada@xxxxxxxxxx>