[Openid-specs-mobile-profile] Source authentication on client notification endpoint

[Torsten Lodderstedt]

Hi Dave,
> Am 13.11.2017 um 17:29 schrieb Dave Tonge <dave.tonge at momentumft.co.uk>:
> 
> Hi Torsten
> 
> Good question. So the general principle was not relying purely on a bearer token from the OP to the Client. 
> From my perspective the threat model is something like this:
>  - The client_notification_endpoint is only protected by a bearer token
>  - This bearer token could leak which could allow a malicious actor to deliver the wrong access token to the client
>  - For example, a MITM between the OP and the Client could intercept two CIBA notification callbacks and swap the access tokens. The proposal would at least bind the access token to the id token.

TLS server authentication was invented to solve MITM, right? :-)

To me this sounds like the well-known discussion about bearer vs. PoP tokens. Would it be possible to utilize any of the solutions being developed at the OAuth WG (Token Binding, mTLS for OAuth, ...). For a discussion of the attack angle, you may take a look into https://tools.ietf.org/html/draft-ietf-oauth-security-topics-04#section-4.7 <https://tools.ietf.org/html/draft-ietf-oauth-security-topics-04#section-4.7>. Just change the roles and make the CIBA RP the RS and the CIBA OP the client.

Best regards,
Torsten.

> 
> To fully prevent the above attack the auth_req_id (or a hash of it should probably also be included in the id_token).
> 
> John or Nat may have a view on this as well?
> 
> Dave
> 
> On 12 November 2017 at 04:01, Torsten Lodderstedt <torsten at lodderstedt.net <mailto:torsten at lodderstedt.net>> wrote:
> Hi Dave,
> 
>> Am 07.11.2017 um 00:35 schrieb Dave Tonge <dave.tonge at momentumft.co.uk <mailto:dave.tonge at momentumft.co.uk>>:
>> 
>> he token response sent to this endpoint has an id_token. We suggested that this id_token should include an `at_hash`. This will give the client greater assurance that the token response is from the OpenID Provider and of the integrity of the payload. 
> 
> can you elaborate on the threat model underpinning this decision? 
> 
> best regards,
> Torsten.
> 
> 
> 
> 
> -- 
> Dave Tonge
> CTO
>  <http://www.google.com/url?q=http%3A%2F%2Fmoneyhubenterprise.com%2F&sa=D&sntz=1&usg=AFQjCNGUnR5opJv5S1uZOVg8aISwPKAv3A>
> 10 Temple Back, Bristol, BS1 6FL
> t: +44 (0)117 280 5120
> 
> Moneyhub Enterprise is a trading style of Momentum Financial Technology Limited which is authorised and regulated by the Financial Conduct Authority ("FCA"). Momentum Financial Technology is entered on the Financial Services Register (FRN 561538) at fca.org.uk/register <http://fca.org.uk/register>. Momentum Financial Technology is registered in England & Wales, company registration number 06909772 © . Momentum Financial Technology Limited 2016. DISCLAIMER: This email (including any attachments) is subject to copyright, and the information in it is confidential. Use of this email or of any information in it other than by the addressee is unauthorised and unlawful. Whilst reasonable efforts are made to ensure that any attachments are virus-free, it is the recipient's sole responsibility to scan all attachments for viruses. All calls and emails to and from this company may be monitored and recorded for legitimate purposes relating to this company's business. Any opinions expressed in this email (or in any attachments) are those of the author and do not necessarily represent the opinions of Momentum Financial Technology Limited or of any other group company.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-mobile-profile/attachments/20171114/6f1ebb79/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3581 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-mobile-profile/attachments/20171114/6f1ebb79/attachment.p7s>