Subject: [OAUTH-WG] Holder-of-the-Key for OAuth

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 9 Jul 2012 21:14:50 +0300

Hi guys, 

today I submitted a short document that illustrates the concept of holder-of-the-key for OAuth. 
Here is the document: 
https://datatracker.ietf.org/doc/draft-tschofenig-oauth-hotk

Your feedback is welcome 

Ciao
Hannes

---

From: Anthony Nadalin <[email-masked]>
Date: Mon, 9 Jul 2012 18:57:28 +0000

Hannes, thanks for drafting this, couple of comments:

1. HOK is one of Proof of Possession methods, should we consider others?
2. This seems just to handle asymmetric keys, need to also handle symmetric keys

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Hannes Tschofenig
Sent: Monday, July 09, 2012 11:15 AM
To: OAuth WG
Subject: [OAUTH-WG] Holder-of-the-Key for OAuth

Hi guys, 

Your feedback is welcome 

Ciao
Hannes

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

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 9 Jul 2012 22:05:15 +0300

Hi Tony, 

I had to start somewhere. I had chosen the asymmetric version since it provides good security properties and there is already the BrowserID/OBC work that I had in the back of my mind. I am particularly interested to illustrate that you can accomplish the same, if not better, characteristics than BrowserID by using OAuth instead of starting from scratch. 

Regarding the symmetric keys: The asymmetric key can be re-used but with a symmetric key holder-of-the-key you would have to request a fresh one every time in order to accomplish comparable security benefits. 

Ciao
Hannes

---

From: Anthony Nadalin <[email-masked]>
Date: Mon, 9 Jul 2012 21:17:33 +0000

> Regarding the symmetric keys: The asymmetric key can be re-used but with a symmetric key holder-of-the-key you would have to request a fresh one every time in order to accomplish comparable securit…

We have use cases for asymmetric, symmetric and for nonce (entropy), and thus would have to distinguish between these types requested and returned. Also do you always see the proof token being embedded in the message or also part of the auth code?

-----Original Message-----
From: Hannes Tschofenig [mailto:[email-masked]] 
Sent: Monday, July 09, 2012 12:05 PM
To: Anthony Nadalin
Cc: Hannes Tschofenig; OAuth WG
Subject: Re: [OAUTH-WG] Holder-of-the-Key for OAuth

Hi Tony, 

Ciao
Hannes

---

From: "Manger, James H" <[email-masked]>
Date: Tue, 10 Jul 2012 13:54:40 +1000

Hannes,

> https://datatracker.ietf.org/doc/draft-tschofenig-oauth-hotk

A different approach would be for the service to issue a private asymmetric key to the client app, along with a certificate, in the access token response. This is a slightly better match to the OAuth2 model of the authorization service issuing temporary credentials for accessing resources on a user’s behalf.

When the token_type is "tls_client_cert" (probably a better label than "hotk"), the client can access protected resources using TLS with client authentication; using the key from the "private_key" field. The "access_token" field holds a base64url-encoded certificate to include in the TLS handshake.

An example access token response could be:

  HTTP/1.1 200 OK
  Content-Type: application/json;charset=UTF-8
  Cache-Control: no-store
  Pragma: no-cache

  {
    "token_type":"tls_client_cert",
    "access_token":"MIIGcDCCBdmgAwIBAgIKE…",
    "private_key":{
      "alg":"RSA", "mod":"Ovx7…", "p":"7dE…", "q":"fJ3…", …
    },
    "expires_in":3600,
    "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA"
  }

The suggestion above passes the "access_token" to the protected resource in the TLS protocol in the form of a certificate.
draft-tschofenig-oauth-hotk says the client "presents the access token to the resource server", but it wasn't clear to me how it was done. Were you expecting the client to use the BEARER HTTP auth scheme inside the client-authenticated TLS connection?

--
James Manger

---

From: John Bradley <[email-masked]>
Date: Tue, 10 Jul 2012 06:33:40 -0400

I agree that there are use-cases for all of the proof of possession mechanisms.

Presentment methods also need to be considered.   

