Minutes for TOKBIND at IETF-92
minutes-92-tokbind-1

Intro/Agenda
 -- no changes to agenda

Andre Popov presented slides relating to the document draft-popov-token-binding

Some discussion about the negotiation that and where it occurs.  Should it be
in an APLN  TLS extension, a different TLS extension or at the application
layer.  AP said that moving to the application layer is a problem as that
introduces extra round trips to do the negotiation.  Current thought is that a
new TLS extension would be used.

In response to a question key lifetimes, Andre responded that the user can
always delete them, the crypto device would be able to delete them based on
parameters about the key algorithms.  It would also be good to provide a
suggestion that easily accessible UI be provided to make logining and (and thus
deleting the key) be easier than cookie deletion is today.

Dirk Balfanz then presented slides relating to draft-balfanz-https-token-binding

There was a large amount of discussion dealing with the issues of what
information is being sent to the IdP and why it was being sent.  Privacy
considerations means that minimal information needs to be sent, but it was not
clear to some people by both public keys were being used in the message to the
IdP.

There was a large discussion on the issue of using the TLS unique value as
opposed to some type of challenge from the server.  While a challenge would
involve the addition of a round trip, depending on the TLS unique value
introduces a large number of problems for TLS proxies on both the client side
and the server side.  The client side introduces a new TLS channel and thus a
new TLS unique value, the server side introduces problems with how to get the
TLS unique value or the verification of the signature from the gateway to the
HTTP server.

Open Discussions

Lief asked the group to express an opinion on adoption of the documents in the
working group.  The hum in the room showed strong consensus to adopt the
document.

Lief suggested that the current github tracker being used for the documents
continued to be used, but requested that the documents themselves be published
so that multiple people can contribute.

A discussion about milestones was then held.  The current milestone seems
somewhat optimistic, however there was not a strong push to have them changed
until the next IETF when it can be seen how the group is functioning

Finally, a presentation FIDO was made by Jeff Hodges and Dirk Balfanz.

******************** END minutes *************************

presentation #1

Martin Thompson (MT)  - Dont use ALPN
     Does not make sense
     using TLS is smaller
Hannes (HT) - Is TLS the correct place to do this?
     why not use OAUTH -
     resouce server needs the information not the client
AP - not client auth - dont' want to use more round trips doing negoation
HT - parameters to communicate client to server tell auth server who issues
token -
   client avoid using alg that resurce server does not know
   auth server knows what the resource server can do
AP - binding use with both the auth server and the resource server
DKG - client signaling what binding can be used - HT has more complex ideas
    signing this piece in TLS extension make sense
HT - need to tell, hash function & protocol - maybe some other (CoaP)
   not endless number of things - but not just one
MT - No one consuming this at the TLS layer - all activity in the HTTP/protocol
layer
   moving to other protocols later not now
AP - This is not in TLS - uses TLS unique - could be used with other protocols
MT - signal at HTTP layer - cleaner - can't use signature extension because not
sufficient AP - don't want to do extra roundtrip in appliction layer to
negotiate John - don't need the multi-party negotiation - Hannes is over
thinking Bill Mills - How does this work with speedy with multiple sites behind
the TLS firewall AP - token binding is per TLD in that case YN - can have
different cookies for different site? AP - yes HT - more infrastructure that
people will want to tie into later even if don't realize it now AP - key
lifetime -
   user can always delete them
   crypto layer can decide to purge key based on age of key
   leave to the crypto layer to make decision about lifetimes
YN - erasing cookies is not a frequent user operation
   Intend this to be more accessable to users?  I.e. log out button?
AP - no language in draft on UI requirements
   Would not object to recommendation to do this.

draft-balfanz-https-token-binding
MT - provide redirect - allows to sling any information over the redirect
   RP stuffs additional data into the URL
   why prove someting to the IdP here
?B - IdP gets proof that both private keys controlled by the client
MT - man in the middle kind of hosed anyway. Prefer not to have the information
shared unless needed ?B - make sure token is about this client - trying to
exclude some MITM attacks MT - RS and IdP have a relationship -
   can pass some information
   setup for OAUTH tokens to be run around
?B - otherwise it could be somebody elses key pair
MT - as long as RP is not exposed to MITM attack - info is useless to the
attacker ?? - concerned about another client stealing the authorization

?? - which TLS_unique is bing used on HTTP-Redirects slide#2
?B - this is the Cient-IdP link TLS-Unique

MT - On fetch question - trying to deprecate XmlHttpRequest, trying not to add
new things to it. Lief - Need to get W3C review on this document.
     can you get some review
MT - yes - go to webapp sec group to get review with email.
Wendy - happy to help to get the communications happen

?? - political question - 99% of world is still using XHR - do you want it to
be highly used ?B - not a problem with getting new browsers since need to have
updates to roll this out anyway. BM -  is the HTTP server assumed to have
access to the tls-unique value?  Does the HTTP app layer recheck this
signature? ?B - @ google would have the terminator do the POP verification -
   alternative would be to send tls-unique downstream to the backend
DKG - is this dependent on the TLS session hash fix?
?B - yes
YN - fails for TLS proxies since TLS unique value has changed
?B - won't get this to work since binding would be to proxy -
   problem is client moves around from behind proxy to not and back.
BM - No binding between TLS and HTTP in the proxy case
Brian ? - Intercepting proxies that currently intercept client certs are going
to have the same problems with this type of system as it will have problems
with different tls_uniques -
      problems with bounding around on different load balance proxies
?B - really trying not to introduce more round trips
MT - only way to solve is to do a challange - only wao to address with MITM of
some type.
   don't know if you want to solve the CDN case or not
?B - don't want the extra round trip, from our data does not seem to be a
massive problem with logging people out from changing being behind proxy

JB - Differing expectations on what appliations can get to what keys in this
case.  Need some security considerations about this. ?B - plans to get some
recommendations on these issues as a group.
   Key protection: should not be extractable -
   Discloser of IdP info to the RP or user data w/the IdP - this is why was
   done with the ower level -

Open Discussion - Lief

Issue tracking - use the GitHub tracker -
      put sources on the github as well for pull requests
working group adoption
        AP - please adopt
Hum shows strong adoption in the room

Charter milestones -
Lief - suggest leaving along until we find how work progresses
Steve Ferral - always somewhat fictional
      please make it fast
Lief - given discussion - probalby not before fall
AP - should have current issues addressed by next meeting with document update
   also have the TLS extension draft by the next meeting
MT - don't have a dependency on TLS - do the extension here
SF - dissucsion on the dependency for the WebAppSec W3C group
Wendy - suggest independent documents - fetch not W3C
SF - use descriptive not normative text on the API changes

Open Mic time

Jeff Hodges on FIDO