Subject: [Unbearable] Scoping of keys on the client.

From: John Bradley <[email-masked]>
Date: Fri, 13 Mar 2015 13:56:46 -0300

Now that we are officially a WG I have a question (no hat)

One thing that I identified as a potential issue talking to people who are working on early deployments, is the expectations around how keys are shared between applications.

I found some people that believe all apps sharing a common TLS library would be able to share the same ID/key for a origin.

Other folks were under the impression that each application would have its own key for an origin.

The different views impact security considerations in native environments.   As an example can you pass a token from one app to another and have it still work to the same origin, or is it a security feature that it won't work and the token cant be stolen from a app and re-used by a different app on the same device.

There was a middle view by the MDM people that the ID/key would be scoped to a profile/container so that all the enterprise apps would share ID/key but that social apps would not.

I don't know that there is necessarily one right answer, as this may be implementation dependent.  

I don't think there is anything in the specs on this.   One reason I ask is that some of those differences impact on Native Application Single Signon and OAuth.

In some of the Windows prototypes I understand there is a Key Storage API that is used to share keys between the browser and apps.  

Android, Windows, iOS , OSX may all have implementation specific details, but people building applications that leverage token binding will need to understand the differences as they may have security and privacy implications.

Figuring out where some of these issues get documented might be useful.

John B.

---

From: Andrei Popov <[email-masked]>
Date: Fri, 13 Mar 2015 17:18:52 +0000

Thanks for raising this topic John.

> I found some people that believe all apps sharing a common TLS library would be able to share the same ID/key for a origin.
In our prototypes so far (in Win10), the Token Binding Protocol implementation, the Token Binding key storage APIs, and the TLS library are three separate components. Among other things, this allows 3-rd-party apps share Token Binding keys and achieve single sign-on regardless of the TLS library they might be using (if they choose to do so).

> The different views impact security considerations in native environments.   As an example can you pass a token from one app to another and have it still work to the same origin, or is it a securit…
I think that single sign-on between apps and browsers is at least a useful option.

> I don't think there is anything in the specs on this.
Documenting key scoping is indeed useful; on the other hand standardizing the specifics might require standardizing user and application isolation models across platforms, which I don't think would be in scope for this forum. Perhaps we could agree on some general principles and include implementation guidance on Token Binding key scoping?

Cheers,

Andrei

-----Original Message-----
From: Unbearable [mailto:[email-masked]] On Behalf Of John Bradley
Sent: Friday, March 13, 2015 9:57 AM
To: [email-masked]
Subject: [Unbearable] Scoping of keys on the client.

John B.

---

From: John Bradley <[email-masked]>
Date: Fri, 13 Mar 2015 14:43:21 -0300

Certainly in some potential OAuth use-cases where we want o encourage people to use the system browser vs a embedded web view, we may want to use the same key to bind a code in the browser and a native app.    

I think understanding how applications outside the browser or between browsers are going to share keys is worth putting some time into so that at a minimum developers will understand the issues.

In the Win10 prototype do you have some way to have a browser or app restrict the sharing of the key?  
Sort of a non exportable flag, though in principal the keys themselves are never exportable but the use of them is shared.

John B.

> On Mar 13, 2015, at 2:18 PM, Andrei Popov <[email-masked]> wrote:
>

---

From: Phil Hunt <[email-masked]>
Date: Fri, 13 Mar 2015 10:46:55 -0700

The problem being that this just becomes device binding and app to app token binding still isn't possible. 

Do we care?

Phil

> On Mar 13, 2015, at 10:18, Andrei Popov <[email-masked]> wrote:
> 
> _______________________________________________
> Unbearable mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/unbearable

---

From: John Bradley <[email-masked]>
Date: Fri, 13 Mar 2015 16:58:21 -0300

I think it is important to think through how the choices may impact how protocols can use token binding. 

The NAAPS profile of connect is a possible candidate for using token binding but that is highly dependent on how keys are shared on the client. 

A simple OAuth use case is using token binding to secure a refresh token.  

