date:20151104

Re: [OAUTH-WG] Sharing a client_id: is it good or bad ?

2015-11-04 Thread John Bradley

For a native app you can have one clientID and no secret (same as having one 
secret for all of them) or you can use dynamic client registration to give each 
one a separate client_id and secret.

The middle ground is to use PKCE and no client secret.  

The client generates a pkce challenge in the authorization request and then 
presents the verifier.  You can then use that verifier to place a identifier 
for that app instance in the refresh/access tokens.   That would allow the RS 
to differentiate between two clients with the same user on different devices.  
That gets you more or less equivalent security, but binds the client instance 
to a user/device as part of the authorization flow,  rather than by creating 
separate client_id for each instance and managing that.

It is up to more of a deployer preference on what way to go.  

I prefer the PKCE route personally,  that requires a real user to be involved 
in the flow before the AS needs to store state.   In open dynamic client 
registration you can face a denial of service attack by creating unlimited 
clients, that is harder to manage.  

One thing that will be coming up at the WG meeting today is the possibility of 
extending PKCE verification to refresh tokens as well as there current use with 
code.  That would move the PKCE and client registration security even closer 
together.

John B.

> On Nov 5, 2015, at 1:01 AM, Sergey Beryozkin  wrote:
> 
> Hi All
> 
> I'm having a discussion with my colleagues on the pros and cons of sharing a 
> client_id.
> 
> For example, say we have N number of public mobile applications (the same 
> application package, an application instance on an individual phone), and one 
> approach is for each of these applications to have the same client_id.
> 
> I've been trying to analyze why it can be bad and the only thing I can come 
> up with is that there will be no (easy) way to track which application 
> instance actually accessed a given RS.
> 
> Can someone please explain what the pros and cons are of having the same 
> client_id shared between public client applications.
> 
> And what about multiple confidential clients being set up with the same 
> id/secret. I suspect it is a bad idea but what is main line why it is a bad 
> idea, lets say it is all done in the protected network, no chance of the bad 
> clients interfering...
> 
> 
> 
> Thanks, Sergey
> 
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Proof-of-Possession Key Semantics for JWTs spec addressing final shepherd comment

2015-11-04 Thread Mike Jones

Thanks for the detailed read, Brian.  You’re right that in the symmetric case, 
either the issuer or the presenter can create the symmetric PoP key and share 
it with the other party, since the effect is equivalent.  I suspect that both 
the key distribution draft and this draft should be updated with a sentence or 
two saying that either approach can be taken.  Do others concur?

-- Mike

From: Brian Campbell [mailto:bcampb...@pingidentity.com]
Sent: Thursday, November 05, 2015 7:48 AM
To: Mike Jones
Cc: Kepeng Li; oauth@ietf.org
Subject: Re: [OAUTH-WG] Proof-of-Possession Key Semantics for JWTs spec 
addressing final shepherd comment

+1 for the diagrams making the document more understandable.
One little nit/question, step 1 in both Symmetric and Asymmetric keys shows the 
Presenter sending the key to the Issuer. It's possible, however, for the key to 
be sent the other way. Presenter sending it to the Issuer is probably preferred 
for asymmetric, especially if the client can secure the private keys in 
hardware. But I don't know if one way or the other is clearly better for 
symmetric case and PoP key distribution currently has it the other 
way.
 Should the intro text somehow mention the possibility that the Issuer could 
create the key and send it to the Presenter?
I know it's only the introduction but it was just something that jumped out at 
me.

On Wed, Nov 4, 2015 at 9:04 AM, Mike Jones 
> wrote:
Thanks for suggesting the diagrams, Kepeng. They make the document more 
understandable.

-- Mike

From: Kepeng Li
Sent: ‎11/‎5/‎2015 12:57 AM
To: Mike Jones; 
oauth@ietf.org
Subject: Re: Proof-of-Possession Key Semantics for JWTs spec addressing final 
shepherd comment
Thank you Mike.

The diagrams look good to me.

Kind Regards
Kepeng

发件人: Mike Jones 
>
日期: Thursday, 5 November, 2015 12:32 am
至: "oauth@ietf.org" 
>
抄送: Li Kepeng >
主题: Proof-of-Possession Key Semantics for JWTs spec addressing final shepherd 
comment

Proof-of-Possession Key Semantics for JWTs draft -06 addresses the remaining 
document shepherd comment – adding use case diagrams to the introduction.

The updated specification is available at:

·http://tools.ietf.org/html/draft-ietf-oauth-proof-of-possession-06

An HTML formatted version is also available at:

·
https://self-issued.info/docs/draft-ietf-oauth-proof-of-possession-06.html

-- Mike

P.S.  This note was also posted at http://self-issued.info/?p=1471 and as 
@selfissued.

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Proof-of-Possession Key Semantics for JWTs spec addressing final shepherd comment

2015-11-04 Thread Brian Campbell

+1 for the diagrams making the document more understandable.

One little nit/question, step 1 in both Symmetric and Asymmetric keys shows
the Presenter sending the key to the Issuer. It's possible, however, for
the key to be sent the other way. Presenter sending it to the Issuer is
probably preferred for asymmetric, especially if the client can secure the
private keys in hardware. But I don't know if one way or the other is
clearly better for symmetric case and PoP key distribution currently has it
the other way
.
Should the intro text somehow mention the possibility that the Issuer could
create the key and send it to the Presenter?

I know it's only the introduction but it was just something that jumped out
at me.

On Wed, Nov 4, 2015 at 9:04 AM, Mike Jones 
wrote:

> Thanks for suggesting the diagrams, Kepeng. They make the document more
> understandable.
>
> -- Mike
> --
> From: Kepeng Li 
> Sent: ‎11/‎5/‎2015 12:57 AM
> To: Mike Jones ; oauth@ietf.org
> Subject: Re: Proof-of-Possession Key Semantics for JWTs spec addressing
> final shepherd comment
>
> Thank you Mike.
>
> The diagrams look good to me.
>
> Kind Regards
> Kepeng
>
> 发件人: Mike Jones 
> 日期: Thursday, 5 November, 2015 12:32 am
> 至: "oauth@ietf.org" 
> 抄送: Li Kepeng 
> 主题: Proof-of-Possession Key Semantics for JWTs spec addressing final
> shepherd comment
>
> Proof-of-Possession Key Semantics for JWTs draft -06 addresses the
> remaining document shepherd comment – adding use case diagrams to the
> introduction.
>
>
>
> The updated specification is available at:
>
> ·
> http://tools.ietf.org/html/draft-ietf-oauth-proof-of-possession-06
>
>
>
> An HTML formatted version is also available at:
>
> ·
> https://self-issued.info/docs/draft-ietf-oauth-proof-of-possession-06.html
>
>
>
> -- Mike
>
>
>
> P.S.  This note was also posted at http://self-issued.info/?p=1471 and as
> @selfissued .
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] OAuth Device Flow

2015-11-04 Thread Hannes Tschofenig

FYI: A couple of us got together and re-published an old, expired draft
about the OAuth Device Flow.

Here is the document:
https://tools.ietf.org/html/draft-denniss-oauth-device-flow-00

For the -00 version we tired to keep it inline with what has been
available with draft-recordon-oauth-v2-device-00. In upcoming versions
of this document we would like to capture existing deployment.

Here are two deployment examples that are reasonably well described:

- Google
https://developers.google.com/youtube/v3/guides/auth/devices

- Facebook
https://developers.facebook.com/docs/facebook-login/for-devices

Ciao
Hannes



signature.asc
Description: OpenPGP digital signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Proof-of-Possession Key Semantics for JWTs spec addressing final shepherd comment

2015-11-04 Thread Mike Jones

Good point.  I'll republish in the next day or so adding that to the security 
considerations.

-- Mike

-Original Message-
From: Hannes Tschofenig [mailto:hannes.tschofe...@gmx.net] 
Sent: Thursday, November 05, 2015 9:26 AM
To: Mike Jones; Brian Campbell
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Proof-of-Possession Key Semantics for JWTs spec 
addressing final shepherd comment

I agree that the effect is the same. From a security point of view there is 
only an impact if one of the two parties is in a better position to generate 
random numbers, which is the basis for generating a high entropy symmetric key.

