Subject: [Unbearable] one proposal for a charter - please dicsuss

From: Stephen Farrell <[email-masked]>
Date: Mon, 08 Dec 2014 23:19:28 +0000

Hi all,

There's about 70+ people on the list now so let's kick off.

Andrei sent Kathleen and I the charter proposal below a while
ago. For myself I don't think its quite right yet but I'd
rather hear what you all think. So please discuss...

Cheers,
S.

Token Binding (TB)

Charter for Working Group

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. The idea of Token Binding is to prevent such
attacks by cryptographically binding security tokens to the TLS layer.

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.

It is a goal of this working group to prevent security token export and
replay attacks, but other issues associated with the use of security
tokens are out of scope. It is a goal of this working group to design
the Token Binding protocol such that it would be also useable with
application protocols other than HTTPS, however specifying such uses is
not a primary goal.

Some of the main design goals for the Token Binding protocol, in no
particular order:
1.            Prevent export and replay of security tokens.
2.            Allow strong key protection, e.g. using hardware-bound keys.
3.            Support both first-party and federation scenarios.
4.            Preserve user privacy.
5.            Make the Token Binding protocol useable in combination
with a variety of application protocols.
6.            Allow the negotiation of the Token Binding protocol
without additional round-trips.
7.            Allow the use of multiple cryptographic algorithms, so
that a variety of secure hardware modules with different cryptographic
capabilities could be used with Token Binding.

The working group will use the following documents as a starting point
for its work:
-              draft-popov-token-binding-00;
-              draft-balfanz-https-token-binding-00.

This WG will collaborate with other IETF WGs, in particular with the
TLS, HTTPbis and Oauth WGs.

Milestones:

March 2015: WG document for the Token Binding Protocol v1.0.
March 2015: WG document for HTTPS Token Binding.
November 2015: Token Binding Protocol v1.0 to IESG.
November 2015: HTTPS Token Binding to IESG.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 8 Dec 2014 18:42:00 -0500

> application protocols other than HTTPS, however specifying such uses is

Umm, I am still rather fuzzy about what is proposed here Stephen.

In particular I don't think we are getting away from bearer tokens, we are
just hiding them different.

This is a draft I have been working on for a while. It allows a token to be
bound to a HTTP/TLS channel.

http://tools.ietf.org/html/draft-hallambaker-httpsession-03

It might help if we had a definition of bearer token. I don't think that
formulation is helping. The problem is not that we have bearer tokens, it
is that our proofs of possession force them to be disclosed in plaintext to
the party checking them.

Is an RSA private key a bearer token?
How about a kerberos ticket?

Presenting this as a problem with the token puts us off track. The problem
is with the way we use them.

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 09 Dec 2014 00:01:48 +0000

Hi Phill,

> Umm, I am still rather fuzzy about what is proposed here Stephen.

'tisn't my proposal so I'll let those who are making the proposal
answer you in detail. The charter proposal came from Andrei and
you can see the authors in the drafts listed there.

That said, I do think the term bearer token is clear enough and
private keys and kerberos tickets don't qualify as they won't be
accepted if you just send them over the wire as-is.

And from memory, yes, your draft was a proposal in roughly this
space. (Roughly, since we're now in the process of figuring out
the borders of "this space.")

S.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 8 Dec 2014 21:23:00 -0500

On Mon, Dec 8, 2014 at 8:52 PM, Andrei Popov <[email-masked]>
wrote:

>  Hi Phillip,
>
>
>
> Ø  In particular I don't think we are getting away from bearer tokens, we
> are just hiding them different.
>
>
>
> The Token Binding Protocol I-D
> <http://tools.ietf.org/html/draft-popov-token-binding-00> provides a
> mechanism for binding security tokens to the TLS layer. When a bound token
> is presented to a server, the server verifies the token binding and rejects
> the token if the binding verification fails. Therefore, such bound tokens
> are not bearer tokens: they are resistant to export and replay attacks.
>
>
>
> Ø  This is a draft I have been working on for a while. It allows a token
> to be bound to a HTTP/TLS channel.
>
>
>
> I agree that your draft is designed to solve a similar problem, although
> the approach you’ve taken is different in multiple ways. We can discuss
> these differences, but perhaps we should first focus on establishing the WG
> charter.
>
>
>
We have a lot of efforts in this space. What I think distinguishes them is
the intended scope of use and which parts of the Web infrastructure it is
proposed to change.

One of the main constraints on the Web authentication/authorization
proposals has been that they have to work with existing browsers. Accepting
that constraint means a lot more corner cases that have to be considered
and a weaker result.

Another big difference is whether a bearer token has to be human friendly
or not. If we are talking about credentials generated by machines for
machines then we can go all 256 bit without penalty. If we have to deal
with users then it gets a lot harder.

---

From: Andrei Popov <[email-masked]>
Date: Tue, 9 Dec 2014 01:52:34 +0000