TLS client auth may not always be the best option.  Sometimes message signing is more appropriate.

One question is if we want to do a generic proof of possession for JWT that is useful outside OAuth,  or something OAuth specific.    The answer may be a combined approach.

I think this is a good start to get discussion going.

John B.

---

From: Anthony Nadalin <[email-masked]>
Date: Tue, 10 Jul 2012 14:29:05 +0000

> One question is if we want to do a generic proof of possession for JWT that is useful outside OAuth,  or something OAuth specific.    The answer may be a combined approach.

Depends if we want OAuth to support the concept of a request/response for a proof token and keep the actual binding for a separate specification, in most of our cases the keying material is opaque (and just a blob), where we care about the key material  is in the key agreement (entropy) cases.

-----Original Message-----
From: John Bradley [mailto:[email-masked]] 
Sent: Tuesday, July 10, 2012 3:34 AM
To: Hannes Tschofenig
Cc: Anthony Nadalin; OAuth WG
Subject: Re: [OAUTH-WG] Holder-of-the-Key for OAuth

John B.

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 10 Jul 2012 19:11:55 +0300

If we do not bind the key to the channel than we will run into all sorts of problems. The current MAC specification illustrates that quite nicely. On top of that you can re-use the established security channel for the actual data exchange.

---

From: Anthony Nadalin <[email-masked]>
Date: Tue, 10 Jul 2012 16:36:27 +0000

The key does not have to be bound to the channel, that is just one option, the key can be a negotiated key

---

From: William Mills <[email-masked]>
Date: Tue, 10 Jul 2012 09:53:34 -0700 (PDT)

The server would need to issue a key pair and not just the private key.  Are you saying the private key is for the certificate, and that certificate is part of the access_token?

________________________________
 From: "Manger, James H" <[email-masked]>
To: Hannes Tschofenig <[email-masked]>; OAuth WG <[email-masked]> 
Sent: Monday, July 9, 2012 8:54 PM
Subject: Re: [OAUTH-WG] Holder-of-the-Key for OAuth
 
