Re: [OAUTH-WG] [token-exchange] exchanging between issuers/domains

2017-08-04 Thread Denis 

Phil,

My comments are in-line too.


inline...
Phil

Oracle Corporation, Identity Cloud Services Architect & Standards
@independentid
www.independentid.com 
phil.h...@oracle.com 

On Aug 1, 2017, at 12:56 PM, Denis > wrote:


Phil,

Originally, with OAuth the AS and the RS were co-located. Many 
additional RFCs made extensions and this assumption is no more valid.


draft-ietf-oauth-token-exchange-09 is now opening a pandora box where 
an even more complex situation is envisaged (without explicitly 
stating it)
there would be one client, one RS and several AS/STS with 
relationships between AS/STS from different domains (don't ask me 
what a domain

might mean in this context).


I don’t think that is true. It allows a resource server to act on 
behalf of the user further on down the line.  The user context is 
already well known.


The draft is saying on page 4:

   An OAuth resource server, for example, might assume
   the role of the client during token exchange in order to trade an
   access token, which it received in a protected resource request, for
   a new token that is appropriate to include in a call to a backend
   service.

This means that a token received from one AS/STS will be sent to another 
AS/STS in order to get a new access token from the second AS/STS.
This means several AS/STS with relationships between AS/STS from 
different "domains" as I wrote.




As always, it can be mis-used.  Maybe there is an argument for more 
guidance?


See my other post about privacy in the case where a single AS/STS is 
involved in a transaction. It is under the following topic :
How could an IdP create an id token for one audience RP without 
knowing for which RP ?
The topic was raised at the last OAuth Workshop in Zürich by a 
student from ETH Zürich.


In OIDC, the audience is *always* the client.  If you are grabbing an 
ID Token to then relay it to another RP, then you are into a 
dual-audience thing which is doable but falls outside the 
specifications AFAIK.


The complex case you are mentioning is fairly different from the basic 
case I am considering. In the basic case, there is one client, one RP 
and one AS/STS.
This is the case I am considering and for which I believe we need a 
solution. Up to now, when using JWTs, if a JWT is targeted, it allows 
the  AS/STS
to act as Big Brother and there is no other alternative. It is a "*Big 
Brother by design*" solution instead of a "*Privacy by Design*" solution.


I have seen a lot of bad patterns where mobile clients are getting ID 
Tokens and simply passing them on to a resource server.
The resource server cannot validate the audience leading to all sorts 
of problem. A better method is the AppAuth pattern.


In OAuth there is currently no RFC which provides a response to that 
question. A specification based on OAuth, OpenID Connect,
is using the concept of an IdP (Identity Provider). Currently, since 
there is no standardized way to address this concern, any IdP will be 
able
to act as Big  Brother: it will know where the access tokens will be 
used. So tracking the activities of the clients will be straightforward.


So the way forward might be to put forward an individual draft and see 
if anyone in the WG wants to work on it in a future charter?


Before writing an individual draft, there needs to be a general 
agreement within the WG to consider such a work item as valuable.




Addressing the same question when multiple AS/STS would be involved 
should only be discussed, once we a solution is defined
in the case where a single AS/STS is involved. Before doing this, we 
would need to define an architecture.


10 years ago, the IETF was only dealing with security considerations. 
Nowadays, it also has to deal with privacy considerations.


This seems like an argument for new work.


Indeed.

Denis




Denis


Denis,

Why is privacy a concern? OAuth is designed to have the 
Authorization Server be the issuer of tokens for a specific set of 
resource servers.  The AS represents users on the Resource server. 
 It does not represent users of the client - though they are often 
the same physical person, they are often different authenticated 
subjects.


Of course, there are profiles of OAuth which change this 
relationship, but the foundational assumption in RFC6749 is the AS 
is usually associated with the RS.


Phil

Oracle Corporation, Identity Cloud Services Architect & Standards
@independentid
www.independentid.com 


phil.h...@oracle.com 

On Aug 1, 2017, at 3:53 AM, Denis > wrote:


Hello Brian,

I don't think that's what I'm saying.