Hi Phillip,

Ø  In particular I don't think we are getting away from bearer tokens, we are just hiding them different.

The Token Binding Protocol I-D<http://tools.ietf.org/html/draft-popov-token-binding-00> provides a mechanism for binding security tokens to the TLS layer. When a bound token is presented to a server, the server verifies the token binding and rejects the token if the binding verification fails. Therefore, such bound tokens are not bearer tokens: they are resistant to export and replay attacks.

Ø  This is a draft I have been working on for a while. It allows a token to be bound to a HTTP/TLS channel.

I agree that your draft is designed to solve a similar problem, although the approach you’ve taken is different in multiple ways. We can discuss these differences, but perhaps we should first focus on establishing the WG charter.

Cheers,

Andrei

From: Unbearable [mailto:[email-masked]] On Behalf Of Phillip Hallam-Baker
Sent: Monday, December 8, 2014 3:42 PM
To: Stephen Farrell
Cc: [email-masked]
Subject: Re: [Unbearable] one proposal for a charter - please dicsuss

On Mon, Dec 8, 2014 at 6:19 PM, Stephen Farrell <[email-masked]<mailto:[email-masked]>> wrote:

Hi all,

Cheers,
S.

Token Binding (TB)

In particular I don't think we are getting away from bearer tokens, we are just hiding them different.

This is a draft I have been working on for a while. It allows a token to be bound to a HTTP/TLS channel.

It might help if we had a definition of bearer token. I don't think that formulation is helping. The problem is not that we have bearer tokens, it is that our proofs of possession force them to be disclosed in plaintext to the party checking them.

Presenting this as a problem with the token puts us off track. The problem is with the way we use them.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 10 Dec 2014 18:05:15 -0500

On Wed, Dec 10, 2014 at 3:45 PM, Andrei Popov <[email-masked]>
wrote:

>  Ø  One of the main constraints on the Web authentication/authorization
> proposals has been that they have to work with existing browsers.
>
> Yes, this is a valid constraint, and it does affect the design choices.
> Perhaps we should make this more explicit in the charter.
>

What is the design space here? Are we fitting into existing browsers or
not?

I am rather fed up of the idea that we never ever consider doing the job
right. Yes it might take ten years before we reach 95% penetration but we
can get to 30% in one Chrome release cycle. With Windows 10 we can expect
something like 80% of the browsers to be on automatic update.

And we did SAML ten years ago now. Think of where we might be now had we
done a clean implementation along side the legacy preserving then.

We don't need to make a leap in the dark here either. Web Services use HTTP
and there are brand new ones every week. So if we design something that can
be used for Web Services, we can eventually use it for other purposes.

Even a 30% reduction in affiliate fraud is real money.

The way I map out the space for authentication is that I see three separate
processes, all of which are called 'authentication' but are different
things. I was once on a panel on 'reauthentication' and the two other
speakers had incompatible definitions.

1) Credential Issue
     This may or may not involve authentication of Alice, in the PKI world
we call it validation.

2) Use of credential to initiate session
     Where I suspect this is to be situated, currently password oriented.

3) Session continuation
     Currently the weakest of the lot, the fact we use cookies as bearer
tokens in HTTPS makes eavy demands on the crypto protocol.

---

From: John Bradley <[email-masked]>
Date: Wed, 10 Dec 2014 23:16:39 +0000

As I understand it this is proposing a change to browsers.  Browsers will need to be updated.  There is a pre standard version of this in Chrome now but even that would need to change.

I don’t think this WG is considering anything that would work with a current browser.

That is why I don’t think it overlaps with current OAuth work using static client keys.

John B.

> On Dec 10, 2014, at 11:05 PM, Phillip Hallam-Baker <[email-masked]> wrote:
> 
> On Wed, Dec 10, 2014 at 3:45 PM, Andrei Popov <[email-masked] <mailto:[email-masked]>> wrote:
> Ø  One of the main constraints on the Web authentication/authorization proposals has been that they have to work with existing browsers.
> 
> Yes, this is a valid constraint, and it does affect the design choices. Perhaps we should make this more explicit in the charter.
> 
> 
> What is the design space here? Are we fitting into existing browsers or not? 
> 
> I am rather fed up of the idea that we never ever consider doing the job right. Yes it might take ten years before we reach 95% penetration but we can get to 30% in one Chrome release cycle. With Windows 10 we can expect something like 80% of the browsers to be on automatic update.
> 
> And we did SAML ten years ago now. Think of where we might be now had we done a clean implementation along side the legacy preserving then.
> 
> 
> We don't need to make a leap in the dark here either. Web Services use HTTP and there are brand new ones every week. So if we design something that can be used for Web Services, we can eventually use it for other purposes.
> 
> The way I map out the space for authentication is that I see three separate processes, all of which are called 'authentication' but are different things. I was once on a panel on 'reauthentication' and the two other speakers had incompatible definitions.
> 
> 1) Credential Issue
>      This may or may not involve authentication of Alice, in the PKI world we call it validation.
> 
>      Currently the weakest of the lot, the fact we use cookies as bearer tokens in HTTPS makes eavy demands on the crypto protocol.
> 
> 
> _______________________________________________
> Unbearable mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/unbearable

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 10 Dec 2014 21:12:38 -0500