How secure that is would depend on what other apps on the device may be able to use that token if it leaked. 

Understanding how keys are shared between apps is I think important. 

John B

Sent from my iPhone

> On Mar 13, 2015, at 2:46 PM, Phil Hunt <[email-masked]> wrote:
>

---

From: Phil Hunt <[email-masked]>
Date: Fri, 13 Mar 2015 13:22:22 -0700

Maybe I am recalling wrongly, but I don’t think OAuth WG discussed securing refresh tokens using binding (yet).  The OAuth POP use cases were focused on app-to-app access token security.

Phil

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

> On Mar 13, 2015, at 12:58 PM, John Bradley <[email-masked]> wrote:
>

---

From: Bill Mills <[email-masked]>
Date: Fri, 13 Mar 2015 20:42:03 +0000 (UTC)

It would fit into client auth pretty cleanly. 

     On Friday, March 13, 2015 1:22 PM, Phil Hunt <[email-masked]> wrote:

Phil

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

---

From: John Bradley <[email-masked]>
Date: Fri, 13 Mar 2015 18:20:59 -0300

I used that as an example.  I know one AS that is doing that for refresh tokens as it doesn't require any client or protocol change.  

No the WG haven't discussed it.

The POP use case for AT is focused on app/client to RS.   Given that the AS and RS may not be in the same domain using token binding to secure the AT to the RS gets trickier.

In principal if the client knows the the URI of the resource server it could make a request to the RS and then take the public key and put it in a JWK to push to the AS as part of the existing POP key distribution spec. 

The client would then get back a AT bound to that key.

That limits the client to only using a single RS as tin the current spec the key is only exchanged for code.

The key could be sent with refresh tokens if we wanted to allow multiple RS with different keys, however to do that securely you really want to secure the refresh token, to do that in a public client the AS could use token binding.

Those are issues the OAuth WG will need to look at.   To do that properly knowing things like if the RT leaks to another app on the device can it still be used?  Those questions need to be answered to formulate security considerations, and determine if token binding is the correct tool to use for a given use case.

John B.

> On Mar 13, 2015, at 5:22 PM, Phil Hunt <[email-masked]> wrote:
>

---

From: Anthony Nadalin <[email-masked]>
Date: Sun, 15 Mar 2015 00:37:04 +0000

Understanding how keys are shared between apps, is an app thing as there can be countless ways, the app that puts the key(s) there needs to be able to document how it expects the sharing to occur.

-----Original Message-----
From: Unbearable [mailto:[email-masked]] On Behalf Of John Bradley
Sent: Friday, March 13, 2015 12:58 PM
To: Phil Hunt
Cc: Andrei Popov; [email-masked]
Subject: Re: [Unbearable] Scoping of keys on the client.

John B

Sent from my iPhone

---

From: John Bradley <[email-masked]>
Date: Sat, 14 Mar 2015 22:24:18 -0300

I was and until told otherwise under the impression that the private keys are explicitly not exposed to the application or JS in the browser.  That only the public keys are.   

If the private key is exposed then it can be stolen along with the token, sort of defeating the purpose of the specs. 

I don't know if there is an intent to have a way for applications to control what other apps have access (not or extract) to crate tls sessions with those private keys. 

It seems like some environments are making the tls session keys available globally to any app on the device,  and some like Microsoft in Win10 prototypes may have a API for controlling access.  Nothing is documented on this that has been submitted to the WG to this point. 

This may not be something that we want to standardize,  but some understanding needs to happen around this so that people can understand how to use token binding safely. 

John B. 

Sent from my iPhone

> On Mar 14, 2015, at 9:37 PM, Anthony Nadalin <[email-masked]> wrote:
>

---

From: Domenico Rotondi <[email-masked]>
Date: Sun, 15 Mar 2015 11:16:37 +0100

