On Mon, Jun 08, 2020 at 11:52:04AM -0700, Michael Thomas wrote: > On 6/8/20 11:45 AM, Nico Williams wrote: > > The idea with RFCs 5387 and 5660 is that there is no need for an IPsec > > PKI for IPsec to be useful, and, indeed, that IPsec for authentication > > is tricky because -after all- it deals in... IP addresses, which are not > > useful for authentication. > > > > Instead, use IPsec for session crypto and use channel binding to bind > > IPsec channels to higher-layer protocols where authentication can and > > does happen. > > Sorry for being lazy and not skimming them, but does this imply sort of like > a naked public key kind of auth like ssh? Or maybe a DNS based one like > DKIM? Bare public keys, certified public keys -- either way. You just wouldn't bother with RFC 4301 style Peer Authentication Database (PAD, which also deals in authorization), and instead construct a guarantee of protection and SA peer continuity at the TCP (and even UDP!, for "connected" UDP sockets) layer. Then you'd let the app use channel binding to IPsec, thus binding authentication at the app layer to session crypto at the lowest end-to-end layer. That was the idea. A good idea, IMO, but it didn't happen. It was too late. > I mean, mitm is always a consideration so auth is always needed, right? See channel binding, RFC 5056. Nico --
