Remote Identity attestation

[abergs]

📔 Objective

This PR adds Remote Identity Attestation.

Today, when an remote client (agent) connects to your client, the protocol gives you no way to know which platform it's running on. It's Trust-on-first-use, without any confirmed identity.

This PR adds a draft spec for an optional attestation extension: the agent's platform signs a short-lived token during pairing, vouching for the clients's identity, and the client can show additional UI or enforce policy ("only accept connections from this platform") before serving any credentials.

The token is cryptographically bound to the exact Noise session, so it can't be replayed or redirected.
The token adds authenticated metadata about the requester without requiring user configuration (e.g. domain name of the remote, and possible other relevant metadata)

📸 Screenshots

⏰ Reminders before review

• Contributor guidelines followed
• All formatters and local linters executed and passed
• Written new unit and / or integration tests where applicable
• Protected functional changes with optionality (feature flags)
• Used internationalization (i18n) for all UI strings
• CI builds passed
• Communicated to DevOps any deployment requirements
• Updated any necessary documentation (Confluence, contributing docs) or informed the documentation team

🦮 Reviewer guidelines

• 👍 (:+1:) or similar for great changes
• 📝 (:memo:) or ℹ️ (:information_source:) for notes or general info
• ❓ (:question:) for questions
• 🤔 (:thinking:) or 💭 (:thought_balloon:) for more open inquiry that's not quite a confirmed issue and could potentially benefit from discussion
• 🎨 (:art:) for suggestions / improvements
• ❌ (:x:) or ⚠️ (:warning:) for more significant problems or concerns needing attention
• 🌱 (:seedling:) or ♻️ (:recycle:) for future improvements or indications of technical debt
• ⛏ (:pick:) for minor or nitpick changes

[iinuwa]

Looks good overall; added things that might be useful additions, and one question about the evaluation of exp in the verification logic.

[iinuwa]

Just a nit: the main document presents the remote client on the right and the user client on the left. It might be worth swapping these to be something like this

UserClient                              Remote Client                   Vendor
    |                                         |                           | <Publishes signing keys>
    |  <--  establishes Noise tunnel  -->     |                           |
    |                                         | - requests attestation -> |
    |                                         | <--- signs attestation--- |
    |  <------- presents attestation -------- |                           |
    | -------------------- requests signing keys ---------------------->  |
    | <verifies attestation>                  |                           |
    |  <----- continues communication ------> |                           |

[iinuwa]

"origin" typically refers to scheme + hostname (e.g. https://example.com/) in the web world, but below, we define iss to be equal to just a hostname. We should either use the full origin for iss, or use the term "hostname" here. Doesn't matter to me which.

[abergs]

@iinuwa Yeah to be honest I sort of want to do away with jkuand just have iss that points to the public key. And we grab the hostname of iss as the Vendor.

[iinuwa]

Hmm. I started thinking that would require a tiny bit more parsing on the client side, which might cause some issues, but they should be validating that that the jku hostname matches iss, so they have to do URL parsing regardless. On the other hand, splitting jku from iss means you need to make sure to validate that they match, which a client might forget to do and trust

{
  "iss":"app.com",
  "jku":"https://evil.com/jwks.json"
}

It'd be slightly abnormal to have a URL directly to the key in iss though. OIdC/OAuth2 handles this by having a .well-known address based on the issuer. In our case, the path can be anything. For that reason, I like splitting jku over iss, but I can see both sides.

Another alternative is following OIdC a .well-known path, which might not be a bad idea. Hosting .well-known on top-level domains can be annoying, but since the organization providing an agent is probably technically savvy, it can be worked around.

[abergs]

While abnormal, I still don't see any downsides with it, and you would need to do less comparisons as you point out.

I haven't fully considered if redirect impact things or not.

Well-known is not a bad idea, and may serve as a compliment but I worry about it being seen as more complex. A direct url is easy to reason about.

[iinuwa]

Another consideration is security UX for domains:

If the hostname is displayed in clients for TOFU attestations, the client SHOULD use some means for the user to securely display those to users to make appropriate trust decisions. These techniques can be borrowed from browsers, e.g.:

• assist with detecting homograph attacks by rendering with Punycode orshowing warnings when non-ASCII characters are present
• highlighting the registrable domain suffix according to PSL, while de-emphasizing subdomains underneath that
• etc.

[abergs]

Yeah, agreed! Is there a complete list of advice to follow that we may want to add here?

[iinuwa]

I don't see a W3C or IETF standard, but I found this list of guidelines from Chromium: https://chromium.googlesource.com/chromium/src/+/HEAD/docs/security/url_display_guidelines/url_display_guidelines.md.

[iinuwa]

I think if signer's clock is ahead at all, all tokens will fail validation on this step:

now = 0
iat = 1
exp = 301
exp - iat = 300 <= MAX_LIFETIME = true
(now, now + MAX_LIFETIME] = (1-300]
301 ∈ (1-300] = False

I think we need to compare (iat, iat + MAX_LIFETIME] instead, which should be fine since we checked that the clock skew was acceptable, and the period between iat and exp is valid.

now = 0
iat = 1
exp = 301
exp - iat = 300 <= MAX_LIFETIME = true
(iat, iat + MAX_LIFETIME] = (1-301]
301 ∈ (1-301] = False

also works if the signer's clock is slow:

now = 30
iat = 0
exp = 300
exp - iat = 300 <= MAX_LIFETIME = true
(iat, iat + MAX_LIFETIME] = (1, 301]
300 ∈ (1, 301] = true