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

Beyond IPSECKEY RE: [IPSECKEY] misc



Abstract:

The point of this note is to put forward some ideas for where I see IPSECKEY
fitting into the overall scheme for widespread PKI deployment. I believe
that what it is a first step on the way to something that is considerably
more comprehensive, a generalized mechanism for advertising security
policies through the DNS.


> P. Hallam-Baker raised interesting points in his Dec.16 mail about DNS
> linked PKI. These sets some of the limits of what services linked to
> security we can expect DNS to provide. Publishing ipseckey 
> rr, even with
> the use of DNSSEC will never end to favorize a kind of a 
> world wide PKI
> scheme. These rr are interesting, though, even if key 
> validation is not
> possible or if an offline scheme is needed.

I believe that there is a need for two infrastructures, a naming
infrastructure and a PKI infrastructure and that the PKI infrastructure
should be linked to the naming infrastructure.

In other words don't put *everything* into the DNS, management is going to
be impossible. DNS is a management infrrastructure for domains and machines
and NOT end users.

But at the same time do not create a PKI that attempts to create an entirely
parallel naming infrastructure as X.509 does. The primary key in a VeriSign
SSL certificate is neither the Subject name or the issuer name, it is the
DNS domain name. In other words the true structure is:

DNS Name: AMAZON.COM
	Registered Office: 1 Book Warehouse Road, Seattle WA, USA
	Issuer: VeriSign
	Authentication Process: VTN Class 3.
	notBefore.. 
	yadda yadda yadda...

Same for an end entity certificate, the primary key is JeffB@amazon.com, his
offline identity is actually irrelevant.

Identity is a sufficient but not a necessary condition in most Internet
security applications. To control risk it is not necessary to have identity
unless I already have some relationship to a party and want to establish
Correspondence between a network identity and an established offline
identity. Control of risk in certain applications MAY require that I know
that I can bind a network identity to an offline identity for the purpose of
serving legal process. 

So lets get rid of the unhelpful and ambiguous concept of identity and
instead consider the following issues:

	Correspondence of Network Address to Other Name
	Registered Office - Ability to serve Writ
	Authenticated Network Address

The criteria that one needs to achieve varies considerably BY APPLICATION.
Most E-Commerce applications require only the Registered Office level, some
require the Correspondence level. For example the AuthentiCode deployment is
intended to allow software downloads to be obtained with an equivalent level
of security to obtaining software on CDROM in a shrinkwrap  box. The
requirement here is the registered office level of security.

Thought for the day - what proportion of spam senders would find giving a
registered office at which process could be served an impossible constraint
on their business?


OK so lets look at IPSECKEY, it is providing a key bound to a machine DNS
address. The degree of operational security is not very high, the
administrative process of installing the key does not provide for
accountability and can thus be subverted with little effort, there is no
safeguard if the machine the key is on becomes owned by an attacker.

However the level of security required for the application in question is
not high. All that is being asked for is a mechanism to turn on encryption.
It is possible for a very sophisticated attacker to subvert the process with
a man in the middle attack, however it is not possible to do this
transparently. That is a major improvement in confidentiality. Knowing that
I am being watched is in many cases more useful than keeping communications
confidential.


The primary benefit for IPSEC as far as I am concerned is the knowledge that
the other side has a security capability. The actual key distribution is of
secondary importance AFAIC, unauthenticated keys can be exchanged in band.
Providing the key or a hash of the key in the DNS makes the attacker's job
measurably harder, an additional platform must be compromised to compromise
the system. it is a similar level of security to publishing hashes in the
New York Times, it is a hard mechanism to subvert but not impossible.

Security is risk control, not risk elimination. This type of mechanism
raises the bar for attack significantly. If the application requires a
higher degree of security it can be achieved by performing additional
validation on the key by leveraging a PKI.


So lets take the DNS security policy concept further. IPSEC key provides one
mechanism for securing one protocol. It has the advantages of simplicity but
will not serve for many important security questions, for example:

    * An Email does not have a digital signature, is it forged?
    * An SMTP response indicates that a server does not support TLS, is this
true?

What is needed here is a general and flexible mechanism for advertising
security policy. i am currently working with some others on a draft called
Security Policy Advertisement Mechanism that defines a generalized IPSECKEY
type mechanism that allows end points to specify their security policy via
the DNS.

The basic model I take here is that the ability to configure the DNS records
for a DNS zone constitutes ownership of a DNS name and that the owner of a
DNS name has the right to establish security policies for all protocol uses
in connection with that domain.

So if I own hallambaker.com I have the right to say that all email from that
zone MUST be signed under S/MIME using a key that is delegated from either a
cert with hash X or a cert with hash Y (i.e. allowing for rollover).


Clearly it is not a sensible idea to store end entity keys or certs in the
DNS. The DNS is a per machine configuration mechanism and not a per user
mechanism. The TTLs and whole operational setup of DNS are out of sync with
those of managing end users. DNS is not designed as a PKI 

You can run an XKMS service on the same machine as a DNS server though.


The Security Policy Advertisement Mechanism is similar to the existing SRV
record approach in XKMS but takes the idea much further.

The SRV approach is to access the DNS and get the director to the XKMS
service. This has advantages when you are dealing with end users and in
particular when you are do encryption in an asynchronous messaging context. 

SRV is less efficient when you are receiving messages and want to test for a
downgrade attack on integrity. You don't know anything from the SRV record,
you have to resolve it before you can even find out if there is a key and at
the moment there is no policy associated with the key - it is just a key
that you MAY use, nothing is said about whether the keyholder MUST use it.

For example we might have a set of SPAM records that state that email from
hallambaker.com

   ALWAYS comes from address X, Y or Z
   OPTIONAL uses STARTTLS, cert root has SHA1 P
   OPTIONAL uses S/MIME, cert root has SHA1 Q
   OPTIONAL uses PGP, validate against XKMS R
   NEVER uses NULL Authentication


		Phill




-
This is the IPSECKEY@sandelman.ca list.
Email to ipseckey-request@sandelman.ca to be removed.