From nobody Fri May 28 13:03:07 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 BAC893A33F8 for ; Fri, 28 May 2021 13:03:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.088 X-Spam-Level: X-Spam-Status: No, score=-2.088 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rhosys.ch 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 ZLdTzg_d-Pfp for ; Fri, 28 May 2021 13:03:00 -0700 (PDT) Received: from mail-yb1-xb2f.google.com (mail-yb1-xb2f.google.com [IPv6:2607:f8b0:4864:20::b2f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4CCB3A33F6 for ; Fri, 28 May 2021 13:03:00 -0700 (PDT) Received: by mail-yb1-xb2f.google.com with SMTP id e10so7092039ybb.7 for ; Fri, 28 May 2021 13:03:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rhosys.ch; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=6na7g4CG1FkHa0/5C2ItfYwdJAnyJu4ckZvlkX+H3Os=; b=AJy4nTo0fnZeKm/OG5vZydTlPNwARh+YJnWrChqPdokjnmQ6UPHRQSpL+NrkC02rtb kZF9Wd/CatV3DWQs+/jcrUx6d4Ok6K6INn4vdRLiuWVZgWXSADYgZhdkggdM3Je+DCwH qJsTNRoj2Eu/M85WhX7EX92oIsWMSnhMtxbMieDEgbbhuQC1thuG4z8tp+gUmWVqAAH7 fj6Hm/w6EMfYdOT2ko44cZYkm1LQ8ln21xWoOGggN6ZvMYFVIv3tZ8hguiR24zcbH0TT RkIWnTpKMYtnV5nMoQbXLRtPYnANW+byvObVOXxNem14X5SeIGSUAXysQZGr9JzAk2ZP qeeA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=6na7g4CG1FkHa0/5C2ItfYwdJAnyJu4ckZvlkX+H3Os=; b=I+YZOBstdcE1UJf+Xj7ADX+JFW5jI/qB3p6N4yB26RCG7uPX1FEGa9WABF+vaoc1e8 1uBfCe1r/EKJ9SLMYYm6NSoNwtfWjH4i1DT6//nMc7sZ8BjuYD5ECHGdJJT4sS7pG3p8 i1nM1oce9vvhkuTU9o5WLSmU4uxXZG44GE+wXhV9byypWWuaDjUHkKVuzkf5lyhpJqnl w8n2QxZfV45Fqjx+q++hUZ5wSVjHhHwAY70bkhnhxtrbl37lSxrxR9fTMlrfAK9N/lpU 0n/OReGpeC1FYjHCxdPU3doWTIX+6qm2Mz+nU/65tKgpokya9AVi4Gup2k3q0OuM12Ex MRUw== X-Gm-Message-State: AOAM533clbA7/QhpVS7TL3VBoqkwpAvhCdK4xY+4BGnaTATMu61Hmauy vB3v+7K1w83WxDjefYlm0Cq7dFC3rNmPwXnxv33B X-Google-Smtp-Source: ABdhPJyA9N4YN5k/+39na+JlO7Oy7yT76Ye4XzV0LGqa0N4M2m1r19VS0C0blMQXoDFls4ZaJ37X3xaO6f9IbTNk1fU= X-Received: by 2002:a25:a003:: with SMTP id x3mr14851194ybh.182.1622232178077; Fri, 28 May 2021 13:02:58 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Warren Parad Date: Fri, 28 May 2021 22:02:47 +0200 Message-ID: To: Kathleen Moriarty Cc: Adrian Gropper , GNAP Mailing List Content-Type: multipart/alternative; boundary="000000000000b7c77205c3695ca1" 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: Fri, 28 May 2021 20:03:06 -0000 --000000000000b7c77205c3695ca1 Content-Type: text/plain; charset="UTF-8" Correct me if I'm mistaken, it sounds like the Golden SAML attack amounts to getting control of the signer's private key. I'm going to go out on a limb here and say, I'm not sure any protocol solution would help solve this problem. But I would love to be mistaken. It's possible to make this harder by allowing multiparty signers to be required (or at least allowed/enabled) to prevent single vulnerable issues. There are other issues with that sort of solution, such as then requiring more nodes to sign each request and thus providing more physical attack surfaces. It's hard for me to evaluate the trade off there. In the case of the OAuth article it seems to suggest, phishing is the problem. The solution here is preventing the user from entering their "password" in malicious locations. I'm hoping that browsers will better support first-class login apis and sanitization for better protection here, however, nothing first comes to mind about what protocol could do to stop that. I would say here, browsers need to get better, device OSs need to be better. Maybe there are better solutions lurking out there. Warren Parad Founder, CTO Secure your user data with IAM authorization as a service. Implement Authress . On Fri, May 28, 2021 at 9:51 PM Kathleen Moriarty < kathleen.moriarty.ietf@gmail.com> wrote: > Hi Adrian, > > Thanks for your interest! > > This is a helpful link that describes how the attackers were able to > bypass MFA by stealing the signing key for SAML assertions: > > https://www.darkreading.com/attacks-breaches/solarwinds-campaign-focuses-attention-on-golden-saml-attack-vector/d/d-id/1339794 > > https://owasp.org/www-chapter-singapore/assets/presos/Deconstructing_the_Solarwinds_Supply_Chain_Attack_and_Deterring_it_Honing_in_on_the_Golden_SAML_Attack_Technique.pdf > > I did read one that was a bit better, but can't find the link at the > moment. > > And one on shared OAuth credentials/token issuance: > > https://www.csoonline.com/article/3607348/how-to-defend-against-oauth-enabled-cloud-based-attacks.html > > It would be good to think about attack vectors and if not prevention, > minimally detection. > > Best regards, > Kathleen > > On Fri, May 28, 2021 at 3:41 PM Adrian Gropper > wrote: > >> Hi Kathleen, >> >> I am not aware of the attacks on SAML and OAuth and would appreciate a >> link or two. >> >> I hope we can provide guidance on how GNAP can facilitate Zero Trust >> Architecture and believe that includes guidance on how to audit various >> things as systems use GNAP protocols to separate concerns among independent >> actors. >> >> Count me in for a brainstorming sessio, >> >> - Adrian >> >> >> On Fri, May 28, 2021 at 3:29 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 >>> >> > > -- > > Best regards, > Kathleen > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --000000000000b7c77205c3695ca1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Correct me if I'm mistaken, it sounds like the Golden = SAML attack amounts to getting control of the signer's private key. I&#= 39;m going to go out on a limb here and say, I'm not sure any protocol = solution would help solve this problem. But I would love to be mistaken. It= 's possible to make this harder by allowing multiparty signers to be re= quired (or at least allowed/enabled) to prevent single vulnerable issues. T= here are other issues with that sort of solution, such as then requiring mo= re nodes to sign each request and thus providing more physical attack surfa= ces. It's hard for me to evaluate the trade off there.

In the case of the OAuth article it seems to suggest, phishing is the pr= oblem. The solution here is preventing the user from entering their "p= assword" in malicious locations. I'm hoping that browsers will bet= ter support first-class login apis and sanitization for better protection h= ere, however, nothing first comes to mind about what protocol could do to s= top that. I would say here, browsers need to get better, device OSs need to= be better. Maybe there are better solutions lurking out there.
<= br clear=3D"all">

Warren Parad

Founde= r, CTO

Secure your user data with IAM authorization as a service. Impleme= nt=C2=A0Authress.


On Fri, May 28, 2021 at 9:51 PM Kathleen Mori= arty <kathleen.moria= rty.ietf@gmail.com> wrote:
Hi Adrian,

Thanks for= your interest!

This is a helpful link that descri= bes how the attackers were able to bypass MFA by stealing the signing key f= or SAML assertions:

I did read on= e that was a bit better, but can't find the link at the moment.

And one on shared OAuth credentials/token issuance:
=

It would be good to think = about attack vectors and if not prevention, minimally detection.
=
Best regards,
Kathleen

On Fri, May 28, 2021= at 3:41 PM Adrian Gropper <agropper@healthurl.com> wrote:
Hi=C2=A0Kathleen,

I am not aware of the att= acks on SAML and OAuth and would appreciate a link or two.

I hope we can provide guidance on how GN= AP can facilitate Zero Trust Architecture and believe that includes guidanc= e on how to audit various things as systems use GNAP protocols to separate = concerns among independent actors.=C2=A0

<= div dir=3D"auto">Count me in for a brainstorming=C2=A0sessio,

- Adrian

<= /div>

On Fri, May 28, 2021 at 3:29 PM Ka= thleen Moriarty <kathleen.moriarty.ietf@gmail.com> wrote:
Hello!
=
In light of recent attacks against SAML and OAuth, I'd l= ike to see what defense mechanisms and detection could be built into the sp= ec.=C2=A0 One example would be from the recent SAML attack.=C2=A0 If there = was a detection of instances of authorization without authentication, the S= AML attack used in SolarWinds might have been detected sooner.
If you think along the lines of fraud detection, where you det= ect unusual events, there may be some specific to GNAP that could enable ea= rly detection of abuse, misuse, or exploits.

Are t= here some planned?=C2=A0 Would people like to brainstorm on this?
Thanks!


= --

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


--

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