[OAUTH-WG] Protocol Action: 'OAuth 2.0 for Native Apps' to Best Current Practice (draft-ietf-oauth-native-apps-12.txt)

2017-08-04 Thread The IESG 
The IESG has approved the following document:
- 'OAuth 2.0 for Native Apps'
  (draft-ietf-oauth-native-apps-12.txt) as Best Current Practice

This document is the product of the Web Authorization Protocol Working Group.

The IESG contact persons are Kathleen Moriarty and Eric Rescorla.

A URL of this Internet Draft is:
https://datatracker.ietf.org/doc/draft-ietf-oauth-native-apps/





Technical Summary

   OAuth 2.0 authorization requests from native apps should only be made
   through external user-agents, primarily the user's browser.  This
   specification details the security and usability reasons why this is
   the case, and how native apps and authorization servers can implement
   this best practice.

Working Group Summary

   The OAuth 2.0 authorization framework, documents two approaches for 
   native apps to interact with the authorization endpoint: via an 
   embedded user-agent, or an external user-agent.

   This document recommends external user-agents like in-app browser
   tabs as the only secure and usable choice for OAuth. 
   
   There is solid working group consensus to publish this document.

Document Quality

  Implementations are included in the shepherd report.

Personnel
  Hannes Tschofenig is the document shepherd and the responsible area 
  director is Kathleen Moriarty. 

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

Re: [OAUTH-WG] Fwd: I-D Action: draft-ietf-oauth-mtls-03.txt

2017-08-04 Thread Brian Campbell 
Just wanted to note that, in an off-list exchange, John has pushed back on
the idea to potentially drop mention of using x5c.

On Wed, Aug 2, 2017 at 9:29 AM, Brian Campbell 
wrote:

