Subject: [OAUTH-WG] oauth - Requested sessions have been scheduled for IETF 98

From: "\"IETF Secretariat\"" <[email-masked]>
Date: Fri, 03 Mar 2017 15:55:28 -0800

Dear Stephanie McCammon,

The session(s) that you have requested have been scheduled.
Below is the scheduled session information followed by
the original request. 

oauth Session 1 (2:30:00)
    Friday, Morning Session I 0900-1130
    Room Name: Zurich C size: 100
    ---------------------------------------------
    oauth Session 2 (1:00:00)
    Monday, Afternoon Session III 1710-1810
    Room Name: Zurich C size: 100
    ---------------------------------------------

Request Information:

---------------------------------------------------------
Working Group Name: Web Authorization Protocol
Area Name: Security Area
Session Requester: Stephanie McCammon

Number of Sessions: 2
Length of Session(s):  2.5 Hours, 1 Hour
Number of Attendees: 50
Conflicts to Avoid: 
 First Priority: saag core tls tokbind

People who must be present:
  Hannes Tschofenig
  Kathleen Moriarty
  Derek Atkins

Resources Requested:
  Projector in room

Special Requests:
  Please avoid conflict with sec area BoFs.
---------------------------------------------------------

---

From: Mike Jones <[email-masked]>
Date: Sat, 18 Mar 2017 00:52:19 +0000

Hi Chairs,

I'd like to request that the following presentations be added to the agenda:

	OAuth Token Exchange (draft-ietf-oauth-token-exchange) - Mike Jones - 15 minutes
	OAuth Authorization Server Metadata (draft-ietf-oauth-discovery) - Mike Jones - 15 minutes

I'd also talked with Brian Campbell and I think he wants to lead this discussion, in part based on his implementation experience:

	OAuth Token Binding (draft-ietf-oauth-token-binding) - Brian Campbell - 30 minutes

(Brian may suggest a different amount of time)

I agree that William Dennis should present about the OAuth Device Flow (draft-ietf-oauth-device-flow).

For completeness, I don't think a presentation is needed about OAuth AMR Values (draft-ietf-oauth-amr-values) because it's now completed its IESG review.

I'll look forward to seeing many of you in just over a week!

				-- Mike

-----Original Message-----
From: OAuth [mailto:[email-masked]] On Behalf Of "IETF Secretariat"
Sent: Friday, March 3, 2017 3:55 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: [OAUTH-WG] oauth - Requested sessions have been scheduled for IETF 98

Dear Stephanie McCammon,

The session(s) that you have requested have been scheduled.
Below is the scheduled session information followed by the original request. 

Request Information:

---------------------------------------------------------
Working Group Name: Web Authorization Protocol Area Name: Security Area Session Requester: Stephanie McCammon

Number of Sessions: 2
Length of Session(s):  2.5 Hours, 1 Hour Number of Attendees: 50 Conflicts to Avoid: 
 First Priority: saag core tls tokbind

Resources Requested:
  Projector in room

Special Requests:

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

---

From: Brian Campbell <[email-masked]>
Date: Fri, 17 Mar 2017 19:34:19 -0600

Thanks Mike, 30 minutes sounds about right for OAuth Token Binding

On Mar 17, 2017 6:54 PM, "Mike Jones" <[email-masked]> wrote:

> I'd also talked with Brian Campbell and I think he wants to lead this
> discussion, in part based on his implementation experience:
>
> For completeness, I don't think a presentation is needed about OAuth AMR
> Values (draft-ietf-oauth-amr-values) because it's now completed its IESG
> review.
>

---

From: Torsten Lodderstedt <[email-masked]>
Date: Tue, 21 Mar 2017 14:08:43 +0100

Hi Chairs,

I would like to request 5 minutes on Monday to briefly present the status of the security document. This is mainly to raise awareness in the group since I didn’t get that much input on it since Seoul.

kind regards,
Torsten.

> Am 18.03.2017 um 01:52 schrieb Mike Jones <[email-masked]>:
> 
> Hi Chairs,
>

---

From: Antonio Sanso <[email-masked]>
Date: Tue, 21 Mar 2017 13:27:45 +0000

hi Torsten,

good one. I personally I am looking forward to see this particular document find its way.

IMHO this is something much needed.

regards

antonio

On Mar 21, 2017, at 2:08 PM, Torsten Lodderstedt <[email-masked]<mailto:[email-masked]>> wrote:

Hi Chairs,

kind regards,
Torsten.

Am 18.03.2017 um 01:52 schrieb Mike Jones <[email-masked]<mailto:[email-masked]>>:

Hi Chairs,

-- Mike

-----Original Message-----
From: OAuth [mailto:[email-masked]] On Behalf Of "IETF Secretariat"
Sent: Friday, March 3, 2017 3:55 PM
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: [OAUTH-WG] oauth - Requested sessions have been scheduled for IETF 98

Dear Stephanie McCammon,