On Wed, Dec 10, 2014 at 6:16 PM, John Bradley <[email-masked]> wrote:

> As I understand it this is proposing a change to browsers.  Browsers will
> need to be updated.  There is a pre standard version of this in Chrome now
> but even that would need to change.
>

OK, that does make a major difference.

---

From: Bill Mills <[email-masked]>
Date: Thu, 11 Dec 2014 05:07:36 +0000 (UTC)

Nothing in the current OAuth work requires a static client key as far as I know.  No reason a key can't be issued per credential just like in OAuth 1.0a or bound to a cred if the client provides a public key when it authenticates. 

     On Wednesday, December 10, 2014 6:12 PM, Phillip Hallam-Baker <[email-masked]> wrote:

1) Credential Issue     This may or may not involve authentication of Alice, in the PKI world we call it validation.
2) Use of credential to initiate session     Where I suspect this is to be situated, currently password oriented.
3) Session continuation     Currently the weakest of the lot, the fact we use cookies as bearer tokens in HTTPS makes eavy demands on the crypto protocol.

---

From: Yoav Nir <[email-masked]>
Date: Thu, 11 Dec 2014 08:33:25 +0200

> On Dec 11, 2014, at 4:12 AM, Phillip Hallam-Baker <[email-masked]> wrote:
> 
> 
> 
> On Wed, Dec 10, 2014 at 6:16 PM, John Bradley <[email-masked] <mailto:[email-masked]>> wrote:

Looking at the proposals, it’s mostly (3) with a little bit about (2)

What I am worried about is that it addresses just one of the issues in HTTP cookies. The other (bigger, IMO) issue is with the scope of cookies, and there are two drafts proposed in httpbis (and not getting much discussion) that attempt to address that.

A poor outcome would be two or three “new cookie” mechanisms, each addressing just one of the shortcomings of cookies. That would be bad for both browser implementers and application developers.

Yoav

---

From: John Bradley <[email-masked]>
Date: Thu, 11 Dec 2014 07:47:45 +0000

Bill,

Yes in OAuth we can issue keys on a per token basis to the client.   However these specs are about the browser, and we don’t currently have any thing for browser clients other than being public.

Currently we have no way to get a key into the browser that can be used across connections.
Even with web crypto we can only provision a key that works with a single origin as I understand it.

These specs create a way for the browser to expose the public key material that it uses for its end of mutual TLS connections, and allow that to be communicated across related sessions.
Allowing it to be communicated between related sessions is new to this proposal and a limitation of the original channel binding and origin bound certificates.

If we called this something like "Interface for exposing Origin bound public keys”  then people might be less worked up (though some are concerned about overlap with HTTP bis and other things that are unrelated to tokens).   It is the spec using the term token in the name that infers a larger scope.

I am not one of the proposers of this WG.   But I read the proposal as something OAuth can use to fill a gap, like we use TLS, not something that intends to compete with OAuth.

I suspect that this won’t impact the existing POP work for server and native OAuth clients at all.   This will allow us to do something for implicit clients however.

John B.

> On Dec 11, 2014, at 5:07 AM, Bill Mills <[email-masked]> wrote:
> 
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/unbearable <https://www.ietf.org/mailman/listinfo/unbearable>
> 
> 
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/unbearable <https://www.ietf.org/mailman/listinfo/unbearable>
> 
>

---

From: Phil Hunt <[email-masked]>
Date: Thu, 11 Dec 2014 08:49:32 -0800

I think my concern is that the announcement sounds too duplicative of the POP work. 

The charter wording is going to be critical. 

I am not clear yet that this work is browser only. 

Phil

> On Dec 10, 2014, at 23:47, John Bradley <[email-masked]> wrote:
> 
> Bill,
>

---

From: Bill Mills <[email-masked]>
Date: Thu, 11 Dec 2014 17:17:35 +0000 (UTC)

If this is about client certs stored and available to  the browser to use that's a different and interesting question.  Is that really just using the browser cert store as a key manager? 

     On Thursday, December 11, 2014 9:08 AM, Phil Hunt <[email-masked]> wrote:

Phil

