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.

---

go-libp2p implementation: https://github.com/libp2p/go-libp2p/pull/2854

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

[MarcoPolo]

I'm considering making one more change to this spec: Allow the client to send a challenge in the initial request. This would allow the client to authenticate the server on the first round trip, and to send application data after only one round trip. It is similar in spirit to how the noise XX handshake works where the responder (server in our case) is authenticated after the first round trip.

I can't think of any compelling reason to not allow this, and many reasons to support it. The main reason being that in cases you know you need to authenticate, it removes a round trip.

Are there any compelling cases you can think of @Stebalien, @sukunrt, @aschmahmann?

---

Essentially supporting this flow:

sequenceDiagram
    C->>S: challenge-server
    S-->>C: challenge-client+server-sig [server authenticated]
    C->>S: client-sig + application data [client authenticated]
    S-->>C: resp

Alongside what is currently defined:

sequenceDiagram
    C->>S: initial request
    S-->>C: challenge-client
    C->>S: client-sig+challenge-server [client authenticated]
    S-->>C: server-sig [server authenticated]
    C->>S: application data
    S-->>C: resp

[Stebalien]

I agree, the client should send its challenge in the first message.