[Unbearable] IETF-96 tokbind raw minutes

[[e-mail]]

##########
Token Binding WG - IETF96 Berlin
=============
http://etherpad.tools.ietf.org:9000/p/notes-ietf-96-tokbind

> * Note Well and Agenda Bashing (5 min)
https://www.ietf.org/proceedings/96/slides/slides-96-tokbind-2.pdf

let's jump straight to presos...


> * Core Documents (55 min)
>    - draft-ietf-tokbind-protocol-08  -- Andrei Popov
https://www.ietf.org/proceedings/96/slides/slides-96-tokbind-0.pdf
>    - draft-ietf-tokbind-negotiation-03

mostly all editorial changes since ietf-95  -- see slides






>    - draft-ietf-tokbind-https-05  -- dirk balfanz
https://www.ietf.org/proceedings/96/slides/slides-96-tokbind-4.pdf

dirk gives demo using canary chrome and google frontend (at a  
particular endpoint which is an alpha/canary TLS frontend...

https://tokbindrptest.appspot.com
echo -n <base 64 tokbind msg> |  base64 -D   |  od -Ax -tx1

Update Fetch to support Token Binding  -- vinod working on this
https://github.com/whatwg/fetch/pull/325

william denis: what about the 302 redirect req -- is that the only way  
to do things? what about other patterns?

dirk(db): we need diff triggers for diff patterns, for patterns that  
utilize redirects, the response header field in spec is the trigger --  
for other patterns, need to write other profiles and define diff  
patterns -- that's somthing that'll happen in other WGs -- i imagine  
will work with XHR like: when create XHR obj, have a flag that's  
'include-referred-tb' -- in saml world, have an auto-submit form,  
could have a boolean attr on the page that signals inclusion of the  
referred TB  --- wrt whatwg/w3c, once stuff in fetch, the stuff passed  
down from higher layer ought to Just Work -- each of these have in  
comman that there's an origin from which the req is made and one to  
which the provided and referred TBIDs are sent


subodh: what about priv implications of including this referred header field?
db: browsers have notions of whether to send 3d party cookies or not,  
if bwsr is sending out a req in which it is not ok to send 3d party  
cookies, it will not send TB header

wseltzer: when bring this up in webappsec WG ?
db: onece Anne gives ok to the PR#325  
<https://github.com/whatwg/fetch/pull/325>
vinod: probably just weeks until done


leif: can these 3 specs goto WGLC?
mike jones(mj): maybe you shud ask that question again after my oauth  
preso, i'll raise an open issue with the core specs...

john bradley(jb): hans has a version of mod_ssl that does TB -- any  
other impls?
andrei (ap): have impl in IE & Edge (both use same http engine)
subodh: have started working on impl



> * Related work: Token Binding for OAUTH (30 min)

>    - draft-jones-oauth-token-binding-00   --- Mike JOnes
https://www.ietf.org/proceedings/96/slides/slides-96-tokbind-3.pdf
see slides
wrt slide 3
tony nadalin(tn): notes that if connection had gone away might get a  
lot of reauthns
db: notes that TBID lifetime can be long and span multiple tls sessions

slide 4: TB ID Tokens
defined in: openid-connect-token-bound-authentication-1_0
3-party use case, this seems to work out well given the present tbind specs

slide 5: representation in openid connect ID Token
they put hast of TBID in ID Token -- saves bytes.
an open issue of how to have crypto agility for the hash function
b campbell(bc): how bout just define names for hashes algs...

slide 6: Tokenbound access tokens
see slides...
slide 7: issue for TB access tokens
this is not using redirects, cross-domain comms is by expicit connection
the prob: two channesl not crypto'y bound when using the explicit param method
proposed soln: req TB impls to provide APIs for clients to explicitly  
provide TB info to be sent as referred TB

Andrei(ap): pushes back on this notion: "don't need to write any api  
reqs in a protocol spec"
JeffH: well, rfc5929 tls channel bindings does have a section "7.   
Required Application Programming Interfaces"   
<https://tools.ietf.org/html/rfc5929#section-7> that is along these  
lines and serves as a reasonable precedent
torsten l.: can see need for such language in the spec, and without  
it, eg if such api isn't made availaBLE, then TB isn't useful

[ tony nadalin, dirk and andrei push back]
tn: you put your api reqs into the oauth TB profile spec...
mjb: well, ought to be in tb-protocol spec because there's other apps  
than oauth who'll want to do this

johnbradly(jb): thinks such broad language is fine
subodh: what does it mean to be a token binding impl -- so does this  
apply to whom and where and in what context?

dick hardt: agree with JeffH and Mike wrt general api guidance
justin richer(jabber): This is all about non-browser-based HTTP  
communication. You *can* do it with the current spec, but there ought  
to be functional guidance so non-browser apps can all do this the same  
way. there's no reason for OAuth to be a special snowflake here.

william d: either way there's apis to add to tls stack and such  
guidance makes sense

tony(tn): stacks are going to look at their resources to writing api,  
they can make decisions on their own...

jb: unclear whether app on top of stack will have access to the  
referredTBID, if we pass it as extra param, there's sec issues maybe;  
if we have an agreement TB will be available to native apps, it'll be  
easier to developers to have access to this

martin thomson(mt): what is this api ?
jb: its a native api
mt: why is this not simply looking at this "we have simple api, enrich  
it a BIT" and mike's happy?

william d(wd): paramater or header need tls stack cooperation...

chair: leif: can someone provide actual text -- this is only a couple  
lines yes?  can do this during WGLC?

?: notes that if we are writing app on top of tls stack and we can't  
rely on there being an API providing this then life is difficult....


leif: hum on whether we need such api guidance/reqs in the spec ?
  result: was roughly 50/50 on support and no support for the notion

leif: who believes having non-norm guidance is ok?
  fair hum
who believes it is evil?
  no hum

MT: hm, there's possible sec issues here if an app can tell the tls  
stack to send the TB to some other arbitrary host....?

mjb: we're trying to secure existing app comms patterns....

MT: <some example where there's privacy leakage and belives it is a problem>

db: so whoever crafts this please include to not violate privacy...

bc: MT is getting to convcerns wrt key scoping -- perhaps some  
guidance wrt scoping in APIs will be necessary...

sf: not clear to me that you can craft the sec cons for the full  
generality of these such API guidance...

leif: if we have text, we can actually dicuss more concretely

leif: are these specs ready for last call?  (various hands go up)

lucy lynch(LL): advises that priv review occur before WGLC

MT: has priv concerns with this stuff...

leif: will you MT do a priv review? LL and WendyS ?  u have a month  
approx before we go into WGLC


>    - draft-campbell-oauth-tbpkce-00 -- biran campbell
https://www.ietf.org/proceedings/96/slides/slides-96-tokbind-1.pdf

a TB method for OAuth proof key token exchange...  pronounced pixy
rfc7636
final slide "what are next steps?" -- questn is more for oauth WG

db: one what to think about pkce is it is assym operation, having TB  
protects against MITM, so yes we should bother
jb: it does improve sec, perhaps gets around some impl issues
   am playing around with TB client IDs...
subodh: does this prevent against atks in android & ios where u can  
register req URLs?
jb: pkce does that now
Kaoru Maeda: PKCE is to differenciate two apps residing on one device.  
TBID is associated to TLS connection, that is device to server. Since  
HTTP/2 requests may coalsce on a single TLS connection, context  
separation may not be what is desired.


end