Bill,
Yes in OAuth we can issue keys on a per token basis to the client.   However these specs are about the browser, and we don’t currently have any thing for browser clients other than being public.
Currently we have no way to get a key into the browser that can be used across connections.Even with web crypto we can only provision a key that works with a single origin as I understand it.
These specs create a way for the browser to expose the public key material that it uses for its end of mutual TLS connections, and allow that to be communicated across related sessions.Allowing it to be communicated between related sessions is new to this proposal and a limitation of the original channel binding and origin bound certificates.
If we called this something like "Interface for exposing Origin bound public keys”  then people might be less worked up (though some are concerned about overlap with HTTP bis and other things that are unrelated to tokens).   It is the spec using the term token in the name that infers a larger scope.
I am not one of the proposers of this WG.   But I read the proposal as something OAuth can use to fill a gap, like we use TLS, not something that intends to compete with OAuth.
I suspect that this won’t impact the existing POP work for server and native OAuth clients at all.   This will allow us to do something for implicit clients however.
John B.

---

From: Andrei Popov <[email-masked]>
Date: Thu, 11 Dec 2014 18:53:32 +0000

Ø  If this is about client certs stored and available to  the browser to use that's a different and interesting question.
In the current proposals, these are not full client certs, but public-private key pairs.

Ø  Is that really just using the browser cert store as a key manager?
The current I-Ds provide a mechanism for the client to prove possession of a client-generated key that is protected from export. This Token Binding key could be hardware-bound or strongly protected in a different manner, depending on system capabilities. The server can bind security tokens to this key.

Cheers,

Andrei

From: Bill Mills [mailto:[email-masked]]
Sent: Thursday, December 11, 2014 9:18 AM
To: Phil Hunt; John Bradley
Cc: [email-masked]; Andrei Popov; Phillip Hallam-Baker; Stephen Farrell
Subject: Re: [Unbearable] one proposal for a charter - please dicsuss

On Thursday, December 11, 2014 9:08 AM, Phil Hunt <[email-masked]<mailto:[email-masked]>> wrote:

Phil

On Dec 10, 2014, at 23:47, John Bradley <[email-masked]<mailto:[email-masked]>> wrote:
Bill,

John B.

On Dec 11, 2014, at 5:07 AM, Bill Mills <[email-masked]<mailto:[email-masked]>> wrote:

On Wednesday, December 10, 2014 6:12 PM, Phillip Hallam-Baker <[email-masked]<mailto:[email-masked]>> wrote:

On Wed, Dec 10, 2014 at 6:16 PM, John Bradley <[email-masked]<mailto:[email-masked]>> wrote:
As I understand it this is proposing a change to browsers.  Browsers will need to be updated.  There is a pre standard version of this in Chrome now but even that would need to change.

1) Credential Issue

3) Session continuation

_______________________________________________
Unbearable mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/unbearable

_______________________________________________
Unbearable mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/unbearable

_______________________________________________
Unbearable mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/unbearable

_______________________________________________
Unbearable mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/unbearable

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 11 Dec 2014 14:05:35 -0500

On Thu, Dec 11, 2014 at 1:53 PM, Andrei Popov <[email-masked]>
wrote:

>  Ø  If this is about client certs stored and available to  the browser to
> use that's a different and interesting question.
>
> The current I-Ds provide a mechanism for the client to prove possession of
> a client-generated key that is protected from export. This Token Binding
> key could be hardware-bound or strongly protected in a different manner,
> depending on system capabilities. The server can bind security tokens to
> this key.
>
>
>

I like public key crypto.

But this is a two party scheme. What benefit do we get from use of public
key here?

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 11 Dec 2014 14:19:35 -0500 (EST)

> But this is a two party scheme. What benefit do we get from use of public

If I remember correctly,
http://tools.ietf.org/html/draft-balfanz-https-token-binding-00 describes
a scheme which is not two-party.

-Ben

---

From: Andrei Popov <[email-masked]>
Date: Thu, 11 Dec 2014 19:25:05 +0000

Without binding, the cookie is relatively easy to export to a different machine and replay to the server, impersonating the user.

A cookie that’s bound to a key is useless, unless the attacker can also export the key (which is very difficult in the case of hardware-bound key).

The use of asymmetric key pair means that the token binding key can be generated in a hardware module, never exposed to local malware, plus the private key is never transmitted across the network.

From: [email-masked] [mailto:[email-masked]] On Behalf Of Phillip Hallam-Baker
Sent: Thursday, December 11, 2014 11:06 AM
To: Andrei Popov
Cc: Bill Mills; Phil Hunt; John Bradley; [email-masked]; Stephen Farrell
Subject: Re: [Unbearable] one proposal for a charter - please dicsuss

On Thu, Dec 11, 2014 at 1:53 PM, Andrei Popov <[email-masked]<mailto:[email-masked]>> wrote:

>  If this is about client certs stored and available to  the browser to use that's a different and interesting question.

>  Is that really just using the browser cert store as a key manager?

But this is a two party scheme. What benefit do we get from use of public key here?

---

From: Andrei Popov <[email-masked]>
Date: Thu, 11 Dec 2014 19:26:40 +0000

Yes, federation scenarios where the token is generated by an Identity Provider and presented to a Relying Party are also supported.

