HTTP: Peer ID Authentication

[MarcoPolo]

I've removed the peer id authentication scheme from the core spec of #508 for a couple reasons:

1. Auth is optional, the MVP may not include it.
2. This needs a bit more discussion since this is the first time we are doing a peer id auth scheme that relies on web PKI.
3. I've also changed the auth scheme to not use Noise because we didn't get as much code reuse as I was hoping for and I think it adds unnecessary complexity to this. It's now a more traditional challenge-response scheme similar to SSH auth and WebAuthn and the first version of this auth.

On 2, this is the first time we are doing a peer id auth scheme that relies on web PKI, and thus has slightly different security properties than what we've done in the past. Instead of tying a peer id to an underlying encrypted channel we are tying it to a domain name. If the client can't trust the domain name (e.g. has enterprise root CAs installed) then their connection can be mitmd. In practice I don't think this is a serious concern because:

• If a 3rd party has installed root CAs on a client, they probably also have root on the client. Thus they don't have to mitm, since they own the client.
• If web PKI breaks, it will be very obvious since many other things will break. Libp2p users will still be able to use a different authentication scheme.

[marten-seemann]

Can we use structured fields here, or is this one of the legacy fields where retrofitting sf was too difficult?

[MarcoPolo]

Yes, it's one of those legacy fields unfortunately. I did a version with sfv, but it was a bit too awkward.

[thomaseizinger]

Thanks Marco!

A few thoughts. I think we could split this into two flows: Libp2p-Challenge-Client and Libp2p-Challenge-Server and specify that they can be combined as necessary or used standalone.

[MarcoPolo]

I've update the spec with a couple changes:

• A single auth scheme with parameters to control who is authenticated. This allows for mutual, client only, and server only auth.
• Change the wording to allow for using a server-encrypted value as the challenge-client value.

[thomaseizinger]

Great work! I've made a few more comments but this looks sound from my end :)