From nobody Tue Jun 1 07:08:00 2021 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 652983A1932 for ; Tue, 1 Jun 2021 07:07:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.115 X-Spam-Level: X-Spam-Status: No, score=-1.115 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id inNAHiP3CXDN for ; Tue, 1 Jun 2021 07:07:53 -0700 (PDT) Received: from smtp.smtpout.orange.fr (smtp13.smtpout.orange.fr [80.12.242.135]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E350C3A191A for ; Tue, 1 Jun 2021 07:07:52 -0700 (PDT) Received: from [192.168.1.11] ([90.26.94.159]) by mwinf5d56 with ME id Bq7p2500A3SJSnu03q7prb; Tue, 01 Jun 2021 16:07:50 +0200 X-ME-Helo: [192.168.1.11] X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg== X-ME-Date: Tue, 01 Jun 2021 16:07:50 +0200 X-ME-IP: 90.26.94.159 To: Justin Richer , Kathleen Moriarty Cc: GNAP Mailing List References: From: Denis Message-ID: <96f15047-29d6-486c-a696-6745ab86580a@free.fr> Date: Tue, 1 Jun 2021 16:07:46 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------78721411DE55F9F31B04C98E" Content-Language: en-GB Archived-At: Subject: Re: [GNAP] Defense protection X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jun 2021 14:07:59 -0000 This is a multi-part message in MIME format. --------------78721411DE55F9F31B04C98E Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi Kathleen, Thank you for your mail. I do appreciate the following sentence that you wrote: It would be good to think about attack vectors and if not prevention, minimally detection. Unfortunately, at this stage, the current documents still do not describe the trust relationships between the various components of the system. The issue about trust relationships#214 is still open: https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/214 The document does not describe the error codes that should be returned by the various component either. The issue about" The access token verifications to be performed by the RS should be described #30" available at: https://github.com/ietf-wg-gnap/gnap-resource-servers/issues/30 has been recently opened. The issue about  Requesting resources with insufficient access #203 has been closed without the definition of the error codes: https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/203 Since access tokens are, for the time being, considered to be opaque to the clients/end-users and subject to private agreements between ASs and RSs this makes hard or impossible to perform a security analysis under these conditions. Nevertheless, I have indicated to the WG, when two users accept to collide against a RS, the possibility to transmit an access token from an authorized user to an unauthorized user. This may happen even under the "assumption that private keys can be secured, by whatever means". In such a case, prevention is impossible, but detection is possible (as you said "if not prevention, minimally detection"). I have presented the case at he last IETF meeting on March, the 9 th , 2021. The title of the presentation was: GNAP model & trust relationships Privacy considerations & Security considerations These slides are available at: https://datatracker.ietf.org/meeting/110/materials/slides-110-gnap-gnap-model-and-trust-relationships-00 Slide 10 is about : Unlinkability between RS user accounts versus Client collaboration attacks. It indicates:       if an access token only contains one or more capabilities, client collaboration attacks will succeed.       In order to defeat client collaboration attacks, the access token must also contain a type (1), (2) or (3) end-user identifier. Note that is an answer somewhat related to the question just raised by Justin: "I don’t know if there’s anything that can be done around protecting against key theft". Last comment: Security is certainly important, but the user's privacy is equally important. At the current time,Unlinkability #241 https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/241 attempts to address a part of the problem. However, unfortunately, the current trend is to think about the user's privacy once the design will be finished instead of thinking about privacy before the starting the design or even during the design. At the current time, all the properties that would allow an AS to act as *Big Brother* have been defined (and none to stop it). Best regards, Denis > Hi Kathleen, thanks so much for raising this topic! It’s important > that GNAP learn from what’s come before. Some aspects of that are > already built into the design, based on what we’ve learned form years > of OIDC and SAML deployments. One of the things that made the SAML > attacks work was that the fake assertions could be easily injected > into SP’s (the relying party equivalent) with a browser request by the > attackers. GNAP already doesn’t allow injection of results (such as > assertions) over the front channel, so an attacker would need to run > an in-the-middle attack against the AS and return the faulty assertion > as well. Properly configured OIDC (with state and nonce) has some > similar protections, but even then it’s more easily misconfigured. I > agree that the detection of unusual events needs to be part of the > protocol. Maybe we should have more language about the direct > information return — things like assertions and subject information — > and explicitly tell clients that they shouldn’t accept that > information from unexpected calls of any type? We might also want to > lock down the callback function from extensions so that people don’t > re-invent the implicit flow and all its problems. I don’t know if > there’s anything that can be done around protecting against key theft. > The key is the identity of the component proven through the protocol. > Do you have suggestions on how this can be called out more? The > security considerations section is just a placeholder still, and it > seems that would be a good place for it, to me. — Justin >> On May 28, 2021, at 3:28 PM, Kathleen Moriarty >> wrote: Hello! In light of recent >> attacks against SAML and OAuth, I'd like to see what defense >> mechanisms and detection could be built into the spec. One example >> would be from the recent SAML attack. If there was a detection of >> instances of authorization without authentication, the SAML attack >> used in SolarWinds might have been detected sooner. If you think >> along the lines of fraud detection, where you detect unusual events, >> there may be some specific to GNAP that could enable early detection >> of abuse, misuse, or exploits. Are there some planned? Would people >> like to brainstorm on this? Thanks! -- Best regards, Kathleen -- >> TXAuth mailing list TXAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth --------------78721411DE55F9F31B04C98E Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hi Kathleen,
Thank you for your mail. I do appreciate the following sentence that you wrote:

         It would be good to think about attack vectors and if not prevention, minimally detection.
Unfortunately, at this stage, the current documents still do not describe the trust relationships between the various components of the system.
The issue about trust relationships#214 is still open: https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/214
The document does not describe the error codes that should be returned by the various component either.
The issue about" The access token verifications to be performed by the RS should be described #30" available at:
 https://github.com/ietf-wg-gnap/gnap-resource-servers/issues/30 has been recently opened.
The issue about  Requesting resources with insufficient access #203 has been closed without the definition of the error codes:
https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/203
Since access tokens are, for the time being, considered to be opaque to the clients/end-users and subject to private agreements between ASs and RSs
this makes hard or impossible to perform a security analysis under these conditions.

Nevertheless, I have indicated to the WG, when two users accept to collide against a RS, the possibility to transmit an access token from an authorized user
to an unauthorized user. This may happen even under the "assumption that private keys can be secured, by whatever means". In such a case, prevention
is impossible, but detection is possible (as you said "if not prevention, minimally detection").
I have presented the case at he last IETF meeting on March, the 9 th , 2021. The title of the presentation was:
GNAP model & trust relationships Privacy considerations & Security considerations
 These slides are available at: https://datatracker.ietf.org/meeting/110/materials/slides-110-gnap-gnap-model-and-trust-relationships-00
Slide 10 is about : Unlinkability between RS user accounts versus Client collaboration attacks. It indicates:

      if an access token only contains one or more capabilities, client collaboration attacks will succeed. 
      In order to defeat client collaboration attacks, the access token must also contain a type (1), (2) or (3) end-user identifier.

Note that is an answer somewhat related to the question just raised by Justin: "I don’t know if there’s anything that can be done around protecting against key theft".

Last comment: Security is certainly important, but the user's privacy is equally important. At the current time, Unlinkability #241
https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/241 attempts to address a part of the problem.

However, unfortunately, the current trend is to think about the user's privacy once the design will be finished instead of thinking about privacy before
the starting the design or even during the design. At the current time, all the properties that would allow an AS to act as Big Brother have been defined
(and none to stop it).

Best regards,
Denis


Hi Kathleen, thanks so much for raising this topic! It’s important that GNAP learn from what’s come before.

Some aspects of that are already built into the design, based on what we’ve learned form years of OIDC and SAML deployments. One of the things that made the SAML attacks work was that the fake assertions could be easily injected into SP’s (the relying party equivalent) with a browser request by the attackers. GNAP already doesn’t allow injection of results (such as assertions) over the front channel, so an attacker would need to run an in-the-middle attack against the AS and return the faulty assertion as well. Properly configured OIDC (with state and nonce) has some similar protections, but even then it’s more easily misconfigured.

I agree that the detection of unusual events needs to be part of the protocol. Maybe we should have more language about the direct information return — things like assertions and subject information — and explicitly tell clients that they shouldn’t accept that information from unexpected calls of any type? We might also want to lock down the callback function from extensions so that people don’t re-invent the implicit flow and all its problems.

I don’t know if there’s anything that can be done around protecting against key theft. The key is the identity of the component proven through the protocol. Do you have suggestions on how this can be called out more? The security considerations section is just a placeholder still, and it seems that would be a good place for it, to me.

 — Justin


On May 28, 2021, at 3:28 PM, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> wrote:

Hello!

In light of recent attacks against SAML and OAuth, I'd like to see what defense mechanisms and detection could be built into the spec.  One example would be from the recent SAML attack.  If there was a detection of instances of authorization without authentication, the SAML attack used in SolarWinds might have been detected sooner.

If you think along the lines of fraud detection, where you detect unusual events, there may be some specific to GNAP that could enable early detection of abuse, misuse, or exploits.

Are there some planned?  Would people like to brainstorm on this?
Thanks!

-- 

Best regards,
Kathleen
-- 
TXAuth mailing list
TXAuth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth


--------------78721411DE55F9F31B04C98E--