On 11/04/2015 11:51 PM, Mike Jones wrote:
> Thanks for the detailed read, Brian.  You’re right that in the 
> symmetric case, either the issuer or the presenter can create the 
> symmetric PoP key and share it with the other party, since the effect is 
> equivalent.
> I suspect that both the key distribution draft and this draft should 
> be updated with a sentence or two saying that either approach can be 
> taken.  Do others concur?
> 
>  
> 
> -- Mike
> 
>  
> 
> *From:*Brian Campbell [mailto:bcampb...@pingidentity.com]
> *Sent:* Thursday, November 05, 2015 7:48 AM
> *To:* Mike Jones
> *Cc:* Kepeng Li; oauth@ietf.org
> *Subject:* Re: [OAUTH-WG] Proof-of-Possession Key Semantics for JWTs 
> spec addressing final shepherd comment
> 
>  
> 
> +1 for the diagrams making the document more understandable.
> 
> One little nit/question, step 1 in both Symmetric and Asymmetric keys 
> shows the Presenter sending the key to the Issuer. It's possible, 
> however, for the key to be sent the other way. Presenter sending it to 
> the Issuer is probably preferred for asymmetric, especially if the 
> client can secure the private keys in hardware. But I don't know if 
> one way or the other is clearly better for symmetric case and PoP key 
> distribution currently has it the other way 
> .
> Should the intro text somehow mention the possibility that the Issuer 
> could create the key and send it to the Presenter?
> 
> I know it's only the introduction but it was just something that 
> jumped out at me.
> 
>  
> 
>  
> 
> On Wed, Nov 4, 2015 at 9:04 AM, Mike Jones 
> > wrote:
> 
> Thanks for suggesting the diagrams, Kepeng. They make the document 
> more understandable.
> 
> -- Mike
> 
> --
> --
> 
> *From: *Kepeng Li 
> *Sent: *‎11/‎5/‎2015 12:57 AM
> *To: *Mike Jones ; oauth@ietf.org 
> 
> *Subject: *Re: Proof-of-Possession Key Semantics for JWTs spec 
> addressing final shepherd comment
> 
> Thank you Mike.
> 
>  
> 
> The diagrams look good to me.
> 
>  
> 
> Kind Regards
> 
> Kepeng
> 
>  
> 
> *发件人**: *Mike Jones  >
> *日期**: *Thursday, 5 November, 2015 12:32 am
> *至**: *"oauth@ietf.org "  >
> *抄送**: *Li Kepeng  >
> *主题**: *Proof-of-Possession Key Semantics for JWTs spec addressing 
> final shepherd comment
> 
>  
> 
> Proof-of-Possession Key Semantics for JWTs draft -06 addresses the 
> remaining document shepherd comment – adding use case diagrams to the 
> introduction.
> 
>  
> 
> The updated specification is available at:
> 
> ·http://tools.ietf.org/html/draft-ietf-oauth-proof-of-possession-06
> 
>  
> 
> An HTML formatted version is also available at:
> 
> ·   
> https://self-issued.info/docs/draft-ietf-oauth-proof-of-possession-06.
> html
> 
>  
> 
> -- Mike
> 
>  
> 
> P.S.  This note was also posted at http://self-issued.info/?p=1471 and 
> as @selfissued .
> 
> 
> ___
> OAuth mailing list
> OAuth@ietf.org  
> https://www.ietf.org/mailman/listinfo/oauth
> 
>  
> 
> 
> 
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
> 

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Proof-of-Possession Key Semantics for JWTs spec addressing final shepherd comment

2015-11-04 Thread Hannes Tschofenig

I agree that the effect is the same. From a security point of view there
is only an impact if one of the two parties is in a better position to
generate random numbers, which is the basis for generating a high
entropy symmetric key.

On 11/04/2015 11:51 PM, Mike Jones wrote:
> Thanks for the detailed read, Brian.  You’re right that in the symmetric
> case, either the issuer or the presenter can create the symmetric PoP
> key and share it with the other party, since the effect is equivalent. 
> I suspect that both the key distribution draft and this draft should be
> updated with a sentence or two saying that either approach can be
> taken.  Do others concur?
> 
>  
> 
> -- Mike
> 
>  
> 
> *From:*Brian Campbell [mailto:bcampb...@pingidentity.com]
> *Sent:* Thursday, November 05, 2015 7:48 AM
> *To:* Mike Jones
> *Cc:* Kepeng Li; oauth@ietf.org
> *Subject:* Re: [OAUTH-WG] Proof-of-Possession Key Semantics for JWTs
> spec addressing final shepherd comment
> 
>  
> 
> +1 for the diagrams making the document more understandable.
> 
> One little nit/question, step 1 in both Symmetric and Asymmetric keys
> shows the Presenter sending the key to the Issuer. It's possible,
> however, for the key to be sent the other way. Presenter sending it to
> the Issuer is probably preferred for asymmetric, especially if the
> client can secure the private keys in hardware. But I don't know if one
> way or the other is clearly better for symmetric case and PoP key
> distribution currently has it the other way
> .
> Should the intro text somehow mention the possibility that the Issuer
> could create the key and send it to the Presenter?
> 
> I know it's only the introduction but it was just something that jumped
> out at me.  
> 
>  
> 
>  
> 
> On Wed, Nov 4, 2015 at 9:04 AM, Mike Jones  > wrote:
> 
> Thanks for suggesting the diagrams, Kepeng. They make the document more
> understandable.
> 
> -- Mike
> 
> 
> 
> *From: *Kepeng Li 
> *Sent: *‎11/‎5/‎2015 12:57 AM
> *To: *Mike Jones ; oauth@ietf.org
> 
> *Subject: *Re: Proof-of-Possession Key Semantics for JWTs spec
> addressing final shepherd comment
> 
> Thank you Mike.
> 
>  
> 
> The diagrams look good to me.
> 
>  
> 
> Kind Regards
> 
> Kepeng
> 
>  
> 
> *发件人**: *Mike Jones  >
> *日期**: *Thursday, 5 November, 2015 12:32 am
> *至**: *"oauth@ietf.org "  >
> *抄送**: *Li Kepeng  >
> *主题**: *Proof-of-Possession Key Semantics for JWTs spec addressing
> final shepherd comment
> 
>  
> 
> Proof-of-Possession Key Semantics for JWTs draft -06 addresses the
> remaining document shepherd comment – adding use case diagrams to the
> introduction.
> 
>  
> 
> The updated specification is available at:
> 
> ·http://tools.ietf.org/html/draft-ietf-oauth-proof-of-possession-06
> 
>  
> 
> An HTML formatted version is also available at:
> 
> ·   
> https://self-issued.info/docs/draft-ietf-oauth-proof-of-possession-06.html
> 
>  
> 
> -- Mike
> 
>  
> 
> P.S.  This note was also posted at http://self-issued.info/?p=1471 and
> as @selfissued .
> 
> 
> ___
> OAuth mailing list
> OAuth@ietf.org 
> https://www.ietf.org/mailman/listinfo/oauth
> 
>  
> 
> 
> 
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
> 



signature.asc
Description: OpenPGP digital signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] OAuth Device Flow

2015-11-04 Thread William Denniss

Google has additional documentation here:
https://developers.google.com/identity/protocols/OAuth2ForDevices

The implementation mostly follows the original draft, but there are a few
differences. Also we've learnt a lot about the security and usability
implications of this flow along the way, which would be good to document.

On Thu, Nov 5, 2015 at 9:44 AM, Hannes Tschofenig  wrote:

> FYI: A couple of us got together and re-published an old, expired draft
> about the OAuth Device Flow.
>
> Here is the document:
> https://tools.ietf.org/html/draft-denniss-oauth-device-flow-00
>
> For the -00 version we tired to keep it inline with what has been
> available with draft-recordon-oauth-v2-device-00. In upcoming versions
> of this document we would like to capture existing deployment.
>
> Here are two deployment examples that are reasonably well described:
>
> - Google
> https://developers.google.com/youtube/v3/guides/auth/devices
>
> - Facebook
> https://developers.facebook.com/docs/facebook-login/for-devices
>
> Ciao
> Hannes
>
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Proof-of-Possession Key Semantics for JWTs spec addressing final shepherd comment

2015-11-04 Thread Justin Richer

That’s only if you’re using good hardware to produce a key. We can’t assume 
that’s the only kind of client that will exist, and software generation is 
likely to be much more common for a while yet.