Cheers,

Andrei

-----Original Message-----
From: Benjamin Kaduk [mailto:[email-masked]] 
Sent: Thursday, December 11, 2014 11:20 AM
To: Phillip Hallam-Baker
Cc: Andrei Popov; [email-masked]
Subject: Re: [Unbearable] one proposal for a charter - please dicsuss

> But this is a two party scheme. What benefit do we get from use of 

If I remember correctly,
http://tools.ietf.org/html/draft-balfanz-https-token-binding-00 describes a scheme which is not two-party.

-Ben

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 11 Dec 2014 14:33:10 -0500

On Thu, Dec 11, 2014 at 2:25 PM, Andrei Popov <[email-masked]>
wrote:

>  Without binding, the cookie is relatively easy to export to a different
> machine and replay to the server, impersonating the user.
>
>
>
> A cookie that’s bound to a key is useless, unless the attacker can also
> export the key (which is very difficult in the case of hardware-bound key).
>

Agreed

> The use of asymmetric key pair means that the token binding key can be
> generated in a hardware module, never exposed to local malware, plus the
> private key is never transmitted across the network.
>

They are exactly the same. Or rather they should be. The Windows API are
limited to asymmetric but that is due to a failure of imagination rather
than need.

The most appropriate way to handle keys in my view is for the TPM to store
just one key that is then used to unwrap tickets to obtain a symmetric or
asymmetric key as the need arises. This minimizes the amount of data that
the TPM needs to store.

---

From: Nico Williams <[email-masked]>
Date: Thu, 11 Dec 2014 14:00:53 -0600

> a scheme which is not two-party.

Is there a list of proposals to be discussed on this list?

Nico
--

---

From: Andrei Popov <[email-masked]>
Date: Thu, 11 Dec 2014 20:01:22 +0000

Protocol details, existing APIs, the use of TPM, etc. are all great topics to discuss as we look at the proposals. I’d be very happy to delve into these. But I thought the guidance from the ADs was to discuss the charter and set up the WG first?

Thanks,

Andrei

From: [email-masked] [mailto:[email-masked]] On Behalf Of Phillip Hallam-Baker
Sent: Thursday, December 11, 2014 11:33 AM
To: Andrei Popov
Cc: Bill Mills; Phil Hunt; John Bradley; [email-masked]; Stephen Farrell
Subject: Re: [Unbearable] one proposal for a charter - please dicsuss

On Thu, Dec 11, 2014 at 2:25 PM, Andrei Popov <[email-masked]<mailto:[email-masked]>> wrote:
Without binding, the cookie is relatively easy to export to a different machine and replay to the server, impersonating the user.

Agreed

They are exactly the same. Or rather they should be. The Windows API are limited to asymmetric but that is due to a failure of imagination rather than need.

The most appropriate way to handle keys in my view is for the TPM to store just one key that is then used to unwrap tickets to obtain a symmetric or asymmetric key as the need arises. This minimizes the amount of data that the TPM needs to store.

---

From: Nico Williams <[email-masked]>
Date: Thu, 11 Dec 2014 14:07:29 -0600

On Thu, Dec 11, 2014 at 08:01:22PM +0000, Andrei Popov wrote:
> Protocol details, existing APIs, the use of TPM, etc. are all great
> topics to discuss as we look at the proposals. I’d be very happy to
> delve into these. But I thought the guidance from the ADs was to
> discuss the charter and set up the WG first?

Existing APIs might act as constraints on some proposals.  Discovering
the rough outline of the problem space and constraints on solutions, as
well as properties we want solutions to have, seems like a worthwhile
activity at this time.  Details can be left for later.

Thoug I don't think that TPM APIs should constrain us too much here.
TPMs should be optional anyways.

Nico
--

---

From: Andrei Popov <[email-masked]>
Date: Thu, 11 Dec 2014 20:16:43 +0000

Yes on both points. If we can come to an agreement on constraints and requirements, further discussion will be more productive.

To this end, the proposed charter has some design goals listed (in no particular order):
1.            Prevent export and replay of security tokens.
2.            Allow strong key protection, e.g. using hardware-bound keys.
3.            Support both first-party and federation scenarios.
4.            Preserve user privacy.
5.            Make the Token Binding protocol useable in combination with a variety of application protocols.
6.            Allow the negotiation of the Token Binding protocol without additional round-trips.
7.            Allow the use of multiple cryptographic algorithms, so that a variety of secure hardware modules with different cryptographic capabilities could be used with Token Binding.

Cheers,

Andrei

-----Original Message-----
From: Nico Williams [mailto:[email-masked]] 
Sent: Thursday, December 11, 2014 12:07 PM
To: Andrei Popov
Cc: Phillip Hallam-Baker; John Bradley; [email-masked]; Stephen Farrell; Bill Mills; Phil Hunt
Subject: Re: [Unbearable] one proposal for a charter - please dicsuss

