Re: looking for draft volunteers

[Derek Atkins <warlord@MIT.EDU>]

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.

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.

> Since you're trying to be even-handed and discuss how each mechanism
> would work with certs *or* keys, I suggest you change the last
> sentence here to say "If raw keys are used, DNSSEC and LDAP over
> TLS or something similar is required. If certs are used, plain
> DNS and LDAP are fine."

As I just pointed out, it is not.  You still need LDAP over TLS with
either the SSL key or key fingerprint signed by DNSSec.

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

> -Steve

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord@MIT.EDU                        PGP key available