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.
token is not an issue here.
administrative domain.
Post by DenisHi Nat,
At present, I do not support the adoption of this document as a WG
document since the different techniques
- 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.
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
Hi Nat,
I have several comments on draft-sakimura-oauth-jpop-01 related to
security or privacy.
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.
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.
aud The identifier of the resource server.
The "aud" (audience) claim identifies the recipients that the JWT is
intended for. The interpretation of audience values is application specific.
aud The recipients that the JWT is intended for (the interpretation of
audience values is application specific).
cnf The confirmation method.
Their semantics are defined in [RFC7519] and [RFC7800]
This is incorrect: cnf is neither defined in [RFC7519] nor in [RFC7800].
1. The client prepares a nonce.
2. The client creates JWS compact serialization over the nonce
https://www.iana.org/assignments/jwt/jwt.xhtml
"nonce" has not been defined by the IANA, but is mentioned in OpenID
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 nonce parameter sent in the
Authentication Request. If present in the Authentication Request,
Authorization Servers MUST include a nonce Claim 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 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
c) The last sentence from the above description states: "Authorization
Servers SHOULD perform no other processing on nonce values 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"
"9.1. Common Name Constrained Token"
The "cn" JWT confirmation method relies its security property on the
X.509 client certificate authentication.
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.
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.
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.
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.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.
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
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
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
I'd also talked with Brian Campbell and I think he wants to lead this
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-----
Behalf Of "IETF Secretariat"
Sent: Friday, March 3, 2017 3:55 PM
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
---------------------------------------------
---------------------------------------------------------
Working Group Name: Web Authorization Protocol Area Name: Security Area
Session Requester: Stephanie McCammon
Number of Sessions: 2
First Priority: saag core tls tokbind
Hannes Tschofenig
Kathleen Moriarty
Derek Atkins
Projector in room
Please avoid conflict with sec area BoFs.
---------------------------------------------------------
_______________________________________________
OAuth mailing list
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
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
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
https://www.ietf.org/mailman/listinfo/oauth
--
Nat Sakimura
Chairman of the Board, OpenID Foundation
_______________________________________________
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
--
Nat Sakimura
Chairman of the Board, OpenID Foundation
--