------------------------------------------- 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): 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): 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? 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: vinod: 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: 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: 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: 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: 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 end tokbind