On 13 Mar 2015 at 14:43, John Bradley wrote:
Hi,
OAuth token is a kind of capability-based security token. A capability-based security 
token can be "ownership based" where having (even a copy of) a token is equivalent 
to being authorized to perform the operation on the resource  the token is associated 
to, as well as more complex things like having the token usable only by entities who 
can prove to be the owner.
Among the possible features tehre is the possibility to grant the right to delegate all 
or part of the rights granted by the token.
So, to answer your question, having a token usable only by a subject being able to 
prove it owns the token restrcits the scope of its usage; while adding the possibility to 
delegate the right to use the token can allow the use by another app to which the 
owner app gratns a delegated token.
Another alternative could be to intelligently use the Google proppsed macaroons 
mechanism.
Ciao
   Domenico

---

From: Anthony Nadalin <[email-masked]>
Date: Sun, 15 Mar 2015 12:19:23 +0000

How the browsers store keys or devices store keys seems totally out of scope of this charter along with key management 

-----Original Message-----
From: John Bradley [mailto:[email-masked]] 
Sent: Saturday, March 14, 2015 6:24 PM
To: Anthony Nadalin
Cc: Phil Hunt; Andrei Popov; [email-masked]
Subject: Re: [Unbearable] Scoping of keys on the client.

John B. 

Sent from my iPhone

---

From: John Bradley <[email-masked]>
Date: Sun, 15 Mar 2015 12:52:43 -0300

I was thinking of something simpler.

Some applications use system web browsers for user interactions with a server.

If 
1: app A invokes a page in a system browser.
2: some interaction with a server B results in a token that is bound to the tls session.
3: Token is passed back to app via a custom scheme URI (or some other way) 
4: can the app on the same device now use that token to interact with server B.

This is probably an important question for protocols/developers wanting to reference token binding.
However it may not be something this WG can answer with other than it is 
"implementation specific and out of scope for these specs".

However even if api's for controlling how the TLS sessions are shared on the device are out of scope,
there will probably need to be some security considerations around what to expect with respect to 
key extractability and TLS session sharing between applications.

John B.
 
> On Mar 15, 2015, at 7:16 AM, Domenico Rotondi <[email-masked]> wrote:
>

---

From: John Bradley <[email-masked]>
Date: Sun, 15 Mar 2015 14:12:57 -0300

Hi Tony,

(no hat)

I don't see in the charter https://datatracker.ietf.org/doc/charter-ietf-tokbind/ that it is explicitly out of scope.

Understanding what applications can share the session keys may be a requirement to securely do objective 1. Allow applications and services to prevent unauthorized replay of security tokens.

Is it possible for a server to have any expectations around what is going to happen on the client device when a cookie is token bound?   Is that to a tab, browser, MDM container or the whole device.
Anything is better than what we have now.  That I agree with completely.   

However at some point in our work some clever person will ask Token Binding to what?    At this point the answer to that seems a bit hand-wavy.

The other thing in the charter would be objective 2 "Allow strong key protection, e.g. using hardware-bound keys."

Is that going to be exposed in the API anyway?   The session is bound to a single app and the private key is non exportable stored in hardware vs stored in software and can be exported by any app and sent off device.

Currently the two specs under consideration for adoption by the WG as starting points don't consider that.

The WG can decide that nothing will be exposed to the server in the protocol and it needs to use some sort of out of band method to determine the client environment.
If the WG decides something else needs to be in the message to help the server make security decisions then the earlier we capture it the better.

I had been thinking of this as being close to/part of the TLS layer, with the client keys being ephemeral and not exportable.   I had assumed that any app sharing the TLS lib would have access to share the same TLS sessions.
I didn't think any key management would be part of that, as the keys would be non exportable and automatically used with a given server.

What my initial question turned up is that implementers are seeing this as a layer on top of TLS and applications would need to call some abstraction of the TLS API that contains some extensions to start token binding on a connection and perhaps do key management.

From a simple HTML in a web browser point of view the two things might look indistinguishable.

I am guessing that when tokbind is done in a browser, the browser would make token binding available on all the connections, and the JS wouldn't need to do anything special.
Even in this simple case are we going to in privacy considerations going to say something about segmenting the sessions that are in "private" tabs to prevent correlation?

At this point I am trying to educate myself on the issues around the specs and the use of the specs, and not advocating for or against any particular API modification.

