Re: [GNAP] Defense protection
Fabien Imbault <fabien.imbault@gmail.com> Tue, 01 June 2021 14:03 UTC
Return-Path: <fabien.imbault@gmail.com>
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 AFB7B3A1962 for <txauth@ietfa.amsl.com>; Tue, 1 Jun 2021 07:03:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 37zMQQ7IUQZW for <txauth@ietfa.amsl.com>; Tue, 1 Jun 2021 07:03:07 -0700 (PDT)
Received: from mail-il1-x132.google.com (mail-il1-x132.google.com [IPv6:2607:f8b0:4864:20::132]) (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 EE4283A1927 for <txauth@ietf.org>; Tue, 1 Jun 2021 07:03:01 -0700 (PDT)
Received: by mail-il1-x132.google.com with SMTP id c2so12967039ilo.11 for <txauth@ietf.org>; Tue, 01 Jun 2021 07:03:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=A+CcI/liwZ3fVyVK+VjhLI/ca82+zKlk5fc1KQR4Sr8=; b=hF95cLE3gdzQdcJ/Dwdk4XeH6uC09VubVq1Wqgueu1L9ESTHSaMKnFB2zJpCG1AGzI /LPtUPPd7PFTjozg+ces0acqg6MFxqDm7mUoutWrkXKR0xEIyuZQB2vvI/Q9i7ioSvos 7twEXyMXVlbwRDf6VAu4O+msuvshWy5d07qaxy+qaN99llxHUhEB5lrltdPt0MfaBB/o 0SC4L36rsnaz9K+wDxC57d8CyugjDlLtMTpnvtVLjuORizFqHR+A2BgpnI183PhFtcqn AhtiALe8VEb+9whnnoyFrC8yGTwOHh6pJguctpynL7EBHZM6UPHAtqzeKE5yQwApJdW8 Zr1Q==
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=A+CcI/liwZ3fVyVK+VjhLI/ca82+zKlk5fc1KQR4Sr8=; b=TCcmByhJ/aueih1C5gwwgQDblcqbWPMFFyYbjvdTfubwule7S7Qf5ryaWUMvx3vrWB Pn/lsSZFJn5MD5BN5ovyGJgyGHK6FT2jpmIKaCbfw+jwfqCgZrolnNhSA/Zy1h/GI8+W g4aSVNKOgKLAk9scW88sF7+qxFn+kx8IyoBidy0VloaP3ShkSj/m4eVT2/WGn85iBilN fYxWoGK19LX7I249cRdoDsa8Qqhns7clhF5jaycXcKhKT/zaUFMm6kwLaWWPTlzzRiE0 cibtX4L8KeQDh/ghAP8RZazjMScPTrybKjEBFFuhqs7vUaYIKv8+P29DfNMF7tTB6Arf IwCg==
X-Gm-Message-State: AOAM532Zb3nJVHbwdhXGcpGMFrNNS2v/3CTmgWbMcqEk6MCamebjEL/0 pVFNtj36sCWDscwRpL8tS75J+vb+w9BUsKYPcXw=
X-Google-Smtp-Source: ABdhPJzJUHVkK8KWQg/TsORJ/TbgJAChyMOg1u5N1hebeloZbvyyhJD9wWtPgHRdcoJHTs0ihJFZR8Qo6CIGp/w9cus=
X-Received: by 2002:a92:d4c2:: with SMTP id o2mr9366732ilm.123.1622556177618; Tue, 01 Jun 2021 07:02:57 -0700 (PDT)
MIME-Version: 1.0
References: <CAHbuEH49sZjKvE0JVsa39WuFG83FbBcQQAyXH-V8TNGt-b-wtw@mail.gmail.com> <A96FB6BB-E01C-40FD-9F77-126780157F98@mit.edu>
In-Reply-To: <A96FB6BB-E01C-40FD-9F77-126780157F98@mit.edu>
From: Fabien Imbault <fabien.imbault@gmail.com>
Date: Tue, 01 Jun 2021 16:02:46 +0200
Message-ID: <CAM8feuTNA6oOihS+gsP0BADnb-Un16tu713Zwqvgi3WO6fzjqQ@mail.gmail.com>
To: Justin Richer <jricher@mit.edu>
Cc: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>, GNAP Mailing List <txauth@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000985bee05c3b4cccd"
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/qWIS49dqu3eBFC4J4YYwhmktJLg>
Subject: Re: [GNAP] Defense protection
X-BeenThere: txauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: GNAP <txauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/txauth>, <mailto:txauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/txauth/>
List-Post: <mailto:txauth@ietf.org>
List-Help: <mailto:txauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/txauth>, <mailto:txauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 01 Jun 2021 14:03:12 -0000
The most advanced discussion I've seen on private key protection is from the cryptocurrency world, since it's so sensitive (and there have been many such attacks). In practice, you find hardware (ex: ledger, etc.) and software (ex: threshold cryptography, sandboxes such as WASI or lavamoat, etc.) solutions. Fabien On Tue, Jun 1, 2021 at 3:52 PM Justin Richer <jricher@mit.edu> wrote: > 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 > > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth >
- [GNAP] Defense protection Kathleen Moriarty
- Re: [GNAP] Defense protection Adrian Gropper
- Re: [GNAP] Defense protection Kathleen Moriarty
- Re: [GNAP] Defense protection Warren Parad
- Re: [GNAP] Defense protection Adrian Gropper
- Re: [GNAP] Defense protection Kathleen Moriarty
- Re: [GNAP] Defense protection Alan Karp
- Re: [GNAP] Defense protection Cendyne
- Re: [GNAP] Defense protection Fabien Imbault
- Re: [GNAP] Defense protection Justin Richer
- Re: [GNAP] Defense protection Fabien Imbault
- Re: [GNAP] Defense protection Denis