Minutes for TOKBIND at IETF-95
minutes-95-tokbind-2

-------------------------------------------
tokbind   IETF-95 Buenos Aires  4-Apr-2016
-------------------------------------------
Leif Johansson & John Bradley presiding
https://www.ietf.org/proceedings/95/slides/slides-95-tokbind-0.pdf

AndreiP(ap) presenting: -tokbind-protocol (TBPROTO) & -tokbind-negotiation
(TBNEGO)
 see slides:
https://www.ietf.org/proceedings/95/slides/slides-95-tokbind-1.pdf

 -protocol-05 pub'd this morn

 say explicitly in draft -
  if receive tbmsg and it contains tb type don't undstand, just skip it
 also punt referred tbtype to -https spec -- [ note: we have subsequently
 decided to not do this due to anticipated OAuthTB use of _referred TBtype ]

 brianC (bc):
  have cognitive issue with TBID being actually a just a public key --
perhaps explain this better

 leif(LJ): what need to do to make it done?
  move referred to -https
  skip unknown tbid types in tbmsg

 johnb(jb): is there something else other than a public key that could be
a tbid?

 AP: nope

 LJ: do one more rev and goto wglc?

 Tony Nadalin(TN): is fine w/wglc now w/ -05

 bc: suggests the drafts goto wglc all together

 bc: there's language brwn the drafts that refer to the same things but
using inconsistent terms -- would be good to clean that all up...

vinod(va) proxying Dirk, presenting:  -tokbind-https aka HTTPSTB
 https://www.ietf.org/proceedings/95/slides/slides-95-tokbind-2.pdf

leif-- what about the federation questions from the list

 JeffH(jh): <explained the question(s)>

 bc: what we ahve is generally sufficient to accomd most use cases, tho
there is idp-initiated flow which this may be an issue

 ap: notes that msft has made idp-initiated work via the 'msft token
broker' -- ie is a custom solution

 jh: might want to add that to the spec in some impl guidance...

 ap: don't want to write up

 scott cantor(sc): custom is worthless in a world where the browser has to
participate, we need standard behavior

john bradley(jb): its best to keep simple enuff to cover 80..90% cases

Scott Cantor(sc): but IdP initiated is really common, so that should be
highlighted in the draft

 tn: don't want to spec just rp-initiated flow and say that is what you
need to do...

 jh: wrt tony's comment that's not what we are saying, this rp-init is
just an example and it may or may not work for you,

 tn: agree w/JH

 lucyl(LL): <said above in very good manner>

JH: now pop stack back to scott's more recent comment..

sc: I am still thinking about the actual risks of one server asking the
client to reveal a different server's binding, but I wondered about the
idea of whitelisting hosts (the IdPs) so the client has reason to believe
it should reveal bindings to it

vinod(va): RP whitelists itself to the IDP via the header...   is current
mech sufficient?

bc: yes sufficient, whitelist may be too complex...

sc: yeah, I see that; I think if we agree to ignore IdP initiated for the
browser case, we can live without it

lj: do you think we can get this done by Berlin?

<heads nod yes>

jb: specs are clear about how things are used in browser, but if have
native apps, do we need to explain more clearly how the priv keys are
sandboxed?  i.e., more than one app might be able to use a given RP-mapped
priv key?

ap: this is platform specific... we could add a vague general stmt to
spec, am not opposed to it..

jb: who has access to the priv key is platform-dep, pls look at platf
doctn for details...

ap: will add to sec cons

bc: what about limits to # keys gen'd on hdwr device?

overall ans: we could handwave about that but is platform specific....

bc: is tb estab'd on initial connection?

ap: client generates tbid on every tls connection

bc: what does that mean?  trying to understand particularly with referred
tbid -- if user has existing https w/idp w/tbid, it will have provided
tbid -- how will redirect to idp work and will client need to regenerate
tbid?

ap: <explains how it works; this is all happening at app layer>

vinod: <adds to it>

bc: thinks it might be more clear to http/app layer if the provided and
referred were conveyed in sep headers rather than in the same
header-cum-tbmsg

bc: on init redir the server would get both of them (hdrs), then on subseq
interactions it would get just one header, would be easier to parse out at
this layer

ie have diff header name for referred -- easier to parse at http/app
layer...would make spec more comprehendable and easier to impl

ap: we can think about this....in either case the server app needs to pass
the tb heaader to some tb impl and get answer from it, so wether i pass
one blob or two blobs, seems equivalent....

jb: are there libs, example code folks can look at?

ap: do have a tb api in windows that is sort of documented -- will send
link to list

va: goog working on server side example code

