Subject: [keyassure] Question about Keyassure and IPsec

From: Yoav Nir <[email-masked]>
Date: Sun, 21 Nov 2010 12:24:03 +0200

Hi all

I was not in Beijing, but I did listen to the discussion at the KiDNS BoF.

Paul Hoffman talked about the various proposals, and mentioned that IPsec (or actually IKE) is not a good candidate, because hardly anyone uses certificates in IKE.

I don't agree with this. HTTPS uses PKI all the time, because the browser vendors pre-package browsers with large trust-anchor stores, so everyone can get a certificate from one of those blessed CAs.

Most IPsec products do not come with a trust-anchor store, so getting any certificate is not helpful in interoperating with anyone outside your small domain.

Having keys in DNS can change all that. If authentication is based on having the same key in the (secure) DNS as you show in the protocol, it makes a lot of sense to start authenticating with such public keys, because now you don't have to have both sides trust the same CA.

I have not yet thought through all the implications for PAD, ID Type, and the cert encoding fields, but I think it should be doable.

Am I missing something?

Yoav

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sun, 21 Nov 2010 10:25:04 -0500

Whether or not Paul was right on the facts, his reasoning was faulty.

The reason for producing a new protocol specification should always be to
make something work that currently does not or to make something that works
poorly work better.

If people were using IPSEC in its original design intent, that is to secure
Internet communications, there would be no need for a DNSSEC keying
approach. The problem would be solved already.

The reason that I think IPSEC needs to be considered here is that currently
IPSEC can only be used for network communications. Most IPSEC use is to
secure remote access to enterprise networks, an application for which it is
rather poorly designed. Tunneling over TLS works far better. It is also
deployed at a few enterprises as a VPN and there are a tiny number of
extranet deployments.

IPSEC is somewhat more successful than S/MIME, but neither has met the
original design goal of ubiquitous deployment. They have had some success in
some niches. The Internet has two billion users. A protocol can have
millions of users and still have underperformed.

If we are going to get to ubiquitous deployment of either, we need to have a
mechanism for ubiquitous keying based on Internet names. So DNSSEC based
approaches are of very real interest to me.

On Sun, Nov 21, 2010 at 5:24 AM, Yoav Nir <[email-masked]> wrote:

> Paul Hoffman talked about the various proposals, and mentioned that IPsec
> (or actually IKE) is not a good candidate, because hardly anyone uses
> certificates in IKE.
>
> I don't agree with this. HTTPS uses PKI all the time, because the browser
> vendors pre-package browsers with large trust-anchor stores, so everyone can
> get a certificate from one of those blessed CAs.
>
> Most IPsec products do not come with a trust-anchor store, so getting any
> certificate is not helpful in interoperating with anyone outside your small
> domain.
>
> Having keys in DNS can change all that. If authentication is based on
> having the same key in the (secure) DNS as you show in the protocol, it
> makes a lot of sense to start authenticating with such public keys, because
> now you don't have to have both sides trust the same CA.
>
> I have not yet thought through all the implications for PAD, ID Type, and
> the cert encoding fields, but I think it should be doable.
>
> Am I missing something?
>
> Yoav
>
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure
>

-- 
Website: http://hallambaker.com/

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 21 Nov 2010 15:13:30 -0800

>I have not yet thought through all the implications for PAD, ID Type, and the cert encoding fields, but I think it should be doable.

Yes. I believe I said (or I certainly hope I said) that IPsec is not a good *initial* or *early* candidate. After we get the semantics down for the more common candidates (Foo over TLS), then we can work on translating that to certificate authentication in IKE.

FWIW, I fully agree with the rest of your logic: having KIDNS functionality for IKE can only improve the low current usage of certficates for authentication.

--Paul Hoffman, Director
--VPN Consortium

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sun, 21 Nov 2010 18:36:52 -0500

PKIX has no semantics that are protocol specific.

If we think we need protocol specific semantics for key assure, isn't that a
sign that we are probably doing something wrong?

On Sun, Nov 21, 2010 at 6:13 PM, Paul Hoffman <[email-masked]> wrote:

> Yes. I believe I said (or I certainly hope I said) that IPsec is not a good
> *initial* or *early* candidate. After we get the semantics down for the more
> common candidates (Foo over TLS), then we can work on translating that to
> certificate authentication in IKE.
>
> FWIW, I fully agree with the rest of your logic: having KIDNS functionality
> for IKE can only improve the low current usage of certficates for
> authentication.
>
> --Paul Hoffman, Director
> --VPN Consortium

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 21 Nov 2010 15:48:36 -0800

>PKIX has no semantics that are protocol specific.

