Draft: draft-ietf-gnap-core-protocol

Commentary: Deploy Preview for gnap - core - protocol - editors - draft ready ! Explore the source changes : Inspect the deploy log : Browse the preview : 
 I am not sure to what extent this The attack may be less of a problem if the honest client instance only serves a single user , since the attack is more difficult to implement in that scenario , but the attack should also be possible when using mobile applications , for example . I miss a warning about this attack , for the combinations of interaction modes where the attack described in is possible . Since this attack is ultimately still a type of phishing attack that can be prevented by an informed user , one could also refer to Section 12.13 . " Client Instance Impersonation " in this context , since here , too , the attack can possibly be prevented by the AS providing helpful information about the client instance to the user during the login . 
 This issue is related to issue . When not using the redirect interaction start mode together with the redirect interaction finish mode , depending on how exactly issue is dealt with , the following attack may be possible : ! We assume that an honest end user wants to start a grant with a client instance controlled by an attacker and using an honest AS . In the role of an end user , the attacker then replays this request to an honest client instance using the same AS . The honest client instance then sends a grant request to the honest AS and receives a grant response with a user code . The honest client instance then forwards / shows this user code to the attacker , who in turn passes it on to the honest end user . The honest end user navigates to the user code interaction URI of the AS , authenticates herself , enters the user code and then has to authorize the request of the client instance . Since this request comes from the honest client instance and not the client instance controlled by the attacker , the end user could notice that something is wrong based on the information shown to her by the AS . However , assuming that every end user is informed enough to prevent the attack at this point is known to be unrealistic . If the end user authorizes the request , the interaction will be completed successfully and the honest client instance will receive an access token , for example . The attacker can now use the honest client instance with an access token that was issued for the honest end user and with the privileges of the honest client instance . This attack fails when using the redirect interaction start mode and the redirect interaction finish mode if the honest client instance checks after the interaction that the same end user is " present " : ! We assume here that the honest client instance ensures that the same end user is present by storing a session ID as a cookie in the end user 's browser . During the first redirect from the client instance to the AS , the attacker can theoretically set the same session ID as the honest client instance , but this would not be of any use for the attacker . With the first redirect , the honest end user is forwarded by the attacker , while with the second redirect she is forwarded by the AS to the honest client instance . The attacker can only set a cookie for his own domain in the first redirect , which means that a session ID set by the attacker is not sent to the honest client instance in the second redirect because the honest client instance uses a different domain than the attacker . Note that in this scenario , the attack could be prevented by the AS already after the first redirect , if the AS would check the Referer header . Since the domain of the attacker 's client instance is specified in the Referer header and not the domain of the honest client instance , the AS can reject . However , this is only possible if redirects are actually used . If , for example , a local client instance installed on the end user 's device starts a browser with the interaction URI , no Referer header will be sent to the AS . It should also be mentioned that for this attack to work , the honest end user does not necessarily have to start a grant with the client instance controlled by the attacker . As seen in the session on during the OAuth Security Workshop , the attacker can also start a flow with the honest client instance on its own . The attacker can then , for example , display the interaction URI as a QR code and somehow get an honest end user to scan this QR code . Since the QR code forwards the end user to an honest AS , the end user is inclined to authorize the request at the AS . 
 Thanks for the extensive writeups and diagrams . This points out what I think are the inherent risks in multi - device setups . What the editors plan to do for ( and ) is have new security considerations and examples that talk about the combinations of start / finish methods where the kinds of session - based mitigations you describe are actually possible , and warn for the cases where they are not . 
 states that when using the redirect interaction finish mode . Perhaps this could be elaborated a bit further . I assume this means that if the redirect interaction start mode is used together with the redirect interaction finish mode , the client instance must validate session information as mentioned in , e.g. using a session identifier that is sent as a cookie . But how should the wording in Section 2.5.2.1 be interpreted if a different interaction start mode is used ? When using the user code interaction start mode , for example , the interaction normally takes place on a different device , so cookies can not be used for this validation . 
 Related to 
 This is more of a security consideration , so we will remove the normative requirements here and have a wider discussion about the different combinations and deployments and what these all mean for making sure the user is " there " in the different circumstances . 
 Yaron : 2.5.3.1 : what does " RQ is present on the request " mean ?  : This is most clear for web server based RC ’s : the session that was used to send the user outbound needs to be the same that is used when the return comes in . It makes less sense with other interaction methods and other client types , but wherever possible the RC needs to make sure that the user who started the request is “ still there ” when the response comes back in the front channel . Is there a better way to say this without making it overly prescriptive ? Yaron : I tried and failed to reword it . But since this is a MUST , we should actually make it prescriptive .