Hannes,

  HTTP/1.1 200 OK

  {

--
James Manger

---

From: John Bradley <[email-masked]>
Date: Tue, 10 Jul 2012 12:54:30 -0400

Binding the key to the channel is arguably the most secure. 

SSL offloading and other factors may prevent that from working in all cases. 

I suspect that we will need two OAuth bindings. One for TLS and one for signed message. 

John B.  

Sent from my iPhone

---

From: Phil Hunt <[email-masked]>
Date: Tue, 10 Jul 2012 09:56:44 -0700

Hannes,

Thanks for your proposal. I'm glad to see work on this starting.

I think use cases may demand more than just channel security. A lot of cases do not have end-to-end TLS channels available. So while this could be stated to be an improvement it may not achieve the end-to-end authentication of clients being looked for.

One aspect of the MAC draft that I did like was that it involved a changing authorization value which essentially gave a message centric security model.

Would it be appropriate to start a discussion on the use cases the WG would like to address?

Phil

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

---

From: John Bradley <[email-masked]>
Date: Tue, 10 Jul 2012 12:58:57 -0400

We should be supporting both the client providing the key pair and a server generated pair. 

In higher security the private key may be stored in hardware. 

There are more possible attacks if the key is sent to the client. 

John B. 

Sent from my iPhone

---

From: Anthony Nadalin <[email-masked]>
Date: Tue, 10 Jul 2012 17:01:24 +0000

> Binding the key to the channel is arguably the most secure

Not really, there are hardware options that give good security properties

-----Original Message-----
From: John Bradley [mailto:[email-masked]] 
Sent: Tuesday, July 10, 2012 9:55 AM
To: Hannes Tschofenig
Cc: Anthony Nadalin; Hannes Tschofenig; OAuth WG
Subject: Re: [OAUTH-WG] Holder-of-the-Key for OAuth

John B.  

Sent from my iPhone

---

From: John Bradley <[email-masked]>
Date: Tue, 10 Jul 2012 13:04:01 -0400

When I say arguably,  I expect you to argue.  

John B. 

Sent from my iPhone

---

From: prateek mishra <[email-masked]>
Date: Tue, 10 Jul 2012 13:42:27 -0400

As Phil Hunt suggests, there is a need for a discussion of the use-cases 
involved

How to bind the key to the requestor may have several variations, I 
would hope the work would cover a broad range

Given the importance of the symmetric key case, I would also be 
interested in key establishment methods as well

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Tue, 10 Jul 2012 20:47:16 +0300

Hi Prateek, 

why do you care about the symmetric key case? 

Specifying more variants requires more code and decreases
interoperability. 

Ciao
Hannes

From: [email-masked] [mailto:[email-masked]] On Behalf
Of ext prateek mishra
Sent: Tuesday, July 10, 2012 8:42 PM
To: [email-masked]
Subject: Re: [OAUTH-WG] Holder-of-the-Key for OAuth

 
John B. 
 
Sent from my iPhone
 
On 2012-07-10, at 1:01 PM, Anthony Nadalin <[email-masked]>
<mailto:[email-masked]>  wrote:

		Binding the key to the channel is arguably the most
secure

	Not really, there are hardware options that give good security
properties
	 
	-----Original Message-----
	From: John Bradley [mailto:[email-masked]] 
	Sent: Tuesday, July 10, 2012 9:55 AM
	To: Hannes Tschofenig
	Cc: Anthony Nadalin; Hannes Tschofenig; OAuth WG
	Subject: Re: [OAUTH-WG] Holder-of-the-Key for OAuth

	SSL offloading and other factors may prevent that from working
in all cases. 
	 
	I suspect that we will need two OAuth bindings. One for TLS and
one for signed message. 
	 
	John B.  
	 
	Sent from my iPhone
	 
	On 2012-07-10, at 12:11 PM, Hannes Tschofenig
<[email-masked]> <mailto:[email-masked]>  wrote:

		If we do not bind the key to the channel than we will
run into all sorts of problems. The current MAC specification
illustrates that quite nicely. On top of that you can re-use the
established security channel for the actual data exchange. 

				One question is if we want to do a
generic proof of possession for JWT that is useful outside OAuth,  or
something OAuth specific.    The answer may be a combined approach.

			Depends if we want OAuth to support the concept
of a request/response for a proof token and keep the actual binding for
a separate specification, in most of our cases the keying material is
opaque (and just a blob), where we care about the key material  is in
the key agreement (entropy) cases.
			 
			-----Original Message-----
			From: John Bradley [mailto:[email-masked]] 
			Sent: Tuesday, July 10, 2012 3:34 AM
			To: Hannes Tschofenig
			Cc: Anthony Nadalin; OAuth WG
			Subject: Re: [OAUTH-WG] Holder-of-the-Key for
OAuth
			 
			I agree that there are use-cases for all of the
proof of possession mechanisms.

			TLS client auth may not always be the best
option.  Sometimes message signing is more appropriate.
			 
			One question is if we want to do a generic proof
of possession for JWT that is useful outside OAuth,  or something OAuth
specific.    The answer may be a combined approach.
			 
			I think this is a good start to get discussion
going.
			 
			John B.
			On 2012-07-09, at 3:05 PM, Hannes Tschofenig
wrote:

				Hi Tony, 
				 
				I had to start somewhere. I had chosen
the asymmetric version since it provides good security properties and
there is already the BrowserID/OBC work that I had in the back of my
mind. I am particularly interested to illustrate that you can accomplish
the same, if not better, characteristics than BrowserID by using OAuth
instead of starting from scratch. 
				 
				Regarding the symmetric keys: The
asymmetric key can be re-used but with a symmetric key holder-of-the-key
you would have to request a fresh one every time in order to accomplish
comparable security benefits. 
				 
				Ciao
				Hannes
				 
				On Jul 9, 2012, at 9:57 PM, Anthony
Nadalin wrote:

				Hannes, thanks for drafting this, couple
of comments:
				 
				1. HOK is one of Proof of Possession
methods, should we consider others?
				2. This seems just to handle asymmetric
keys, need to also handle symmetric keys

				-----Original Message-----
				From: [email-masked]
[mailto:[email-masked]] On Behalf Of Hannes Tschofenig
				Sent: Monday, July 09, 2012 11:15 AM
				To: OAuth WG
				Subject: [OAUTH-WG] Holder-of-the-Key
for OAuth
				 
				Hi guys, 
				 
				today I submitted a short document that
illustrates the concept of holder-of-the-key for OAuth. 
				Here is the document: 

				Your feedback is welcome 
				 
				Ciao
				Hannes

---

From: Anthony Nadalin <[email-masked]>
Date: Tue, 10 Jul 2012 17:58:08 +0000

So one of our cases is that we want to use a proof key to protect the symmetric key that is used to protect messages, so yes this would be application specific but that is the nature of OAuth in general, not much interop except at the application level

From: [email-masked] [mailto:[email-masked]] On Behalf Of Tschofenig, Hannes (NSN - FI/Espoo)
Sent: Tuesday, July 10, 2012 10:47 AM
To: ext prateek mishra; [email-masked]
Subject: Re: [OAUTH-WG] Holder-of-the-Key for OAuth

Hi Prateek,

why do you care about the symmetric key case?
Specifying more variants requires more code and decreases interoperability.

Ciao
Hannes

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]<mailto:[mailto:[email-masked]]> On Behalf Of ext prateek mishra
Sent: Tuesday, July 10, 2012 8:42 PM
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [OAUTH-WG] Holder-of-the-Key for OAuth