sc: is the expectation that TLS impls actually provide the EKM material to
applications to verify these token bindings? That seems like a gap if they
don't.  Initially I had thought all that work was meant to be inside the
TLS layer, sounds like the raw material needs to be bubbled out.

ap: yes, need EKM exporter in tls api, this can be impl'd in some sort of
middleware, but yes the tls stack needs to supply this -- in our impl,
have a sep tb lib, pass it tls session handle and it does the work

williamd: having disc of applying TB to OAuth, OIDF has released this lib
called "appauth" and also the "cronut" libs for native apps -- having
discussions this week about this

bc: still quite don't understand how this works....if there's been any
prog wrt support for referred to be on 30x redirects ... it is not
uncommon that RP redirs to IDP via POST .... spec doesn't accomodate this
presently

ap: can mention this limitation more clearly in the spec...

jh: this applies to SAML form-post binding
bc: many such other bindings...
jh: so perhaps need to think about different signaling, pesent signal is
for one thing: just redir -- does every binding need diff signal?

bc: see discussion in the issue (not on list (sigh)) perhaps fetch() needs
to be updated to more handle these various approaches

jb: had a form-post in earlier drafts, yes?

sc: I'd be somewhat shocked if Java did, but I've been surprised before, I
feel his pain

sc: I certainly noted the limitation, this is clearly leading to us
killing off these other scenarios, not "supporting them later", just my
opinion

sc: (unless there is active work going on, sounds like there is?) it's not
about language, if you ship browsers that don't support POST, I'm not
going to tell people to keep deploying POST, I'm going to kill it -- I was
responding to the speaker, not you John

va: want to support this stuff, is this the corect forum, or do we need to
do this in fetch() ?  this works with GET yes?

jb: its only if you're doing a POST authn req we need more support...

sc: yes, just speaking about POST-conveyed authn requests, and much like
the IdP-initiated case, it's a strong pressure on those deployment models,
not saying it's good/bad, just highlighting that it will be an outcome

bc: maybe will intro of TB make it easier to do certain models and others
can be superseded...

jb: so supporting other patterns can perhaps be addressed on longer
timescale in additional drafts cuz might need help from fetch()

ap: <explains how things work via the "ongoing discussion: federation"
slide>

bc: ok, so feel even more that having two distinct headers will be much
easier for the http/app layer to process, seems more natural, exp if move
the notion of referred into the -https spec --- conveying what's going on
will be much easier to understand, eg for folks like myself....

va: initial design allows for even more tbtypes did't want to alloc one
header per tb type.....but you're making a good case for doing this....

sc: Q: If the token binding message is application layer, then how do you
envision the message being validated in conjunction with the negotiated
token binding type worked out in the TLS handshake? That seems a bit
awkward.

ap: impld in asp.net, which gens tokens, creates tbmsg, etc.  shields app
layer dvlp from it

sc: it's how this would work with generic libs like OpenSSL that I'm
thinking of

jb: expanding on directino of Scott's q -- i can see how msft has impl'd
it, but some folks use IIS, is it impl'd in IIS and how's it exposed to
.net apps who want to use TBID in cookies?

ap: <explains layering>  server-side apps use asp.net to do all this

jb: is tb exposed such that one can do their own thing?

ap: have lib that helps you parse this stuff and verify sigs, you can use
lib directly

jb: pls send ptrs to the list...

sc: believe it or not, though, people ask some of us to supply our own
SAML implementations on IIS

lucy(ll): asking why having the mult tbids in one msg....
ap: easier to pass to api to deal with it....
lucy: you're getting feedback here that at app layer it might not be "more
conveninent" and you should listen to that

jb: <some explanation on how this design evolved>

ll: if you're going with why you're obscuring (ie packaging) things
together for folks at app layer

va/ap: we can either change the https spec to break things apart or
explain why it is packaged together

karl rose: what about authn creds, have one per server for priv reasons,
but there are use cases where mult entities actually are same entity....

jb: was put in such that we're tryiing to prevent correlation by design;
because the keys are pair-wise we're doing audience restriction
effectively;

va: there are two classes of UAs, browsers and others, because the browser
is connecting to "other servers" as matter of course, need this, but in a
purpose app UA can relax this requirement...

kr: <clarifies>

jb: having this restriction is preventing a sec vuln you may have glossed
over in your app -- in oauth lib thinks we leaning towards diff keys for
diff providers cuz there are priv benefits

kr: analogy: in SSH, have priv key per machine, but client can use same
key for diff servers

kr/jb <long discusion about various aspects of this wrt priv key mgmt...>

end tokbind