Request Information:

Number of Sessions: 2

Resources Requested:
Projector in room

Special Requests:

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&data=02%7C01%7C%7C254d07b9729a4cfc8dd408d4705b73a2%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636256985463058106&sdata=FYIqTvgn1%2Fpjyqw%2BtGhDWgiB0G0ATuL30ap%2B3bLX6aQ%3D&reserved=0

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&data=02%7C01%7C%7C254d07b9729a4cfc8dd408d4705b73a2%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636256985463058106&sdata=FYIqTvgn1%2Fpjyqw%2BtGhDWgiB0G0ATuL30ap%2B3bLX6aQ%3D&reserved=0

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&data=02%7C01%7C%7C254d07b9729a4cfc8dd408d4705b73a2%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636256985463068122&sdata=5CIJnWs2VdLM9FUWt%2FWlOxIilp5N2vfr7b9elwhL%2BA4%3D&reserved=0

---

From: Nat Sakimura <[email-masked]>
Date: Tue, 21 Mar 2017 14:00:42 +0000

HI Chairs,

I would also like to ask 5 min. on Monday (as I cannot be on Friday) for
The OAuth 2.0 Authorization Framework: JWT Pop Token Usage [1].

[1] https://tools.ietf.org/html/draft-sakimura-oauth-jpop-01

It is capturing strong and rather urgent demands from the financial sector
and would be great if it can be considered in the WG.

Best,

Nat Sakimura

On Tue, Mar 21, 2017 at 10:28 PM Antonio Sanso <[email-masked]> wrote:

hi Torsten,

good one. I personally I am looking forward to see this particular document
find its way.

regards

antonio

On Mar 21, 2017, at 2:08 PM, Torsten Lodderstedt <[email-masked]>
wrote:

Hi Chairs,

I would like to request 5 minutes on Monday to briefly present the status
of the security document. This is mainly to raise awareness in the group
since I didn’t get that much input on it since Seoul.

kind regards,
Torsten.

Hi Chairs,

OAuth Token Exchange (draft-ietf-oauth-token-exchange) - Mike Jones - 15
minutes
OAuth Authorization Server Metadata (draft-ietf-oauth-discovery) - Mike
Jones - 15 minutes

OAuth Token Binding (draft-ietf-oauth-token-binding) - Brian Campbell - 30
minutes

I agree that William Dennis should present about the OAuth Device Flow
(draft-ietf-oauth-device-flow).

-- Mike

-----Original Message-----
From: OAuth [mailto:[email-masked] <[email-masked]>] On
Behalf Of "IETF Secretariat"
Sent: Friday, March 3, 2017 3:55 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: [OAUTH-WG] oauth - Requested sessions have been scheduled for IETF
98

Dear Stephanie McCammon,

Request Information:

---------------------------------------------------------
Working Group Name: Web Authorization Protocol Area Name: Security Area
Session Requester: Stephanie McCammon

Number of Sessions: 2
Length of Session(s):  2.5 Hours, 1 Hour Number of Attendees: 50 Conflicts
to Avoid:
First Priority: saag core tls tokbind

Resources Requested:
Projector in room

Special Requests:

-- 

Nat Sakimura

Chairman of the Board, OpenID Foundation

---

From: Denis <[email-masked]>
Date: Wed, 22 Mar 2017 11:15:04 +0100

Hi Nat,

I have several comments on draft-sakimura-oauth-jpop-01 related to 
security or privacy.

1.The abstract states:

Only the party in possession of a corresponding cryptographic key with 
the Jpop token can use it to get access
to the associated resources unlike in the case of the bearer token 
described in [RFC6750] where any party
in possession of the access token can access the resource.

This is incorrect.

Replace with:

Any party able to use a corresponding private cryptographic key with the 
Jpop token can use it to get access
to the associated resources unlike in the case of the bearer token 
described in [RFC6750] where any party
in possession of the access token can access the resource.

2.In section 3, the text states:

audThe identifier of the resource server.

According to the content of RFC 7800:

The "aud" (audience) claim identifies the recipients that the JWT is 
intended for. The interpretation of audience values is application specific.

Replace with:

audThe recipients that the JWT is intended for (the interpretation of 
audience values is application specific).

3.In section 3, the text states:

cnfThe confirmation method.

Their semantics are defined in [RFC7519] and [RFC7800]

This is incorrect: cnf is neither defined in [RFC7519] nor in [RFC7800].

4.In section 6.2, the text states:

For this, the following steps are taken:

1.The client prepares a nonce.

2.The client creates JWS compact serialization over the nonce

    JSON Web Token Claims are listed at:
    https://www.iana.org/assignments/jwt/jwt.xhtml

"nonce" has not been defined by the IANA, but is mentioned in OpenID 
Connect Core 1.0 incorporating errata set 1. It is described as :

nonce

