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 protected]
<mailto:[email protected]>> wrote:
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
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 protected] <mailto:[email protected]>> wrote:
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 protected]
<mailto:[email protected]>> 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 protected]
<mailto:[email protected]>>:
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 protected]] On Behalf
Of "IETF Secretariat"
Sent: Friday, March 3, 2017 3:55 PM
To: [email protected]
<mailto:[email protected]>; [email protected]
<mailto:[email protected]>
Cc: [email protected] <mailto:[email protected]>
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.
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.
---------------------------------------------------------
_______________________________________________
OAuth mailing list
[email protected] <mailto:[email protected]>
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 protected] <mailto:[email protected]>
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 protected] <mailto:[email protected]>
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
_______________________________________________
OAuth mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/oauth
--
Nat Sakimura
Chairman of the Board, OpenID Foundation
_______________________________________________
OAuth mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/oauth
--
Nat Sakimura
Chairman of the Board, OpenID Foundation