> discuss the charter and set up the WG first?

Existing APIs might act as constraints on some proposals.  Discovering the rough outline of the problem space and constraints on solutions, as well as properties we want solutions to have, seems like a worthwhile activity at this time.  Details can be left for later.

Nico
--

---

From: Andrei Popov <[email-masked]>
Date: Thu, 11 Dec 2014 20:24:39 +0000

The proposed charter suggests the following list of I-Ds as a starting point for the new WG:
- http://tools.ietf.org/html/draft-popov-token-binding-00;
- http://tools.ietf.org/html/draft-balfanz-https-token-binding-00.

Andrei

-----Original Message-----
From: Nico Williams [mailto:[email-masked]] 
Sent: Thursday, December 11, 2014 12:01 PM
To: Benjamin Kaduk
Cc: Phillip Hallam-Baker; Andrei Popov; [email-masked]
Subject: List of proposals? Re: one proposal for a charter - please dicsuss

On Thu, Dec 11, 2014 at 02:19:35PM -0500, Benjamin Kaduk wrote:
> http://tools.ietf.org/html/draft-balfanz-https-token-binding-00 
> describes a scheme which is not two-party.

Nico
--

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 11 Dec 2014 21:43:04 +0100

In OAuth we have explored more proposals.

Use Cases/Requirements/Architecture Document (currently in WGLC):
http://datatracker.ietf.org/doc/draft-ietf-oauth-pop-architecture/

These are the documents referenced:
http://datatracker.ietf.org/doc/draft-ietf-oauth-pop-key-distribution/
http://datatracker.ietf.org/doc/draft-ietf-oauth-proof-of-possession/
http://datatracker.ietf.org/doc/draft-ietf-oauth-signed-http-request/

Ciao
Hannes

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 11 Dec 2014 16:10:28 -0500

Given that the principal constraint here is 'what else is going on', I
think it is appropriate to look at mechanism.

We are certainly looking to solve some of the problems that OAUTH does.
That is OK with me provided that 1) we are addressing them in a different
way and 2) the differences are more than syntax or a different selection of
features.

On Thu, Dec 11, 2014 at 3:01 PM, Andrei Popov <[email-masked]>
wrote:

> topics to discuss as we look at the proposals. I’d be very happy to delve
> into these. But I thought the guidance from the ADs was to discuss the
> charter and set up the WG first?
>
>
>
> Thanks,
>
>
>
> Andrei
>
>
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf Of *Phillip
> Hallam-Baker
> *Sent:* Thursday, December 11, 2014 11:33 AM
> *To:* Andrei Popov
> *Cc:* Bill Mills; Phil Hunt; John Bradley; [email-masked]; Stephen
> Farrell
> *Subject:* Re: [Unbearable] one proposal for a charter - please dicsuss
>
>
>
>
>
>
>

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 11 Dec 2014 22:01:28 +0000

> discuss the charter and set up the WG first?

As I read it, I think people are trying to feel out the right
scope and distinguish that from current work so some level of
diving into detail should be expected (and hey, that's what
we do and when did we ever manage to resist doing just that;-).

For the particular question, I guess a symmetric solution would
differ from an asymmetric one in a few ways that might impinge
on scope, so highish level discussion of that should prove
useful. But yes, the specific details of how one might protect
a private/secret key are probably for later to the extent that
they'd ever be part of the IETF work as opposed to the work
for implementers.

Hope that helps,
S.

> 
> Thanks,
> 
> Andrei
> 
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Phillip
> Hallam-Baker Sent: Thursday, December 11, 2014 11:33 AM To: Andrei
> Popov Cc: Bill Mills; Phil Hunt; John Bradley; [email-masked];
> Stephen Farrell Subject: Re: [Unbearable] one proposal for a charter
> - please dicsuss
> 
> 
> 
> On Thu, Dec 11, 2014 at 2:25 PM, Andrei Popov
> <[email-masked]<mailto:[email-masked]>>
> wrote: Without binding, the cookie is relatively easy to export to a
> different machine and replay to the server, impersonating the user.
> 
> A cookie that’s bound to a key is useless, unless the attacker can
> also export the key (which is very difficult in the case of
> hardware-bound key).
> 
> Agreed
> 
> The use of asymmetric key pair means that the token binding key can
> be generated in a hardware module, never exposed to local malware,
> plus the private key is never transmitted across the network.
> 
> They are exactly the same. Or rather they should be. The Windows API
> are limited to asymmetric but that is due to a failure of imagination
> rather than need.
> 
> 
> The most appropriate way to handle keys in my view is for the TPM to
> store just one key that is then used to unwrap tickets to obtain a
> symmetric or asymmetric key as the need arises. This minimizes the
> amount of data that the TPM needs to store.
> 
> 
> 
> 
> 
> _______________________________________________ Unbearable mailing
> list [email-masked]

---