Perhaps what we really need is strong guidance on when to use which approach. 
“If you client has a strong random generator function then you can make your 
own key, but otherwise let the server do it for you."

 — Justin

> On Nov 5, 2015, at 1:45 PM, Anthony Nadalin  wrote:
> 
> Not sure why you think its weaker as it would be a wrapped key that the 
> hardware produces 
> 
> -Original Message-
> From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of John Bradley
> Sent: Wednesday, November 4, 2015 8:43 PM
> To: Justin Richer 
> Cc:  
> Subject: Re: [OAUTH-WG] Proof-of-Possession Key Semantics for JWTs spec 
> addressing final shepherd comment
> 
> In the asymmetric case the use of a HSM or secure element is the argument for 
> the client selecting the public key.   In those cases the client is doing the 
> key gen in hardware so one hopes it is OK.   In the symetric case the client 
> generating the key is weaker (as in I can’t think of any really good reason).
> 
> 
>> On Nov 5, 2015, at 1:35 PM, Justin Richer  wrote:
>> 
>> I’d argue that it’s best practice, and in line with other parts of OAuth, if 
>> we assume the server generates it in the normal case (issuer -> presenter). 
>> Client generated token keys should be an exception, especially in the 
>> asymmetric case.
>> 
>> — Justin
>> 
>>> On Nov 5, 2015, at 1:32 PM, John Bradley  wrote:
>>> 
>>> Agreed the only real difference is the quality of the key.  If the server 
>>> generates it, then it knows that the client is not using the fixed hex 
>>> value of DEADBEEF for everything.
>>> 
>>> John B.
 On Nov 5, 2015, at 9:25 AM, Hannes Tschofenig  
 wrote:
 
 I agree that the effect is the same. From a security point of view 
 there is only an impact if one of the two parties is in a better 
 position to generate random numbers, which is the basis for 
 generating a high entropy symmetric key.
 
 On 11/04/2015 11:51 PM, Mike Jones wrote:
> Thanks for the detailed read, Brian.  You’re right that in the 
> symmetric case, either the issuer or the presenter can create the 
> symmetric PoP key and share it with the other party, since the effect is 
> equivalent.
> I suspect that both the key distribution draft and this draft 
> should be updated with a sentence or two saying that either 
> approach can be taken.  Do others concur?
> 
> 
> 
> -- Mike
> 
> 
> 
> *From:*Brian Campbell [mailto:bcampb...@pingidentity.com]
> *Sent:* Thursday, November 05, 2015 7:48 AM
> *To:* Mike Jones
> *Cc:* Kepeng Li; oauth@ietf.org
> *Subject:* Re: [OAUTH-WG] Proof-of-Possession Key Semantics for 
> JWTs spec addressing final shepherd comment
> 
> 
> 
> +1 for the diagrams making the document more understandable.
> 
> One little nit/question, step 1 in both Symmetric and Asymmetric 
> keys shows the Presenter sending the key to the Issuer. It's 
> possible, however, for the key to be sent the other way. Presenter 
> sending it to the Issuer is probably preferred for asymmetric, 
> especially if the client can secure the private keys in hardware. 
> But I don't know if one way or the other is clearly better for 
> symmetric case and PoP key distribution currently has it the other 
> way 
> .
> Should the intro text somehow mention the possibility that the 
> Issuer could create the key and send it to the Presenter?
> 
> I know it's only the introduction but it was just something that 
> jumped out at me.
> 
> 
> 
> 
> 
> On Wed, Nov 4, 2015 at 9:04 AM, Mike Jones 
> > wrote:
> 
> Thanks for suggesting the diagrams, Kepeng. They make the document 
> more understandable.
> 
> -- Mike
> 
> ---
> -
> 
> *From: *Kepeng Li 
> *Sent: *‎11/‎5/‎2015 12:57 AM
> *To: *Mike Jones ; 
> oauth@ietf.org 
> *Subject: *Re: Proof-of-Possession Key Semantics for JWTs spec 
> addressing final shepherd

[OAUTH-WG] Queue for oauth Remote Attendees

2015-11-04 Thread Alexa Morris

If you are planning to participate in the oauth session here at IETF 94 today — 
either locally in Yokohama or as a remote participant — we want to make sure 
that you are aware that the IETF is providing remote participants with a fairly 
new way to ask questions or make comments. In addition to using the Jabber 
room, for the oauth session there is also the opportunity for remote 
participants to enter a virtual queue and ask questions directly into the 
meeting room. 

This experimental queue was used in several sessions at IETF 92 and IETF 93, so 
you may have already seen it in action. There will be two queues for the oauth 
session — a virtual queue and an actual (in-room) queue. Remote attendees will 
log into the Meetecho platform and will have a virtual mic line that they can 
enter if they have a question or comment. In-room participants will continue to 
use normal mic lines. 

Instructions for remote participants are at 
http://ietf94.conf.meetecho.com/index.php/Remote_Participation. 

Information on how to join the Meetecho session is at 
http://ietf94.conf.meetecho.com/.

Verify that you are WebRTC compliant (required to use the virtual queue) by 
performing a self-test here: 
http://ietf94.conf.meetecho.com/index.php/Self_Test. 

Regards,
Alexa

--
Alexa Morris / Executive Director / IETF
48377 Fremont Blvd., Suite 117, Fremont, CA  94538
Phone: +1.510.492.4089 / Fax: +1.510.492.4001
Email: amor...@amsl.com

Managed by Association Management Solutions (AMS)
Forum Management, Meeting and Event Planning
www.amsl.com 

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Proof-of-Possession Key Semantics for JWTs spec addressing final shepherd comment

2015-11-04 Thread Anthony Nadalin

I can say on all windows based devices (pc, xbox, phone, etc) with only TPM 1.1 
this will be the approach so it will be commonly used 

-Original Message-
From: John Bradley [mailto:ve7...@ve7jtb.com] 
Sent: Wednesday, November 4, 2015 8:52 PM
To: Anthony Nadalin 
Cc: Justin Richer ;  
Subject: Re: [OAUTH-WG] Proof-of-Possession Key Semantics for JWTs spec 
addressing final shepherd comment

OK, no good reason unless the client is using a HSM that can do HMAC and can 
export a symmetric key wrapped in a asymmetric key provided by the AS.

We don’t currently cover that use case of sending a wrapped symmetric key to 
the AS in POP key distribution.   
I don’t know how common that is going to be, but it is worth thinking about 
defining.

John B.

> On Nov 5, 2015, at 1:45 PM, Anthony Nadalin  wrote:
> 
> Not sure why you think its weaker as it would be a wrapped key that 
> the hardware produces
> 
> -Original Message-
> From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of John Bradley
> Sent: Wednesday, November 4, 2015 8:43 PM
> To: Justin Richer 
> Cc:  
> Subject: Re: [OAUTH-WG] Proof-of-Possession Key Semantics for JWTs 
> spec addressing final shepherd comment
> 
> In the asymmetric case the use of a HSM or secure element is the argument for 
> the client selecting the public key.   In those cases the client is doing the 
> key gen in hardware so one hopes it is OK.   In the symetric case the client 
> generating the key is weaker (as in I can’t think of any really good reason).
> 
> 
>> On Nov 5, 2015, at 1:35 PM, Justin Richer  wrote:
>> 
>> I’d argue that it’s best practice, and in line with other parts of OAuth, if 
>> we assume the server generates it in the normal case (issuer -> presenter). 
>> Client generated token keys should be an exception, especially in the 
>> asymmetric case.
>> 
>> — Justin
>> 
>>> On Nov 5, 2015, at 1:32 PM, John Bradley  wrote:
>>> 
>>> Agreed the only real difference is the quality of the key.  If the server 
>>> generates it, then it knows that the client is not using the fixed hex 
>>> value of DEADBEEF for everything.
>>> 
>>> John B.
 On Nov 5, 2015, at 9:25 AM, Hannes Tschofenig  
 wrote:
 
 I agree that the effect is the same. From a security point of view 
 there is only an impact if one of the two parties is in a better 
 position to generate random numbers, which is the basis for 
 generating a high entropy symmetric key.
 
 On 11/04/2015 11:51 PM, Mike Jones wrote:
