[ipv6hackers] opportunistic encryption in IPv6

[Owen DeLong]

On Jun 10, 2013, at 18:02 , Jim Small <jim.small at cdw.com> wrote:

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

If you don't have pre-shared public keys through a trusted external channel, then you CANNOT trust the keys for authentication of the other side.

If you don't care about using the key for authentication, then IKE DH does (at least on most devices I've worked with) have an ability to use a randomly generated key.

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

Some systems I've worked with in the past use this method:

1.	Each system generates a random symmetric encryption key appropriate for
	the cipher to be used.

2.	The systems exchange public keys in the clear (if they don't already know
	them).

3.	Each system uses the remote public key and it's own private key to sign
	and encrypt the generated random key.

4.	Each system transmits the encrypted generated random key to the other.

5.	The key generated by A is used for the A->B SA. The key generated by B
	is used for the B->A SA.


>>> * 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:

I believe it has been mathematically proven that you cannot.

> * pre-shared keys (but not scalable and keys tend to be weak to make it easy to share - keys are rarely if ever rotated)

Any pre-shared key mechanism that does not involve a trusted third party that can validate both primary parties is inherently insecure.

> * PKI - good but complex and as Moxie Marlinspike has demonstrated with others many flaws, abused by governments

Depends on the PKI. A private PKI that is reliable is difficult to set up, but if done right does not necessarily suffer from all that many flaws. A WoT style PKI has a number of flaws. Certificates signed by "trusted CAs are obviously fraught with issues because there does not exist a CA with truly good practices."

> * DNSSec - interesting one to watch but not really ready for wide spread use yet, needs greater adoption

I don't see how DNSSec would actually help this issue. I can see a few ways you could add things to signed TXT records, but at that point, you're trusting the DNS Delegation signers as the third party in the definition above. Obviously this means that the security is only as good as the DNS delegators from the root down to the last delegation in the chain. (weakest link)

> * Manual/3rd party CA - possible if one party trusts the other or in a service provider scenario

And in the scenario I mentioned, I believe that AD performs this role within the domain, no?
Obviously Micr0$0ft is not my forte, so I won't pretend I know all the details, but I believe that's one of the objects inherent in the AD data structures for each machine/person, no?

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

I don't know how many are using the Micr0$0ft solution or not. I would expect you to have better insight into that than I.

It's a very strange world when I'm actually suggesting that Micr0$0ft's current solution is a model people should look at for future implementations.

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

But doesn't that amount to opportunistic encryption once it is implemented? As I understand it, any host pair within the AD domain will establish an IPv6 IPSEC SA bidirectionally and send all traffic for the other host through that channel (IPv4 and IPv6) rather than in clear text.

Doesn't that pretty well define "opportunistic encryption"? What am I missing.

I wasn't claiming it was a breakthrough or any sort of fantastic technology. Merely that it was a solution using existing tools that seemed to achieve the overall goals stated in the ID that was referenced.

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

Hence my suggestion that DA was running code that seemed to do everything the paper set out to do.

Owen