> Thanks for the review, Vladimir.
>
> The text about which you have questions was written by Torsten (credit or
> blame where it's due!) but I believe he's out of the office for a bit so
> I'll try and answer.
>
> Your 1st question:
> I've had the same thought regarding the public key method and using the
> JWK x5c parameter. A JWK already has the public key, which is sufficient
> for comparison in the public key method. So x5c is just superfluous here. I
> believe that's a change that the next revision should have and will look to
> make it unless someone wants to make a strong case for needing x5c.
>
> Your 2nd question:
> I also found the sentence, "When used in conjunction with a trusted X.509
> certificate source, it also allows the client to rotate its X.509
> certificates without the need to change its respective authentication data
> at the authorization server." somewhat difficult to understand when I first
> read it. The intended meaning relies on content earlier in the same
> paragraph that says, "As pre-requisite, the client registers a X.509
> certificate or *a trusted source for its X.509 certificates (jwks uri as
> defined in [RFC7591])* with the authorization server."  Basically what
> it's trying to say is that when a client is registered or configured with a
> jwks_uri, then client key rotation can be done without needing to
> explicitly update the client config/registration with the AS. Does that
> explain it? I believe the text could be more straightforward and will
> endeavor to make it more clear in the next draft update.
>
>
>
>
>
>
>
>
>
> On Wed, Aug 2, 2017 at 1:53 AM, Vladimir Dzhuvinov <
> vladi...@connect2id.com> wrote:
>
>> Thanks everyone for the update! Having a clear distinction between the
>> PKIX vs public key bound methods will help interop, implementers' job, and
>> it also appears good for security.
>>
>> Questions:
>>
>> https://datatracker.ietf.org/doc/html/draft-ietf-oauth-mtls-
>> 03#section-2.3
>>
>> where the X.509 certificates are represented using the "x5c" parameter from 
>> [RFC7517 ]
>>
>> For the public key method, is it really necessary for the client to
>> include its certificate in the JWK x5c parameter? This will make
>> implementation harder for developers, and I'm not sure it adds anything in
>> terms of security. Registering the public key parameters seems sufficient
>> to me.
>>
>>
>> https://datatracker.ietf.org/doc/html/draft-ietf-oauth-mtls-
>> 03#section-2.1
>>
>> When used in conjunction with a trusted X.509 certificate source, it also 
>> allows the client to rotate its X.509 certificates without the need to 
>> change its respective authentication data at the authorization server.
>>
>> I don't understand this - "in conjunction with a trusted X.509
>> certificate source"
>>
>>
>> Thanks,
>>
>> Vladimir
>>
>> On 28/07/17 21:33, Brian Campbell wrote:
>>
>> A new draft of "Mutual TLS Profile for OAuth 2.0" has been published with
>> the changes listed below based on comments and dissuasion in Prague.
>>
>>
>> draft-ietf-oauth-mtls-03
>>  
>>
>>
>>o  Introduced metadata and client registration parameter to publish
>>   and request support for mutual TLS sender constrained access
>>   tokens
>>o  Added description of two methods of binding the cert and client,
>>   PKI and Public Key.
>>o  Indicated that the "tls_client_auth" authentication method is for
>>   the PKI method and introduced "pub_key_tls_client_auth" for the
>>   Public Key method
>>o  Added implementation considerations, mainly regarding TLS stack
>>   configuration and trust chain validation, as well as how to to do
>>   binding of access tokens to a TLS client certificate for public
>>   clients, and considerations around certificate bound access tokens
>>o  Added new section to security considerations on cert spoofing
>>o  Add text suggesting that a new cnf member be defined in the
>>   future, if hash function(s) other than SHA-256 need to be used for
>>   certificate thumbprints
>>
>>
>>
>> -- Forwarded message --
>> From:  
>> Date: Fri, Jul 28, 2017 at 12:25 PM
>> Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-mtls-03.txt
>> To: i-d-annou...@ietf.org
>> Cc: oauth@ietf.org
>>
>>
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories.
>> This draft is a work item of the Web Authorization Protocol WG of the IETF.
>>
>> Title   : Mutual TLS Profile for OAuth 2.0
>> Authors : Brian Campbell
>>   John Bradley
>>   Nat Sakimura
>>

Re: [OAUTH-WG] Fwd: I-D Action: draft-ietf-oauth-mtls-03.txt

2017-08-04 Thread Vladimir Dzhuvinov 
What are the potential uses of the x5c parameter?

Vladimir


On 04/08/17 21:13, Brian Campbell wrote:
> Just wanted to note that, in an off-list exchange, John has pushed back on
> the idea to potentially drop mention of using x5c.
>
> On Wed, Aug 2, 2017 at 9:29 AM, Brian Campbell 
> wrote:
>
>> Thanks for the review, Vladimir.
>>
>> The text about which you have questions was written by Torsten (credit or
>> blame where it's due!) but I believe he's out of the office for a bit so
>> I'll try and answer.
>>
>> Your 1st question:
>> I've had the same thought regarding the public key method and using the
>> JWK x5c parameter. A JWK already has the public key, which is sufficient
>> for comparison in the public key method. So x5c is just superfluous here. I
>> believe that's a change that the next revision should have and will look to
>> make it unless someone wants to make a strong case for needing x5c.
>>
>> Your 2nd question:
>> I also found the sentence, "When used in conjunction with a trusted X.509
>> certificate source, it also allows the client to rotate its X.509
>> certificates without the need to change its respective authentication data
>> at the authorization server." somewhat difficult to understand when I first
>> read it. The intended meaning relies on content earlier in the same
>> paragraph that says, "As pre-requisite, the client registers a X.509
>> certificate or *a trusted source for its X.509 certificates (jwks uri as
>> defined in [RFC7591])* with the authorization server."  Basically what
>> it's trying to say is that when a client is registered or configured with a
>> jwks_uri, then client key rotation can be done without needing to
>> explicitly update the client config/registration with the AS. Does that
>> explain it? I believe the text could be more straightforward and will
>> endeavor to make it more clear in the next draft update.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On Wed, Aug 2, 2017 at 1:53 AM, Vladimir Dzhuvinov <
>> vladi...@connect2id.com> wrote:
>>
>>> Thanks everyone for the update! Having a clear distinction between the
>>> PKIX vs public key bound methods will help interop, implementers' job, and
>>> it also appears good for security.
>>>
>>> Questions:
>>>
>>> https://datatracker.ietf.org/doc/html/draft-ietf-oauth-mtls-
>>> 03#section-2.3
>>>
>>> where the X.509 certificates are represented using the "x5c" parameter from 
>>> [RFC7517 ]
>>>
>>> For the public key method, is it really necessary for the client to
>>> include its certificate in the JWK x5c parameter? This will make
>>> implementation harder for developers, and I'm not sure it adds anything in
>>> terms of security. Registering the public key parameters seems sufficient
>>> to me.
>>>
>>>
>>> https://datatracker.ietf.org/doc/html/draft-ietf-oauth-mtls-
>>> 03#section-2.1
>>>
>>> When used in conjunction with a trusted X.509 certificate source, it also 
>>> allows the client to rotate its X.509 certificates without the need to 
>>> change its respective authentication data at the authorization server.
>>>
>>> I don't understand this - "in conjunction with a trusted X.509
>>> certificate source"
>>>
>>>
>>> Thanks,
>>>
>>> Vladimir
>>>
>>> On 28/07/17 21:33, Brian Campbell wrote:
>>>
>>> A new draft of "Mutual TLS Profile for OAuth 2.0" has been published with
>>> the changes listed below based on comments and dissuasion in Prague.
>>>
>>>
>>> draft-ietf-oauth-mtls-03
>>>  
>>>
>>>
>>>o  Introduced metadata and client registration parameter to publish
>>>   and request support for mutual TLS sender constrained access
>>>   tokens
>>>o  Added description of two methods of binding the cert and client,
>>>   PKI and Public Key.
>>>o  Indicated that the "tls_client_auth" authentication method is for
>>>   the PKI method and introduced "pub_key_tls_client_auth" for the
>>>   Public Key method
>>>o  Added implementation considerations, mainly regarding TLS stack
>>>   configuration and trust chain validation, as well as how to to do
>>>   binding of access tokens to a TLS client certificate for public
>>>   clients, and considerations around certificate bound access tokens
>>>o  Added new section to security considerations on cert spoofing
>>>o  Add text suggesting that a new cnf member be defined in the
>>>   future, if hash function(s) other than SHA-256 need to be used for
>>>   certificate thumbprints
>>>
>>>
>>>
>>> -- Forwarded message --
>>> From:  
>>> Date: Fri, Jul 28, 2017 at 12:25 PM
>>> Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-mtls-03.txt
>>> To: i-d-annou...@ietf.org
>>> Cc: oauth@ietf.org
>>>
>>>
>>>
>>> A New Internet-Draft is available from the on-line Internet-Drafts
>>> directories.
>>> This draft is a work item of the Web Authorizatio

Re: [OAUTH-WG] Fwd: I-D Action: draft-ietf-oauth-mtls-03.txt

2017-08-04 Thread Brian Campbell 
His argument (best I can articulate anyway) is that there may be
difficulties or gotchas in some cases in doing a comparison of the public
key from the client cert to the public key from a JWK. Where the comparison
or the client cert directly to the cert from x5c in a JWK would be more
straightforward and/or less error prone. I don't necessarily agree but
wanted to bring the discussion back to the list.

On Fri, Aug 4, 2017 at 1:17 PM, Vladimir Dzhuvinov 
wrote:

> What are the potential uses of the x5c parameter?
>
> Vladimir
>
>
> On 04/08/17 21:13, Brian Campbell wrote:
> > Just wanted to note that, in an off-list exchange, John has pushed back
> on
> > the idea to potentially drop mention of using x5c.
> >
> > On Wed, Aug 2, 2017 at 9:29 AM, Brian Campbell <
> bcampb...@pingidentity.com>
> > wrote:
> >
> >> Thanks for the review, Vladimir.
> >>
> >> The text about which you have questions was written by Torsten (credit
> or
> >> blame where it's due!) but I believe he's out of the office for a bit so
> >> I'll try and answer.
> >>
> >> Your 1st question:
> >> I've had the same thought regarding the public key method and using the
> >> JWK x5c parameter. A JWK already has the public key, which is sufficient
> >> for comparison in the public key method. So x5c is just superfluous
> here. I
> >> believe that's a change that the next revision should have and will
> look to
> >> make it unless someone wants to make a strong case for needing x5c.
> >>
> >> Your 2nd question:
> >> I also found the sentence, "When used in conjunction with a trusted
> X.509
> >> certificate source, it also allows the client to rotate its X.509
> >> certificates without the need to change its respective authentication
> data
> >> at the authorization server." somewhat difficult to understand when I
> first
> >> read it. The intended meaning relies on content earlier in the same
> >> paragraph that says, "As pre-requisite, the client registers a X.509
> >> certificate or *a trusted source for its X.509 certificates (jwks uri as
> >> defined in [RFC7591])* with the authorization server."  Basically what
> >> it's trying to say is that when a client is registered or configured
> with a
> >> jwks_uri, then client key rotation can be done without needing to
> >> explicitly update the client config/registration with the AS. Does that
> >> explain it? I believe the text could be more straightforward and will
> >> endeavor to make it more clear in the next draft update.
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> On Wed, Aug 2, 2017 at 1:53 AM, Vladimir Dzhuvinov <
> >> vladi...@connect2id.com> wrote:
> >>
> >>> Thanks everyone for the update! Having a clear distinction between the
> >>> PKIX vs public key bound methods will help interop, implementers' job,
> and
> >>> it also appears good for security.
> >>>
> >>> Questions:
> >>>
> >>> https://datatracker.ietf.org/doc/html/draft-ietf-oauth-mtls-
> >>> 03#section-2.3
> >>>
> >>> where the X.509 certificates are represented using the "x5c" parameter
> from [RFC7517 ]
> >>>
> >>> For the public key method, is it really necessary for the client to
> >>> include its certificate in the JWK x5c parameter? This will make
> >>> implementation harder for developers, and I'm not sure it adds
> anything in
> >>> terms of security. Registering the public key parameters seems
> sufficient
> >>> to me.
> >>>
> >>>
> >>> https://datatracker.ietf.org/doc/html/draft-ietf-oauth-mtls-
> >>> 03#section-2.1
> >>>
> >>> When used in conjunction with a trusted X.509 certificate source, it
> also allows the client to rotate its X.509 certificates without the need to
> change its respective authentication data at the authorization server.
> >>>
> >>> I don't understand this - "in conjunction with a trusted X.509
> >>> certificate source"
> >>>
> >>>
> >>> Thanks,
> >>>
> >>> Vladimir
> >>>
> >>> On 28/07/17 21:33, Brian Campbell wrote:
> >>>
> >>> A new draft of "Mutual TLS Profile for OAuth 2.0" has been published
> with
> >>> the changes listed below based on comments and dissuasion in Prague.
> >>>
> >>>draft-ietf-oauth-mtls-03 html/draft-ietf-oauth-mtls-03>  doc/html/draft-ietf-oauth-mtls-03>
> >>>
> >>>
> >>>o  Introduced metadata and client registration parameter to publish
> >>>   and request support for mutual TLS sender constrained access
> >>>   tokens
> >>>o  Added description of two methods of binding the cert and client,
> >>>   PKI and Public Key.
> >>>o  Indicated that the "tls_client_auth" authentication method is for
> >>>   the PKI method and introduced "pub_key_tls_client_auth" for the
> >>>   Public Key method
> >>>o  Added implementation considerations, mainly regarding TLS stack
> >>>   configuration and trust chain validation, as well as how to to do
> >>>   binding of access tokens to a TLS client certificate for public

Re: [OAUTH-WG] Fwd: I-D Action: draft-ietf-oauth-mtls-03.txt

2017-08-04 Thread John Bradley 
Having the whole certificate to compare may be easier in some environments that 
trying to directly compare the public keys.

I believe most environments make the cert from TLS available to the app 
comparing that to the one retrieved from the x5c element is relatively strait 
forward.

When comparing keys I worry that that may not be that easy to get from the 
TLS/HTTP stack.  
Some environments will provide SPKI and others like java have methods to 
directly manipulate the keys.

We should also check on any issues with representation of EC public keys.  
While JWA docent allow compressed points RFC 5480 allows them in SPKI.

Of the top of my head I don’t know if anyone issues certs in that format, but 
they could.  

If the client receives compressed points from SPKI and uncompressed from JWK it 
is possible to compare them but I have a bad feeling people will get it wrong.  
 

There is also a issue with leading zeros that must be present in the JWK but 
are not in the SPKI.

For the most part comparing the raw keys will work with the three currently 
supported named curves. 
New curves may also introduce new wrinkles.

If we were only talking RSA I would definitely ditch x5c.

However given that a certificate of some sort must exist to make MTLS work 
putting it in the x5c is not asking the world.

Getting a app to string compare two blobs seems less likely to go wrong in 
deployment than asking apps to do atleast format normalization of the public 
keys to compare them.

I wish it could be simpler.

John B.


> On Aug 4, 2017, at 3:17 PM, Vladimir Dzhuvinov  
> wrote:
> 
> What are the potential uses of the x5c parameter?
> 
> Vladimir
> 
> 
> On 04/08/17 21:13, Brian Campbell wrote:
>> Just wanted to note that, in an off-list exchange, John has pushed back on
>> the idea to potentially drop mention of using x5c.
>> 
>> On Wed, Aug 2, 2017 at 9:29 AM, Brian Campbell 
>> wrote:
>> 
>>> Thanks for the review, Vladimir.
>>> 
>>> The text about which you have questions was written by Torsten (credit or
>>> blame where it's due!) but I believe he's out of the office for a bit so
>>> I'll try and answer.
>>> 
>>> Your 1st question:
>>> I've had the same thought regarding the public key method and using the
>>> JWK x5c parameter. A JWK already has the public key, which is sufficient
>>> for comparison in the public key method. So x5c is just superfluous here. I
>>> believe that's a change that the next revision should have and will look to
>>> make it unless someone wants to make a strong case for needing x5c.
>>> 
>>> Your 2nd question:
>>> I also found the sentence, "When used in conjunction with a trusted X.509
>>> certificate source, it also allows the client to rotate its X.509
>>> certificates without the need to change its respective authentication data
>>> at the authorization server." somewhat difficult to understand when I first
>>> read it. The intended meaning relies on content earlier in the same
>>> paragraph that says, "As pre-requisite, the client registers a X.509
>>> certificate or *a trusted source for its X.509 certificates (jwks uri as
>>> defined in [RFC7591])* with the authorization server."  Basically what
>>> it's trying to say is that when a client is registered or configured with a
>>> jwks_uri, then client key rotation can be done without needing to
>>> explicitly update the client config/registration with the AS. Does that
>>> explain it? I believe the text could be more straightforward and will
>>> endeavor to make it more clear in the next draft update.
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> On Wed, Aug 2, 2017 at 1:53 AM, Vladimir Dzhuvinov <
>>> vladi...@connect2id.com> wrote:
>>> 
 Thanks everyone for the update! Having a clear distinction between the
 PKIX vs public key bound methods will help interop, implementers' job, and
 it also appears good for security.
 
 Questions:
 
 https://datatracker.ietf.org/doc/html/draft-ietf-oauth-mtls-
 03#section-2.3
 
 where the X.509 certificates are represented using the "x5c" parameter 
 from [RFC7517 >]
 
 For the public key method, is it really necessary for the client to
 include its certificate in the JWK x5c parameter? This will make
 implementation harder for developers, and I'm not sure it adds anything in
 terms of security. Registering the public key parameters seems sufficient
 to me.
 
 
 https://datatracker.ietf.org/doc/html/draft-ietf-oauth-mtls- 
 
 03#section-2.1
 
 When used in conjunction with a trusted X.509 certificate source, it also 
 allows the client to rotate its X.509 certificates without the need to 
 change its respective authentication data at the authorization server.
 
 I don't understand this - "in conjunction with a trusted