jricher
commented
2 years ago Yes, this is out of scope but not because of what you wrote here: Users can collaborate without using access tokens at all by simply making the software calls for each other.
Closed Denisthemalice closed 2 years ago
jricher
commented
2 years ago Yes, this is out of scope but not because of what you wrote here: Users can collaborate without using access tokens at all by simply making the software calls for each other.
Denisthemalice
commented
2 years ago @jricher wrote:
Users can collaborate without using access tokens at all by simply making the software calls for each other.
Yes, but this is not the point. The key point is to take advantage of a right or of an attribute that belongs to another user, without the need for the other user to be on line present anymore.
It is important to define the context and, then after, the conditions that allows a RS to detect collusion attacks.
Let us assume that two users have legitimately opened a session on a RS that allows them to perform some operations on some resources. The RS has associated with each of them some rights and/or attributes. Let us also assume that these rights and/or attributes are valid either for one month or more (i.e. a user account is maintained by the RS between different sessions) or only during the duration of the session (i.e. the user account is only maintained by the RS during the session).
In both cases, each user may perform some operations on the resource under the control of the RS without the need to present again rights and/or attributes that are still valid.
As it will be explained below, among other conditions, in order to be accepted by a RS, an access token shall always contain either a single user attribute or a set of user attributes that allows the RS to be confident that the content of the access token indeed relates to the right user.
These two cases are now considered.
1). The access token contains a single user identifier attribute (i.e. an identifying attribute)
When the access token contains a single user identifier attribute, several types of user identifiers can be considered by the RS to be an identifying attribute:
(a) globally unique user identifier (e.g. a personal email address, a social security number including the issuing country, a passport number including the issuing country c, a driving licence including the issuing state or country), or
(b) a locally unique user identifier used by the AS to identify the user, whatever server is involved (e.g. a single pseudonym used for all the servers), or
(c) a unique user identifier issued by the Access provider to identify the user for each AS / RS pair (e.g. a different pseudonym for each AS / RS pair), or
(d) a unique user identifier used by the AS to identify the user for each User/ RS pair (e.g. a different pseudonym for each User / RS pair), or
(e) a temporary user unique identifier used by the AS to identify the user, that is only valid during a single session between the client application and the AS, whatever RS is involved (e.g. a large random number).
If the RS decides that this single user attribute is adequate to uniquely identify the user, then some rights and/or attributes can be added to the set of rights and/or attributes already associated with the user account or to the session.
2) The access token contains a set of user attributes
If the RS decides that the access token contains a subset of attributes that is sufficient to uniquely identify the user, then the rights and/or attributes can be added to the set of rights and/or attributes already associated with the user account or to the session. In practice, that set of attributes will compared with already known such attributes and shall match with them.
Advantages and drawbacks when using several user attributes or a single identifying attribute
1. Advantages and drawbacks when using a single identifying attribute
The identifying attribute may be either:
(1) a globally unique user identifier, or (2) a locally unique user identifier used to identify a user whatever RS is being involved, or (3) a unique user identifier used to identify a user for each AS / RS pair, or (4) a unique user identifier used to identify a user for each User/ RS pair, or (5) a temporary user unique identifier.
1.1. Globally unique user identifier
Several RSs (not necessarily receiving access tokens) may be able to establish a link between their users’ accounts by using this single identifying attribute. This may be a concern for some users in terms of privacy.
1.2. Locally unique user identifier
Several RSs (receiving an access token from the same AS) may be able to establish a link between their users’ accounts by using this single identifying attribute. This may be a concern for some users in terms of privacy.
1.3. User identifier unique for each AS / RS pair
In order to be able to generate such an identifying attribute, the client application shall disclose to the AS, an identifier of the RS. This allows the AS to know where the attributes tokens it issues are likely to be used.
This may be a concern for the user in terms of privacy, since the AS will be able to log the identifiers of these accesses.
However, this case offers a benefit: several RSs (receiving an access token from the same AS) will be unable to establish a link between their users’ accounts by using this single identifying attribute. Hence, this is an interesting property in terms of privacy.
1.4. Unique user identifier for each User/ RS pair
Several RSs (necessarily receiving an access token from the same AS) will be unable to establish a link between their users’ accounts by using this single identifying attribute. This is an interesting property in terms of privacy.
1.5. Temporary unique user identifier
Several RSs (necessarily receiving an access token from different ASs) will be unable to establish a link between their users accounts by using this single identifying attribute. This is an interesting property in terms of privacy.
2. Advantages and drawbacks when using several user attributes
The set of user attributes associated with the user should be sufficient, in the context of the RS, to uniquely identify the user. A larger number of user attributes than is the previous case needs to be disclosed.
3. Security considerations
A legitimate user who has received from an AS an access token that contains an attribute stating that he is above a certain age (e.g. 18), might attempt to collaborate with another user under a certain age (e.g. 13) in order to make believe to a RS that the second user is above a certain age (e.g. 18) while in reality he is under 13.
Such a collusion between users can be detected and thus can be defeated by the RS because an access token shall contain one or more attributes associated with the user that allow to uniquely and unambiguously identity the user, as it has been explained above.
As an example, an access token that would only contain a right (and hence no user attribute) would be forwardable to another user. If it is a bearer token, this is straight forward and no cryptographic collaboration will be involved between the two users while for a sender-constrained token this is less straight forward since some cryptographic collaboration will be involved between the two users.
In both cases, the collaborative attack can be detected by the RS.
aaronpk
commented
2 years ago Such a collusion between users can be detected and thus can be defeated by the RS because an access token shall contain one or more attributes associated with the user that allow to uniquely and unambiguously identity the user, as it has been explained above.
So you put a user identifier into the token, great, let's call it "user1". Now that user gives their access token to another user. The token still has the original user's identifier "user1" in it, but now it's being used by user 2. This is not detectable by the RS, it just looks like the request is being made by user 1. Am I missing something?
Denisthemalice
commented
2 years ago Let us use a simple example, where access tokens contain in a "sub-alt" claim a globally unique user identifier (as in case 1.1 above).
Let us assume that user1 is known by the RS under "user1@company.com" while user2 is known under "user2@company.com".
When user2 presents to the RS an access token that contains the "sub-alt" claim, "user1@company.com", the RS will notice that a the "sub-alt" claim "user2@company.com" should have been present and will reject the access token. If a right (i.e. a capability) was also present in the access token, it will not be accepted.
You might have noticed that the access token profile defined by the OAuth WG mandates the inclusion of a "sub" claim. It is not fully explained why in the RFC, but the topic I want to address is similar : either a "sub" or a "sub-alt" claim shall be present in an access token.
jricher
commented
2 years ago @Denisthemalice in your example, how does the RS know that it's user2 presenting the token with a sub-alt claim of "user1@company.com"? If the access token has that claim, how else is the RS supposed to know that "this is actually user2" besides what's in the access token? Especially if user1 and user2 are colluding, as you describe in your attack, and user1 has willingly handed both the access token (with sub-alt claim) and key material to user2? Can you please explain why the inclusion of this claim would stop this attack that you've described, and more pressingly, how the RS is supposed to "know" that it's user2 calling vs. user1?
aaronpk
commented
2 years ago When user2 presents to the RS an access token that contains the "sub-alt" claim, "user1@company.com", the RS will notice that a the "sub-alt" claim "user2@company.com" should have been present and will reject the access token.
This is the part I'm confused about. How does the RS know what user to expect so that it knows this value is wrong?
Denisthemalice
commented
2 years ago I realize that the wording "in the access token" was missing in the sentence you quoted. The corrected sentence is:
When user2 presents to the RS an access token that contains the "sub-alt" claim, "user1@company.com", the RS will notice that in the access token the "sub-alt" claim "user2@company.com" should have been present and will reject the access token.
I guess that your question is about the following sentence:
Let us assume that user1 is known by the RS under "user1@company.com" while user2 is known under "user2@company.com".
There are many ways to do this and there is no intent to standardize all of them. However, some examples could be provided. Let us use one banking example.
A bank already knows its customers. The bank would contact its customer and ask him which kind of "identifying attribute" he would like to use. The user chooses a "globally unique user identifier" and provides the following value: "user1@company.com",
The bank also indicates that it trusts AS 1, AS 4 and AS 25. If the customer has an account on one of these three ASs where one of his attributes is a globally unique user identifier with the value "user1@company.com", then we are done.
For the user2, in order to be accepted by the RS, every access token that contains a "globally unique user identifier" shall contain the value "user2@company.com". If not, the access token will be rejected by the RS.
jricher
commented
2 years ago @Denisthemalice I think you're misunderstanding the question that @aaronpk and I are asking: the globally unique identifier of user1@company.com is in the access token, sure. This token is presented (with valid key material if need be) by user2. Remember, the access token is presented by software to the RS. There is no user authentication involved, at all, since it's an API call -- which is what the RS is. So then, how does the RS know that it's user2 presenting the token for user1@company.com.
Denisthemalice
commented
2 years ago In the example, the RS knows that it receives an access token that contains user1@company.com. This does not allow user2 to perform any operation on his own account at the RS, but only on the user1 account.
As an example, if user1 is over 21 and user2 is under 13, if the access token contains an attribute saying "over 21", user2 cannot take advantage of it on his own user account.
Now, let me raise now the following question:
Being aware of the consequences of forwarding such a structured access token, will user1 be foolish enough (or confident enough) to forward his access token to user2, so that user2 can impersonate him on the RS and perform some operations on the user1 account at the RS without any of control from user1 ?
Your question was:
how does the RS know that it's user2 presenting the token for user1@company.com ?
The answer is:
the RS does not need to know whether user1 or user2 is presenting the access token.
jricher
commented
2 years ago Then there is no problem here since the access token represents user1. You can already do that in the existing GNAP protocol, and people do this all the time today with OAuth 2 as well. Can we close this issue, then?
Denisthemalice
commented
2 years ago Firstly, we should not close this issue, because you are not the single member of the WG and some members will only be informed of these exchanges on this thread next Sunday.
"People do this all the time today with OAuth 2", only if they support the access token profile and if they make the appropriate checks (which may be doubtful).
Secondly, the arguments are about defeating a user collaborative attack and such a description will need to be incorporated into section 12 (Security Considerations). Once this will be done, then this issue will be a candidate for a deletion.
jricher
commented
2 years ago There is no "single member" of the working group -- that's why it's a working group. No one member's opinion rules -- including yours, please remember. These duplicate issues have been closed because they continue to repeat things without bringing new aspects to the conversation.
This thread for example says that when a token represents access for a specific user, the token should indicate that somehow. This is already well understood best practice. What's in the access token and what it represents are subjects of the RS draft, as has been pointed out many, many, many times. There is no new attack. There is no new feature. But even so, please propose text to expand the RS draft's discussion of the access token's representation.
Please propose text for security considerations that you think would be helpful to describe this issue, which is already on the editors' radar to discuss.
aaronpk
commented
2 years ago From the original text of this issue:
If such attributes cannot be incorporated into an access token, the inability to defeat user collaborative attacks should be advertised in the security considerations section.
This claim is false. There is nothing in GNAP that says you cannot incorporate attributes into an access token. Instead, GNAP does not require any particular structure or format for access tokens, so it is up to a particular implementation to choose how to handle this.
I propose we close the issue with no changes. If you want to add text to the security considerations section please suggest some text to add.
Denisthemalice
commented
2 years ago @jricher . You wrote:
This thread for example says that when a token represents access for a specific user, the token should indicate that somehow. This is already well understood best practice.
When a reader will read this document, he may not be aware of this"well understood best practice" unless it is explicitly written in the document. At the moment, it is not present.
But the thread is addressing another aspect that has not been addressed before : being able to choose how a user would like to be identified in the access token towards a given RS according to his privacy preferences.
@aaronpk . It is not because "any attribute can be incorporated" (well the current text does not even state it) that the issue is solved. In order to interoperate, rules must be established on the use of those attributes. in particular to defeat collaborative attacks.
If you allow "a particular implementation to choose how to handle this" you cannot be confident that the implementation will be secure.
All the material to write a text on how defeating a collaborative attack while preserving or not the user's privacy
is already present in the various threads. Text is not only needed inside the Security considerations section since the privacy choices of the users should be part of the core protocol.
IMO, the issue should be left open.
Denisthemalice
commented
2 years ago In issue #292 an interesting question has been raised:
How the RS is supposed to know what user to expect in order to verify the field in the access token matches the expected value ?
Since it belongs to this issue, it is responded here.
Different scenarios can be envisioned to allow a user to perform operations on a resource (protected under the GNAP protocol).
A user may be willing to perform operations on a protected resource without opening a user account or with the opening of a user account so that next time (days or months later) he can take advantage of already performed operations.
1. Operations on a protected resource without opening a user account
The client sends on HTTP OPTIONS request to the RS to know which ASs are trusted by the RS. The RS indicates to the user which ASs are trusted by the RS. If the user has an account on one of these ASs, the user (or the client) selects one of these AS.
The client requests on operation on a resource protected under the GNAP protocol.
Let us imagine that some goods or activities with some preferred rates are only disclosed by a town to its residents and if there are over 21. In such a case, two attribute types and values will be requested by the RS, e.g. :
The RS will allow the user to know the reason(s) why such attribute types are being requested (User Notice). The user may agree or deny to provide them (User choice and User Consent) and, if he agrees, the client will request to the AS an access token that should contain these attributes types.
In order to detect the replay of the access token by the client towards another client, the client indicates in its access token request that a temporary user unique identifier should be used by the AS to identify the user whatever RS is involved (e.g. a large random number).
In order to detect the replay of the access token by a RS towards another RS, the client indicates in its access token request the identifier of the intended RS.
If the attribute types and values contained in the access token match with the expected attribute types and values, the operation will be granted.
Later on (e.g. within a few hours), if the client presents another access token to the same RS for the same user with other attributes, it shall include the same temporary user unique identifier issued by the AS to identify the user, otherwise the access token will be rejected.
2. Operations on a protected resource with the opening a user account
2.1. The RS already "knows" the user
The RS may already "know" the user because it already holds some information about him and the user is already identified by the RS under a user account number.
The user would like now to like to get on on-line access to perform some operations on some information associated with his user account number.
The client sends on HTTP OPTIONS request to the RS to know which ASs are trusted by the RS. The RS indicates to the user which ASs are trusted by the RS. If the user has an account on one of these ASs, the user (or the client) selects one of these AS.
The client requests on operation on a resource protected under the GNAP protocol.
The RS asks the client to provide some certified user attributes known by the AS that has been selected by the client. Certified attributes are attributes delivered in an access token by an AS trusted by the RS.
The RS allows the user to know the reason(s) why such attribute types are being requested (User Notice). The user may agree or deny to provide them (User choice and User Consent) and, if he agrees, the client will request to the AS an access token that should contain these attribute types.
For example, the attribute types may be: first name, family name, birth date and birth location.
In order to detect the replay of the access token by the client towards another client, the client indicates whether the access token should be protected under, e.g. :
If the user does not care about its privacy or has not been educated in privacy, among these three choices, he might choose the last one.
In order to detect the replay of the access token by a RS towards another RS, the client indicates the identifier of the intended RS. The returned access token will then include some attributes, the globally unique user identifier issued by the AS to identify the user, and an identifier of the RS.
If the attribute types and values contained in the access token match with the already known attribute types and values, the operation will be granted.
Later on, if the client presents another access token to the same RS for the same user, it shall include the same globally unique user identifier issued by the AS to identify the user, otherwise the access token will be rejected.
2.2. The RS does not already "know" the user
The RS does not yet "know" the user: he has no user account with the RS.
The client sends on HTTP OPTIONS request to the RS to know which ASs are trusted by the RS. The RS indicates to the user which ASs are trusted by the RS. If the user has an account or is able to open an account with one of these ASs, the user will be able to attempt to create a user account on the RS.
In order to detect the replay of the access token by the client towards another client, the client indicates whether the access token should be protected under, e.g. :
If the user cares about its privacy or has been educated in privacy, among these three choices, it is likely that he will choose the first one.
In order to detect the replay of the access token by a RS towards another RS, the client indicates the identifier of the intended RS. The returned access token will then include some attributes, the unique user identifier issued by the AS to identify the user, and an identifier of the RS.
In order to create the user account, the RS will likely ask for both claimed attributes and certified attributes. Certified attributes are attributes delivered in an access token by an AS trusted by the RS. Claimed attributes are simply attributes as claimed by the user. The client will then ask to an AS trusted by the RS an access token that contains some attribute types known by the AS.
If the attribute types and values contained in the access token match with the expected attribute types, the operation will be granted, assuming that this is not a duplicate account and that other claimed attributes are also received and the RS will create the user account, maybe after some verifications that might introduce some delay.
Later on, if the client presents another access token to the same RS for the same user, it shall include the same unique user identifier issued by the AS to identify the user for each AS / RS pair, otherwise the access token will be rejected.
Note: Other scenarios may be envisioned, but these ones allow to understand some differences.
aaronpk
commented
2 years ago You're still misunderstanding the question.
Regardless of the contents of the access token, or whether it contains a certain type of identifier or any identifier at all, you still haven't described how the RS knows what values to expect in the access token in order to be able to check it against what is expected.
In all the examples you listed, it's still possible for two users to collaborate by sharing access tokens with each other.
Denisthemalice
commented
2 years ago I believe that I have responded to your question. As example, in the last case:
If the attribute types and values contained in the access token match with the expected attribute types, the operation will be granted,
I would guess that our misunderstanding is coming from the vocabulary.
"User collaboration" is different from "impersonation". Impersonation cannot be prevented nor detected.
In the context of rights and attributes, the main idea is to prevent a user who legitimately got an attribute or a right included into an access token to transmit such access token to another user without the RS being able to detect that these rights or attributes do not belong to the right user (holder).
It is quite strange that you write:
Regardless of the contents of the access token
since the content of the access token is USED to detect the fact that the rights or attributes contained in the access token belong to the right user.
It is impossible to PREVENT users to share or forward access token, but it is possible to DETECT the collusion attack
I have explained, in three different typical cases, how the RS can make sure that the access token (and hence the rights or attributes contained in it) belongs to the right user.
aaronpk
commented
2 years ago Here it is again:
without the RS being able to detect that these rights or attributes do not belong to the right user (holder).
How does the RS know what is the "right user"? In order for that to be detectable, the RS needs some information other than the access token. What is that other information?
Denisthemalice
commented
2 years ago The answer is slightly different for each of the three cases.
For case 1, a temporary user unique identifier is assigned by the AS when the first access token is issued. Each subsequent access token issued by this AS during the session between the client and the AS (usually less than a few hours) will use the same value. So this temporary user unique identifier is memorized by the RS at the first call and will be used afterwards to make sure that any other access token received through the same TLS channel with the RS will have the same value.
For case 2.1, a globally unique user identifier is assigned by the AS when the first access token is issued. Each subsequent access token issued by this AS. will use the same value. So this globally unique user identifier is memorized by the RS at the first call and will be used afterwards to make sure that any other access token received through a TLS channel with the RS will have the same value. This scenario is only applicable once the user has been able to successfully open a user account on the RS.
For case 2.2, a unique user identifier issued by the AS to identify the user for each AS / RS pair is assigned by the AS when the first access token is issued. Each subsequent access token issued by this AS. will use the same value. So this unique user identifier issued by the AS to identify the user for each AS / RS pair is memorized by the RS at the first call and will be used afterwards to make sure that any other access token received through a TLS channel with the RS will have the same value. This scenario is only applicable once the user has been able to successfully open a user account on the RS.
aaronpk
commented
2 years ago Okay, now we're getting somewhere. So to clarify:
to make sure that any other access token received through the same TLS channel with the RS
You are proposing that the RS use the TLS session identifier to maintain state between requests so that it knows which user to expect in subsequent requests?
jricher
commented
2 years ago @aaronpk just so I am following, this would require TLS token binding and referred token binding, correct?
aaronpk
commented
2 years ago I didn't want to jump to concrete spec proposals just yet, still trying to understand the general architecture patterns being discussed.
Denisthemalice
commented
2 years ago @aaronpk . You wrote :
You are proposing that the RS use the TLS session identifier to maintain state between requests so that it knows which user to expect in subsequent requests?
No, this has nothing to do with TLS. The binding of the access token with the right user is made using a specific field included in the access token. In the above examples, that field contains either a unique user identifier or a locally unique user identifier or a globally unique user identifier.
Let us give a name for that new field and call it: a binding user identifier.
No cryptography is necessary, only the management of that field by the AS in accordance with the request from the client, the presence of this field in the access token and the checks to be done by the RS on this field.
aaronpk
commented
2 years ago Okay then we're back to the same unanswered question.
What information does the RS know about the request that enables it to know what "binding user identifier" to expect so that it can reject one that is wrong?
Denisthemalice
commented
2 years ago Well, I tried my best to explain, but apparently I still failed.
In case 1 (not the most useful case), the user is willing to perform anonymously some operations on a protected resource without opening a user account on the RS: all the access tokens coming through the same TLS channel between the client and the RS must bear the same value in the "binding user identifier".
In case 2.1, the RS already "knows" the user which means that it already knows a subset of the user's attributes. At the first access, the RS must check that attribute types and values contained in the access token match with the already known attribute types and values. How many and which attribute types and values are needed is left at the decision of the RS. Before opening the user account, the RS may also ask for some claimed attributes. After some verifications and maybe some delay, the user account at the RS will be opened.
In case 2.2, the RS already does not already "know" the user. The goal is to create a user account at the RS using both certified attributes and claimed attributes. At the first operation, the RS asks for a number of attributes types and values that will be provided in an access token issued by an AS trusted by the RS. The first access token contains a "binding user identifier"whose type but not the value is chosen by the client. Before opening the user account, the RS may also ask for some claimed attributes. After some verifications and maybe some delay, the user account at the RS will be opened.
All subsequent access tokens coming from that AS for the same user shall contain the same "binding user identifier" type and value, otherwise they will be rejected.
If a user is forwarding one of his access tokens to another user (user collusion), it will necessarily contain a different value in the "binding user identifier" and as a consequence the access token will be rejected by the RS.
Is it understandable now ?
aaronpk
commented
2 years ago Okay, I am getting a better sense of what you are describing but you still seem to be misunderstanding the question. Let me see if I can ask this differently.
When a client gets an access token from the AS and makes its first request to an RS, this will be the first time the RS sees this particular access token. The RS will validate the token based on whatever rules it deems appropriate in order to process the request and return a response.
The second time a client makes a request to the RS, it may use the same access token as before, but there is no other connection/link between the first and second requests from the client to the RS.
When the RS is validating the access token, it may do a series of checks such as "is this token expired" and "is this token issued by the AS I expect it to be" and "is there a claim in/associated with this access token that allows me to return the requested response" etc.
If a user is forwarding one of his access tokens to another user (user collusion), it will necessarily contain a different value in the "binding user identifier" and as a consequence the access token will be rejected by the RS.
In order for the RS to make this assessment that the binding user identifier is "different", it needs to know from what it is different.
What is the missing piece of information in what I am describing that lets the RS know what value to expect for this user identifier that allows it to know that it is different from what is expected?
Denisthemalice
commented
2 years ago Let us first consider cases 2.1 and 2.2 that relate to operations performed on a protected resource that are related to a user account.
You wrote:
The second time a client makes a request to the RS, it may use the same access token as before, but there is no other connection/link between the first and second requests from the client to the RS.
If the session with the RS has not been closed, it is unnecessary to present the same access token again, but nevertheless this could be done.
When a RS receives an access token, after the usual security checks that you mention, it will take a look at the "binding user identifier" which will point to a single user account. If later on, in the same session, the user presents an access token that it obtained thanks to the collaboration of another user, that access token will contain a different "binding user identifier" and hence this "forwarded" access token will be rejected.
Then let us now consider Case 1. This case does not prevent the forwarding of an access token to another user, since no comparison can be made by the RS as the user is anonymous. If a single access token is being used, the RS does not know to which user it belongs. There is however a small advantage: the user cannot mix access tokens that it legitimately received with access tokens that were obtained from another user.
In this Case 1, the access tokens are likely to be valid only a few hours or even less and anyway the rights or attributes that are presented will not be memorized by the RS any longer than the duration of the session with the RS.
jricher
commented
2 years ago @Denisthemalice I'd like to get more concrete here-- what is the session-binding and -tracking mechanism that is in play in the description above? Do you mean cookies, or do you anticipate the client to keep the TLS socket connection to the RS open for multiple requests, and bind against that?
aaronpk
commented
2 years ago It seems this is the missing piece of information that I'm trying to get you to clarify:
If the session with the RS has not been closed, it is unnecessary to present the same access token again
What exactly do you mean by "session"? You said above that you don't mean TLS session.
Denisthemalice
commented
2 years ago @jricher : There is no binding (cryptographic or not) of an access token with a TLS session. I see a TLS session as a pipe, where the client is confident that it talks with the right RS and where the RS is confident that the information it gets through that pipe is coming from a single unknown client. If multiple operations are done during a "short" time period, I expect to keep the TLS socket connection to the RS open.
@aaronpk : The "session" should not be longer than the TLS socket connection to the RS. Today, in the real world, I connect and authenticate to my bank, I perform some operations and when I am done, I "disconnect". For me, the "session" corresponds to the duration between the successful authentication to my bank and the disconnection (voluntarily done by myself or imposed by the bank in case of inactivity). Once I have been disconnected, the client should close the TLS socket connection.
aaronpk
commented
2 years ago Okay so just to clarify, when you said above:
No, this has nothing to do with TLS.
what exactly do you mean?
I am confused that you seem to both want access tokens to not be bound to TLS sessions while also wanting that to be true.
In your banking example, it is extremely common to have the user sessions exist completely outside the concept of TLS sessions, instead using access tokens to represent sessions. The "logging off" operation can be telling the AS to revoke a particular access token when the session ends.
Denisthemalice
commented
2 years ago Access tokens are transmitted through the TLS channel, but they contain no information related to the TLS session. Access tokens do not "represent sessions".
You wrote:
The "logging off" operation can be telling the AS to revoke a particular access token when the session ends.
When I log off from my Amazon account, do I need to tell such an information to somebody else (e.g. an AS) ? The answer is "no". This is the same when using access tokens. Let us make the life simple. :-)
An addition about Case 1. where I reuse the previous example:
Let us assume that Alice has the two following attributes:
while Bob has has the two following attributes:
If Alice asks for an access token that only contains:
and Bob asks for an access token that only contains:
if they agree to collaborate, they will not be able to combine their attributes to perform an operation on the server managed by the town of Nashville, the access of which is restricted to Nashville residents and if there are over 21.
aaronpk
commented
2 years ago When I log off from my Amazon account, do I need to tell such an information to somebody else (e.g. an AS) ? The answer is "no".
The answer is it depends. There are multiple ways to accomplish this. In one method, the client just deletes any access tokens and session information it maintains. In another method, the client can tell the AS to explicitly revoke certain access tokens. Both of these are common in practice.
if they agree to collaborate, they will not be able to combine their attributes to perform an operation on the server managed by the town of Nashville, the access of which is restricted to Nashville residents and if there are over 21.
This example is the clearest one you've given so far, but now we've lost the idea of the "binding user identifier" as you previously described. Additionally, this system would still benefit from client instances using their own keys since that is preventing an unrelated attack to the issue being discussed here.
Denisthemalice
commented
2 years ago In one method, the client just deletes any access tokens and session information it maintains. In another method, the client can tell the AS to explicitly revoke certain access tokens. Both of these are common in practice.
We can compare the advantages and drawbacks of each method.
This example is the clearest one you've given so far, but now we've lost the idea of the "binding user identifier" as you previously described.
The combination of the two attributes is not possible since each access token will contain a different value for the binding user identifier.
Additionally, this system would still benefit from client instances using their own keys since that is preventing an unrelated attack to the issue being discussed here.
It is difficult to understand what you exactly mean here, since you don't explain what is this "unrelated attack ".
In this thread, at any point of time, client instances keys are not used. In order not to mix issues, I suggest that you open a new issue about "client instances keys" and explain why they are necessary, in addition to the use of "binding user identifiers".
aaronpk
commented
2 years ago The combination of the two attributes is not possible since each access token will contain a different value for the binding user identifier.
I thought in your example that the only claims in the access token were the ones listed, and that a user identifier was not included. If a user identifier is also included then that changes things slightly.
In this thread, at any point of time, client instances keys are not used. In order not to mix issues, I suggest that you open a new issue about "client instances keys" and explain why they are necessary, in addition to the use of "binding user identifiers".
I am not going to open an issue to defend to keep a feature that already exists in the spec of which the benefits are well understood. If you want to argue that this "binding user identifier" makes client instance keys unnecessary the burden is on you to describe why.
Denisthemalice
commented
2 years ago It seems that you now understand the concepts behind the use of this mandatory "binding user identifier" field to be included in every access token.
You claim that _client instances keys are preventing an unrelated attack to the issue being discussed here_.
Would yo be able to explain what is this " unrelated attack to the issue being discussed here" ?
With such a wording, it is hard to guess which kind of attack it can be.
aaronpk
commented
2 years ago It seems that you now understand the concepts behind the use of this mandatory "binding user identifier" field
I am still not clear on what you are actually proposing here. If it is to mandate that certain properties of a user or of an authorization are included in an access token (regardless of whether by reference or by value) then that isn't anything particularly new and is already done in practice by many systems today. It also is something that would not be done in the core draft, since the core is mainly about client-to-AS communication and validating access tokens is something that the RS does.
Denisthemalice
commented
2 years ago I am proposing to add a specific field into the access token, e.g. a bui "Binding User Identifier" field that allows a RS to detect the inappropriate use of an access token by a malicious user, including in the case of collusion between users..
AFAIK, it is new and it is not done in practice today ... unless you can refer to a technical documentation that already describes it .
You wrote:
the core is mainly about client-to-AS communication and validating access tokens is something that the RS does.
The core of the document is supposed to be on the Standards Track. This means that the document should describe a protocol that is both secure and interoperable.
As far as security is concerned, the core document should describe which MINIMUM security checks shall be performed by a RS for the acceptance of an access token. The core document should contain sufficient information on its own to be implementable. This is not the case at this time.
OPTIONAL protocols should be described in the companion document, and among that list of options: "Token Introspection".
Basically, the core document should describe the minimum fields that should be included into an access token,
Additionally, in order to allow a clean separation between "rights" and "attributes", two additional fields should be defined.
PS. You claimed in your previous message that client instances keys are preventing an unrelated attack to the issue being discussed here. Would yo be able to explain here (or preferably in a new issue) what is this " unrelated attack " ?
aaronpk
commented
2 years ago AFAIK, it is new and it is not done in practice today ... unless you can refer to a technical documentation that already describes it .
Here is the section in the OAuth JWT Access Token spec the describes this practice, specifically the "sub" claim: https://datatracker.ietf.org/doc/html/draft-ietf-oauth-access-token-jwt-13#section-2.2
You claimed in your previous message that client instances keys are preventing an unrelated attack to the issue being discussed here.
I left a comment about the other attack in the issue you opened previously asking why client instance keys are necessary: https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/292#issuecomment-888336350
Denisthemalice
commented
2 years ago Thank you for the other comment left in #292.
Although the concepts behind the "sub" claim and the "bui" (binding user identifier) are similar, the "sub" claim as defined and described in RFC 7519 cannot be used.
The "sub" (subject) claim as defined in RFC 7519 is both application specific and OPTIONAL:
The "sub" (subject) claim identifies the principal that is the subject of the JWT. The claims in a JWT are normally statements about the subject. The subject value MUST either be scoped to be locally unique in the context of the issuer or be globally unique. The processing of this claim is generally application specific. The "sub" value is a case-sensitive string containing a StringOrURI value. Use of this claim is OPTIONAL.
In the context we are discussing, the use of the "bui" claim would not be "application specific" and OPTIONAL but would be REQUIRED with a specific treatment to be done on it by the RS which also means that it would not be necessary anymore to rely on private agreements to be done between each AS/RS pair.
In addition, the syntax of the "sub" claim would not be sufficient, since it does not allow a RS to make a difference between :
Whatever we call that field, it seems that we agree that such a field should always be present and thus be mentioned in the core document.
I recall my previous position:
Basically, the core document should describe the minimum fields that should be included into an access token,
- a validity period field that allows the RS to make sure that the access token is during its validity period,
- a second field that allows the RS to verify that the access token is intended for itself,
- a third field (binding user identifier" field) that allows the RS to verify that the access token is associated with the right user and/or the right user account.
Additionally, in order to allow a clean separation between "rights" and "attributes", two additional fields should be defined.
In addition to the description of these five fields, the processing to be done on each of these five fields by a RS should be indicated in the core document. This is the price to pay to get both security and interoperability between a client and a RS.
jricher
commented
2 years ago @Denisthemalice What about when an access token does not represent a user?
aaronpk
commented
2 years ago Whatever we call that field, it seems that we agree that such a field should always be present and thus be mentioned in the core document.
Just to be clear, I haven't agreed to anything. I am trying to understand what you are talking about.
Denisthemalice
commented
2 years ago draft-ietf-gnap-core-protocol-06 mentions:
End-user : natural person that operates a client instance.
and also:
Client : application operated by an end-user
@jricher : You wrote:
What about when an access token does not represent a user?
Given the definition of an end-user, who else would be operating a client instance ?
jricher
commented
2 years ago Those definitions describe the relationship between the entities when both exist, they don't say that they both have to exist every time. The client instance could be acting on its own accord, as shown in the example of section 1.4.4:
And D3:
https://www.ietf.org/archive/id/draft-ietf-gnap-core-protocol-06.html#name-no-user-involvement
Denisthemalice
commented
2 years ago You wrote:
Those definitions describe the relationship between the entities when both exist, they don't say that they both have to exist every time.
Wait a second. I believe that a client always exists. If it exists, that client is an application operated by an end-user. So an end-user necessarily exists. and that end-user operates the client. You cannot twist the wording.
I have worked a long time within standardization committees.
The text underneath a definition section (or a definition clause as called in ISO) needs to be in accordance with these definitions and currently it is not. The text also needs to be "normative". In ISO standards, examples are placed in informative annexes. The current document is filled-up with many examples but is missing to provide an understandable normative overview.
Section 2 is suddenly talking of a "client" field and is not indicating how it relates to user authentication. An access token is delivered to a user, i.e. not to a client application instance known by the AS.
But this conversation is drifting away from the central topic which is :
We need to describe how we can get both security and interoperability between a client and a RS and between a client and an AS .
With the current content of the core document this is not possible.
See again my proposals above that explain how to get both of them.
aaronpk
commented
2 years ago Clients are not always operated by an end user.
I have worked a long time within standardization committees.
These kinds of statements are not helpful to the discussion, please stop. Many of us have worked a long time within standards groups.
Denisthemalice
commented
2 years ago If clients are not always operated by an end-user, then the definition needs to be changed.
IMHO, this kind of statement is helpful to the discussion.
However, this conversation is still drifting away from the central topic which is :
We need to describe how we can get both security and interoperability between a client and a RS and between a client and an AS .
fimbault
commented
2 years ago I've been reading the entire thread, and I've got to say I agree with @aaronpk and @jricher. I don't see how @Denisthemalice 's proposal (which isn't entirely clear to me) solves the issue described.
Denisthemalice
commented
2 years ago For all readers;
Since the time the previous message was sent, many exchanges have been done to explain my proposal. Please take a look at #292.
jricher
commented
2 years ago Addressed in security considerations: https://www.ietf.org/archive/id/draft-ietf-gnap-core-protocol-07.html#name-protection-of-client-instan
On page 11, in step (7) the text states:
This means that checks that would be able to defeat a user collaborative attack are out of the scope of the document. The controls able to defeat such an attack mandate the presence of one or more attributes chosen by the client into an access token.
If such attributes cannot be incorporated into an access token, the inability to defeat user collaborative attacks should be advertised in the security considerations section.