We do have a real security issue now, and having this WG take a long time to produce something is not in the public interest.

I agree that the core task is to get the core spec and the HTTP binding done in a timely way.

John B.

> On Mar 15, 2015, at 9:19 AM, Anthony Nadalin <[email-masked]> wrote:
>

---

From: Ilari Liusvaara <[email-masked]>
Date: Sun, 15 Mar 2015 20:11:30 +0200

On Sun, Mar 15, 2015 at 02:12:57PM -0300, John Bradley wrote:

[On what should be exposed]

I say there is very little server end can sanely do with information
about the client environment (besides just denying service if it
doesn't think client environment is "strong" enough, where defintion
of "strong" can be highly variable and might not have anything to do
with actual security).

Additionally, every piece of information exposed besides the public
key (where type is part of public key) is potential extra privacy
risk. Some kinds of information (including device identity) are
especially sensitive.

[On what layer to bind]

I think the deployment model web browsers have in mind is either:
1) End-to-end TLS connection between client and server.
2) Connection from client to gateway trusted by origin (CDN, load-
   balancer, etc...), which can extract the identifier for server
   use.

Both can be done fine by binding to TLS layer.

It seems that OAuth folks are wanting to do end-to-end binding at
layer above TLS (as TLS lacks enough reach according them).

[On scope of secrets]

Even if secrets are at TLS layer, it does not follow that keys are
scoped to TLS library.

My view is that the secrets should be associated with tokens they
protect and pinned only by those tokens and active sessions. That
is, once all tokens and sessions using secret go away, that secret
is deleted.

Also, obviously any application accessing the token needs access to
the corresponding secret.

This kind of management is obviously greatly above TLS layer.

-Ilari

---

From: Tony Arcieri <[email-masked]>
Date: Sun, 15 Mar 2015 12:14:02 -0700

On Sun, Mar 15, 2015 at 3:16 AM, Domenico Rotondi <[email-masked]>
wrote:

> OAuth token is a kind of capability-based security token.

I think you need to be very careful when using the term "capability". It's
a term that doesn't mean a whole lot to most people but has incredible
significance in systems like CapTP/E.

> A capability-based security token can be "ownership based" where having
> (even a copy of) a token is equivalent to being authorized to perform the
> operation on the resource

Yes, however the capability must be entangled and inseparable from the
resource it acts on. For HTTP requests, I would consider that encoding both
an HTTP method and a full path to a resource in addition to the hostname.

> the token is associated to, as well as more complex things like having the
> token usable only by entities who

These are properties that I think are necessary of true capability systems,
but not sufficient. I'd look to the Capability Myths Demolished paper for
that:

http://zesty.ca/capmyths/usenix.pdf

> Another alternative could be to intelligently use the Google proppsed

Note that the Macaroons paper quite carefully distinguishes between
capabilities and credentials, and suggests that Macaroons are credentials
and *not* capabilities.

https://static.googleusercontent.com/media/research.google.com/en/us/pubs/archive/41892.pdf

--
Tony Arcieri

---

From: John Bradley <[email-masked]>
Date: Sun, 15 Mar 2015 16:34:24 -0300

I am mostly trying to get discussion started on the list, and people thinking about what questions need to bb worked on:)

Yes privacy is important and minimizing disclosure seems like a important principal.

The Server knowing something about the client may allow it to take other precautions or restrict the access of a token to match the security of the environment.

The counter argument would be that to trust what the client is saying may lead to the question of attestation keys and other things that are in the FIDO specs.
That is probably more complicated than we want.   Though if people think it is important get it on the table early.

OAuth is working on two binding/presentment specs for access tokens.
One that is signed HTTP requests https://tools.ietf.org/html/draft-ietf-oauth-signed-http-request-01 that is defiantly a layer above tokbind.
The other is binding the token to the TLS session talked about in http://tools.ietf.org/html/draft-tschofenig-oauth-hotk-03#section-3.2.2

The POP security architecture doc may be a good place to look for people that want to find out what OAuth is thinking https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-01