> Thanks for the detailed read, Brian.  You’re right that in the 
> symmetric case, either the issuer or the presenter can create the 
> symmetric PoP key and share it with the other party, since the effect is 
> equivalent.
> I suspect that both the key distribution draft and this draft 
> should be updated with a sentence or two saying that either 
> approach can be taken.  Do others concur?
> 
> 
> 
> -- Mike
> 
> 
> 
> *From:*Brian Campbell [mailto:bcampb...@pingidentity.com]
> *Sent:* Thursday, November 05, 2015 7:48 AM
> *To:* Mike Jones
> *Cc:* Kepeng Li; oauth@ietf.org
> *Subject:* Re: [OAUTH-WG] Proof-of-Possession Key Semantics for 
> JWTs spec addressing final shepherd comment
> 
> 
> 
> +1 for the diagrams making the document more understandable.
> 
> One little nit/question, step 1 in both Symmetric and Asymmetric 
> keys shows the Presenter sending the key to the Issuer. It's 
> possible, however, for the key to be sent the other way. Presenter 
> sending it to the Issuer is probably preferred for asymmetric, 
> especially if the client can secure the private keys in hardware.
> But I don't know if one way or the other is clearly better for 
> symmetric case and PoP key distribution currently has it the other 
> way 
> .
> Should the intro text somehow mention the possibility that the 
> Issuer could create the key and send it to the Presenter?
> 
> I know it's only the introduction but it was just something that 
> jumped out at me.
> 
> 
> 
> 
> 
> On Wed, Nov 4, 2015 at 9:04 AM, Mike Jones 
> > wrote:
> 
> Thanks for suggesting the diagrams, Kepeng. They make the document 
> more understandable.
> 
> --

Re: [OAUTH-WG] Proof-of-Possession Key Semantics for JWTs spec addressing final shepherd comment

2015-11-04 Thread John Bradley

In the asymmetric case the use of a HSM or secure element is the argument for 
the client selecting the public key.   In those cases the client is doing the 
key gen in hardware so one hopes it is OK.   In the symetric case the client 
generating the key is weaker (as in I can’t think of any really good reason).

> On Nov 5, 2015, at 1:35 PM, Justin Richer  wrote:
> 
> I’d argue that it’s best practice, and in line with other parts of OAuth, if 
> we assume the server generates it in the normal case (issuer -> presenter). 
> Client generated token keys should be an exception, especially in the 
> asymmetric case.
> 
> — Justin
> 
>> On Nov 5, 2015, at 1:32 PM, John Bradley  wrote:
>> 
>> Agreed the only real difference is the quality of the key.  If the server 
>> generates it, then it knows that the client is not using the fixed hex value 
>> of DEADBEEF for everything.
>> 
>> John B.
>>> On Nov 5, 2015, at 9:25 AM, Hannes Tschofenig  
>>> wrote:
>>> 
>>> I agree that the effect is the same. From a security point of view there
>>> is only an impact if one of the two parties is in a better position to
>>> generate random numbers, which is the basis for generating a high
>>> entropy symmetric key.
>>> 
>>> On 11/04/2015 11:51 PM, Mike Jones wrote:
 Thanks for the detailed read, Brian.  You’re right that in the symmetric
 case, either the issuer or the presenter can create the symmetric PoP
 key and share it with the other party, since the effect is equivalent. 
 I suspect that both the key distribution draft and this draft should be
 updated with a sentence or two saying that either approach can be
 taken.  Do others concur?

  -- Mike

 *From:*Brian Campbell [mailto:bcampb...@pingidentity.com]
 *Sent:* Thursday, November 05, 2015 7:48 AM
 *To:* Mike Jones
 *Cc:* Kepeng Li; oauth@ietf.org
 *Subject:* Re: [OAUTH-WG] Proof-of-Possession Key Semantics for JWTs
 spec addressing final shepherd comment

 +1 for the diagrams making the document more understandable.

 One little nit/question, step 1 in both Symmetric and Asymmetric keys
 shows the Presenter sending the key to the Issuer. It's possible,
 however, for the key to be sent the other way. Presenter sending it to
 the Issuer is probably preferred for asymmetric, especially if the
 client can secure the private keys in hardware. But I don't know if one
 way or the other is clearly better for symmetric case and PoP key
 distribution currently has it the other way
 .
 Should the intro text somehow mention the possibility that the Issuer
 could create the key and send it to the Presenter?

 I know it's only the introduction but it was just something that jumped
 out at me.  

 On Wed, Nov 4, 2015 at 9:04 AM, Mike Jones > wrote:

 Thanks for suggesting the diagrams, Kepeng. They make the document more
 understandable.

 -- Mike

 *From: *Kepeng Li 
 *Sent: *‎11/‎5/‎2015 12:57 AM
 *To: *Mike Jones ; oauth@ietf.org

 *Subject: *Re: Proof-of-Possession Key Semantics for JWTs spec
 addressing final shepherd comment

 Thank you Mike.

 The diagrams look good to me.

 Kind Regards

 Kepeng

 *发件人**: *Mike Jones >
 *日期**: *Thursday, 5 November, 2015 12:32 am
 *至**: *"oauth@ietf.org " >
 *抄送**: *Li Kepeng >
 *主题**: *Proof-of-Possession Key Semantics for JWTs spec addressing
 final shepherd comment

 Proof-of-Possession Key Semantics for JWTs draft -06 addresses the
 remaining document shepherd comment – adding use case diagrams to the
 introduction.

 The updated specification is available at:

 ·http://tools.ietf.org/html/draft-ietf-oauth-proof-of-possession-06

 An HTML formatted version is also available at:

 ·   
 https://self-issued.info/docs/draft-ietf-oauth-proof-of-possession-06.html

  -- Mike

 P.S.  This note was also posted at http://self-issued.info/?p=1471 and

Re: [OAUTH-WG] Proof-of-Possession Key Semantics for JWTs spec addressing final shepherd comment

2015-11-04 Thread John Bradley

Agreed the only real difference is the quality of the key.  If the server 
generates it, then it knows that the client is not using the fixed hex value of 
DEADBEEF for everything.

John B.
> On Nov 5, 2015, at 9:25 AM, Hannes Tschofenig  
> wrote:
> 
> I agree that the effect is the same. From a security point of view there
> is only an impact if one of the two parties is in a better position to
> generate random numbers, which is the basis for generating a high
> entropy symmetric key.
> 
> On 11/04/2015 11:51 PM, Mike Jones wrote:
>> Thanks for the detailed read, Brian.  You’re right that in the symmetric
>> case, either the issuer or the presenter can create the symmetric PoP
>> key and share it with the other party, since the effect is equivalent. 
>> I suspect that both the key distribution draft and this draft should be
>> updated with a sentence or two saying that either approach can be
>> taken.  Do others concur?
>> 
>> 
>> 
>>-- Mike
>> 
>> 
>> 
>> *From:*Brian Campbell [mailto:bcampb...@pingidentity.com]
>> *Sent:* Thursday, November 05, 2015 7:48 AM
>> *To:* Mike Jones
>> *Cc:* Kepeng Li; oauth@ietf.org
>> *Subject:* Re: [OAUTH-WG] Proof-of-Possession Key Semantics for JWTs
>> spec addressing final shepherd comment
>> 
>> 
>> 
>> +1 for the diagrams making the document more understandable.
>> 
>> One little nit/question, step 1 in both Symmetric and Asymmetric keys
>> shows the Presenter sending the key to the Issuer. It's possible,
>> however, for the key to be sent the other way. Presenter sending it to
>> the Issuer is probably preferred for asymmetric, especially if the
>> client can secure the private keys in hardware. But I don't know if one
>> way or the other is clearly better for symmetric case and PoP key
>> distribution currently has it the other way
>> .
>> Should the intro text somehow mention the possibility that the Issuer
>> could create the key and send it to the Presenter?
>> 
>> I know it's only the introduction but it was just something that jumped
>> out at me.  
>> 
>> 
>> 
>> 
>> 
>> On Wed, Nov 4, 2015 at 9:04 AM, Mike Jones > > wrote:
>> 
>> Thanks for suggesting the diagrams, Kepeng. They make the document more
>> understandable.
>> 
>> -- Mike
>> 
>> 
>> 
>> *From: *Kepeng Li 
>> *Sent: *‎11/‎5/‎2015 12:57 AM
>> *To: *Mike Jones ; oauth@ietf.org
>> 
>> *Subject: *Re: Proof-of-Possession Key Semantics for JWTs spec
>> addressing final shepherd comment
>> 
>> Thank you Mike.
>> 
>> 
>> 
>> The diagrams look good to me.
>> 
>> 
>> 
>> Kind Regards
>> 
>> Kepeng
>> 
>> 
>> 
>> *发件人**: *Mike Jones > >
>> *日期**: *Thursday, 5 November, 2015 12:32 am
>> *至**: *"oauth@ietf.org " > >
>> *抄送**: *Li Kepeng > >
>> *主题**: *Proof-of-Possession Key Semantics for JWTs spec addressing
>> final shepherd comment
>> 
>> 
>> 
>> Proof-of-Possession Key Semantics for JWTs draft -06 addresses the
>> remaining document shepherd comment – adding use case diagrams to the
>> introduction.
>> 
>> 
>> 
>> The updated specification is available at:
>> 
>> ·http://tools.ietf.org/html/draft-ietf-oauth-proof-of-possession-06
>> 
>> 
>> 
>> An HTML formatted version is also available at:
>> 
>> ·   
>> https://self-issued.info/docs/draft-ietf-oauth-proof-of-possession-06.html
>> 
>> 
>> 
>>-- Mike
>> 
>> 
>> 
>> P.S.  This note was also posted at http://self-issued.info/?p=1471 and
>> as @selfissued .
>> 
>> 
>> ___
>> OAuth mailing list
>> OAuth@ietf.org 
>> https://www.ietf.org/mailman/listinfo/oauth
>> 
>> 
>> 
>> 
>> 
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>> 
> 
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Proof-of-Possession Key Semantics for JWTs spec addressing final shepherd comment

