Re: [Unbearable] New version of Attested TLS Token Binding

[Giridhar Mandyam <[e-mail]>]

Hi Andrei and others,

Thanks for the feedback and the good discussion in Montreal.

As per new version (-06).

>- What are we attesting?

Provenance of the tokbind keypair.

>- Should EKM be involved?

Latest version requires a signature over the hash of the tokbind public key, as was suggested in Montreal.  Replay protections for attestation are the same as for the tokbind message (sec 3.3 of draft-ietf-tokbind-protocol).  The attestation therefore needs to only be generated once during the lifetime
of the tokbind keypair. 

>-Should the extension be signed?

This is dependent on the type of attestation.  The attestation types described in the document require signatures.  There are others that are for security purposes the equivalent of unsigned attestations (e.g. 'Self Attestation' in https://w3c.github.io/webauthn/#sctn-attestation-types).  An unsigned attestation
could be added to the tokbind.extensions registry.

>- What needs to be negotiated and how?

Current draft keeps the proposed TLS handshake and new TLS extension codepoint as previous version (-05).  Current draft registers a new tokbind.extension value for each attestation type.  In other words, each attestation type is a new tokbind.extension.  There is only an octet provided for identification of tokbind extensions, but there seems to be only one use case identified for tokbind.extensions as per Sec. 6.3 of draft-ietf-tokbind-protocol.  I don't expect that there will be 255 extension types added to the registry, but if the value field of tokbind.extension needs to accommodate 256 or more extensions then there are ways to extend the  tokbind.extension value field.

>> ...whereby servers can leverage cryptographically-bound authentication tokens to verify TLS connections.
> I'm not sure we can say that TB or bound tokens help verify TLS connections. TB relies on TLS for negotiation and nonce.

As per draft-ietf-tokbind-protocol, " The Token Binding protocol allows client/server applications to create long-lived, uniquely identifiable TLS bindings spanning multiple TLS sessions and connections."  A TLS connection can be verified by leveraging these 'long-lived, uniquely identifiable TLS bindings'.  You are correct however that it is more than just TB and bound tokens that are required for this, but it was not my intention to state that TB and bound tokens alone can be used for verification of a TLS connection.

>>This is useful for prevention of man-in-the-middle attacks on TLS sessions,...
> TB does not prevent MITM attacks on TLS, because a MITM can either prevent parties from negotiating TB or mint bound tokens of its own.

It was not my intention to say that TB prevents MITM.  It is just one of many potential ways to detect MITM and apply countermeasures.  This was a (rather poor) paraphrasing of https://tools.ietf.org/html/draft-ietf-tokbind-https-08#section-7.4, which provided a more detailed overview of the role in detection of MITM's (and I do realize that the latest version of this I.-D. has moved this discussion to Sec. 7.3).  In the latest draft, I have removed this text.

>>2.1.  Token Binding Attestation Registry
> This belongs in the IANA section, so that it can be easily found.

Agreed.  See latest version.

-Giri Mandyam

-----Original Message-----
From: Andrei Popov <[e-mail]> 
Sent: Friday, July 20, 2018 11:55 AM
To: Giridhar Mandyam <[e-mail]>; [e-mail]
Subject: RE: New version of Attested TLS Token Binding

In addition to the more fundamental issues we discussed:
- What are we attesting? 
- Should EKM be involved? 
- Should the extension be signed? 
- What needs to be negotiated and how?

here are some editorial issues I found while reading the spec:

> ...whereby servers can leverage cryptographically-
>	   bound authentication tokens to verify TLS connections.

I'm not sure we can say that TB or bound tokens help verify TLS connections. TB relies on TLS for negotiation and nonce.

>	This is useful for prevention of man-in-the-middle attacks on TLS sessions,...

TB does not prevent MITM attacks on TLS, because a MITM can either prevent parties from negotiating TB or mint bound tokens of its own.

>	2.1.  Token Binding Attestation Registry

This belongs in the IANA section, so that it can be easily found.

Cheers,

Andrei

-----Original Message-----
From: Unbearable <[e-mail]> On Behalf Of Giridhar Mandyam
Sent: Tuesday, July 17, 2018 5:02 PM
To: [e-mail]
Subject: [Unbearable] New version of Attested TLS Token Binding

Hello All,

I hope to discuss this during Friday's meeting.  Some of the major changes since ver. 0.4 and ver. 0.3:

a) Proposal of new TLS extensions codepoint for tokbind sessions that will involve tokbind.extensions
b) Proposal for negotiating use of extensions  as part of TLS handshake
c) Addition of two base attestation types:  Android Keystore and TPMv2, along with verification procedures (heavily leveraged from Webauthn).
d) Proposal of establishment of tokbind attestation registry.