OAuth can define cannel binding of tokens for native apps with plain TLS.   I suppose that could also be done using tokbind, though depending on key management that may or may not be a good idea compared to
regular mutual TLS.

Tying the TLS keys to sessions is perhaps the most privacy preserving way to do it but may loose many of the other benefits.  
Some people believe that question should be out of scope and left to implementations.

If that is the case then nailing that down early will save a lot of discussion, though I think it is something the WG will need to understand even if it is only represented in our security and privacy considerations.

John B.

> On Mar 15, 2015, at 3:11 PM, Ilari Liusvaara <[email-masked]> wrote:
>

---

From: Ilari Liusvaara <[email-masked]>
Date: Mon, 16 Mar 2015 13:05:48 +0200

On Sun, Mar 15, 2015 at 04:34:24PM -0300, John Bradley wrote:

Also, it occurs to me that scope of keys can be even smaller than
an application. What if the application is a browser that support
profiles? Each profile has its own cookie jar and thus should have
its own keys.

It gets even more fine-grained if "private browsing" is considered
as each private browsing context needs its own keys.
 
> Yes privacy is important and minimizing disclosure seems like a

For some, "important" about privacy is a major understatement.

> The Server knowing something about the client may allow it to take
> other precautions or restrict the access of a token to match the
> security of the environment.

Well, I don't see great amounts of difference. By the time one can
dump the keys from well-made SW-only solution, one is very likely
in position to do great deal of damage without dumping the keys
anyway.

> The counter argument would be that to trust what the client is saying
> may lead to the question of attestation keys and other things that are
> in the FIDO specs. That is probably more complicated than we want. 
> Though if people think it is important get it on the table early.

The reason why attestation is so complicated in FIDO is because
of they need to do it in a way that doesn't break the web (e.g. by
allowing cross-domain tracking).

> One that is signed HTTP requests
> https://tools.ietf.org/html/draft-ietf-oauth-signed-http-request-01
> that is defiantly a layer above tokbind. The other is binding the token
> to the TLS session talked about in
> http://tools.ietf.org/html/draft-tschofenig-oauth-hotk-03#section-3.2.2

I would say that if one has choice between binding to TLS session and
HTTP-level request signing, one should go to first. It is MUCH simpler.

> The POP security architecture doc may be a good place to look for people
> that want to find out what OAuth is thinking
> https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-01

Reading that document, I see:

"3. Use Cases"
"3.4. Offering Application Layer End-to-End Security"

That is precisely "TLS does not have enough reach".

Whereas the two starting documents (implicitly representing two major
browser vendors) implicitly consider TLS to have enough reach.

> OAuth can define cannel binding of tokens for native apps with plain TLS.
> I suppose that could also be done using tokbind, though depending on key
> management that may or may not be a good idea compared to regular mutual
> TLS.

I consider mutual TLS much more secure than messing with bearer tokens
and signature keys protecting those (of course, mutual TLS has usability
problems in practice).

> Tying the TLS keys to sessions is perhaps the most privacy preserving
> way to do it but may loose many of the other benefits. Some people
> believe that question should be out of scope and left to implementations.

It was tying to both sessions and tokens. Basically, it seems to me that
doing anything beyond that opens up new distinct ways of tracking and
such.

TLS sessions alone are not long-lived enough (otherwise this whole effort
would not be needed). And pinning to tokens alone just plain does not
work (keys would immediately be lost).

-Ilari

---

From: Bill Mills <[email-masked]>
Date: Mon, 16 Mar 2015 16:52:45 +0000 (UTC)

If there is a standard that determines how secrets are handled, such as TLS, I think it's reasonable to use/reference that but it may limit you to being able to use only that if it's MTI.  Specifying how keys are managed and stored in a spec is very very likely to just make the spec less adoptable unless that's the main purpose of the spec and it's intended to be used on multiple platforms.
I agree with Tony,key management should be out of scope here.  I'd go so far as to say it should be explicitly out of scope.  I think this conversation is similar to the question in the POP token drafts where there is a push to mandate how secrets are managed/shared/populated as an MTI item, and I think this is a big mistake.
If there is really a need for a new key distribution/management/sharing standard that's probably worth it's own WG.  It's a rich space though.  Lots of solutions out there. 

     On Saturday, March 14, 2015 5:37 PM, Anthony Nadalin <[email-masked]> wrote:

-----Original Message-----
From: Unbearable [mailto:[email-masked]] On Behalf Of John Bradley
Sent: Friday, March 13, 2015 12:58 PM
To: Phil Hunt
Cc: Andrei Popov; [email-masked]
Subject: Re: [Unbearable] Scoping of keys on the client.

John B

Sent from my iPhone

---

From: Amos Jeffries <[email-masked]>
Date: Tue, 17 Mar 2015 08:25:27 +1300

> allowing cross-domain tracking).

Sigh. Please dont use that phase "break the web". Its been over inflated
with meanings and political posturing.

Your example is even one situation in which "break" implies a wrong
meaning. Cross-domain tracking breaks *Trust*, even while the web at a
protocol/specification level continues to work as specified with regular
users not aware of anything.

> HTTP-level request signing, one should go to first. It is MUCH simpler.

No, they are approximately the same in both complexity and difficulty.

With TLS one has to account for multiple HTTP layer hops with different
TLS connections, even duifferent types of TLS, and messages in each
connection being multiplexed between different applications and/or clients.

With HTTP signing one has to account for information leakage, what
headers to include in the signature, which to omit, how to do the
signing securely, and cached responses.

Both gives token binding from point A to B, where either A or B could be
endpoints or midpoints.

> browser vendors) implicitly consider TLS to have enough reach.

Warning to the wise; this is the same situation faced by HTTP WG
developing HTTP/2 out of SPDY. The browser vendors driving the
specification showed a bias towards the belief that TLS was end-to-end
across the entire Interent. The existence of that e2e assumption in the
very core concepts of the SPDY draft and carried over to HTTP/2 draft
have lead to some very, very long debates and division within the WG.

Having accurate information and WG consensus on what exactly is the
reach of TLS (or any protocol being bound to) would help avoid a lot of
that. If nothing else it would help to explicitly prohibit binding use
in cases where required reach is not being guaranteed and/or supplied.