String value used to associate a Client session with an ID Token, and to 
mitigate replay attacks. The value is passed through
unmodified from the Authentication Request to the ID Token. If present 
in the ID Token, Clients MUST verify that the nonce
Claim Value is equal to the value of the nonceparameter sent in the 
Authentication Request. If present in the Authentication Request,
Authorization Servers MUST include a nonceClaim in the ID Token with the 
Claim Value being the nonce value sent in the Authentication Request.
Authorization Servers SHOULD perform no other processing on noncevalues 
used. The noncevalue is a case sensitive string.

I have several observations:

a)there is some difficulty to mandate the use of a parameter that is not 
registered by IANA.

b)the further processing of the nonce is not indicated in the text

c) The last sentence from the above description states: "Authorization 
Servers SHOULD perform no other processing on noncevalues used"
There is a practical problem with such a sentence since Authorization 
Servers would need to remember nonces for ever.
Either that sentence should be deleted or the nonce shall be only used 
with a UTC time parameter included in the Authentication Request.

In any case, the definition of a nonce as specified in OpenID Connect 
Core 1.0 incorporating errata set 1 should not be used and another 
parameter
(e.g. rdn for random) should be defined and registered by IANA and used 
in combination with a UTC time parameter included in the Authentication 
Request.
In this way, only the rdn received during the last X minutes will need 
to be remembered by the Authorization Servers.

5.The title of section 9.1 is: "Certificate validation"

Change the title of this section into :

"9.1. Common Name Constrained Token"

6.In section 9.1, the text states:

The "cn" JWT confirmation method relies its security property on the

X.509 client certificate authentication.

Replace with:

The "cn" JWT confirmation method relies its security property by the 
inclusion of the Common Name (CN)
that is part of the Distinguished Name (DN) of an X.509 certificate. The 
JWT is linked to the common name
included in the certificate. Such a method is not privacy friendly since 
it allows an easy linkage between
all the accounts of a given user on different resource servers.

7.Add a new section 9.2 to deal with the case of the cid.

Proposed text:

9.2. Client ID Constrained Token

The "cid" JWT confirmation method relies its security property on the 
assumption that the cid legitimately
used by one server cannot be used by another user. It also relies on the 
assumption that the authentication data
associated with "cid" combined with the "iss" will only be used by the 
legitimate user. This method is ineffective
in case of a collusion between two users, since one user can perform all 
the computations needed by the other user.

8.In section 9.2, the text states:

The client’s secret key must be kept securely. Otherwise, the notion of 
PoP breaks down.

The PKIX group from the IETF is using the vocabulary private key / 
public key when asymmetric cryptography is being used
and secret key when symmetric algorithms are being used (let us call a 
spade a spade).

However, keeping a client's private key securely is not the right 
wording either. If the key is kept securely in a secure element
(e.g. smart card), this is not enough, since the holder of the secure 
element may use this key for himself ... or worse for the benefit of 
someone else.

Proposed change :

9.3. Key Constrained Token

This method has four variants.

When the JWT contains a jwk, the JWT confirmation method relies its 
security property on the assumption that the private key
associated with the public key contained in the access token will only 
be used by the legitimate user. In order to avoid an easy linkage
between user's accounts, this method presents the advantage that the key 
pair can be changed for every JWT. However, this method
is ineffective in case of a collusion between two users, since one user 
can perform all the computations needed by the other user.

When the JWT contains a jwkt#s256, the server must have a prior 
knowledge of the public key and the method relies its security property
on the assumption that the private key associated with the public key 
contained in the access token will only be used by the legitimate user.
Hence, this method is ineffective in case of a collusion between two 
users, since one user can perform all the computations needed
by the other user.

When the JWT contains a x5t#s256, the server must have a prior knowledge 
of the public key certificate. The JWT is then linked to a hash value
of a certificate included in the JWT. The server knows a unique 
identifier of the user. Such a method is not privacy friendly since it 
allows
an easy linkage between all the accounts of a given user on different 
resource servers.

When the JWT contains a jwe, the JWT confirmation method relies its 
security property on the assumption that the secret key included
in the JWT will only be used by the legitimate user. In order to avoid 
an easy linkage between user's accounts, this method presents
the advantage that the secret key can be changed for every JWT. However, 
this method is ineffective in case of a collusion between two users,
since one user can perform all the computations needed by the other user.

9.The text states in section 9.3:

9.3.Audi_a_nce Restriction

When using the signature method the client must specify to the AS the 
aud it intends to send the token to, so that it can be included in the AT.

A malicious RS could receive a AT with no aud or a logical audience and 
then replay the AT and jws-on-nonce to the actual server.

Proposed change in order to address privacy concerns :

9.4.Audi_e_nce Restriction

When using the signature method, the client must specify to the AS the 
aud it intends to send the token to, so that it can be included in the AT.

RFC 7800 states that the interpretation of audience values is 
application specific. If a fixed value is being used, e.g. a URL of the 
server,
then the authorization server can easily know where the access tokens 
will be used and thus is in a position to act as Big Brother.
It is thus recommended to use a different value in the aud claims for 
each access token that contains no semantics in it but that the resource 
server
can easily recognize.//

