[Openid-specs-mobile-profile] Async authentication with polling and callback

Tue Dec 27 16:39:52 UTC 2016

Sorry just catching up on this thread.

I agree with Torsten’s concern regarding 2 not needing server authentication.
With a browser redirect you are protected by the session the RP has with the browser.

With the backchannel approaches any server can post to the RP endpoint directly. 
If the RP gets a arbitrary URI to poll that could be one from a bad guys server.

There is a bunch of state that needs to be stored on both sides of the conversation and potentially allowing a unauthenticated party into that can cause unanticipated issues, as we have seen elsewhere in OAuth.

I like the ideas in general, but security reviews are need.

John B.

> On Dec 27, 2016, at 12:57 PM, Torsten Lodderstedt <torsten at lodderstedt.net> wrote:
> 
> Hi Petteri,
> 
> as promised during the last WG call, please find below my detailed feedback on your proposal:
> 
> Your proposal consists of two distinct contributions: 
> (1) a generic http level mechanism to control client/server interaction using standard HTTP status codes
> (2) a pattern to turn push-style into pull-style data retrival
> 
> I think the WG needs more concrete examples to understand the nature and benefits of those contributions. I suggest to treat them separately since they can be discussed and potentially adopted independently.
> 
> Regarding (1) I would suggest you to provide an example of how UQ or CIBA could be represented.
> 
> Regarding (2) I suggest you to provide the WG with a concrete example for CIBA (since this was the subject of the discussion where you made this proposal for the first time). In order to facilitate comparability, I would propose you do so based on the the application leven control mechanism as defined in the CIBA spec (incl. fetching the tokens from the token endpoint). Moreover, there is the need for a threat analysis of this flow. You state your proposal will remove the need to authenticate the caller (OP/AS). I'm not convinsed since any attacker could obviously call (flood) the clients notification endpoint and cause the client to send any opaque value to the OP/AS. Don't you think this must be prevented? 
> 
> and indeed, such an analysis must be conducted for the proposal defined in the CIBA spec as well!
> 
> best regards,
> Torsten.
> 
> Am 07.12.2016 um 10:15 schrieb Petteri Stenius:
>> Hi Torsten.
>>  
>> You are right, it is better not to mix the modes of the endpoints.
>>  
>> Petteri
>>   <>
>> From: Torsten Lodderstedt [mailto:torsten at lodderstedt.net <mailto:torsten at lodderstedt.net>] 
>> Sent: maanantaina 5. joulukuuta 2016 22.33
>> To: Petteri Stenius <Petteri.Stenius at ubisecure.com> <mailto:Petteri.Stenius at ubisecure.com>
>> Cc: openid-specs-mobile-profile at lists.openid.net <mailto:openid-specs-mobile-profile at lists.openid.net>
>> Subject: Re: [Openid-specs-mobile-profile] Async authentication with polling and callback
>>  
>> Hi,
>>  
>> Am 05.12.2016 um 13:18 schrieb Petteri Stenius:
>> Hi,
>>  
>> Registration of endpoints is an application level issue, not part of the generalized http level mechanism.
>> 
>> but it somehow intervenes with the generic http level mechanism, so the generic http part is not self-explanatory.
>> 
>> 
>>  
>> With OAuth/OIDC we should follow the convention of registering endpoints with client registration and provider metadata.
>>  
>> The UQ draft defines a new client registration value “client_notification_endpoint” for the callback, but would it not be possible to use “redirect_uris” for this purpose?
>> 
>> Do you think this is a good idea to mix the two different modes? The rules for processing a conventional redirect (XSRF, referrer header, session state/cookies) are different from receiving a server2server callback (e.g. IP address black/whitelisting). I would prefer to keep them separate.
>> 
>> 
>>  
>> The client callback endpoint is an entry in the redirect_uris array of client registration metadata. With a parameter of the request that starts async authentication client indicates at which of the registered endpoints it wishes to receive the async callback. This is comparable to authorization code request.
>>  
>>  
>> Petteri
>>  
>> 
>> best regards,
>> Torsten.
>> 
>>  
>> From: Torsten Lodderstedt <torsten at lodderstedt.net> <mailto:torsten at lodderstedt.net>
>> Sent: Saturday, December 3, 2016 10:50:10 AM
>> To: Petteri Stenius
>> Cc: openid-specs-mobile-profile at lists.openid.net <mailto:openid-specs-mobile-profile at lists.openid.net>
>> Subject: Re: [Openid-specs-mobile-profile] Async authentication with polling and callback
>>  
>> Hi Petteri,
>>  
>> thanks for your proposal.
>>  
>> One question popped up when I read the sequence for the callback case: how does the server know where to send the callback in step 3?
>>  
>> best regards,
>> Torsten.
>> 
>> Am 01.12.2016 um 16:58 schrieb Petteri Stenius <Petteri.Stenius at ubisecure.com <mailto:Petteri.Stenius at ubisecure.com>>:
>> 
>> Hello everybody
>>  
>> At the Paris meeting in September there was some discussion about polling and callback mechanisms related to asynchronous functions.
>>  
>> These mechanisms exist in both UQ and SIBA draft specifications. Polling is also defined in OAuth Device Flow draft.
>>  
>> This proposal is an attempt to generalize async polling and callback mechanisms:
>>  
>> ·         Define polling on the http level, not an application level function
>> ·         Callback is only a simple notification request, a client initiated request is required to fetch the actual content
>>  
>> The two proposals work together, and make for example switching between polling and callback mechanisms very easy.
>>  
>> Thanks,
>> Petteri
>>  
>>  
>> Polling defined on the http level
>>  
>> Define mechanism with HTTP 303 redirect and Retry-After response header.
>>  
>> 303 redirect is used to define polling as sequence of http redirects the client follows until async operation completes and response appears.
>> The client MUST wait time indicated by Retry-After header before following a redirect. Failing to do so would result in 503 Service Unavailable error (with Retry-After header).
>> Semantics is comparable to "Wait a moment, the response will soon appear at this location"
>>  
>> The server is allowed to implement "long polling" by holding a response up to 30 seconds (seehttps://tools.ietf.org/html/rfc6202#section-5.5 <https://tools.ietf.org/html/rfc6202#section-5.5>)
>>  
>> Example of polling sequence:
>>  
>> 1.       Client begins async operation
>>  
>> POST /begin-async-operation HTTP/1.1
>>  
>> 2.       Server response with 303 status indicates client must begin polling for response. Server encodes state into querystring of redirect uri
>>  
>> HTTP/1.1 303 See Other
>> Location: /async-response?opaque-server-state-1
>> Retry-After: 10
>>  
>> 3.       Client waits at least 10 seconds before following the redirect
>>  
>> GET /async-response?opaque-server-state-1 HTTP/1.1
>>  
>> 4.       Server response with new uri where querystring has changed
>>  
>> HTTP/1.1 303 See Other
>> Location: /async-response?opaque-server-state-2
>> Retry-After: 10
>>  
>> 5.       Client again waits before following the redirect
>>  
>> GET /async-response?opaque-server-state-2 HTTP/1.1
>>  
>> 6.       Server response with content when async operation has completed
>>  
>> HTTP/1.1 200 OK
>>  
>> "completed"
>>  
>>  
>> Callback is a simple notification request
>>  
>> My proposal for callback mechanism is a simple notification request.
>> Server encodes any state it needs into querystring of the notification request.
>> For the client the querysring is opaque and the client must pass it as-is when fetching the actual content from the server.
>> Using a simple notification request removes the requirement for client to authenticate the callback request from server.
>>  
>> Example of callback sequence:
>>  
>> 1.       Client begins async operation
>>  
>> POST /begin-async-operation HTTP/1.1
>>  
>> 2.       Server response with 202 status indicates client needs to wait for callback
>>  
>> HTTP/1.1 202 Accepted
>>  
>> 3.       When async operation completes server sends a notification request to client. Server encodes state into querystring of notification uri
>>  
>> GET /callback?opaque-server-state-3 HTTP/1.1
>>  
>> 4.       Client response is not processed by server
>>  
>> HTTP/1.1 204 No Content
>>  
>> 5.       Client creates request uri and fetches content from server
>>  
>> GET /async-response?opaque-server-state-3 HTTP/1.1
>>  
>> 6.       Server response with content
>>  
>> HTTP/1.1 200 OK
>>  
>> "completed"
>>  
>>  
>>  
>> Related discussion
>>  
>> [Openid-specs-mobile-profile] Async authentication
>> http://lists.openid.net/pipermail/openid-specs-mobile-profile/Week-of-Mon-20161010/000615.html <http://lists.openid.net/pipermail/openid-specs-mobile-profile/Week-of-Mon-20161010/000615.html>
>>  
>> [OAUTH-WG] polling in the device flow
>> https://www.ietf.org/mail-archive/web/oauth/current/msg02939.html <https://www.ietf.org/mail-archive/web/oauth/current/msg02939.html>
>>  
>> [OAUTH-WG] Device Flow: Alternative to Polling
>> https://www.ietf.org/mail-archive/web/oauth/current/msg16723.html <https://www.ietf.org/mail-archive/web/oauth/current/msg16723.html>
>>  
>> References
>>  
>> OAuth 2.0 Device Flow
>> https://tools.ietf.org/html/draft-ietf-oauth-device-flow-03 <https://tools.ietf.org/html/draft-ietf-oauth-device-flow-03>
>>  
>> HTTP/1.1 Semantics and Content
>> https://tools.ietf.org/html/rfc7231 <https://tools.ietf.org/html/rfc7231>
>>  
>> Retry-After
>> https://tools.ietf.org/html/rfc7231#section-7.1.3 <https://tools.ietf.org/html/rfc7231#section-7.1.3>
>>  
>> Best Practices for the Use of Long Polling
>> https://tools.ietf.org/html/rfc6202 <https://tools.ietf.org/html/rfc6202>
>>  
>>  
>> _______________________________________________
>> Openid-specs-mobile-profile mailing list
>> Openid-specs-mobile-profile at lists.openid.net <mailto:Openid-specs-mobile-profile at lists.openid.net>
>> http://lists.openid.net/mailman/listinfo/openid-specs-mobile-profile <http://lists.openid.net/mailman/listinfo/openid-specs-mobile-profile>
>>  
> 
> _______________________________________________
> Openid-specs-mobile-profile mailing list
> Openid-specs-mobile-profile at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-mobile-profile

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-mobile-profile/attachments/20161227/58e08ced/attachment-0001.html>