Other than the EKUs, that is correct.

>If we think we need protocol specific semantics for key assure, isn't that a sign that we are probably doing something wrong?

No, it is a sign that we are not trying to slap a one-size-fits-all set of semantics across dissimilar protocols. As Yoav said in his earlier message:

>I have not yet thought through all the implications for PAD, ID Type, and the cert encoding fields, but I think it should be doable.

If you *have* thought about all those and have proposed wording for them, that's great. Given the long, drawn-out history of the pki4ipsec WG, particularly with respect to the second point, having someone who is not part of the IPsec community solve our problems in a way that can be agreed to by that community would be wonderful.

--Paul Hoffman, Director
--VPN Consortium

---

From: Yoav Nir <[email-masked]>
Date: Wed, 24 Nov 2010 14:30:45 +0200

>> I have not yet thought through all the implications for PAD, ID Type, and the cert encoding fields, but I think it should be doable.

I am not in any way suggesting that this is complicated or will take a 20-page RFC to explain. I think the end result would be a 2-page document (plus boilerplate).

For example, we're looking in DNS, so it makes sense that ID Type will be FQDN. Do we also allow IP address and tell people to do a reverse lookup?  I hope not, but can't rule it out before it's discussed. Also, maybe RFC822 addresses for users?

Cert Encoding should be X509, or RAW RSA key, or a new encoding specifically created for this application. We would probably follow the example of TLS.