If a malicious RS receives an AT with no aud or a logical audience in it 
then it can replay the AT and jws-on-nonce to another server.

Denis

> It is capturing strong and rather urgent demands from the financial 
> sector and would be great if it can be considered in the WG.
>
> Best,
>
> Nat Sakimura
>
> On Tue, Mar 21, 2017 at 10:28 PM Antonio Sanso <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     hi Torsten,
>
>     On Mar 21, 2017, at 2:08 PM, Torsten Lodderstedt
>     <[email-masked] <mailto:[email-masked]>> wrote:
>
>>     Hi Chairs,
>>
>>     I would like to request 5 minutes on Monday to briefly present
>>     the status of the security document. This is mainly to raise
>>     awareness in the group since I didn’t get that much input on it
>>     since Seoul.
>>
>>     kind regards,
>>     Torsten.
>>
>>>     Am 18.03.2017 um 01:52 schrieb Mike Jones
>>>     <[email-masked] <mailto:[email-masked]>>:
>>>
>>>     Hi Chairs,
>>>
>>>     I'd also talked with Brian Campbell and I think he wants to lead
>>>     this discussion, in part based on his implementation experience:
>>>
>>>     I agree that William Dennis should present about the OAuth
>>>     Device Flow (draft-ietf-oauth-device-flow).
>>>
>>>     For completeness, I don't think a presentation is needed about
>>>     OAuth AMR Values (draft-ietf-oauth-amr-values) because it's now
>>>     completed its IESG review.
>>>
>>>     To: [email-masked] <mailto:[email-masked]>;
>>>     [email-masked] <mailto:[email-masked]>
>>>     Cc: [email-masked] <mailto:[email-masked]>
>>>     Working Group Name: Web Authorization Protocol Area Name:
>>>     Security Area Session Requester: Stephanie McCammon
>>>
>>>     Number of Sessions: 2
>>>     [email-masked] <mailto:[email-masked]>
>>>     [email-masked] <mailto:[email-masked]>
>>     [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

---

From: Nat Sakimura <[email-masked]>
Date: Sun, 26 Mar 2017 16:37:18 +0000

Hi Denis,

Thanks.

Is it possible to file these separately at
https://bitbucket.org/Nat/oauth-rjwtprof/issues?status=new&status=open so
that each issue can be closed separately? (You need to login to bitbucket
to do so.) Pull request would be nice, too, but we are going to do a bit of
surgery on the spec as of now, so it might be wise to wait till after that
to avoid conflicts.

Also, it is not yet a WG document so please support it become one.

Best,

Nat Sakimura

On Wed, Mar 22, 2017 at 5:15 AM Denis <[email-masked]> wrote:

> 1. The abstract states:
> Only the party in possession of a corresponding cryptographic key with the
> 2. In section 3, the text states:
>
>   aud  The identifier of the resource server.
>
>   aud  The recipients that the JWT is intended for (the interpretation of
> 3. In section 3, the text states:
>
> cnf  The confirmation method.
>
> 4. In section 6.2, the text states:
>
>    1.  The client prepares a nonce.
>
>    2.  The client creates JWS compact serialization over the nonce
> unmodified from the Authentication Request to the ID Token. If present in
> the ID Token, Clients MUST verify that the nonce
> Claim Value is equal to the value of the nonce parameter sent in the
> Authorization Servers MUST include a nonce Claim in the ID Token with the
> Authorization Servers SHOULD perform no other processing on nonce values
> used. The nonce value is a case sensitive string.
>
>
>
> a)     there is some difficulty to mandate the use of a parameter that is
> not registered by IANA.
>
> b)     the further processing of the nonce is not indicated in the text
>
> Servers SHOULD perform no other processing on nonce values used"
> (e.g. rdn for random) should be defined and registered by IANA and used in
> combination with a UTC time parameter included in the Authentication
> Request.
> In this way, only the rdn received during the last X minutes will need to
> be remembered by the Authorization Servers.
>
>
> 5. The title of section 9.1 is: "Certificate validation"
>
> 6. In section 9.1, the text states:
>
> 7. Add a new section 9.2 to deal with the case of the cid.
>
> Proposed text:
>
> 8. In section 9.2, the text states:
>
> The PKIX group from the IETF is using the vocabulary private key / public
> key when asymmetric cryptography is being used
> However, keeping a client's private key securely is not the right wording
> either. If the key is kept securely in a secure element
> associated with the public key contained in the access token will only be
> used by the legitimate user. In order to avoid an easy linkage
> When the JWT contains a jwkt#s256, the server must have a prior knowledge
> of the public key and the method relies its security property
> of a certificate included in the JWT. The server knows a unique identifier
> of the user. Such a method is not privacy friendly since it allows
> in the JWT will only be used by the legitimate user. In order to avoid an
> easy linkage between user's accounts, this method presents
> 9. The text states in section 9.3:
>
> 9.3.  Audi*a*nce Restriction
>
> When using the signature method the client must specify to the AS the aud
> it intends to send the token to, so that it can be included in the AT.
>
> 9.4.  Audi*e*nce Restriction
>
> When using the signature method, the client must specify to the AS the aud
> it intends to send the token to, so that it can be included in the AT.
>
> RFC 7800 states that the interpretation of audience values is application
> specific. If a fixed value is being used, e.g. a URL of the server,
> then the authorization server can easily know where the access tokens will
> be used and thus is in a position to act as Big Brother.
> It is thus recommended to use a different value in the aud claims for each
> access token that contains no semantics in it but that the resource server
> can easily recognize.
>
> OAuth mailing [email-masked]://www.ietf.org/mailman/listinfo/oauth
>
>
-- 

