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

Re: DNS? was Key Management



One of the problems that has hung up all sorts of crypto protocols is
getting confused about what problem you are trying to solve.  Like PEM,
let's not define all the packet formats and then spend three years
arguing over who authenticates what to who.

> Then the minimal basis for authentication is the association of a public key 
> with an e-mail address, a hostname, or an IP address that can be used to 
> support access control decisions.

DNSSEC supports associating a public key (or several public keys) with
each of the above.  IP addresses are encoded into the domain-name
space in the usual 1.2.174.140.in-addr.arpa way.  Email addresses
are encoded as e.g. gnu.toad.com by setting a bit in the KEY record
which indicates that the first component refers to a user rather than
to a host or subdomain.

However, IPSEC only authenticates to IP addresses.  There's no further
identification in the IPSEC packets.  Even if usernames or hostnames
are used in generating keys, there's no well-defined way to get that
information back to an application; all it has is getpeername().

> Is it sufficient to say that authentication is based on an e-mail address 
> (personal), hostname, OR an IP address (network entrypoint)?  Then the 
> application/service which is accepting the authenticated identity must 
> determine if this binding is sufficient authentication for the particular 
> activity/access/application?

I believe you meant "sufficient authorization".

IPSEC and DNSEEC do not solve this second problem (applications
deciding whether to accept authenticated identities).  That's an
access control question (is he allowed?) as opposed to an identity
question (who is he?).

IPSEC doesn't solve the global "single signon" problem; don't expect
it to.

I may supply information to authenticate myself to other parts of the
network, and a firewall somewhere may use this information to decide
whether to let my packets in the door.  But IPSEC running at FOO.COM
should be willing to build an encrypted tunnel to my laptop, whether
or not my laptop later ends up authenticated as "the laptop that
FOO.COM's system administrator borrowed while he was at a conference".

I also think we should focus on shipping standards that hit the sweet
spot (most gain for least pain), which includes securing communications
among all the hosts with fixed IP addresses.  If dynamically assigned
IP addresses are easy, throw 'em in; if not, leave them for the next
round of standards.  Since everyone seems to think they're hard,
let's leave them for next time, and secure the large fraction of
the Internet that we know how to do now.

	John Gilmore



Follow-Ups: