To:
Derek Atkins <warlord@MIT.EDU>
CC:
Simon Josefsson <simon+keydist@josefsson.org>, Edward Lewis <lewis@tislabs.com>, keydist@cafax.se
From:
Steve Hanna <steve.hanna@sun.com>
Date:
Mon, 14 Jan 2002 15:27:12 -0500
Sender:
owner-keydist@cafax.se
Subject:
Re: looking for draft volunteers
Derek Atkins wrote: > Steve Hanna <steve.hanna@sun.com> writes: > > Good summary. A few comments on your text: > > > > > "Store referral in DNS, retrieve keys via other protocols" > > > > > > This is possible now using, e.g., SRV and LDAP. > > > > > > Requires LDAP over TLS or similar. > > > > Plain LDAP is fine if you're retrieving certs instead of raw keys. > > When using certs, the application's trust in the key comes from > > the fact that the cert was signed by a trusted party, not that it > > came from a particular repository. > > That's not true... If you ask for cert X and Mallet hands you cert X' > (signed by CA'), you have no way to know that you've been attacked and > given X' and not X. If, however, there is a clear line of signatures > from the name you asked for to the data you receive, then you know > that you received the right pile-o-bits. Let's get concrete. When retrieving certs over LDAP, you don't ask for a specific cert. You search for the proper directory entry (one with a mail attribute of steve.hanna@sun.com, for instance) and then retrieve the certs stored in that entry (in the userCertificate attribute). You don't trust any of those certificates unless you can establish and validate a path to one of your trust anchors. > In other words, the referral (to LDAP) must be signed and must give > you a signed hint of the key used to authenticate LDAP. Otherwise you > are still subject to this spoofing attack. Yes, you are subject to > this even with signed certificates -- I only need to find one of your > list of hundreds of CAs that will grant be a certificate and I can > mount this attack. > > Note that the reason this attack can happen is because all your > trusted CAs are authoritative for all names, so there is no what to > know that joe-random-CA (which is in your list of trusted CAs) > shouldn't be signing a certificate for Sun.COM. If Sun.COM wanted to > get a cert from joe-random-CA, they could, but there is no way to know > whether the joe-random-CA Sun.COM cert or the mighty-big-CA Sun.COM > cert is the "right" one. If you're running even a moderately secure PKI, you will not have hundreds of trust anchors. You'll have one trust anchor. That trust anchor will include name constraints in the certificates that it issues (saying "sun.com is only trusted to certify names in the sun.com domain", for instance). So a nasty person who wanted to trick you into accepting a false certificate for steve.hanna@sun.com would need to compromise either your single trust anchor or the sun.com CA. No worse than the task with DNSSEC: compromise your DNSSEC trusted key or sun.com's DNSSEC key. To summarize: If your PKI is any good, you don't need DNSSEC or LDAP over TLS to securely establish a key. If your PKI isn't any good, why bother having one? > > > Requirements on a Solution > > > > > > "MUST be possible to locate application keys given only IP address > > > or hostname" > > > > You also need *some* sort of trusted key (DNS or PKI). Otherwise, > > you're wide open for impersonation. Note that the first use case for > > SSH above seems to suffer from this problem. You only brought one > > key, the SSH host key for beagle. Now that machine is down. You're > > SOL unless you also have another trusted key. > > I think the assumption is 'some DNSSec key'... If there's a built-in assumption here, it should be made explicit. The use case should say "Fortunately, I have the key of the DNS root or a PKI trust anchor." The requirements should say "MUST be possible to locate application keys given only IP address or hostname *and* a trusted key (DNS or PKI)" Simon, was there a built-in assumption there? -Steve