> and signature keys protecting those (of course, mutual TLS has usability

Ditto. Also its worth noting that mutual TLS authentication may exist
between any two parties in the end-to-end messaging pathway. There are
numerous permutation possibilities where the application layer is fully
disconnected from the TLS auth.

The following HTTP structure is quite popular:
 client -> ISP proxy -> CDN -> origin

where 5 of the 6 permutations and point-to-point, and only 2 have
client->origin contact in any way.

> work (keys would immediately be lost).

Agreed. IMO, leaving it to implemetations without any guidance is a mistake.

At the very least implementors need a set of pros/cons and security
considerations to base any such decisions on. Without that there are
guaranteed interoperability and security flaws.

Amos

---

From: Vinod Anupam <[email-masked]>
Date: Mon, 16 Mar 2015 12:50:42 -0700

> guaranteed interoperability and security flaws.
Agree.

At a high level, here's the typical anticipated Token Binding flow:

On a client:
keyPairForServerA = createKeyPairForServerIfNeeded(serverA);
keyPairForServerB = createKeyPairForServerIfNeeded(serverB);

First party scenario, with ServerA:

Client to ServerA-

proofOfKeyForServerA = signToProvePossession(privateKeyForServerA);
tokenForServerA = requestBoundToken(proofOfKeyForServerA, pubKeyForServerA);
presentBoundToken(proofOfKeyForServerA, tokenForServerA);

Federation scenario, with ServerA issuing token for use with ServerB:

Client to ServerA-
proofOfKeyForServerA = signToProvePossession(privateKeyForServerA);
proofOfKeyForServerA = signToProvePossession(privateKeyForServerB);
tokenForServerB = requestBoundToken(proofOfKeyOfServerA, pubKeyForServerA,
                                    proofOfKeyOfServerB, pubKeyForServerB);

Client to ServerB-
proofOfKeyForServerB = signToProvePossession(privateKeyForServerB);
presentBoundToken(proofOfKeyForServerB, tokenForServerB);

Main points:
- Tokens are bound to 'keys' (both in First Party and Federation scenarios)

- Key management is orthogonal to Token Binding, but governs "security"
since
  o- In general, any app that can prove possession of a specific key can
ask for tokens to be bound to that key, and can present tokens issued to
that key
  o- In general, any app that can prove possession of a pair of specific
keys can ask one of the servers to issue tokens bound to the other key and
present those tokens to the other server

Implications:
- An app that does not want to share keys with any other app should use a
key management solution that allows only that app to access and use the
keys.

- An app (from a family of apps, for some notion of family) that wants to
share keys with other apps in that family should use a key management
solution that allows that app family to access and use the keys (including
providing a way for an app to prove that it belongs to the family)

- An app that wants to use keys scoped to a machine and/or user and/or
profile should use a key management solution that allows any apps on that
machine and/or user and/or profile to access and use the keys.

The key management solution will define overall security (e.g. can malware
on client side access keys)
And there will be dependencies on the app-platform interface with regard to
hardware-backed keys.

I think we will see different key management solutions (though the first
and the third can be though of as special cases of the second)

Implementers need to determine what makes sense in their case.

We need to make sure that we are not blocking out important use cases.

---

From: John Bradley <[email-masked]>
Date: Mon, 16 Mar 2015 17:12:18 -0300

Thanks

That was more or less what I was looking for with my question.

John B.

> On Mar 16, 2015, at 4:50 PM, Vinod Anupam <[email-masked]> wrote:
> 
> 
> 
> 
> On Mon, Mar 16, 2015 at 12:25 PM, Amos Jeffries <[email-masked] <mailto:[email-masked]>> wrote:
> >> https://tools.ietf.org/html/draft-ietf-oauth-signed-http-request-01 <https://tools.ietf.org/html/draft-ietf-oauth-signed-http-request-01>
> >> http://tools.ietf.org/html/draft-tschofenig-oauth-hotk-03#section-3.2.2 <http://tools.ietf.org/html/draft-tschofenig-oauth-hotk-03#section-3.2.2>
> >
> >> https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-01 <https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-01>
> >
> - Key management is orthogonal to Token Binding, but governs "security" since
>   o- In general, any app that can prove possession of a specific key can ask for tokens to be bound to that key, and can present tokens issued to that key
>   o- In general, any app that can prove possession of a pair of specific keys can ask one of the servers to issue tokens bound to the other key and present those tokens to the other server
> 
> 
> Implications:
> - An app that does not want to share keys with any other app should use a key management solution that allows only that app to access and use the keys.
> 
> - An app (from a family of apps, for some notion of family) that wants to share keys with other apps in that family should use a key management solution that allows that app family to access and use the keys (including providing a way for an app to prove that it belongs to the family)
> 
> - An app that wants to use keys scoped to a machine and/or user and/or profile should use a key management solution that allows any apps on that machine and/or user and/or profile to access and use the keys.
> 
> The key management solution will define overall security (e.g. can malware on client side access keys)
> And there will be dependencies on the app-platform interface with regard to hardware-backed keys.
> 
> I think we will see different key management solutions (though the first and the third can be though of as special cases of the second)
> 
> [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: Domenico Rotondi <[email-masked]>
Date: Tue, 17 Mar 2015 21:48:53 +0100

Hi,
see inline my comments.
Ciao
   Domenico

On 15 Mar 2015 at 12:14, Tony Arcieri wrote:

On Sun, Mar 15, 2015 at 3:16 AM, Domenico Rotondi <[email-masked]> wrote:
    OAuth token is a kind of capability-based security token.

I think you need to be very careful when using the term "capability". It's a term that doesn't mean a 
whole lot to most people but has incredible significance in systems like CapTP/E.
[Dom] I know it's a term many people doesn't know, as I know its meaning its quite wide. Anyway, its 
most synthetic defintion can be summed up as "its a way to manage access to a resource based on the 
possession of a token that states what 'capability' you have on that resource"
 
    A capability-based security token can be "ownership based" where having (even 
    a copy of) a token is equivalent to being authorized to perform the operation on 
    the resource

Yes, however the capability must be entangled and inseparable from the resource it acts on. For HTTP 
requests, I would consider that encoding both an HTTP method and a full path to a resource in 
addition to the hostname.
[Dom] exactly. A capability token identifies the resource(s) you are entitled to act on, as well as what 
'action' can you do on it. So for an HTTP request you have to clearly deintify the resurce (using its 
URL) and the HTTP 'verbs' you can use on that resoure. To avoid security issues, like confused deputy 
problem, the capability token has to specify only 1 verb.
    the token is associated to, as well as more complex things like having the token 
    usable only by entities who
    can prove to be the owner.
    Among the possible features tehre is the possibility to grant the right to delegate 
    all
    or part of the rights granted by the token.

These are properties that I think are necessary of true capability systems, but not sufficient. I'd look to 
the Capability Myths Demolished paper for that:

[Dom] in same capability based system, capabilities are directly associated by the OS to each object's 
instance; so in these systems there is no need for object's instances to prove they are the owner of a 
capability token. In more distributed and open systems the proff of ownership becomes a critical 
aspect especially when rights delegation has to be supported.
A big adavantage of capability tokens is that you decouple Identity Management from Access Control 
Management, which improves scalability and can be essential in some contexts.

Note that the Macaroons paper quite carefully distinguishes between capabilities and credentials, and 
suggests that Macaroons are credentials and *not* capabilities.

[Dom] the Google paper doesn't use the term "credentials" as we normally use it (i.e., to identify 
somethings that is tied to authentication); the meaning they give to "credentials" is the one the 
diplomacy gives to this term: a set of statements that entitle you to have a role (e.g., an ambassador 
representing country X toward country Y).
This is the meaning of a capability token (as is the meaning of an OAuth token): the token states that 
you are entitled to do a specific action on a specific reosurce.
--
Tony Arcieri

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Tue, 17 Mar 2015 22:00:13 -0400

On Sun 2015-03-15 15:34:24 -0400, John Bradley wrote:
> way to do it but may loose many of the other benefits.

There are lots of sessions involved at different layers the stack at
this point ;) Do you mean "tying the keys to TLS sessions"?