2015-11-04 Thread Anthony Nadalin

Not sure why you think its weaker as it would be a wrapped key that the 
hardware produces 

-Original Message-
From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of John Bradley
Sent: Wednesday, November 4, 2015 8:43 PM
To: Justin Richer 
Cc:  
Subject: Re: [OAUTH-WG] Proof-of-Possession Key Semantics for JWTs spec 
addressing final shepherd comment

In the asymmetric case the use of a HSM or secure element is the argument for 
the client selecting the public key.   In those cases the client is doing the 
key gen in hardware so one hopes it is OK.   In the symetric case the client 
generating the key is weaker (as in I can’t think of any really good reason).

> On Nov 5, 2015, at 1:35 PM, Justin Richer  wrote:
> 
> I’d argue that it’s best practice, and in line with other parts of OAuth, if 
> we assume the server generates it in the normal case (issuer -> presenter). 
> Client generated token keys should be an exception, especially in the 
> asymmetric case.
> 
> — Justin
> 
>> On Nov 5, 2015, at 1:32 PM, John Bradley  wrote:
>> 
>> Agreed the only real difference is the quality of the key.  If the server 
>> generates it, then it knows that the client is not using the fixed hex value 
>> of DEADBEEF for everything.
>> 
>> John B.
>>> On Nov 5, 2015, at 9:25 AM, Hannes Tschofenig  
>>> wrote:
>>> 
>>> I agree that the effect is the same. From a security point of view 
>>> there is only an impact if one of the two parties is in a better 
>>> position to generate random numbers, which is the basis for 
>>> generating a high entropy symmetric key.
>>> 
>>> On 11/04/2015 11:51 PM, Mike Jones wrote:
 Thanks for the detailed read, Brian.  You’re right that in the 
 symmetric case, either the issuer or the presenter can create the 
 symmetric PoP key and share it with the other party, since the effect is 
 equivalent.
 I suspect that both the key distribution draft and this draft 
 should be updated with a sentence or two saying that either 
 approach can be taken.  Do others concur?

  -- Mike

 *From:*Brian Campbell [mailto:bcampb...@pingidentity.com]
 *Sent:* Thursday, November 05, 2015 7:48 AM
 *To:* Mike Jones
 *Cc:* Kepeng Li; oauth@ietf.org
 *Subject:* Re: [OAUTH-WG] Proof-of-Possession Key Semantics for 
 JWTs spec addressing final shepherd comment

 +1 for the diagrams making the document more understandable.

 One little nit/question, step 1 in both Symmetric and Asymmetric 
 keys shows the Presenter sending the key to the Issuer. It's 
 possible, however, for the key to be sent the other way. Presenter 
 sending it to the Issuer is probably preferred for asymmetric, 
 especially if the client can secure the private keys in hardware. 
 But I don't know if one way or the other is clearly better for 
 symmetric case and PoP key distribution currently has it the other 
 way 
 .
 Should the intro text somehow mention the possibility that the 
 Issuer could create the key and send it to the Presenter?

 I know it's only the introduction but it was just something that 
 jumped out at me.

 On Wed, Nov 4, 2015 at 9:04 AM, Mike Jones 
 > wrote:

 Thanks for suggesting the diagrams, Kepeng. They make the document 
 more understandable.

 -- Mike

 ---
 -

 *From: *Kepeng Li 
 *Sent: *‎11/‎5/‎2015 12:57 AM
 *To: *Mike Jones ; 
 oauth@ietf.org 
 *Subject: *Re: Proof-of-Possession Key Semantics for JWTs spec 
 addressing final shepherd comment

 Thank you Mike.

 The diagrams look good to me.

 Kind Regards

 Kepeng

 *发件人**: *Mike Jones >
 *日期**: *Thursday, 5 November, 2015 12:32 am
 *至**: *"oauth@ietf.org " >
 *抄送**: *Li Kepeng >
 *主题**: *Proof-of-Possession Key Semantics for JWTs spec addressing 
 final shepherd comment

Re: [OAUTH-WG] Proof-of-Possession Key Semantics for JWTs spec addressing final shepherd comment

2015-11-04 Thread Justin Richer

I’d argue that it’s best practice, and in line with other parts of OAuth, if we 
assume the server generates it in the normal case (issuer -> presenter). Client 
generated token keys should be an exception, especially in the asymmetric case.

 — Justin