Paragraph (version A):
Since the incoming request to the callback URI is from the RO's
browser, this method is usually used when the RO and end user are the
same entity.  As such, the client instance MUST ensure the end user
is present on the request to prevent substitution attacks.
Paragraph (version A):
See security-front-channel for more considerations regarding the use
of front-channel communication techniques such as this.
Paragraph (version B):
Since the incoming request to the callback URI is from the RO's
browser, this method is usually used when the RO and end user are the
same entity.  See security-sessions for considerations on ensuring
the incoming HTTP message matches the expected context of the
request.  See security-front-channel for more considerations
regarding the use of front-channel communication techniques such as
this.
Paragraph (version A):
Since the incoming request to the callback URI is from the AS and not
from the RO's browser, the client instance MUST NOT require the end
user to be present on the incoming HTTP request.
Paragraph (version B):
Since the incoming request to the callback URI is from the AS and not
from the RO's browser, this request is not expected to have any
shared session information from the start method.  See security-
sessions and security-polling for more considerations regarding the
use of back-channel and polling mechanisms like this.
Paragraph (version B):
When using an interaction finish method such as "redirect" or "push",
the client instance receives an unsolicited HTTP request from an
unknown party.  The client instance needs to be able to successfully
associate this incoming request with a specific pending grant request
being managed by the client instance.  If the client instance is not
careful and precise about this, an attacker could associate their own
session at the client instance with a stolen interaction response.
The means of preventing this varies by the type of client software
and interaction methods in use.  Some common patterns are enumerated
here.
Paragraph (version B):
If the end user interacts with the client instance through a web
browser and the "redirect" interaction finish method is used, the
client instance can ensure that the incoming HTTP request from the
finish method is presented in the same browser session that the grant
request was started in.  This technique is particularly useful when
the "redirect" interaction start mode is used as well, since in many
cases the end user will follow the redirection with the same browser
that they are using to interact with the client instance.  The client
instance can then store the relevant pending grant information in the
session, either in the browser storage directly (such as with a
single-page application) or in an associated session store on a back-
end server.  In both cases, when the incoming request reaches the
client instance, the session information can be used to ensure that
the same party that started the request is present as the request
finishes.
Paragraph (version B):
Ensuring that the same party that started a request is present when
that request finishes can prevent phishing attacks, where an attacker
starts a request at an honest client instance and tricks an honest RO
into authorizing it.  For example, if an honest end user (that also
acts as the RO) wants to start a request through a client instance
controlled by the attacker, the attacker can start a request at an
honest client instance and then redirect the honest end user to the
interaction URI from the attackers session with the honest client
instance.  If the honest end user then fails to realize that it is
not authorizing the attacker-controlled client instance (with which
it started its request) but the honest client instance when
interacting with the AS, the attacker's session with the honest
client instance would be authorized.  This would give the attacker
access to the honest end user's resources that the honest client
instance is authorized to access.  However, if after the interaction
the AS redirects the honest end user back to the client instance
whose grant request the end user just authorized, the honest end user
is redirected to the honest client instance.  The honest client
instance can then detect that it is not the party that started the
request that is present, since the request at the honest client
instance was started by the attacker, which can prevent the attack.
This is related to security-impersonation, because again the attack
can be prevented by the AS informing the user as much as possible
about the client instance that is to be authorized.
Paragraph (version B):
If the end user does not interact with the client instance through a
web browser or the interaction start method does not use the same
browser or device that the end user is interacting through (such as
the launch of a second device through a scannable code or
presentation of a user code) the client instance will not be able to
strongly associate an incoming HTTP request with an established
session with the end user.  This is also true when the "push"
interaction finish method is used, since the HTTP request comes
directly from the interaction component of the AS.  In these
circumstances, the client instance can at least ensure that the
incoming HTTP request can be uniquely associated with an ongoing
grant request by making the interaction finish callback URI unique
for the grant when making the request-interact-finish.  Mobile
applications and other client instances that generally serve only a
single end user at a time can use this unique incoming URL to
differentiate between a legitimate incoming request and an attacker's
stolen request.
Paragraph (version B):
If the client instance does not have the ability to use an
interaction finish method, it can use polling to continue the
request.  The tradeoffs of this approach are discussed in security-
polling, and if possible, an explicit interaction finish method
should be used instead.