Even in this case, the above suggestion isn't clear.  The only way that
a TLS session is guaranteed to be terminated by both peers is in the
case of a fatal alert, so we still don't really know when the key should
be invalidated.

Even failure of a server to accept a proposed TLS session resumption
doesn't necessarily invalidate a given TLS session ID (though many TLS
clients will treat a server response rejecting the session ID as a
signal to discard it).

       --dkg

---

From: Andrei Popov <[email-masked]>
Date: Wed, 18 Mar 2015 17:17:24 +0000

Hi Daniel,

In the current proposals, the client proves possession of the Token Binding key for each TLS connection (not session).

For privacy reasons, the user must have an option of deleting Token Binding keys (e.g. when clearing cookies).

Cheers,

Andrei

-----Original Message-----
From: Daniel Kahn Gillmor [mailto:[email-masked]] 
Sent: Tuesday, March 17, 2015 7:00 PM
To: John Bradley; Ilari Liusvaara
Cc: Anthony Nadalin; Andrei Popov; [email-masked]; Phil Hunt
Subject: Re: [Unbearable] Scoping of keys on the client.

> way to do it but may loose many of the other benefits.

There are lots of sessions involved at different layers the stack at this point ;) Do you mean "tying the keys to TLS sessions"?

Even in this case, the above suggestion isn't clear.  The only way that a TLS session is guaranteed to be terminated by both peers is in the case of a fatal alert, so we still don't really know when the key should be invalidated.

Even failure of a server to accept a proposed TLS session resumption doesn't necessarily invalidate a given TLS session ID (though many TLS clients will treat a server response rejecting the session ID as a signal to discard it).

       --dkg