> On Nov 5, 2015, at 1:32 PM, John Bradley  wrote:
> 
> Agreed the only real difference is the quality of the key.  If the server 
> generates it, then it knows that the client is not using the fixed hex value 
> of DEADBEEF for everything.
> 
> John B.
>> On Nov 5, 2015, at 9:25 AM, Hannes Tschofenig  
>> wrote:
>> 
>> I agree that the effect is the same. From a security point of view there
>> is only an impact if one of the two parties is in a better position to
>> generate random numbers, which is the basis for generating a high
>> entropy symmetric key.
>> 
>> On 11/04/2015 11:51 PM, Mike Jones wrote:
>>> Thanks for the detailed read, Brian.  You’re right that in the symmetric
>>> case, either the issuer or the presenter can create the symmetric PoP
>>> key and share it with the other party, since the effect is equivalent. 
>>> I suspect that both the key distribution draft and this draft should be
>>> updated with a sentence or two saying that either approach can be
>>> taken.  Do others concur?
>>> 
>>> 
>>> 
>>>   -- Mike
>>> 
>>> 
>>> 
>>> *From:*Brian Campbell [mailto:bcampb...@pingidentity.com]
>>> *Sent:* Thursday, November 05, 2015 7:48 AM
>>> *To:* Mike Jones
>>> *Cc:* Kepeng Li; oauth@ietf.org
>>> *Subject:* Re: [OAUTH-WG] Proof-of-Possession Key Semantics for JWTs
>>> spec addressing final shepherd comment
>>> 
>>> 
>>> 
>>> +1 for the diagrams making the document more understandable.
>>> 
>>> One little nit/question, step 1 in both Symmetric and Asymmetric keys
>>> shows the Presenter sending the key to the Issuer. It's possible,
>>> however, for the key to be sent the other way. Presenter sending it to
>>> the Issuer is probably preferred for asymmetric, especially if the
>>> client can secure the private keys in hardware. But I don't know if one
>>> way or the other is clearly better for symmetric case and PoP key
>>> distribution currently has it the other way
>>> .
>>> Should the intro text somehow mention the possibility that the Issuer
>>> could create the key and send it to the Presenter?
>>> 
>>> I know it's only the introduction but it was just something that jumped
>>> out at me.  
>>> 
>>> 
>>> 
>>> 
>>> 
>>> On Wed, Nov 4, 2015 at 9:04 AM, Mike Jones >> > wrote:
>>> 
>>> Thanks for suggesting the diagrams, Kepeng. They make the document more
>>> understandable.
>>> 
>>> -- Mike
>>> 
>>> 
>>> 
>>> *From: *Kepeng Li 
>>> *Sent: *‎11/‎5/‎2015 12:57 AM
>>> *To: *Mike Jones ; oauth@ietf.org
>>> 
>>> *Subject: *Re: Proof-of-Possession Key Semantics for JWTs spec
>>> addressing final shepherd comment
>>> 
>>> Thank you Mike.
>>> 
>>> 
>>> 
>>> The diagrams look good to me.
>>> 
>>> 
>>> 
>>> Kind Regards
>>> 
>>> Kepeng
>>> 
>>> 
>>> 
>>> *发件人**: *Mike Jones >> >
>>> *日期**: *Thursday, 5 November, 2015 12:32 am
>>> *至**: *"oauth@ietf.org " >> >
>>> *抄送**: *Li Kepeng >> >
>>> *主题**: *Proof-of-Possession Key Semantics for JWTs spec addressing
>>> final shepherd comment
>>> 
>>> 
>>> 
>>> Proof-of-Possession Key Semantics for JWTs draft -06 addresses the
>>> remaining document shepherd comment – adding use case diagrams to the
>>> introduction.
>>> 
>>> 
>>> 
>>> The updated specification is available at:
>>> 
>>> ·http://tools.ietf.org/html/draft-ietf-oauth-proof-of-possession-06
>>> 
>>> 
>>> 
>>> An HTML formatted version is also available at:
>>> 
>>> ·   
>>> https://self-issued.info/docs/draft-ietf-oauth-proof-of-possession-06.html
>>> 
>>> 
>>> 
>>>   -- Mike
>>> 
>>> 
>>> 
>>> P.S.  This note was also posted at http://self-issued.info/?p=1471 and
>>> as @selfissued .
>>> 
>>> 
>>> ___
>>> OAuth mailing list
>>> OAuth@ietf.org 
>>> https://www.ietf.org/mailman/listinfo/oauth
>>> 
>>> 
>>> 
>>> 
>>> 
>>> ___
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>> 
>> 
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>>

Re: [OAUTH-WG] Proof-of-Possession Key Semantics for JWTs spec addressing final shepherd comment

2015-11-04 Thread John Bradley

Good to know.   So the AS needs to expose a public key for the TPM to use for 
encryption.   I am guessing you are not using a encrypted JWK for that.  What 
is the format the TPM produces the wrapped key in?

John B.
> On Nov 5, 2015, at 1:55 PM, Anthony Nadalin  wrote:
> 
> I can say on all windows based devices (pc, xbox, phone, etc) with only TPM 
> 1.1 this will be the approach so it will be commonly used 
> 
> -Original Message-
> From: John Bradley [mailto:ve7...@ve7jtb.com] 
> Sent: Wednesday, November 4, 2015 8:52 PM
> To: Anthony Nadalin 
> Cc: Justin Richer ;  
> Subject: Re: [OAUTH-WG] Proof-of-Possession Key Semantics for JWTs spec 
> addressing final shepherd comment
> 
> OK, no good reason unless the client is using a HSM that can do HMAC and can 
> export a symmetric key wrapped in a asymmetric key provided by the AS.
> 
> We don’t currently cover that use case of sending a wrapped symmetric key to 
> the AS in POP key distribution.   
> I don’t know how common that is going to be, but it is worth thinking about 
> defining.
> 
> John B.
> 
>> On Nov 5, 2015, at 1:45 PM, Anthony Nadalin  wrote:
>> 
>> Not sure why you think its weaker as it would be a wrapped key that 
>> the hardware produces
>> 
>> -Original Message-
>> From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of John Bradley
>> Sent: Wednesday, November 4, 2015 8:43 PM
>> To: Justin Richer 
>> Cc:  
>> Subject: Re: [OAUTH-WG] Proof-of-Possession Key Semantics for JWTs 
>> spec addressing final shepherd comment
>> 
>> In the asymmetric case the use of a HSM or secure element is the argument 
>> for the client selecting the public key.   In those cases the client is 
>> doing the key gen in hardware so one hopes it is OK.   In the symetric case 
>> the client generating the key is weaker (as in I can’t think of any really 
>> good reason).
>> 
>> 
>>> On Nov 5, 2015, at 1:35 PM, Justin Richer  wrote:
>>> 
>>> I’d argue that it’s best practice, and in line with other parts of OAuth, 
>>> if we assume the server generates it in the normal case (issuer -> 
>>> presenter). Client generated token keys should be an exception, especially 
>>> in the asymmetric case.
>>> 
>>> — Justin
>>> 
 On Nov 5, 2015, at 1:32 PM, John Bradley  wrote:
 
 Agreed the only real difference is the quality of the key.  If the server 
 generates it, then it knows that the client is not using the fixed hex 
 value of DEADBEEF for everything.
 
 John B.
> On Nov 5, 2015, at 9:25 AM, Hannes Tschofenig  
> wrote:
> 
> I agree that the effect is the same. From a security point of view 
> there is only an impact if one of the two parties is in a better 
> position to generate random numbers, which is the basis for 
> generating a high entropy symmetric key.
> 
> On 11/04/2015 11:51 PM, Mike Jones wrote:
>> Thanks for the detailed read, Brian.  You’re right that in the 
>> symmetric case, either the issuer or the presenter can create the 
>> symmetric PoP key and share it with the other party, since the effect is 
>> equivalent.
>> I suspect that both the key distribution draft and this draft 
>> should be updated with a sentence or two saying that either 
>> approach can be taken.  Do others concur?
>> 
>> 
>> 
>>-- Mike
>> 
>> 
>> 
>> *From:*Brian Campbell [mailto:bcampb...@pingidentity.com]
>> *Sent:* Thursday, November 05, 2015 7:48 AM
>> *To:* Mike Jones
>> *Cc:* Kepeng Li; oauth@ietf.org
>> *Subject:* Re: [OAUTH-WG] Proof-of-Possession Key Semantics for 
>> JWTs spec addressing final shepherd comment
>> 
>> 
>> 
>> +1 for the diagrams making the document more understandable.
>> 
>> One little nit/question, step 1 in both Symmetric and Asymmetric 
>> keys shows the Presenter sending the key to the Issuer. It's 
>> possible, however, for the key to be sent the other way. Presenter 
>> sending it to the Issuer is probably preferred for asymmetric, 
>> especially if the client can secure the private keys in hardware.
>> But I don't know if one way or the other is clearly better for 
>> symmetric case and PoP key distribution currently has it the other 
>> way 
>> .
>> Should the intro text somehow mention the possibility that the 
>> Issuer could create the key

Re: [OAUTH-WG] Proof-of-Possession Key Semantics for JWTs spec addressing final shepherd comment

2015-11-04 Thread Anthony Nadalin

Our use case involves mostly hardware (TPM 1.2) based key generation, where the 
hardware (TPM 1.1) is slow we will use secure software execution environment, 
our use case is always client side generated keys

-Original Message-
From: Justin Richer [mailto:jric...@mit.edu] 
Sent: Wednesday, November 4, 2015 8:48 PM
To: Anthony Nadalin 
Cc: John Bradley ;  
Subject: Re: [OAUTH-WG] Proof-of-Possession Key Semantics for JWTs spec 
addressing final shepherd comment

That’s only if you’re using good hardware to produce a key. We can’t assume 
that’s the only kind of client that will exist, and software generation is 
likely to be much more common for a while yet.

Perhaps what we really need is strong guidance on when to use which approach. 
“If you client has a strong random generator function then you can make your 
own key, but otherwise let the server do it for you."

 — Justin