From: Phil Hunt <[email-masked]>
Date: Thu, 11 Dec 2014 14:34:41 -0800

This event in the press also heavily influenced the POP discussions on symmetric vs. asymmetric:

http://www.programmableweb.com/news/why-attack-buffer-was-serious-wake-call-web/analysis/2013/11/04

There was concern that symmetric keys could easily be stored with tokens and likely will (as in the case of OAuth1). If the database is compromised (as was the case in buffer.com), both the key and the tokens are lost. 

Asymmetric keys by their nature tend to have the private key kept securely. Further, a client could use the same key-pair for multiple separate access tokens issued to it by a service provider.  This can also get us away from the 1:1 key for token paradigm and leads to something naturally more secure (meaning a developer has to work extra hard to mess this up).

Phil

@independentid
www.independentid.com
[email-masked]

> On Dec 11, 2014, at 12:43 PM, Hannes Tschofenig <[email-masked]> wrote:
>

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 11 Dec 2014 18:20:26 -0500

On Thu, Dec 11, 2014 at 5:34 PM, Phil Hunt <[email-masked]> wrote:

> There was concern that symmetric keys could easily be stored with tokens
> and likely will (as in the case of OAuth1). If the database is compromised
> (as was the case in buffer.com), both the key and the tokens are lost.
>
> Asymmetric keys by their nature tend to have the private key kept
> securely. Further, a client could use the same key-pair for multiple
> separate access tokens issued to it by a service provider.  This can also
> get us away from the 1:1 key for token paradigm and leads to something
> naturally more secure (meaning a developer has to work extra hard to mess
> this up).
>

OK I concede the point if you don't have a TPM. If you do then you can play
Kerberos ticket games which makes the two systems equivalent.

These are pairwise secrets rather than a universal key so its not like when
Gawker got rolled and my universal password for all the accounts I don't
care about the asset being protected was disclosed.

What I think it comes down to is the time between interactions. Do we want
to do a public key interaction on every HTTP transaction?

---

From: Andrei Popov <[email-masked]>
Date: Thu, 11 Dec 2014 23:36:12 +0000

The current Token Binding I-Ds do not require public key operations on every HTTP transaction.

In the “fist-party” scenario (Identity Provider generating a security token to be presented back to this Identity Provider), the client proves possession of the private key once per TLS handshake. Multiple requests within the same TLS connection do not result in multiple public key operations.

In the “federation” scenario (Identity Provider generating a security token for a Relying Party to consume), the client proves possession of one additional key per Relying Party.

Cheers,

Andrei

From: [email-masked] [mailto:[email-masked]] On Behalf Of Phillip Hallam-Baker
Sent: Thursday, December 11, 2014 3:20 PM
To: Phil Hunt
Cc: Hannes Tschofenig; Andrei Popov; Nico Williams; Benjamin Kaduk; [email-masked]
Subject: Re: [Unbearable] List of proposals? Re: one proposal for a charter - please dicsuss

On Thu, Dec 11, 2014 at 5:34 PM, Phil Hunt <[email-masked]<mailto:[email-masked]>> wrote:
This event in the press also heavily influenced the POP discussions on symmetric vs. asymmetric:

There was concern that symmetric keys could easily be stored with tokens and likely will (as in the case of OAuth1). If the database is compromised (as was the case in buffer.com<http://buffer.com>), both the key and the tokens are lost.

OK I concede the point if you don't have a TPM. If you do then you can play Kerberos ticket games which makes the two systems equivalent.

These are pairwise secrets rather than a universal key so its not like when Gawker got rolled and my universal password for all the accounts I don't care about the asset being protected was disclosed.

What I think it comes down to is the time between interactions. Do we want to do a public key interaction on every HTTP transaction?

---

From: Nico Williams <[email-masked]>
Date: Thu, 11 Dec 2014 17:41:26 -0600

> to do a public key interaction on every HTTP transaction?

This is exactly the same sub-thread as we saw on the TLS list as to
resumption and the OPTLS proposal.  We'll probably reach similar
conclusions.

Nico
--

---

From: Andrei Popov <[email-masked]>
Date: Wed, 10 Dec 2014 20:45:05 +0000

Cheers,

Andrei

From: [email-masked] [mailto:[email-masked]] On Behalf Of Phillip Hallam-Baker
Sent: Monday, December 8, 2014 6:23 PM
To: Andrei Popov
Cc: Stephen Farrell; [email-masked]
Subject: Re: [Unbearable] one proposal for a charter - please dicsuss

On Mon, Dec 8, 2014 at 8:52 PM, Andrei Popov <[email-masked]<mailto:[email-masked]>> wrote:
Hi Phillip,

We have a lot of efforts in this space. What I think distinguishes them is the intended scope of use and which parts of the Web infrastructure it is proposed to change.

One of the main constraints on the Web authentication/authorization proposals has been that they have to work with existing browsers. Accepting that constraint means a lot more corner cases that have to be considered and a weaker result.

Another big difference is whether a bearer token has to be human friendly or not. If we are talking about credentials generated by machines for machines then we can go all 256 bit without penalty. If we have to deal with users then it gets a lot harder.

---

From: Andrei Popov <[email-masked]>
Date: Thu, 11 Dec 2014 00:12:38 +0000

The current I-Ds do propose a change in the HTTP stack (new HTTP headers). But I think it is a valid requirement that whatever solution we arrive at must work for Web browsers. E.g. this means that security tokens must be presentable over multiple TLS sessions and connections, etc.

From: John Bradley [mailto:[email-masked]]
Sent: Wednesday, December 10, 2014 3:17 PM
To: Phillip Hallam-Baker
Cc: Andrei Popov; [email-masked]; Stephen Farrell
Subject: Re: [Unbearable] one proposal for a charter - please dicsuss

John B.

On Dec 10, 2014, at 11:05 PM, Phillip Hallam-Baker <[email-masked]<mailto:[email-masked]>> wrote:

On Wed, Dec 10, 2014 at 3:45 PM, Andrei Popov <[email-masked]<mailto:[email-masked]>> wrote:
>  One of the main constraints on the Web authentication/authorization proposals has been that they have to work with existing browsers.

1) Credential Issue