There are some other issues that I would like to get guidance from the group on the topic of tokbind.extensions, including:

a) Should clients advertise supported extensions? 
b) Should servers select extensions that they are interested in, and have the client suppress other extensions?  
c) Should clients just send all extensions that they support?  If so, can servers just ignore extensions in which they have no interest?

And specific to the attestation extension,

d) Should clients advertise the attestation types they support (which may expose some fingerprinting surface)?  Should servers communicate the attestation roots that they support?

-Giri Mandyam

-----Original Message-----
From: [e-mail] <[e-mail]> 
Sent: Tuesday, July 17, 2018 12:52 PM
To: Giridhar Mandyam <[e-mail]>; Jon Azen <[e-mail]>; Laurence Lundblade <[e-mail]>
Subject: New Version Notification for draft-mandyam-tokbind-attest-05.txt


A new version of I-D, draft-mandyam-tokbind-attest-05.txt
has been successfully submitted by Giridhar Mandyam and posted to the IETF repository.

Name:		draft-mandyam-tokbind-attest
Revision:	05
Title:		Attested TLS Token Binding
Document date:	2018-07-17
Group:		Individual Submission
Pages:		10
URL:            https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Finternet-drafts%2Fdraft-mandyam-tokbind-attest-05.txt&amp;data=02%7C01%7CAndrei.Popov%40microsoft.com%7C19470c8a07844450983008d5ec28a4a2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636674581665030439&amp;sdata=7iVbWDGYoGe7LqpC9IdqMl0hEtoBHjB97frVvHEX2Bk%3D&amp;reserved=0
Status:         https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-mandyam-tokbind-attest%2F&amp;data=02%7C01%7CAndrei.Popov%40microsoft.com%7C19470c8a07844450983008d5ec28a4a2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636674581665030439&amp;sdata=hWksFyxxMjGhq%2Fe57IEGyiiHpFKmUOxLGzm02eewpXU%3D&amp;reserved=0
Htmlized:       https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-mandyam-tokbind-attest-05&amp;data=02%7C01%7CAndrei.Popov%40microsoft.com%7C19470c8a07844450983008d5ec28a4a2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636674581665030439&amp;sdata=iR6RZq8MUwiyePBEgNhQi0MF3BQF92TKns8Ip255Gsc%3D&amp;reserved=0
Htmlized:       https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-mandyam-tokbind-attest&amp;data=02%7C01%7CAndrei.Popov%40microsoft.com%7C19470c8a07844450983008d5ec28a4a2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636674581665030439&amp;sdata=pr0ccS%2FMllsV5Cvrixl3oFJidNs%2BXs0ekRkoNFE0kBY%3D&amp;reserved=0
Diff:           https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Frfcdiff%3Furl2%3Ddraft-mandyam-tokbind-attest-05&amp;data=02%7C01%7CAndrei.Popov%40microsoft.com%7C19470c8a07844450983008d5ec28a4a2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636674581665030439&amp;sdata=CSRP9cMlllw1Xfn%2BAJI%2B9tfzm02hbvDctRNve3lb9Bs%3D&amp;reserved=0

Abstract:
   Token binding allows HTTP servers to bind bearer tokens to TLS
   connections.  In order to do this, clients or user agents must prove
   possession of a private key.  However, proof-of-possession of a
   private key becomes truly meaningful to a server when accompanied by
   an attestation statement.  This specification describes extensions to
   the existing token binding protocol to allow for attestation
   statements to be sent along with the related token binding messages.

                                                                                  


Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

_______________________________________________
Unbearable mailing list
[e-mail]
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Funbearable&amp;data=02%7C01%7CAndrei.Popov%40microsoft.com%7C19470c8a07844450983008d5ec28a4a2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636674581665040447&amp;sdata=oZPtCiwLy%2FctRkV4PmG6cS7SaiCG5PYWAnLFjTU5fVs%3D&amp;reserved=0