> On Nov 5, 2015, at 1:45 PM, Anthony Nadalin  wrote:
> 
> Not sure why you think its weaker as it would be a wrapped key that 
> the hardware produces
> 
> -Original Message-
> From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of John Bradley
> Sent: Wednesday, November 4, 2015 8:43 PM
> To: Justin Richer 
> Cc:  
> Subject: Re: [OAUTH-WG] Proof-of-Possession Key Semantics for JWTs 
> spec addressing final shepherd comment
> 
> In the asymmetric case the use of a HSM or secure element is the argument for 
> the client selecting the public key.   In those cases the client is doing the 
> key gen in hardware so one hopes it is OK.   In the symetric case the client 
> generating the key is weaker (as in I can’t think of any really good reason).
> 
> 
>> On Nov 5, 2015, at 1:35 PM, Justin Richer  wrote:
>> 
>> I’d argue that it’s best practice, and in line with other parts of OAuth, if 
>> we assume the server generates it in the normal case (issuer -> presenter). 
>> Client generated token keys should be an exception, especially in the 
>> asymmetric case.
>> 
>> — Justin
>> 
>>> On Nov 5, 2015, at 1:32 PM, John Bradley  wrote:
>>> 
>>> Agreed the only real difference is the quality of the key.  If the server 
>>> generates it, then it knows that the client is not using the fixed hex 
>>> value of DEADBEEF for everything.
>>> 
>>> John B.
 On Nov 5, 2015, at 9:25 AM, Hannes Tschofenig  
 wrote:
 
 I agree that the effect is the same. From a security point of view 
 there is only an impact if one of the two parties is in a better 
 position to generate random numbers, which is the basis for 
 generating a high entropy symmetric key.
 
 On 11/04/2015 11:51 PM, Mike Jones wrote:
> Thanks for the detailed read, Brian.  You’re right that in the 
> symmetric case, either the issuer or the presenter can create the 
> symmetric PoP key and share it with the other party, since the effect is 
> equivalent.
> I suspect that both the key distribution draft and this draft 
> should be updated with a sentence or two saying that either 
> approach can be taken.  Do others concur?
> 
> 
> 
> -- Mike
> 
> 
> 
> *From:*Brian Campbell [mailto:bcampb...@pingidentity.com]
> *Sent:* Thursday, November 05, 2015 7:48 AM
> *To:* Mike Jones
> *Cc:* Kepeng Li; oauth@ietf.org
> *Subject:* Re: [OAUTH-WG] Proof-of-Possession Key Semantics for 
> JWTs spec addressing final shepherd comment
> 
> 
> 
> +1 for the diagrams making the document more understandable.
> 
> One little nit/question, step 1 in both Symmetric and Asymmetric 
> keys shows the Presenter sending the key to the Issuer. It's 
> possible, however, for the key to be sent the other way. Presenter 
> sending it to the Issuer is probably preferred for asymmetric, 
> especially if the client can secure the private keys in hardware.
> But I don't know if one way or the other is clearly better for 
> symmetric case and PoP key distribution currently has it the other 
> way 
> .
> Should the intro text somehow mention the possibility that the 
> Issuer could create the key and send it to the Presenter?
> 
> I know it's only the introduction but it was just something that 
> jumped out at me.
> 
> 
> 
> 
> 
> On Wed, Nov 4, 2015 at 9:04 AM, Mike Jones 
>

Re: [OAUTH-WG] Proof-of-Possession Key Semantics for JWTs spec addressing final shepherd comment

2015-11-04 Thread John Bradley

OK, no good reason unless the client is using a HSM that can do HMAC and can 
export a symmetric key wrapped in a asymmetric key provided by the AS.

We don’t currently cover that use case of sending a wrapped symmetric key to 
the AS in POP key distribution.   
I don’t know how common that is going to be, but it is worth thinking about 
defining.

John B.

> On Nov 5, 2015, at 1:45 PM, Anthony Nadalin  wrote:
> 
> Not sure why you think its weaker as it would be a wrapped key that the 
> hardware produces 
> 
> -Original Message-
> From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of John Bradley
> Sent: Wednesday, November 4, 2015 8:43 PM
> To: Justin Richer 
> Cc:  
> Subject: Re: [OAUTH-WG] Proof-of-Possession Key Semantics for JWTs spec 
> addressing final shepherd comment
> 
> In the asymmetric case the use of a HSM or secure element is the argument for 
> the client selecting the public key.   In those cases the client is doing the 
> key gen in hardware so one hopes it is OK.   In the symetric case the client 
> generating the key is weaker (as in I can’t think of any really good reason).
> 
> 
>> On Nov 5, 2015, at 1:35 PM, Justin Richer  wrote:
>> 
>> I’d argue that it’s best practice, and in line with other parts of OAuth, if 
>> we assume the server generates it in the normal case (issuer -> presenter). 
>> Client generated token keys should be an exception, especially in the 
>> asymmetric case.
>> 
>> — Justin
>> 
>>> On Nov 5, 2015, at 1:32 PM, John Bradley  wrote:
>>> 
>>> Agreed the only real difference is the quality of the key.  If the server 
>>> generates it, then it knows that the client is not using the fixed hex 
>>> value of DEADBEEF for everything.
>>> 
>>> John B.
 On Nov 5, 2015, at 9:25 AM, Hannes Tschofenig  
 wrote:
 
 I agree that the effect is the same. From a security point of view 
 there is only an impact if one of the two parties is in a better 
 position to generate random numbers, which is the basis for 
 generating a high entropy symmetric key.
 
 On 11/04/2015 11:51 PM, Mike Jones wrote:
> Thanks for the detailed read, Brian.  You’re right that in the 
> symmetric case, either the issuer or the presenter can create the 
> symmetric PoP key and share it with the other party, since the effect is 
> equivalent.
> I suspect that both the key distribution draft and this draft 
> should be updated with a sentence or two saying that either 
> approach can be taken.  Do others concur?
> 
> 
> 
> -- Mike
> 
> 
> 
> *From:*Brian Campbell [mailto:bcampb...@pingidentity.com]
> *Sent:* Thursday, November 05, 2015 7:48 AM
> *To:* Mike Jones
> *Cc:* Kepeng Li; oauth@ietf.org
> *Subject:* Re: [OAUTH-WG] Proof-of-Possession Key Semantics for 
> JWTs spec addressing final shepherd comment
> 
> 
> 
> +1 for the diagrams making the document more understandable.
> 
> One little nit/question, step 1 in both Symmetric and Asymmetric 
> keys shows the Presenter sending the key to the Issuer. It's 
> possible, however, for the key to be sent the other way. Presenter 
> sending it to the Issuer is probably preferred for asymmetric, 
> especially if the client can secure the private keys in hardware. 
> But I don't know if one way or the other is clearly better for 
> symmetric case and PoP key distribution currently has it the other 
> way 
> .
> Should the intro text somehow mention the possibility that the 
> Issuer could create the key and send it to the Presenter?
> 
> I know it's only the introduction but it was just something that 
> jumped out at me.
> 
> 
> 
> 
> 
> On Wed, Nov 4, 2015 at 9:04 AM, Mike Jones 
> > wrote:
> 
> Thanks for suggesting the diagrams, Kepeng. They make the document 
> more understandable.
> 
> -- Mike
> 
> ---
> -
> 
> *From: *Kepeng Li 
> *Sent: *‎11/‎5/‎2015 12:57 AM
> *To: *Mike Jones ; 
> oauth@ietf.org 
> *Subject: *Re: Proof-of-Possession Key Semantics for JWTs spec 
> addressing final shepherd comment
> 
> Thank you Mike.
> 
> 
> 
> The

[OAUTH-WG] Inaccuracy in last point in JWSREQ presentation about registering request_object_signing_alg

2015-11-04 Thread Mike Jones

The last bullet of the last slide of 
https://www.ietf.org/proceedings/94/slides/slides-94-oauth-5.pdf says:
  Section 7
  - False statement:
● The request_object_signing_alg OAuth Dynamic Client Registration Metadata 
is pending registration by OpenID Connect Dynamic Registration specification.
● The registry doesn't have it and Connect's Registration "makes no 
requests of IANA"

This not false.  (I didn’t say so from the microphone in the room in the 
interest of time.)  
http://openid.net/specs/openid-connect-registration-1_0-29.html#DynRegContents, 
the current errata 2 draft version, contains the registration request for 
request_object_signing_alg.  It has not yet been submitted to IANA but it will 
be soon.

-- Mike

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] I-D Action: draft-ietf-oauth-proof-of-possession-06.txt

2015-11-04 Thread internet-drafts


A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Web Authorization Protocol Working Group of 
the IETF.