3) Session continuation

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 11 Dec 2014 22:00:05 -0500 (EST)

On Thu, 11 Dec 2014, Phil Hunt wrote:

> separate access tokens issued to it by a service provider.  This can
> also get us away from the 1:1 key for token paradigm and leads to
> something naturally more secure (meaning a developer has to work extra
> hard to mess this up).

This does have the property that conspiring resource servers can track the
user based on that reused public key (as is noted in many of the documents
floating around).  But, I guess that is a discussion to have after there
is a charter (i.e., later).

-Ben

---

From: Andrei Popov <[email-masked]>
Date: Fri, 12 Dec 2014 03:11:59 +0000

The current Token Binding IDs mitigate this by using different Token Binding keys to connect to different resource servers, according to the token scoping rules of the application protocol (for HTTPS this means a Token Binding key per eTLD).

Additionally, the Token Binding keys can be deleted by the user at any time, e.g. when clearing browser cookies.

Cheers,

Andrei

-----Original Message-----
From: Unbearable [mailto:[email-masked]] On Behalf Of Benjamin Kaduk
Sent: Thursday, December 11, 2014 7:00 PM
To: Phil Hunt
Cc: [email-masked]
Subject: Re: [Unbearable] List of proposals? Re: one proposal for a charter - please dicsuss

> something naturally more secure (meaning a developer has to work extra 

This does have the property that conspiring resource servers can track the user based on that reused public key (as is noted in many of the documents floating around).  But, I guess that is a discussion to have after there is a charter (i.e., later).

-Ben

---

From: John Bradley <[email-masked]>
Date: Fri, 12 Dec 2014 10:11:33 +0000

Yes the current OAuth work is based on what is currently available to native applications only.   Clarifying that this is new functionality for browsers/user agents will help, I think. 

John B. 

Sent from my iPhone

> On Dec 10, 2014, at 8:45 PM, Andrei Popov <[email-masked]> wrote:
> 
> On Mon, Dec 8, 2014 at 8:52 PM, Andrei Popov <[email-masked]> wrote:
> Hi Phillip,
>  
> The Token Binding Protocol I-D provides a mechanism for binding security tokens to the TLS layer. When a bound token is presented to a server, the server verifies the token binding and rejects the token if the binding verification fails. Therefore, such bound tokens are not bearer tokens: they are resistant to export and replay attacks.
>

---

From: [email-masked]
Date: Sun, 14 Dec 2014 01:27:32 +0100

Hi All,

I'm catching up from oldest first, so apologies if someone else has already said te same, but the volume of messages generated at the moment precudes me sifting upward.

I think the point Andrei was making was that in the sense of pursuing the ideal, and not the ad-hock, perhaps it might be better to design for the thoeretical ideal, and once that is clear to make requests to browser developers as to what might be needed from thier systems.

Otherwise we fall into the never-ending-story of upon each iteration of browser geberation, the group has to start again.

I'm more of a get-it-right-first-time person. Further non-group involvement would just fine tuning etc.

Salutem

Dean

Gesendet: Mittwoch, 10. Dezember 2014 um 21:45 Uhr

Von: "Andrei Popov" <[email-masked]>

An: "Phillip Hallam-Baker" <[email-masked]>

Cc: "[email-masked]" <[email-masked]>, "Stephen Farrell" <[email-masked]>

Betreff: Re: [Unbearable] one proposal for a charter - please dicsuss

Cheers,

Andrei

To: Andrei Popov

Hi Phillip,

_______________________________________________ Unbearable mailing list [email-masked] https://www.ietf.org/mailman/listinfo/unbearable