Nat Sakimura

---

From: Denis <[email-masked]>
Date: Mon, 27 Mar 2017 10:46:41 +0200

Hi Nat,

At present, I do not support the adoption of this document as a WG 
document since the different techniques
that are being proposed have severe problems:

  * When the JWT contains a jwk , jwkt#s256 or jwe, the method is
    ineffective in case of a collusion between two users (ABC attack).
  * When the JWT contains a x5t#s256, the JWT is linked to a hash value
    of a certificate included in the JWT.
    The server then knows a unique identifier of the user. Such a method
    allows an easy linkage between all the accounts
    of a given user on different resource servers, even when the JWT
    only contains non-directly identifiable attributes.
    Hence, it does not respect 'privacy by design' principles.

In addition, if a fixed value is being used for the audience restriction 
parameter, e.g. a URL of the server, then the authorization server
can easily know where the access tokens will be used and thus it will be 
in a position to act as Big Brother.

You may however continue to progress this document as an individual 
contribution.

Denis

PS. I will not subscribe to bitbucket.org because I don't agree with the 
conditions of this site.

> that each issue can be closed separately? (You need to login to 
> bitbucket to do so.) Pull request would be nice, too, but we are going 
> to do a bit of surgery on the spec as of now, so it might be wise to 
> wait till after that to avoid conflicts.
>
> On Wed, Mar 22, 2017 at 5:15 AM Denis <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Hi Nat,
>
>
>     Only the party in possession of a corresponding cryptographic key
>     with the Jpop token can use it to get access
>     Any party able to use a corresponding private cryptographic key
>     with the Jpop token can use it to get access
>     The "aud" (audience) claim identifies the recipients that the JWT
>     is intended for. The interpretation of audience values is
>     application specific.
>
>     Replace with:
>
>     audThe recipients that the JWT is intended for (the interpretation
>     of audience values is application specific).
>
>     "nonce" has not been defined by the IANA, but is mentioned in
>     OpenID Connect Core 1.0 incorporating errata set 1. It is
>     described as :
>
>     nonce
>
>     String value used to associate a Client session with an ID Token,
>     and to mitigate replay attacks. The value is passed through
>     unmodified from the Authentication Request to the ID Token. If
>     present in the ID Token, Clients MUST verify that the nonce
>     Claim Value is equal to the value of the nonceparameter sent in
>     the Authentication Request. If present in the Authentication Request,
>     Authorization Servers MUST include a nonceClaim in the ID Token
>     with the Claim Value being the nonce value sent in the
>     Authentication Request.
>     Authorization Servers SHOULD perform no other processing on
>     noncevalues used. The noncevalue is a case sensitive string.
>
>     a)there is some difficulty to mandate the use of a parameter that
>     is not registered by IANA.
>
>     c) The last sentence from the above description states:
>     "Authorization Servers SHOULD perform no other processing on
>     noncevalues used"
>     There is a practical problem with such a sentence since
>     Authorization Servers would need to remember nonces for ever.
>     Either that sentence should be deleted or the nonce shall be only
>     used with a UTC time parameter included in the Authentication Request.
>
>     In any case, the definition of a nonce as specified in OpenID
>     Connect Core 1.0 incorporating errata set 1 should not be used and
>     another parameter
>     (e.g. rdn for random) should be defined and registered by IANA and
>     used in combination with a UTC time parameter included in the
>     Authentication Request.
>     In this way, only the rdn received during the last X minutes will
>     need to be remembered by the Authorization Servers.
>
>
>     The "cn" JWT confirmation method relies its security property by
>     the inclusion of the Common Name (CN)
>     that is part of the Distinguished Name (DN) of an X.509
>     certificate. The JWT is linked to the common name
>     included in the certificate. Such a method is not privacy friendly
>     since it allows an easy linkage between
>     The "cid" JWT confirmation method relies its security property on
>     the assumption that the cid legitimately
>     used by one server cannot be used by another user. It also relies
>     on the assumption that the authentication data
>     associated with "cid" combined with the "iss" will only be used by
>     the legitimate user. This method is ineffective
>     in case of a collusion between two users, since one user can
>     perform all the computations needed by the other user.
>
>     The client’s secret key must be kept securely. Otherwise, the
>     notion of PoP breaks down.
>
>     and secret key when symmetric algorithms are being used (let us
>     call a spade a spade).
>
>     (e.g. smart card), this is not enough, since the holder of the
>     secure element may use this key for himself ... or worse for the
>     benefit of someone else.
>
>     Proposed change :
>
>     When the JWT contains a jwk, the JWT confirmation method relies
>     its security property on the assumption that the private key
>     associated with the public key contained in the access token will
>     only be used by the legitimate user. In order to avoid an easy linkage
>     between user's accounts, this method presents the advantage that
>     the key pair can be changed for every JWT. However, this method
>     is ineffective in case of a collusion between two users, since one
>     user can perform all the computations needed by the other user.
>
>     on the assumption that the private key associated with the public
>     key contained in the access token will only be used by the
>     legitimate user.
>     Hence, this method is ineffective in case of a collusion between
>     two users, since one user can perform all the computations needed
>     by the other user.
>
>     When the JWT contains a x5t#s256, the server must have a prior
>     knowledge of the public key certificate. The JWT is then linked to
>     a hash value
>     identifier of the user. Such a method is not privacy friendly
>     since it allows
>     an easy linkage between all the accounts of a given user on
>     different resource servers.
>
>     When the JWT contains a jwe, the JWT confirmation method relies
>     its security property on the assumption that the secret key included
>     in the JWT will only be used by the legitimate user. In order to
>     avoid an easy linkage between user's accounts, this method presents
>     the advantage that the secret key can be changed for every JWT.
>     However, this method is ineffective in case of a collusion between
>     two users,
>     When using the signature method the client must specify to the AS
>     the aud it intends to send the token to, so that it can be
>     included in the AT.
>
>     A malicious RS could receive a AT with no aud or a logical
>     audience and then replay the AT and jws-on-nonce to the actual server.
>
>
>     When using the signature method, the client must specify to the AS
>     the aud it intends to send the token to, so that it can be
>     included in the AT.
>
>     application specific. If a fixed value is being used, e.g. a URL
>     of the server,
>     then the authorization server can easily know where the access
>     tokens will be used and thus is in a position to act as Big Brother.
>     It is thus recommended to use a different value in the aud claims
>     for each access token that contains no semantics in it but that
>     the resource server
>     can easily recognize.//
>
>     If a malicious RS receives an AT with no aud or a logical audience
>     in it then it can replay the AT and jws-on-nonce to another server.
>
>     Denis
>
>
>>     HI Chairs,
>>
>>     It is capturing strong and rather urgent demands from the
>>     financial sector and would be great if it can be considered in
>>     the WG.
>>
>>     Best,
>>
>>     Nat Sakimura
>>
>>>         I would like to request 5 minutes on Monday to briefly
>>>         present the status of the security document. This is mainly
>>>         to raise awareness in the group since I didn’t get that much
>>>         input on it since Seoul.
>>>
>>>         kind regards,
>>>         Torsten.
>>>
>>>>         OAuth Authorization Server Metadata
>>>>         (draft-ietf-oauth-discovery) - Mike Jones - 15 minutes
>>>>
>>>>         I'd also talked with Brian Campbell and I think he wants to
>>>>         lead this discussion, in part based on his implementation
>>>>         experience:
>>>>
>>>>         For completeness, I don't think a presentation is needed
>>>>         about OAuth AMR Values (draft-ietf-oauth-amr-values)
>>>>         because it's now completed its IESG review.
>>>>

