From 9ee854304bef375237a6a3c989df39ea63954501 Mon Sep 17 00:00:00 2001 From: Hugh Nimmo-Smith Date: Tue, 16 Apr 2024 13:15:28 +0100 Subject: [PATCH] Revert changes to device id and proofs These are now in https://github.com/matrix-org/matrix-spec-proposals/pull/4130 --- proposals/4108-oidc-qr-login.md | 83 +++++++-------------------------- 1 file changed, 16 insertions(+), 67 deletions(-) diff --git a/proposals/4108-oidc-qr-login.md b/proposals/4108-oidc-qr-login.md index 37662a60..fcb9c95e 100644 --- a/proposals/4108-oidc-qr-login.md +++ b/proposals/4108-oidc-qr-login.md @@ -787,16 +787,8 @@ At this point the new device knows that, subject to the user consenting, it shou 3. **New device informs existing device that it wants to use the `device_authorization_grant`** -At this point, the new device should ensure it has generated its Olm account, so that it has its Curve25519 and Ed25519 -device identity keys. - -It then sends a `m.login.protocol` message to the existing device, containing: - -- An indicator that it wants to use protocol `device_authorization_grant` -- The `verification_uri` -- The `verification_uri_complete`, if present -- The device ID it will be using, which MUST equal the unpadded base64-encoded form of the Curve25519 identity key of - the new device +The new device send the `verification_uri` and, if present, the `verification_uri_complete` over to the existing device and +indicates that want to use protocol `device_authorization_grant` along with the `device_id` that will be used: *New device => Existing device via secure channel* @@ -808,7 +800,7 @@ It then sends a `m.login.protocol` message to the existing device, containing: "verification_uri": "https://auth-oidc.lab.element.dev/link", "verification_uri_complete": "https://auth-oidc.lab.element.dev/link?code=123456" }, - "device_id": "3C5BFWi2Y8MaVvjM8M22DBmh24PmgR0nPvJOIArzgyI" + "device_id": "ABCDEFGH" } ``` @@ -855,7 +847,7 @@ sequenceDiagram N->>+OP: POST /auth/device client_id=xyz&scope=openid+urn:matrix:api:*+urn:matrix:device:ABCDEFGH... OP->>-N: 200 OK {"user_code": "123456",
"verification_uri_complete": "https://id.matrix.org/device/abcde",
"expires_in_ms": 120000, "device_code": "XYZ", "interval": 1} note over N: 3) New device informs existing device of choice of protocol: - N->>Z: SecureSend({"type": "m.login.protocol", "protocol": "device_authorization_grant",
"device_authorization_grant":{
"verification_uri_complete": "https://id.matrix.org/device/abcde",
"verification_uri": ...,
"device_id": "3C5BFWi2Y8MaVvjM8M22DBmh24PmgR0nPvJOIArzgyI"}) + N->>Z: SecureSend({"type": "m.login.protocol", "protocol": "device_authorization_grant",
"device_authorization_grant":{
"verification_uri_complete": "https://id.matrix.org/device/abcde",
"verification_uri": ...}, "device_id": "ABCDEFGH"}) deactivate N end @@ -867,7 +859,7 @@ sequenceDiagram end rect rgba(0,255,0, 0.1) - Z->>E: SecureReceive() => {"type": "m.login.protocol", "protocol": "device_authorization_grant",
"device_authorization_grant":{
"verification_uri_complete": "https://id.matrix.org/device/abcde",
"verification_uri": ...},
"device_id": "3C5BFWi2Y8MaVvjM8M22DBmh24PmgR0nPvJOIArzgyI"} + Z->>E: SecureReceive() => {"type": "m.login.protocol", "protocol": "device_authorization_grant",
"device_authorization_grant":{
"verification_uri_complete": "https://id.matrix.org/device/abcde",
"verification_uri": ...}, "device_id": "ABCDEFGH"} end rect rgba(255,0,0, 0.1) @@ -925,7 +917,7 @@ sequenceDiagram N->>+OP: POST /auth/device client_id=xyz&scope=openid+urn:matrix:api:*+urn:matrix:device:ABCDEFGH... OP->>-N: 200 OK {"user_code": "123456",
"verification_uri_complete": "https://id.matrix.org/device/abcde",
"expires_in_ms": 120000, "device_code": "XYZ", "interval": 1} note over N: 3) New device informs existing device of choice of protocol: - N->>Z: SecureSend({"type": "m.login.protocol", "protocol": "device_authorization_grant",
"device_authorization_grant":{
"verification_uri_complete": "https://id.matrix.org/device/abcde",
"verification_uri": ...},
"device_id": "3C5BFWi2Y8MaVvjM8M22DBmh24PmgR0nPvJOIArzgyI"}) + N->>Z: SecureSend({"type": "m.login.protocol", "protocol": "device_authorization_grant",
"device_authorization_grant":{
"verification_uri_complete": "https://id.matrix.org/device/abcde",
"verification_uri": ...}, "device_id": "ABCDEFGH"}) deactivate N end @@ -936,7 +928,7 @@ sequenceDiagram #end rect rgba(0,255,0, 0.1) - Z->>E: SecureReceive() => {"type": "m.login.protocol", "protocol": "device_authorization_grant",
"device_authorization_grant":{
"verification_uri_complete": "https://id.matrix.org/device/abcde",
"verification_uri": ...},
"device_id": "3C5BFWi2Y8MaVvjM8M22DBmh24PmgR0nPvJOIArzgyI"} + Z->>E: SecureReceive() => {"type": "m.login.protocol", "protocol": "device_authorization_grant",
"device_authorization_grant":{
"verification_uri_complete": "https://id.matrix.org/device/abcde",
"verification_uri": ...}, "device_id": "ABCDEFGH"} end # alt if New device scanned QR code @@ -1035,7 +1027,7 @@ sequenceDiagram OP-->>N: 400 Bad Request {"error": "authorization_pending"} else granted OP-->>N: 200 OK {"access_token": "...", "token_type": "Bearer", ...} - N->>E: SecureSend({ "type": "m.login.success", "proof": base64_encoded_proof_of_identity_key_ownership }) + N->>E: SecureSend({ "type": "m.login.success" }) Note over N: Device now has an access_token and can start to talk to the homeserver else denied OP-->>N: 400 Bad Request {"error": "authorization_declined"} @@ -1058,9 +1050,6 @@ sequenceDiagram end ``` -The reader will note that the `m.login.success` contains a proof that the new device owns the identity key it had -previously committed to, in the `m.login.protocol` step. This is explained in the next section. - #### Secret sharing and device verification Once the new device has logged in and obtained an access token it will want to obtain the secrets necessary to set up @@ -1077,7 +1066,7 @@ If checked successfully then the existing device sends the following secrets to This is achieved as following: -1. **Existing device confirms that a device with the previously committed-to device ID (device identity key) has indeed logged in successfully** +1. **Existing device confirms that the new device has indeed logged in successfully** On receipt of an `m.login.success` message the existing device queries the homeserver to check that the is a device online with the corresponding device_id (from the `m.login.protocol` message). @@ -1089,47 +1078,9 @@ If the device isn't immediately visible it can repeat the `GET` request for up t If no device is found then the process should be stopped. -2. **Existing device confirms that the new device owns the private part of the committed-to device identity key** - -The new device then proves it controls the private key to which it previously committed. It does this by doing an ECDH -between the committed-to identity key and the other device's secure channel ephemeral key to derive a shared secret, -which is used to construct a proof of ownership based on HMAC-SHA256. Due to the properties of ECDH, the other device -knows that the new device can only do this if it possesses the private part of the committed-to identity key. - -The new device does: - -``` -SH := ECDH(Is, Ep) -ProofKey := HKDF_SHA256(SH, "MATRIX_QR_CODE_LOGIN_PROOFKEY|" || Ip || "|" || Ep, salt=0, size=32) -ProofBytes := HMAC_SHA256(ProofKey, "MATRIX_QR_CODE_PROOF_OF_POSSESSION") -Proof := UnpaddedBase64Encode(ProofBytes) -``` - -And sends the **Proof** to the existing device. - -The existing device does the following to verify the proof: - -``` -ProofBytes := UnpaddedBase64_Decode(Proof) - -SH := ECDH(Es, Ip) -ProofKey := HKDF_SHA256(SH, "MATRIX_QR_CODE_LOGIN_PROOFKEY|" || Ip || "|" || Ep, salt=0, size=32) - -unless HMAC_SHA256(ProofKey, "MATRIX_QR_CODE_PROOF_OF_POSSESSION") == ProofBytes: - FAIL -``` - -```json -{ - "type": "m.login.success", - "proof": "$Proof" -} -``` - -3. **Existing device shares secrets with new device** +2. **Existing device shares secrets with new device** -If both previous steps succeeded, the existing device proceeds to send a `m.login.secrets` message via the secure -channel: +The existing device sends a `m.login.secrets` message via the secure channel: ```json { @@ -1170,14 +1121,14 @@ Content-Type: application/json "m.olm.v1.curve25519-aes-sha2", "m.megolm.v1.aes-sha2" ], - "device_id": "3C5BFWi2Y8MaVvjM8M22DBmh24PmgR0nPvJOIArzgyI", + "device_id": "SGKMSRAGBF", "keys": { - "curve25519:3C5BFWi2Y8MaVvjM8M22DBmh24PmgR0nPvJOIArzgyI": "3C5BFWi2Y8MaVvjM8M22DBmh24PmgR0nPvJOIArzgyI", - "ed25519:3C5BFWi2Y8MaVvjM8M22DBmh24PmgR0nPvJOIArzgyI": "b8gROFh+UIHLD/obY0+IlxoWiGtYVhKdqixvw4QHcN8" + "curve25519:SGKMSRAGBF": "I11VOe5quKuH/YjdOqn5VcW06fvPIJQ9JX8ryj6ario", + "ed25519:SGKMSRAGBF": "b8gROFh+UIHLD/obY0+IlxoWiGtYVhKdqixvw4QHcN8" }, "signatures": { "@testing_35:morpheus.localhost": { - "ed25519:3C5BFWi2Y8MaVvjM8M22DBmh24PmgR0nPvJOIArzgyI": "ziHEUIsHnrYBH4CqYpN1JC/ex3t4VG3zvo16D8ORqN6yAErpsKsnd/5LDdZERIOB1MGffKGfCL6ny5V7rT9FCQ", + "ed25519:SGKMSRAGBF": "ziHEUIsHnrYBH4CqYpN1JC/ex3t4VG3zvo16D8ORqN6yAErpsKsnd/5LDdZERIOB1MGffKGfCL6ny5V7rT9FCQ", "ed25519:bkYgAVUNqvuyy8b1w09utJNJxBvK3hZB65xxoLPVzFol": "p257k0tfPF98OIDuXnFSJS2DmVlxO4sgTHdF41DTdZBCpTZfPwok6iASo3xMRKdyy3WMEgkQ6lzhEyRKKZBGBQ" } }, @@ -1366,14 +1317,12 @@ Fields: |Field|Type|| |--- |--- |--- | |`type`|required `string`|`m.login.success`| -|`proof`|required `string`|New device's proof of identity key ownership, base64-encoded| Example: ```json { - "type": "m.login.success", - "proof": base64_encoded_proof_of_identity_key_ownership + "type": "m.login.success" } ```