As Phil Hunt suggests, there is a need for a discussion of the use-cases involved

How to bind the key to the requestor may have several variations, I would hope the work would cover a broad range

Given the importance of the symmetric key case, I would also be interested in key establishment methods as well

John B.

Sent from my iPhone

On 2012-07-10, at 1:01 PM, Anthony Nadalin <[email-masked]><mailto:[email-masked]> wrote:

-----Original Message-----

To: Hannes Tschofenig

John B.

Sent from my iPhone

On 2012-07-10, at 12:11 PM, Hannes Tschofenig <[email-masked]><mailto:[email-masked]> wrote:

-----Original Message-----

To: Hannes Tschofenig

John B.

Hi Tony,

Ciao

Hannes

-----Original Message-----

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Hannes Tschofenig

To: OAuth WG

Hi guys,

Here is the document:

Your feedback is welcome

Ciao

Hannes

OAuth mailing list

[email-masked]<mailto:[email-masked]>

OAuth mailing list

[email-masked]<mailto:[email-masked]>

OAuth mailing list

[email-masked]<mailto:[email-masked]>

---

From: prateek mishra <[email-masked]>
Date: Tue, 10 Jul 2012 15:00:20 -0400

Hannes,

we have a variety of use-cases wherein a single server ("client") 
repeatedly interacts with a resource server for business purposes. These 
interactions may be on-behalf-of
a single user or even multiple users. In such a use-case, use of 
assymetric signature imposes an unacceptable performance penalty and 
there is a lot of interest in being able
to use symmetric signature instead.

- prateek
> *From:[email-masked] [mailto:[email-masked]] *On 
> Behalf Of *ext prateek mishra
> *Sent:* Tuesday, July 10, 2012 8:42 PM
> *To:* [email-masked]
> *Subject:* Re: [OAUTH-WG] Holder-of-the-Key for OAuth
>
> On 2012-07-10, at 1:01 PM, Anthony Nadalin<[email-masked]>  <mailto:[email-masked]>  wrote:
>   
>
>     On 2012-07-10, at 12:11 PM, Hannes Tschofenig<[email-masked]>  <mailto:[email-masked]>  wrote:
>
>       
>
>                     From:[email-masked]  <mailto:[email-masked]>  [mailto:[email-masked]] On Behalf Of Hannes Tschofenig
>
>                     [email-masked]  <mailto:[email-masked]>
>
>                 [email-masked]  <mailto:[email-masked]>
>
>     [email-masked]  <mailto:[email-masked]>
>

---

From: William Mills <[email-masked]>
Date: Tue, 10 Jul 2012 13:26:19 -0700 (PDT)