---

From: Nat Sakimura <[email-masked]>
Date: Mon, 27 Mar 2017 12:26:49 +0000

HI.

As pointed out in saag, the OAuth WG is not dealing with ABC attack. It is
out of scope for now at least.
The certs used is the certs of the client and not the subject/user. It is
the client authentication, not the user authentication.
In addition, authorization server knowing where the user is going with this
token is not an issue here.
The protected resource and the authorization server belongs to the same
administrative domain.

Best,

Nat

On Mon, Mar 27, 2017 at 3:46 AM Denis <[email-masked]> wrote:

>    - When the JWT contains a jwk , jwkt#s256 or jwe, the method is
>    - When the JWT contains a x5t#s256, the JWT is linked to a hash value
>    of a given user on different resource servers, even when the JWT only contains
>    non-directly identifiable attributes.

Nat Sakimura

---

From: Denis <[email-masked]>
Date: Mon, 27 Mar 2017 15:08:39 +0200

Hi Nat,
> HI.
>
> As pointed out in saag, the OAuth WG is not dealing with ABC attack. 
> It is out of scope for now at least.

A threat along the ABC attack is not mentioned in RFC 6819 : OAuth 2.0 
Threat Model and Security Considerations (2013).
Hence, nobody attempted to find a solution ... for a threat that had not 
been identified.

