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] [cryptography] [ipv6hackers] opportunistic encryption in IPv6

Nico Williams nico at cryptonector.com
Wed Jun 12 16:25:47 PDT 2013


On Tue, Jun 11, 2013 at 8:45 AM, Eugen Leitl <eugen at leitl.org> wrote:
> From: Jim Small <jim.small at cdw.com>
> To: IPv6 Hackers Mailing List <ipv6hackers at lists.si6networks.com>
>
>> "Better-Than-Nothing Security: An Unauthenticated Mode of IPsec"
>> http://tools.ietf.org/html/rfc5386
>
> Thanks - I was not aware of that.  So BTNS is interesting - but it doesn't solve the above problems.  Per the RFC, BTNS doesn't authenticate peers.  It would seem that secure key distribution (maintain confidentiality, integrity, and authentication) remains a vexing problem.

You also need RFC5660, "IPsec Channels".  I.e., a guarantee of
continuity of peer IDs for the lifetime of a "connection".

*Then* you can use channel binding to whatever application-layer
authentication mechanism you have,

*or* you can use TOFU and insist on the same key/CA/whatever next time
you talk to the same peer.

There have been many proposed ways of doing roughly the same thing.
To my knowledge not one has succeeded wildly.  RFC5660 has not been
implemented.  Lacking IPsec channels one needs something like CGA to
ensure peer key/ID continuity, as otherwise IPsec only authenticates
individual packets (and their senders), not *packet flows*, which
wouldn't be a problem if IP addresses weren't assigned dynamically.

Nico
--



More information about the liberationtech mailing list