PAD entries would be of the DNS type, or maybe RFC822 for users. Authentication data would have to hold something new and different to tell the IKE daemon to query the DNS for keys (and what to do if it can't?)

OK, maybe 4 pages plus boilerplate.

Point is, we already have something that works for TLS (or at least HTTPS). There's plenty of things that are wrong with the trust model, but it's generally functional. IKE still doesn't have a universal infrastructure for establishing trust between different organizations. For whatever reason, administrators are not willing to trust Verisign for communications between organizations. Maybe keyassure can fix this.

Yoav

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 24 Nov 2010 06:36:49 -0800

>I am not in any way suggesting that this is complicated or will take a 20-page RFC to explain. I think the end result would be a 2-page document (plus boilerplate).

Hopefully true. And, if we determine that early enough, it could just get folded into the TLS document.

>For example, we're looking in DNS, so it makes sense that ID Type will be FQDN. Do we also allow IP address and tell people to do a reverse lookup?  I hope not, but can't rule it out before it's discussed.

Here, we disagree. Given that many/most common IPsec gateway-to-gateway deployments rely on IP addresses, this WG needs to think about how to deal with them for IPsec (or to punt and say "only works for domain names"). That will be an interesting discussion.

>Also, maybe RFC822 addresses for users?

I don't think this is needed for the use case being dealt with here: in IPsec, those are almost exclusively used for clients, not for gateways.

>Cert Encoding should be X509, or RAW RSA key, or a new encoding specifically created for this application. We would probably follow the example of TLS.

Hopefully true.

>PAD entries would be of the DNS type, or maybe RFC822 for users. Authentication data would have to hold something new and different to tell the IKE daemon to query the DNS for keys (and what to do i…

And here we go down the rabbit hole, maybe not too far.

>OK, maybe 4 pages plus boilerplate.

That would be OK too.

>Point is, we already have something that works for TLS (or at least HTTPS). There's plenty of things that are wrong with the trust model, but it's generally functional. IKE still doesn't have a univ…

That's why it is in the charter!

--Paul Hoffman, Director
--VPN Consortium

---

From: Martin Rex <[email-masked]>
Date: Wed, 24 Nov 2010 17:26:57 +0100 (MET)

Yoav Nir wrote:
> 
> Point is, we already have something that works for TLS (or at least HTTPS).
> There's plenty of things that are wrong with the trust model, it's
> generally functional.

TLS does not have a trust model.  It is at most a better-than-nothing
untrusted key "introduction" scheme.

>
> IKE still doesn't have a universal infrastructure
> for establishing trust between different organizations. For whatever
> reason, administrators are not willing to trust Verisign for
> communications between organizations. Maybe keyassure can fix this.

Trust between organization through keyassure?
I have strong doubts that this will work.

We're running the entire company in a seperate DNS universe,
and there is no possibility to obtain DNS records from the
internet inside the company.  Any communication to other organizations
is via application level gateways (which are located in the DMZ and
are the only components that can resolve internet DNS names.

For security and robustness, if a company has business- or mission-critical
internal IT systems, those should not have dependicies of the internet
connection being up and running, or particular services like DNS being
fully functional in order for company-internal communication to work.
Creating any such dependencies would be calling for disaster.

-Martin

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 24 Nov 2010 08:59:35 -0800

>untrusted key "introduction" scheme.

This is utter nonsense. There is a completely-defined trust model: the TLS server must authenticate itself with a PKIX certificate that chains to a trust anchor in the TLS client. The fact that the implementation of that trust model has been openly perverted by browser and OS vendors who stuff dozens or hundreds of trust anchors into the client does not negate the fact that TLS itself has a simple and well-defined trust model.

>I have strong doubts that this will work.

Same here, but that doesn't mean that we should not do the work for the organizations where it would actually help.

--Paul Hoffman, Director
--VPN Consortium

---

From: Yoav Nir <[email-masked]>
Date: Wed, 24 Nov 2010 22:02:59 +0200

On Nov 24, 2010, at 6:26 PM, Martin Rex wrote:

> untrusted key "introduction" scheme

Of course there's a trust model. Even in the context of the browser, I trust a (relatively) small group of CAs to never sign an EE unless that DN or alternate name correctly identifies the owner, and never to sign a CA certificate for anyone who would do otherwise. I might be a little too trusting.

> I have strong doubts that this will work.

Actually, I'm not sure what "trust" means in this context. Let's suppose for a moment that Check Point is a customer of SAP. Relating to this business relationship, some emails are exchanged. Occasionally, we might run into a problem, talk (through VoIP?) to a support engineer, and they might tell up to upload this or that file to your FTP server. All this data going back and forth might be sensitive (might contain customer data), so it would be good if it was encrypted.  We can do it the hard way, by configuring a mutually trusted CA, or by distributing shared secrets, or keyassure may give us an easier way.

I don't need to trust SAP. The only trust I need is to know that the gateway on the other side actually belongs to SAP, and that it's showing me the correct certificate in IKE. This is just the same as trusting that the address I get by typing "nslookup www.sap.com" actually belongs to SAP. Both can be enabled by DNSSEC. No?

---

From: Paul Wouters <[email-masked]>
Date: Wed, 24 Nov 2010 16:21:47 -0500 (EST)

> Point is, we already have something that works for TLS (or at least HTTPS). There's plenty of things that are wrong with the trust model, but it's generally functional. IKE still doesn't have a uni…

Look at RFC 4025, IPSECKEY. Other useful fields might be a "gateway"

Paul

---

From: Martin Rex <[email-masked]>
Date: Thu, 25 Nov 2010 02:14:35 +0100 (MET)

Paul Hoffman wrote:
> This is utter nonsense. There is a completely-defined trust model:
> the TLS server must authenticate itself with a PKIX certificate that
> chains to a trust anchor in the TLS client. The fact that the
> implementation of that trust model has been openly perverted by
> browser and OS vendors who stuff dozens or hundreds of trust anchors
> into the client does not negate the fact that TLS itself has a simple
> and well-defined trust model.

We're fighting about terminology here.

The technology TLS as described in rfc-2246,rfc-4346 and rfc-5246
does not have and does not define _any_ trust model.

The certificate path validation described in rfc-5280 and implemented
in the PKI software part of TLS stacks is an algorithm and not a trust model.

When folks refer to "PKI" when talking about TLS, they normally refer
to the set of 50+ self-signed rootCA certs distributed with every
WebBrowser, preconfigured as trust anchors.

That is no trust model, that is a pretty bold concept of faith. 
There is zero trust involved.  99.999% of the folks using that set
of self-signed rootCAs (plus a bunch of intermediate CA certs)
pre-configured as trusted by software distributors do _NOT_ know
and do _NOT_ care what organizations and what CAs are covered by
und under what terms CAs are issued.  There is actually no known
algorithm to reliably figure out which CAs are valid under that
configuration.

And think of Microsoft Windows 7, where you do not even know any longer
which rootCAs actually exist, because the Browser will automatically
and dynamically download missing rootCA certs.  Deleting such roots
manually doesn't get you anywhere, you will need to manually move
rootCAs that you don't trust over into "Untrusted Certs" to disable it.
But unless you tried to verify a chain to a particular root, it doesn't
exist under trusted roots yet.

The so-called "PKI" that is commonly used with TLS is definitely
not a "model of trust", for any sensible meaning of the word "trust".

> Same here, but that doesn't mean that we should not do the work
> for the organizations where it would actually help.

Fair enough.  I didn't mean to preclude this.
I just wanted to point out the the cross-organization
key introduction scheme that Browsers currently use during
server endpoint identification works across HTTP CONNECT proxies
even when organizations use seperate DNS universes throughout
their internal network.

-Martin