draft-ietf-oauth-token-binding-02 is a document form the OAuth WG. Since 
this threat has not been identified in RFC 6813,
it does not contain any proposal to counter that threat. However, this 
threat is now identified. Should this threat be addressed
by sticking our heads in the sand ?

A basic property of the current Token Binding mechanisms being developed 
both by the OAuth WG and the Token Binding WG
is that a specific piece of software voluntarily installed by a client 
can export any token and perform all the needed computations
so that any token can successfully be usedby another client. It is NOT 
the replay of a token, since the token is not used at any
time by the legitimate owner, but is used by an illegitimateuser.

> The certs used is the certs of the client and not the subject/user. It 
> is the client authentication, not the user authentication.

If the user is always using the same client, then the end-result is 
nearly the same.

> In addition, authorization server knowing where the user is going with 
> this token is not an issue here.
> The protected resource and the authorization server belongs to the 
> same administrative domain.

OAuth 2.0 was originally limited to this scope but has been expanded to 
be used in other contexts where the protected resource
and the authorization server do not necessarily belong to the same 
administrative domain. Hence, mandating the use of a URI is
against privacy principles. More flexibility is needed.

Denis

>
> Best,
>
> Nat
>
>
> On Mon, Mar 27, 2017 at 3:46 AM Denis <[email-masked] 
>       * When the JWT contains a x5t#s256, the JWT is linked to a hash
>         value of a certificate included in the JWT.
>         The server then knows a unique identifier of the user. Such a
>         method allows an easy linkage between all the accounts
>         of a given user on different resource servers, even when the
>         JWT only contains non-directly identifiable attributes.
>     In addition, if a fixed value is being used for the audience
>     restriction parameter, e.g. a URL of the server, then the
>     authorization server
>     can easily know where the access tokens will be used and thus it
>     will be in a position to act as Big Brother.
>
>     You may however continue to progress this document as an
>     individual contribution.
>
>
>     Denis
>
>     PS. I will not subscribe to bitbucket.org <http://bitbucket.org>
>     because I don't agree with the conditions of this site.
>
>
>>     Hi Denis,
>>
>>     Thanks.
>>
>>     bitbucket to do so.) Pull request would be nice, too, but we are
>>     going to do a bit of surgery on the spec as of now, so it might
>>     be wise to wait till after that to avoid conflicts.
>>
>>         I have several comments on draft-sakimura-oauth-jpop-01
>>         related to security or privacy.
>>
>>
>>         1.The abstract states:
>>
>>         Only the party in possession of a corresponding cryptographic
>>         key with the Jpop token can use it to get access
>>         to the associated resources unlike in the case of the bearer
>>         token described in [RFC6750] where any party
>>         Any party able to use a corresponding private cryptographic
>>         key with the Jpop token can use it to get access
>>         to the associated resources unlike in the case of the bearer
>>         token described in [RFC6750] where any party
>>         The "aud" (audience) claim identifies the recipients that the
>>         JWT is intended for. The interpretation of audience values is
>>         application specific.
>>
>>         Replace with:
>>
>>         audThe recipients that the JWT is intended for (the
>>         interpretation of audience values is application specific).
>>
>>         String value used to associate a Client session with an ID
>>         Token, and to mitigate replay attacks. The value is passed
>>         through
>>         unmodified from the Authentication Request to the ID Token.
>>         If present in the ID Token, Clients MUST verify that the nonce
>>         Claim Value is equal to the value of the nonceparameter sent
>>         in the Authentication Request. If present in the
>>         Authentication Request,
>>         Authorization Servers MUST include a nonceClaim in the ID
>>         Token with the Claim Value being the nonce value sent in the
>>         Authentication Request.
>>         a)there is some difficulty to mandate the use of a parameter
>>         that is not registered by IANA.
>>
>>         Either that sentence should be deleted or the nonce shall be
>>         only used with a UTC time parameter included in the
>>         Authentication Request.
>>
>>         Connect Core 1.0 incorporating errata set 1 should not be
>>         used and another parameter
>>         (e.g. rdn for random) should be defined and registered by
>>         IANA and used in combination with a UTC time parameter
>>         included in the Authentication Request.
>>         In this way, only the rdn received during the last X minutes
>>         will need to be remembered by the Authorization Servers.
>>
>>
>>         The "cn" JWT confirmation method relies its security property
>>         by the inclusion of the Common Name (CN)
>>         included in the certificate. Such a method is not privacy
>>         friendly since it allows an easy linkage between
>>         The "cid" JWT confirmation method relies its security
>>         property on the assumption that the cid legitimately
>>         used by one server cannot be used by another user. It also
>>         relies on the assumption that the authentication data
>>         associated with "cid" combined with the "iss" will only be
>>         used by the legitimate user. This method is ineffective
>>         The PKIX group from the IETF is using the vocabulary private
>>         key / public key when asymmetric cryptography is being used
>>         and secret key when symmetric algorithms are being used (let
>>         us call a spade a spade).
>>
>>         However, keeping a client's private key securely is not the
>>         right wording either. If the key is kept securely in a secure
>>         element
>>         (e.g. smart card), this is not enough, since the holder of
>>         the secure element may use this key for himself ... or worse
>>         for the benefit of someone else.
>>
>>         Proposed change :
>>
>>         When the JWT contains a jwk, the JWT confirmation method
>>         relies its security property on the assumption that the
>>         private key
>>         associated with the public key contained in the access token
>>         will only be used by the legitimate user. In order to avoid
>>         an easy linkage
>>         between user's accounts, this method presents the advantage
>>         that the key pair can be changed for every JWT. However, this
>>         method
>>         is ineffective in case of a collusion between two users,
>>         When the JWT contains a jwkt#s256, the server must have a
>>         prior knowledge of the public key and the method relies its
>>         security property
>>         on the assumption that the private key associated with the
>>         public key contained in the access token will only be used by
>>         the legitimate user.
>>         Hence, this method is ineffective in case of a collusion
>>         between two users, since one user can perform all the
>>         computations needed
>>         by the other user.
>>
>>         When the JWT contains a x5t#s256, the server must have a
>>         prior knowledge of the public key certificate. The JWT is
>>         then linked to a hash value
>>         of a certificate included in the JWT. The server knows a
>>         unique identifier of the user. Such a method is not privacy
>>         friendly since it allows
>>         When the JWT contains a jwe, the JWT confirmation method
>>         relies its security property on the assumption that the
>>         secret key included
>>         in the JWT will only be used by the legitimate user. In order
>>         to avoid an easy linkage between user's accounts, this method
>>         presents
>>         the advantage that the secret key can be changed for every
>>         JWT. However, this method is ineffective in case of a
>>         collusion between two users,
>>         When using the signature method the client must specify to
>>         the AS the aud it intends to send the token to, so that it
>>         can be included in the AT.
>>
>>         When using the signature method, the client must specify to
>>         the AS the aud it intends to send the token to, so that it
>>         can be included in the AT.
>>
>>         application specific. If a fixed value is being used, e.g. a
>>         URL of the server,
>>         then the authorization server can easily know where the
>>         access tokens will be used and thus is in a position to act
>>         as Big Brother.
>>         It is thus recommended to use a different value in the aud
>>         claims for each access token that contains no semantics in it
>>         but that the resource server
>>         can easily recognize.//
>>
>>         If a malicious RS receives an AT with no aud or a logical
>>         audience in it then it can replay the AT and jws-on-nonce to
>>         another server.
>>
>>         Denis
>>
>>
>>>         HI Chairs,
>>>
>>>         financial sector and would be great if it can be considered
>>>         in the WG.
>>>
>>>         Best,
>>>
>>>         Nat Sakimura
>>>
>>>         On Tue, Mar 21, 2017 at 10:28 PM Antonio Sanso
>>>         <[email-masked] <mailto:[email-masked]>> wrote:
>>>
>>>             hi Torsten,
>>>
>>>>             present the status of the security document. This is
>>>>             mainly to raise awareness in the group since I didn’t
>>>>             get that much input on it since Seoul.
>>>>
>>>>             kind regards,
>>>>             Torsten.
>>>>
>>>>>             I'd also talked with Brian Campbell and I think he
>>>>>             wants to lead this discussion, in part based on his
>>>>>             implementation experience:
>>>>>
>>>>>             I agree that William Dennis should present about the
>>>>>             OAuth Device Flow (draft-ietf-oauth-device-flow).
>>>>>
>>>>>             For completeness, I don't think a presentation is
>>>>>             needed about OAuth AMR Values
>>>>>             (draft-ietf-oauth-amr-values) because it's now
>>>>>             To: [email-masked]
>>>>>             <mailto:[email-masked]>; [email-masked]
>>>>>             <mailto:[email-masked]>
>>>>>             Working Group Name: Web Authorization Protocol Area
>>>>>             Name: Security Area Session Requester: Stephanie McCammon
>>>>>
>>>>>             Number of Sessions: 2

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 27 Mar 2017 16:52:41 -0500

> by sticking our heads in the sand ?

I am not sure that everyone in this conversation agrees on the same
definition of "threat model" that is in use.  The definition that I
am using involves choosing a specific set of attacker capabilities
to attempt to counter, and explictly does not include considering
an all-powerful attacker or considering all conceivable potential
"threats".  That is to say, the discovery of a new potential threat
need not necessate a modification to the threat model, as the new
threat  may require an attacker capability against which we are not
trying to defend.

-Ben

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 27 Mar 2017 17:26:23 -0500

> You may however continue to progress this document as an individual 

[obligatory note that Denis is not in a position to grant or deny
permission to adopt the document as a WG document]

-Ben