RE: [Unbearable] IETF seeking feedback on proposed "Token Binding" Working Group

[Andrei Popov]

Hi Anne,

This is part of a starting point proposal for the new working group; we expect 
the documents to change. It's a great time to suggest revisions; please feel 
free to suggest your text. I've put the initial I-Ds on github for easier 
editing: https://github.com/TokenBinding/Internet-Drafts

Cheers,

Andrei

-Original Message-
From: Unbearable [mailto:unbearable-boun...@ietf.org] On Behalf Of Anne van 
Kesteren
Sent: Wednesday, February 11, 2015 4:19 AM
To: Arthur Barstow
Cc: public-webapps; unbeara...@ietf.org; WebAppSec WG
Subject: Re: [Unbearable] IETF seeking feedback on proposed "Token Binding" 
Working Group

On Wed, Feb 11, 2015 at 1:10 PM, Arthur Barstow  wrote:
> WebApps - please note the draft spec includes a new XHR property 
> "withRefererTokenBindingID"
> <https://tools.ietf.org/html/draft-balfanz-https-token-binding-00#section-3.4>.
>
> If anyone has feedback about the proposal, please send it to the 
> unbearable @ ietf.org list. However, comments related to the XHR 
> aspect should be Cc/Bcc to public-webapps.

Relatively recently we decided not to extend XMLHttpRequest further and 
prioritize fetch().

Can we expect a more concrete proposal to revise either or is this it?

One problem with this proposal is that it does not use the Sec-* convention for 
headers so the header can be spoofed...


--
https://annevankesteren.nl/

___
Unbearable mailing list
unbeara...@ietf.org
https://www.ietf.org/mailman/listinfo/unbearable

Re: [Unbearable] IETF seeking feedback on proposed "Token Binding" Working Group

[Anne van Kesteren]

On Wed, Feb 11, 2015 at 7:41 PM, Andrei Popov
 wrote:
> This is part of a starting point proposal for the new working group; we 
> expect the documents to change.

I think it would be best if the document was written in such a way
that any API could be plugged on top. And that it leaves changing APIs
to those working on those APIs.


> https://github.com/TokenBinding/Internet-Drafts

I filed some issues for now.


-- 
https://annevankesteren.nl/

Re: IETF seeking feedback on proposed "Token Binding" Working Group

[Anne van Kesteren]

On Wed, Feb 11, 2015 at 1:10 PM, Arthur Barstow  wrote:
> WebApps - please note the draft spec includes a new XHR property
> "withRefererTokenBindingID"
> .
>
> If anyone has feedback about the proposal, please send it to the
> unbearable @ ietf.org list. However, comments related to the XHR aspect
> should be Cc/Bcc to public-webapps.

Relatively recently we decided not to extend XMLHttpRequest further
and prioritize fetch().

Can we expect a more concrete proposal to revise either or is this it?

One problem with this proposal is that it does not use the Sec-*
convention for headers so the header can be spoofed...


-- 
https://annevankesteren.nl/

IETF seeking feedback on proposed "Token Binding" Working Group

[Arthur Barstow]

[ public-webapps should have been included but was not ]

 Forwarded Message 
Subject:IETF seeking feedback on proposed "Token Binding" Working Group
Date:   Wed, 11 Feb 2015 07:00:35 -0500
From:   Arthur Barstow 
Reply-To:   unbeara...@ietf.org
CC: Stephen Farrell 



[ Bcc: WebApps, WebAppSec, Web Security IG; Reply-to: unbearable @
ietf.org ]

Hi All,

Below is an e-mail from Stephen Farrell regarding a proposed "Token
Binding" Working Group at the IETF. Stephen is interested in feedback
regarding the proposed group:

* Home: <https://datatracker.ietf.org/wg/tokbind/charter/>
* Draft spec:
<https://tools.ietf.org/html/draft-balfanz-https-token-binding>
* List archive:
<http://www.ietf.org/mail-archive/web/unbearable/current/maillist.html>

The Draft charter includes:

[[
Web services generate various security tokens (e.g. HTTP cookies, OAuth
tokens, etc.) for web applications to access protected resources.
Currently these are bearer tokens, i.e. any party in possession of such
token gains access to the protected resource. Attackers export bearer
tokens from client machines or from compromised network connections,
present these bearer tokens to Web services, and impersonate
authenticated users. Token Binding enables defense against such attacks
by cryptographically binding security tokens to a secret held by the client.

The tasks of this working group are as follows:

1. Specify the Token Binding protocol v1.0.
2. Specify the use of the Token Binding protocol in combination with HTTPS.

...
]]

WebAppSec, Web Security IG - this is mainly an FYI for you.

WebApps - please note the draft spec includes a new XHR property
"withRefererTokenBindingID"
<https://tools.ietf.org/html/draft-balfanz-https-token-binding-00#section-3.4>.

If anyone has feedback about the proposal, please send it to the
unbearable @ ietf.org list. However, comments related to the XHR aspect
should be Cc/Bcc to public-webapps.

-Thanks, AB


On 6 Feb 2015, at 8:40 am, Stephen Farrell  wrote:


Hi Mark & W3C folks,

(I'm cc'ing various W3C folks I know in case one of you just know
the answer and can save us some iterations, apologies to the others
of you:-)

We're starting the chartering process for a WG aiming to do better
than bearer tokens. [1] As of now, it looks like that has a good
chance of getting into some or all browsers which is great. We'll
see what else turns up during the chartering process as usual, and
please do comment on that also as usual.

One thing I noted is that the current draft [2] for part of this
work proposes (in section 3.4 [3]) a small change to XHR, so I
wanted to bring that up with you and see if you think that's a
thing that'll need to be addressed during chartering or if it's
ok to handle later (in whatever is the right manner) after we've
chartered an IETF WG. Or maybe it's something that's already done
or bring done in W3C.

The informal IESG evaluation of this charter is set for Feb 19th,
so if we could figure it out by then that'd be great. If not,
we've another couple of weeks of external review when we can get
it done, but I'd prefer be quick if we can.

And in case it helps, I think the simplest way to handle this if
the change turns out to be needed in the end, would be for the
relevant folks to just keep chatting and ideally get that XHR
change tee'd up in W3C. In the meantime, the IETF spec could say
something like "if you did change XHR in such-and-such a way then..."
just so's we don't get in one another's way. Or maybe some other
plan is better.

Anyway, please let me know who's the right W3C person to keep
in the loop on this and hopefully let's sort it out in the next
week or so.

Cheers,
Stephen.



[1]https://datatracker.ietf.org/wg/tokbind/charter/
[2]https://tools.ietf.org/html/draft-balfanz-https-token-binding
[3]
https://tools.ietf.org/html/draft-balfanz-https-token-binding-00#section-3.4