Re: [Unbearable] Opaqueness of Token Binding ID

Andrei Popov <Andrei.Popov@microsoft.com> Wed, 31 August 2016 18:31 UTC

From: Andrei Popov <Andrei.Popov@microsoft.com>
To: Tokbind WG <unbearable@ietf.org>
Thread-Topic: Opaqueness of Token Binding ID
Thread-Index: AQHSA7C1QN5Po5xpx0Wbvq3ilbKBZaBjWm6QgAAJvkA=
Date: Wed, 31 Aug 2016 18:31:16 +0000
Message-ID: <CY1PR0301MB084219708F8ADE48189A3A888CE30@CY1PR0301MB0842.namprd03.prod.outlook.com>
References: <CADHfa2Byeb5OMJehqh=P7gFGr51U=11=N1xp4FHphFDBaHgmBA@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_CY1PR0301MB084219708F8ADE48189A3A888CE30CY1PR0301MB0842_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Aug 2016 18:31:16.8954 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0301MB0842
Archived-At: <https://mailarchive.ietf.org/arch/msg/unbearable/ebpUpuPBK2LGwsp5BG_q8G5ZDaA>
Subject: Re: [Unbearable] Opaqueness of Token Binding ID
X-BeenThere: unbearable@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" <unbearable.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/unbearable>, <mailto:unbearable-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/unbearable/>
List-Post: <mailto:unbearable@ietf.org>
List-Help: <mailto:unbearable-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/unbearable>, <mailto:unbearable-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 31 Aug 2016 18:31:53 -0000

TBPROTO currently says:
“Token Binding protocol implementations SHOULD make Token Binding IDs available to the application as opaque byte sequences.”

The reason is that a future TB version should be free to redefine the contents of the TB IDs, without breaking apps that rely on a certain TB ID structure.


Ø  It seems to me that it is safer to explicitly surface the fact that the Token Binding ID is a public key, and what kind of key it is, to other applications, rather than asking them to string-compare two strings whose semantics they don't understand.
Then the application would need to be aware of the TB version, and will likely need to be updated when we update the Token Binding protocol. We’ve already changed the contents/structure of TB IDs between drafts.

From: Dirk Balfanz [mailto:balfanz@google.com]
Sent: Wednesday, August 31, 2016 10:54 AM
To: Andrei Popov <Andrei.Popov@microsoft.com<mailto:Andrei.Popov@microsoft.com>>
Cc: Tokbind WG <unbearable@ietf.org<mailto:unbearable@ietf.org>>
Subject: Opaqueness of Token Binding ID

Hi Andrei & the rest of the Unbearables,

in the FIDO (well, W3C webauthn) discussion the question came up whether Token Binding IDs should be treated as opaque blobs in other protocols. In particular, FIDO assertions are (in part) over Token Binding IDs.

I had originally spec'd this out as including a JWK representation of the Token Binding key, as in:

// The FIDO signature is over this:
{
  "origin": "www.example.com<http://www.example.com>",
  "challenge": "129843adj03948",
  "tokbind": {
    "kty":"EC",
    "crv":"P-256",
    "x":"HzQwlfXX7Q4S5MtCRMzPO9tOyWjBqRl4tJ8",
    "y":"XVguGFLIZx1fXg375hi4-7-BxhMljw42Ht4"
  }
}

The webauthn participants are pointing out that the latest Token Binding spec says that other applications should use an opaque representation of the Token Binding ID, as in:

// The FIDO signature is over this:
{
  "origin": "www.example.com<http://www.example.com>",
  "challenge": "129843adj03948",
  "tokbind": "KJDSW34AAJSjasAKJsha-ISajj8sJSA..."
}

where the tokbind value would be the base64-enccoding of the TokenBindingID, as specified in ietf-tokbind-protocol.

It seems to me that it is safer to explicitly surface the fact that the Token Binding ID is a public key, and what kind of key it is, to other applications, rather than asking them to string-compare two strings whose semantics they don't understand.

I can't come up with a particular attack, since the Token Binding ID - just like the JWK - is an unambiguous representation of they key. Furthermore, since it is a canonical serialization, string comparison *should* be ok.

It seems strange, however, that the application (in this case webauthn) shouldn't be aware of the precise semantics of the tokbind value in this dictionary.

Any thoughts on this?

Dirk.

[Unbearable] Opaqueness of Token Binding ID Dirk Balfanz
Re: [Unbearable] Opaqueness of Token Binding ID Andrei Popov
Re: [Unbearable] Opaqueness of Token Binding ID Andrei Popov
Re: [Unbearable] Opaqueness of Token Binding ID Bill Cox
Re: [Unbearable] Opaqueness of Token Binding ID John Bradley
Re: [Unbearable] Opaqueness of Token Binding ID Anthony Nadalin
Re: [Unbearable] Opaqueness of Token Binding ID Andrei Popov
Re: [Unbearable] Opaqueness of Token Binding ID Dirk Balfanz
Re: [Unbearable] Opaqueness of Token Binding ID Andrei Popov
Re: [Unbearable] Opaqueness of Token Binding ID John Bradley
Re: [Unbearable] Opaqueness of Token Binding ID =JeffH
Re: [Unbearable] Opaqueness of Token Binding ID Benjamin Kaduk
Re: [Unbearable] Opaqueness of Token Binding ID Dirk Balfanz