OK, but why do you need holder-of-key then?  I think holder-of-key gets significantly weird in the symmetric key case.   In the PKI case the token has (public_key, token, signature(public_key, token, serversecret)).  How will the server assert something in the credential that's useful in place of a plublic key (or certificate)?  I think the best case there is that the server is asserting a client name which the protected resource uses to look up the symmetric key to use for the signature check, but that could just be included in token anyway without holder-of-key.

I really don't see how this works with symmetric keys in any useful way that's not easier via another method like MAC tokens?

________________________________
 From: prateek mishra <[email-masked]>
To: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]> 
Cc: [email-masked] 
Sent: Tuesday, July 10, 2012 12:00 PM
Subject: Re: [OAUTH-WG] Holder-of-the-Key for OAuth

Hannes,

we have a variety of use-cases wherein a single server ("client")
    repeatedly interacts with a resource server for business purposes.
    These interactions may be on-behalf-of
a single user or even multiple users. In such a use-case, use of
    assymetric signature imposes an unacceptable performance penalty and
    there is a lot of interest in being able
to use symmetric signature instead.

- prateek

>From:[email-masked] [mailto:[email-masked]] On Behalf Of ext prateek mishra
>How to bind the key to the requestor may have several
            variations, I would hope the work would cover a broad range
>
>Given the importance of the symmetric key case, I would also
            be interested in key establishment methods as well

---

From: Phil Hunt <[email-masked]>
Date: Tue, 10 Jul 2012 14:37:04 -0700

I don't have much data on how many request/responses an oauth web client does per connection. But if we force a new TLS connection for each access token (which may only be used for 1 or 2 request/responses) we will have a scalability issue. I do agree the approach is relatively simple and workable for native apps since there is less of a client performance issue. 

For web app clients, I'd rather keep TLS security a separate issue/layer.  For example, a long-lived private key (symmetric or asymmetric) could be issued to the client so that it can establish 2-way TLS connections that can be used for 1000s of requests per connection.  Then a separate authorization header HoK access token is used to authenticate each request/response.

Speaking of the authorization header, it's not clear in section 3.2 whether in fact an authorization header is sent. The implication seems to be that the resource server must have a way to pull the information from the TLS end-point or get it from the authorization header which 3.2 doesn't speak to.

Phil

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

On 2012-07-10, at 1:26 PM, William Mills wrote:

> we have a variety of use-cases wherein a single server ("client") repeatedly interacts with a resource server for business purposes. These interactions may be on-behalf-of
> a single user or even multiple users. In such a use-case, use of assymetric signature imposes an unacceptable performance penalty and there is a lot of interest in being able
>> From: [email-masked] [mailto:[email-masked]] On Behalf Of ext prateek mishra

---

From: "Manger, James H" <[email-masked]>
Date: Wed, 11 Jul 2012 10:44:59 +1000

> The server would need to issue a key pair and not just the private key.  Are you saying the private key is for the certificate, and that certificate is part of the access_token?

Yes. The AS issues temporary credentials for the client app to use. In this case the credentials are a public/private key pair and associated certificate to be used in TLS. The cert (which includes the public key and any info the AS wants) is returned in the “access_token” field. The private key is returned in a separate field.

> I suspect that we will need two OAuth bindings. One for TLS and one for signed message.

I agree. For instance, set “token_type”:”tls_client_cert” when the client has to use TLS; set “token_type”:”cms” when the client has to digitally sign messages using Crypto Message Syntax (CMS); ….

> We should be supporting both the client providing the key pair and a server generated pair.

Ok. Do you expect a client app to use a separate key pair for each authorization? Or do you expect a client app to have one key pair for all actions (on behalf of all users) and use the access_token to distinguish the authorization in each request? Or something in between?

--
James Manger

Hannes,

  HTTP/1.1 200 OK

  {

--
James Manger

---

From: John Bradley <[email-masked]>
Date: Tue, 10 Jul 2012 21:04:40 -0400

inline

> I agree. For instance, set “token_type”:”tls_client_cert” when the client has to use TLS; set “token_type”:”cms” when the client has to digitally sign messages using Crypto Message Syntax (CMS); ….
Perhaps JWT/JOSE rather than CMS:)

