Search Mailing List Archives


Limit search to: Subject & Body Subject Author
Sort by: Reverse Sort
Limit to: All This Week Last Week This Month Last Month
Select Date Range     through    

[liberationtech] [ipv6hackers] opportunistic encryption in IPv6

Eugen Leitl eugen at leitl.org
Tue Jun 11 05:32:28 PDT 2013


----- Forwarded message from Jim Small <jim.small at cdw.com> -----

Date: Tue, 11 Jun 2013 01:02:54 +0000
From: Jim Small <jim.small at cdw.com>
To: IPv6 Hackers Mailing List <ipv6hackers at lists.si6networks.com>
Subject: Re: [ipv6hackers] opportunistic encryption in IPv6
Reply-To: IPv6 Hackers Mailing List <ipv6hackers at lists.si6networks.com>

Hi Owen,

> > The fundamental challenge for encryption is key distribution and
> management:
> > * How do I authenticate the intended recipient(s)?
> 
> This is a traditional challenge with many traditional solutions, all of which have
> tradeoffs, especially in M2M communications.
> 
> > * How do I distribute a key without letting anyone except the intended
> recipient(s) get it?
> 
> DH pretty well solves this, no?

Yes and no.  DH is a good answer, but IKE/IPsec still requires pre-shared keys or RSA key pairs to start with.  So I think there would be some value in a keying system that allows some kind of controlled federation without having to depend on pre-shared keys, PKI, or DNSSec.

> > * How do I manage the key to periodically change it while keeping it
> confidential?
> 
> Again, DH with PFS makes this a solved problem AFAIK.

True - but only after the initial hurdle of having a pre-shared key or RSA key pair.
 
> > * How do I notify the recipient if the key was compromised or is otherwise
> invalid?
> 
> This doesn't seem all that hard so long as a rekey instruction is built into the
> protocol. I believe that's already the case with IPSEC SAs, no?

Well - if we take DH, it's true once we've established a connection.  What about if we haven't?  Really the question I'm asking - if we have two independent parties, how do they validate each other without a trusted 3rd party?  Current options:
* pre-shared keys (but not scalable and keys tend to be weak to make it easy to share - keys are rarely if ever rotated)
* PKI - good but complex and as Moxie Marlinspike has demonstrated with others many flaws, abused by governments
* DNSSec - interesting one to watch but not really ready for wide spread use yet, needs greater adoption
* Manual/3rd party CA - possible if one party trusts the other or in a service provider scenario

Did I miss any viable wide spread options?  I know there are lots of theoretical ones but I'm talking about significantly deployed ones - say used by at least 1 million parties.

> Vs. this paper, I think that opportunistic IPSEC, ala Micr0$0ft's "direct-
> connect" or whatever they call it product is quite a bit more viable.
> It depends on AD as a PKI distribution mechanism for authentication.

DirectAccess is neat - but it's not exactly a break through.  DA is just a service based (aka UNIX/Linux daemon) IPv6 IPsec VPN with good provisioning and automatic IPv4 tunneling.  It's essentially a nice packaging of certificate-based IPsec leveraging Windows Active Directory provisioning.

There are some good ideas in this paper.  I just think there are some things missing - at least from my cursory reading of it.

--Jim


_______________________________________________
Ipv6hackers mailing list
Ipv6hackers at lists.si6networks.com
http://lists.si6networks.com/listinfo/ipv6hackers

----- End forwarded message -----
-- 
Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org
______________________________________________________________
ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org
AC894EC5: 38A5 5F46 A4FF 59B8 336B  47EE F46E 3489 AC89 4EC5



More information about the liberationtech mailing list