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

Re: DNS? was Key Management

At 04:55 PM 8/14/96 -0700, John Gilmore wrote:

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

As Ted points out, IPSEC packets are bound to SA's, and that's where
the actual authenticated identity is, not in ESP or AH packets.

While true that the ISAKMP Internet DOI as defined in the NSA draft
only uses ip addresses and FQDN's for identifiers, these are really
needed to identify SA endpoints (hosts and subnetworks), especially
for proxy netotiation. They are not necessarily the only means for
identifying the authenticated "entity" that will be using that SA.

Even if shortcomings such as this in the current draft remained,
identities can still be passed in other fields whose semantics have
yet to be pinned down (e.g., in certificates).

>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 don't follow. Are you advocating that DNSSEC be used even if the best
it can do is one-way authentication, since authentication in the other
direction is ... somebody else's problem?

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

You should qualify "sweet spot" by "in yesterday's internet". This message
originated at pool030.Max20.San-Francisco.CA.DYNIP.ALTER.NET and
comes to you via an encrypted tunnel to our POP server in Waltham, MA.
This is my "sweet spot", hard for DNSSEC to handle maybe, but not rocket
science.

DNSSEC is *not* a "shipping standard". If you want a shipping standard,
I'll point out that X.509 based schemes are currently deployed and 
becomming more widely so every day (e.g., VeriSign, Netscape, Microsoft,
Cybertrust, Sun, Nortel ...). They are used extensively in tls.  Why
exclude this shipping standard and include one that still experimental,
permits only one trust infrastructure, has no developed sense of quality
of authentication (read: who takes responsiblilty and liability for
for authenticated but bogus domain names), and for which there is no 
committed schedule for deployment?

Put another way, if you want good encryption, why use authentication that
doesn't solve enough of the problem?

-- Joe
= ========================================================= =
  Joe Tardo                           Voice: 415-843-0991 
  Raptor Systems, Inc.
  777 San Antonio Ave. Suite 92       Fax:   617-487-6755
  Palo Alto, CA. 94303
= ========================================================= =