Though there will need to be discussions about what part of the message needs to be signed.

> Ok. Do you expect a client app to use a separate key pair for each authorization? Or do you expect a client app to have one key pair for all actions (on behalf of all users) and use the access_toke…
Using a separate key pair per authorization is not required for asymmetric keys.
The idea is that the presenter of the token needs to prove that they know the proof key.

The only reason to change the key would be privacy, to prevent correlation.

If we look at how openID Connect used id_tokens a ephemeral key generated by the user agent on a per client basis may be useful.

The Client and the token issuer should sort out the proof mechanism and key rotation.

The protected resource should only care about the proof based on the token it receives.  

I think part of this is a JWT/JOSE issue and part of this ia a OAuth binding or bindings issue.

John B.

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 11 Jul 2012 09:23:18 +0300

I also fail to see the value of a symmetric holder-of-the-key solution and I don't buy the performance argument either (particularly since we are using a short key length here.

I hope that this is not the "let us replicate all the work we had done in some other crazy enterprise identity management solution so far." approach.

---

From: "Manger, James H" <[email-masked]>
Date: Wed, 11 Jul 2012 17:37:38 +1000

> Though there will need to be discussions about what part of the message needs to be signed.

I was about to list JOSE as the example, but baulked precisely because of this issue. It wasn't obvious how a request to a protected resource would be wrapped in a JOSE message. At least with CMS (or WS-*, or XML DSig, or SOAP…) you can guess that the request is a POST of a signed blob.

--
James Manger

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 11 Jul 2012 13:13:49 +0300

Hi Tony, 

On Jul 10, 2012, at 12:17 AM, Anthony Nadalin wrote:

> We have use cases for asymmetric, symmetric and for nonce (entropy),

I tried to describe the difference between the various approaches in this document: 
http://www.potaroo.net/ietf/all-ids/draft-tschofenig-oauth-signature-thoughts-00.txt

There is a small performance improvement when using symmetric key techniques compared to short-lived asymmetric keys but asymmetric keys provide security benefits (since the resource server nor the authorization server ever get to see the private key). 

Do you really need both? 

And: Could you explain the nonce-based technique? 

> and thus would have to distinguish between these types requested and returned.

Certainly true. 

I currently use the pk-info parameter to allow the client to hint support for this extension in the request, and the "token_type":"hotk" in the response as a confirmation that the server-side understands it and had included the public key into the access token. 

Ciao
Hannes

---

From: John Bradley <[email-masked]>
Date: Wed, 11 Jul 2012 06:37:51 -0400

The POST of a signed blob would work with JOSE or CMS signing the blob.

I suspect that would be more of a application level signing than OAuth though.
Though worth talking about.

I suspect a OAuth level signing might look a bit like HMAC.

The access_token might be:
1 a JWT including a JWK structure for the proof key (public key or key reference).
2 a opaque token that is used by the Protected resource to look up the actual token via a STS like mechanism.   
3 a SAML token in JOSE is also a possibility for some people.

The above choice should be opaque to the client.

For asymmetric binding the key to TLS seems like a good idea.  There are however many practical key management issues that clients may have (especially if multiple keys are used) and it may not be end to end.  

Another OAuth binding might be to use a token collection.  One being the access token and another being a JWT/JWS containing one or more hashes of the HTTP message or message components.

I don't want to reinvent SOAP, or WS-Security, however I also don't want to reject all of the use-cases out of hand.

The common uses need to be dead simple for clients.

John B.

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 11 Jul 2012 13:48:49 +0300

It is certainly a plus that we can now make use of the JSON work. This will improve interoperability and avoid making implementation mistakes if developers use libraries (with the JOSE features).

---

From: John Bradley <[email-masked]>
Date: Wed, 11 Jul 2012 07:20:07 -0400

JWT is a OAuth WG item so we can do a proof semantic for that that works with the OAuth bindings but is not necessarily specific to OAuth.   Connect and Browser ID may want to use it as well for JWT outside of OAuth.

