Subject: Re: [keyassure] Question about Keyassure and IPsec

From: "Jeffrey A. Williams" <[email-masked]>
Date: Wed, 24 Nov 2010 09:46:56 -0600 (GMT-06:00)

All,

-----Original Message-----
>From: Paul Hoffman <[email-masked]>
>Sent: Nov 24, 2010 8:36 AM
>To: Yoav Nir <[email-masked]>
>Cc: "[email-masked]" <[email-masked]>
>Subject: Re: [keyassure] Question about Keyassure and IPsec
>
>At 2:30 PM +0200 11/24/10, Yoav Nir wrote:
>> > At 12:24 PM +0200 11/21/10, Yoav Nir wrote:
>>>> 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).
>
>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 if it can't?)
>
>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 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.
>
>That's why it is in the charter!

  Right!  Still the trust model is trustworthy if we still have CA's
that are also trust anchors AND have a history of their CERT DB being
breached as well as passing out CERTS under questionable circumstances.
Ergo, a new and better trust model is sorely needed.
>--Paul Hoffman, Director
>--VPN Consortium

>_________________________

Regards,
Jeffrey A. Williams
"Obedience of the law is the greatest freedom" -
   Abraham Lincoln

"Credit should go with the performance of duty and not with what is very
often the accident of glory" - Theodore Roosevelt

"If the probability be called P; the injury, L; and the burden, B; liability
depends upon whether B is less than L multiplied by
P: i.e., whether B is less than PL."
United States v. Carroll Towing  (159 F.2d 169 [2d Cir. 1947]
===============================================================
Updated 1/26/04
Network Eng. SR. Eng. Network data security
ABA member in good standing member ID 01257402 
E-Mail [email-masked]
Phone: 214-244-4827

______________________
>keyassure mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/keyassure

---

From: "Jeffrey A. Williams" <[email-masked]>
Date: Wed, 24 Nov 2010 11:36:40 -0600 (GMT-06:00)

Paul and all,

-----Original Message-----
>Sent: Nov 24, 2010 10:59 AM
>To: [email-masked]
>Cc: [email-masked]
>At 5:26 PM +0100 11/24/10, Martin Rex wrote:
>>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.
>
>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.

  Your right.  The problem is that the Trust model itself is not
trustworthy or at a minimum as it has been perverted as you say
and/or as there is stark COI's built within the 'Simple and well-
defined trust model' demonstrates the at least possibility that
as a useful mechinisim it is lacking accordingly.
>
>> > 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.
>
>Same here, but that doesn't mean that we should not do the work for the organizations where it would actually help.

  Completely agreed!  The most in need are those that seemingly 
wish to pervert it.  And that is a difficult task, but worth while.
>
>--Paul Hoffman, Director
>--VPN Consortium
>_______________________________________________
>keyassure mailing list
>[email-masked]

Regards,
Jeffrey A. Williams