Title   : Proof-of-Possession Key Semantics for JSON Web Tokens 
(JWTs)
Authors : Michael B. Jones
  John Bradley
  Hannes Tschofenig
Filename: draft-ietf-oauth-proof-of-possession-06.txt
Pages   : 17
Date: 2015-11-04

Abstract:
   This specification defines how to express a declaration in a JSON Web
   Token (JWT) that the presenter of the JWT possesses a particular key
   and that the recipient can cryptographically confirm proof-of-
   possession of the key by the presenter.  Being able to prove
   possession of a key is also sometimes described as the presenter
   being a holder-of-key.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-oauth-proof-of-possession/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-oauth-proof-of-possession-06

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-proof-of-possession-06


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] Proof-of-Possession Key Semantics for JWTs spec addressing final shepherd comment

2015-11-04 Thread Mike Jones

Proof-of-Possession Key Semantics for JWTs draft -06 addresses the remaining 
document shepherd comment - adding use case diagrams to the introduction.

The updated specification is available at:

*http://tools.ietf.org/html/draft-ietf-oauth-proof-of-possession-06

An HTML formatted version is also available at:

*
https://self-issued.info/docs/draft-ietf-oauth-proof-of-possession-06.html

-- Mike

P.S.  This note was also posted at http://self-issued.info/?p=1471 and as 
@selfissued.
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] Sharing a client_id: is it good or bad ?

2015-11-04 Thread Sergey Beryozkin


Hi All

I'm having a discussion with my colleagues on the pros and cons of 
sharing a client_id.


For example, say we have N number of public mobile applications (the 
same application package, an application instance on an individual 
phone), and one approach is for each of these applications to have the 
same client_id.


I've been trying to analyze why it can be bad and the only thing I can 
come up with is that there will be no (easy) way to track which 
application instance actually accessed a given RS.


Can someone please explain what the pros and cons are of having the same 
client_id shared between public client applications.


And what about multiple confidential clients being set up with the same 
id/secret. I suspect it is a bad idea but what is main line why it is a 
bad idea, lets say it is all done in the protected network, no chance of 
the bad clients interfering...




Thanks, Sergey

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Proof-of-Possession Key Semantics for JWTs spec addressing final shepherd comment

2015-11-04 Thread Kepeng Li

Thank you Mike.

The diagrams look good to me.

Kind Regards
Kepeng

发件人:  Mike Jones 
日期:  Thursday, 5 November, 2015 12:32 am
至:  "oauth@ietf.org" 
抄送:  Li Kepeng 
主题:  Proof-of-Possession Key Semantics for JWTs spec addressing final
shepherd comment

Proof-of-Possession Key Semantics for JWTs draft -06 addresses the remaining
document shepherd comment – adding use case diagrams to the introduction.
 
The updated specification is available at:
·   http://tools.ietf.org/html/draft-ietf-oauth-proof-of-possession-06

 
An HTML formatted version is also available at:
·   
https://self-issued.info/docs/draft-ietf-oauth-proof-of-possession-06.html

 
-- Mike
 
P.S.  This note was also posted at http://self-issued.info/?p=1471 and as
@selfissued  .


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Proof-of-Possession Key Semantics for JWTs spec addressing final shepherd comment

2015-11-04 Thread Mike Jones

Thanks for suggesting the diagrams, Kepeng. They make the document more 
understandable.

-- Mike

From: Kepeng Li
Sent: ‎11/‎5/‎2015 12:57 AM
To: Mike Jones; 
oauth@ietf.org
Subject: Re: Proof-of-Possession Key Semantics for JWTs spec addressing final 
shepherd comment

Thank you Mike.

The diagrams look good to me.

Kind Regards
Kepeng

???: Mike Jones 
>
??: Thursday, 5 November, 2015 12:32 am
?: "oauth@ietf.org" 
>
??: Li Kepeng >
??: Proof-of-Possession Key Semantics for JWTs spec addressing final shepherd 
comment

Proof-of-Possession Key Semantics for JWTs draft -06 addresses the remaining 
document shepherd comment – adding use case diagrams to the introduction.

The updated specification is available at:

·http://tools.ietf.org/html/draft-ietf-oauth-proof-of-possession-06

An HTML formatted version is also available at:

·
https://self-issued.info/docs/draft-ietf-oauth-proof-of-possession-06.html

-- Mike

P.S.  This note was also posted at http://self-issued.info/?p=1471 and as 
@selfissued.
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Sharing a client_id: is it good or bad ?

2015-11-04 Thread Jim Manico

> And what about multiple confidential clients being set up with the same 
> id/secret. 

Bad idea. For security when you see one confidential client doing bad things 
you will need to revoke it individually. If multiple confidential clients have 
the same client secrets, thats no longer possible.

--
Jim Manico
@Manicode
Secure Coding Education
+1 (808) 652-3805

> On Nov 4, 2015, at 8:01 AM, Sergey Beryozkin  wrote:
> 
> Hi All
> 
> I'm having a discussion with my colleagues on the pros and cons of sharing a 
> client_id.
> 
> For example, say we have N number of public mobile applications (the same 
> application package, an application instance on an individual phone), and one 
> approach is for each of these applications to have the same client_id.
> 
> I've been trying to analyze why it can be bad and the only thing I can come 
> up with is that there will be no (easy) way to track which application 
> instance actually accessed a given RS.
> 
> Can someone please explain what the pros and cons are of having the same 
> client_id shared between public client applications.
> 
> And what about multiple confidential clients being set up with the same 
> id/secret. I suspect it is a bad idea but what is main line why it is a bad 
> idea, lets say it is all done in the protected network, no chance of the bad 
> clients interfering...
> 
> 
> 
> Thanks, Sergey
> 
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] Re

2015-11-04 Thread ronald comaling

Reply

http://about.me/ronaldo_comaling
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Sharing a client_id: is it good or bad ?

Re: [OAUTH-WG] Proof-of-Possession Key Semantics for JWTs spec addressing final shepherd comment

Re: [OAUTH-WG] Proof-of-Possession Key Semantics for JWTs spec addressing final shepherd comment

[OAUTH-WG] OAuth Device Flow

Re: [OAUTH-WG] Proof-of-Possession Key Semantics for JWTs spec addressing final shepherd comment

Re: [OAUTH-WG] Proof-of-Possession Key Semantics for JWTs spec addressing final shepherd comment

Re: [OAUTH-WG] OAuth Device Flow

Re: [OAUTH-WG] Proof-of-Possession Key Semantics for JWTs spec addressing final shepherd comment

[OAUTH-WG] Queue for oauth Remote Attendees

Re: [OAUTH-WG] Proof-of-Possession Key Semantics for JWTs spec addressing final shepherd comment

Re: [OAUTH-WG] Proof-of-Possession Key Semantics for JWTs spec addressing final shepherd comment

Re: [OAUTH-WG] Proof-of-Possession Key Semantics for JWTs spec addressing final shepherd comment

Re: [OAUTH-WG] Proof-of-Possession Key Semantics for JWTs spec addressing final shepherd comment

Re: [OAUTH-WG] Proof-of-Possession Key Semantics for JWTs spec addressing final shepherd comment

Re: [OAUTH-WG] Proof-of-Possession Key Semantics for JWTs spec addressing final shepherd comment

Re: [OAUTH-WG] Proof-of-Possession Key Semantics for JWTs spec addressing final shepherd comment

Re: [OAUTH-WG] Proof-of-Possession Key Semantics for JWTs spec addressing final shepherd comment

[OAUTH-WG] Inaccuracy in last point in JWSREQ presentation about registering request_object_signing_alg

[OAUTH-WG] I-D Action: draft-ietf-oauth-proof-of-possession-06.txt

[OAUTH-WG] Proof-of-Possession Key Semantics for JWTs spec addressing final shepherd comment

[OAUTH-WG] Sharing a client_id: is it good or bad ?

Re: [OAUTH-WG] Proof-of-Possession Key Semantics for JWTs spec addressing final shepherd comment

Re: [OAUTH-WG] Proof-of-Possession Key Semantics for JWTs spec addressing final shepherd comment

Re: [OAUTH-WG] Sharing a client_id: is it good or bad ?

[OAUTH-WG] Re

25 matches

Site Navigation

Mail list logo

Footer information