John B.

---

From: John Bradley <[email-masked]>
Date: Wed, 11 Jul 2012 07:33:02 -0400

On the specifics of OAuth bindings.

We may profit by stepping back a bit and agreeing on what threats we are attempting to mitigate.

One threat that is on a number of peoples minds is the complete failure of PKIX.
Another is the simple fact that many clients don't validate server certificates and ignore warnings.

One of the issues people had with MAC was that while it protected the client from MTM in the connection to the protected resource it basically did nothing to stop the same attack between the client and token endpoint where the attacker gets the MAC token and secret.

Agreeing on what attacks against OAuth we are trying to prevent may help focus our discussions on bindings.  

We need to be careful not to just push the problem around, from endpoint to endpoint.

John B.

---

From: prateek mishra <[email-masked]>
Date: Wed, 11 Jul 2012 12:24:14 -0400

Hmmm, well actually, I am referencing something like the symmetric key 
generation (ephemeral) within TLS, I certainly dont view that as "crazy 
enterprise identity management" :-)

If a client (with a public-private key pair) and resource have a 
multi-step interaction, and this is a common use-case for us, there is a 
lot of value in being able to agree  on a symmetric key for the session

Anyway, jumping into a lot of technical detail is probably not the best 
approach at this stage

There have been suggestions for use-cases (Phil Hunt) and threat model 
(John Bradley) for HoK and I would endorse those

---

From: William Mills <[email-masked]>
Date: Wed, 11 Jul 2012 09:52:00 -0700 (PDT)

Having re-read this I think I now understand how symmetric would work.  In the HOK model as I think of it we have 3 basic parts:  opaque token stuff, asserted client key, and server signature.  The asserted client key could be:

-a public key
-a certificate
-an encrypted symmetric key
-other?

For symmetric key it would act as a key distribution for clients to the endpoints, so it would be doing a similar thing for symmetric keys that it would for PK, e.g. key distribution and trust.  In the end the token itself can contain the asserted key, MAC tokens can support this concept now in fact.  The relying endpoint would extract the secret from the token to check the signature.  For the PK case you don't have to encrypt the asserted key, which is a little cheaper.

-bill

________________________________
 From: Hannes Tschofenig <[email-masked]>
To: William Mills <[email-masked]> 
Cc: Hannes Tschofenig <[email-masked]>; prateek mishra <[email-masked]>; "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>; "[email-masked]" <[email-masked]> 
Sent: Tuesday, July 10, 2012 11:23 PM
Subject: Re: [OAUTH-WG] Holder-of-the-Key for OAuth

---

From: William Mills <[email-masked]>
Date: Fri, 13 Jul 2012 13:43:04 -0700 (PDT)

The more I think about this the more I think that HoK is really more or an informational type RFC if anything.  If you really want a cleartext part so as not to encrypt a certificate or something then OK, but in the end all our extant token types can support the HoK token payload.  In profiles where we already have a transaction signature nothing more is needed.   And if you want to apply it to something like Bearer, then you should be using MAC instead.

We could theoretically wedge it in to the client authentication mechanism, but why?

________________________________
 From: William Mills <[email-masked]>
To: Hannes Tschofenig <[email-masked]> 
Cc: "[email-masked]" <[email-masked]> 
Sent: Wednesday, July 11, 2012 9:52 AM
Subject: Re: [OAUTH-WG] Holder-of-the-Key for OAuth

-a public key
-a certificate

-bill

On Jul 10, 2012, at 11:26 PM, William Mills wrote:

> a single user or
 even multiple users. In such a use-case, use of assymetric signature imposes an unacceptable performance penalty and there is a lot of interest in being able
>> Not really, there are hardware
 options that give good security properties
>> Depends if we want OAuth to support the concept of a request/response for a proof token and keep the actual binding for a separate specification, in most of our cases the keying material is opaque (and just a blob), where we care
 about the key material  is in the key agreement (entropy) cases.
 Hannes
>> today I submitted a short document
 that illustrates the concept of holder-of-the-key for OAuth.