Re: [Ace] Fwd: New Version Notification for draft-ietf-ace-oauth-authz-17.txt and draft-ietf-ace-oauth-params-01.txt
Ludwig Seitz <ludwig.seitz@ri.se> Wed, 12 December 2018 10:04 UTC
Return-Path: <ludwig.seitz@ri.se>
X-Original-To: ace@ietfa.amsl.com
Delivered-To: ace@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BED812F295 for <ace@ietfa.amsl.com>; Wed, 12 Dec 2018 02:04:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 ldKHEyCfmamM for <ace@ietfa.amsl.com>; Wed, 12 Dec 2018 02:04:25 -0800 (PST)
Received: from smtp-out11.electric.net (smtp-out11.electric.net [185.38.181.38]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B993F12777C for <ace@ietf.org>; Wed, 12 Dec 2018 02:04:25 -0800 (PST)
Received: from 1gX1NN-0002uW-TH by out11a.electric.net with emc1-ok (Exim 4.90_1) (envelope-from <ludwig.seitz@ri.se>) id 1gX1NN-0002w3-Ua; Wed, 12 Dec 2018 02:04:21 -0800
Received: by emcmailer; Wed, 12 Dec 2018 02:04:21 -0800
Received: from [194.218.146.197] (helo=sp-mail-2.sp.se) by out11a.electric.net with esmtps (TLSv1.2:ECDHE-RSA-AES128-SHA256:128) (Exim 4.90_1) (envelope-from <ludwig.seitz@ri.se>) id 1gX1NN-0002uW-TH; Wed, 12 Dec 2018 02:04:21 -0800
Received: from [192.168.0.166] (10.116.0.226) by sp-mail-2.sp.se (10.100.0.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1531.3; Wed, 12 Dec 2018 11:04:20 +0100
To: Stefanie Gerdes <gerdes@tzi.de>, Jim Schaad <ietf@augustcellars.com>, ace@ietf.org
References: <154322421294.8323.8505315870685563404.idtracker@ietfa.amsl.com> <cbd083d1-cb95-0732-aa8b-7c7de3f480d1@ri.se> <a0cdd836-7fe3-339e-0c48-961503857447@tzi.de> <03b601d49191$7d1bb400$77531c00$@augustcellars.com> <2778adbc-a453-f9bf-b8b8-2e23bafd5da2@tzi.de>
From: Ludwig Seitz <ludwig.seitz@ri.se>
Message-ID: <b17225d2-087c-04ac-8790-1f954251cf07@ri.se>
Date: Wed, 12 Dec 2018 11:04:20 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1
MIME-Version: 1.0
In-Reply-To: <2778adbc-a453-f9bf-b8b8-2e23bafd5da2@tzi.de>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-Originating-IP: [10.116.0.226]
X-ClientProxiedBy: sp-mail-1.sp.se (10.100.0.161) To sp-mail-2.sp.se (10.100.0.162)
X-Outbound-IP: 194.218.146.197
X-Env-From: ludwig.seitz@ri.se
X-Proto: esmtps
X-Revdns:
X-HELO: sp-mail-2.sp.se
X-TLS: TLSv1.2:ECDHE-RSA-AES128-SHA256:128
X-Authenticated_ID:
X-PolicySMART: 14510320
X-Virus-Status: Scanned by VirusSMART (c)
X-Virus-Status: Scanned by VirusSMART (s)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/Fitl8XmrQOf1lWfhH_7rrTdslm4>
Subject: Re: [Ace] Fwd: New Version Notification for draft-ietf-ace-oauth-authz-17.txt and draft-ietf-ace-oauth-params-01.txt
X-BeenThere: ace@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" <ace.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ace>, <mailto:ace-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ace/>
List-Post: <mailto:ace@ietf.org>
List-Help: <mailto:ace-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ace>, <mailto:ace-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 12 Dec 2018 10:04:29 -0000
On 12/12/2018 10:27, Stefanie Gerdes wrote: > Hi Jim, > > thank you for your quick response. > > On 12/11/2018 09:38 PM, Jim Schaad wrote: >>> >>> C may receive keying material for the communication with RS from AS. >>> Unfortunately, the AS does not inform C how long the keying material is >> valid. C >>> therefore may use outdated keying material for the communication. C cannot >>> rely on RS to reject messages that were sent with outdated keying material >>> because 1. the information in the request sent by C may be confidential >> and is >>> then compromised and 2. C cannot be sure that it is actually communicating >>> with the intended RS if the keying material is no longer valid. >> >> Would you feel that this would be eased by requiring the expires_in field to >> be required as part of the response? It is the expiration of the token, but >> I have never understood the difference between the expiration of the token >> and the expiration of keying material myself. Keying material never >> expires, you just cannot use it without a valid token. > > As long as it is clear that the expires_in field describes the time > until the keying material expires, this is at least better than nothing, > although it leaves the problem that the client does not know when the > token was created and how much time has already passed since then. > > The ACE framework should also point out that a client must check if its > keying material for RS is still valid before it makes a request. > > BTW, I don't think keying material should be valid forever, especially > if there is no useful revocation mechanism. > Note that expires_in (exi) is currently defined as "expires in x seconds from the time at which the RS first saw the token". I am aware that this is quite weak since malicious clients can hoard tokens that would be valid indefinitely. I do not currently see any other means of expiration when the RS has no connectivity to the AS and no synchronized clock. I would be open for suggestions if you have better ideas. >>> >>> I did not find any indication how the client knows how to choose the >> correct >>> req_aud for RS. The document must point out that C may communicate with >>> the wrong RS unless C and AS have a common understanding how RS is >>> identified. >> >> Scope is also something that the client does not know how to build. > > In the worst case, a wrong scope can only prevent a client from > accessing a certain resource. Even if the client does not specify any > scope, the AS can still grant it permissions. If they are broad enough, > they will likely cover the resource that C wants to access. > A wrong req_aud however may cause the client to communicate with the > wrong RS. Even worse, C will not be able to notice that it communicates > with the wrong RS. This is a serious security risk. > Currently, the ACE > framework does not even acknowledge that such a risk exists. > We do acknowledge that, in the security considerations of draft-ietf-ace-oauth-params where req_aud is defined. I'll add additional clarification to that text though, since it currently only talks about the needing to RS know which audiences it recognizes. -- Ludwig Seitz, PhD Security Lab, RISE Phone +46(0)70-349 92 51
- [Ace] Fwd: New Version Notification for draft-iet… Ludwig Seitz
- Re: [Ace] Fwd: New Version Notification for draft… Jim Schaad
- Re: [Ace] Fwd: New Version Notification for draft… Stefanie Gerdes
- Re: [Ace] Fwd: New Version Notification for draft… Jim Schaad
- Re: [Ace] Fwd: New Version Notification for draft… Ludwig Seitz
- Re: [Ace] Fwd: New Version Notification for draft… Stefanie Gerdes
- [Ace] Overwriting Tokens Stefanie Gerdes
- Re: [Ace] Fwd: New Version Notification for draft… Ludwig Seitz
- Re: [Ace] Fwd: New Version Notification for draft… Ludwig Seitz
- Re: [Ace] Overwriting Tokens Ludwig Seitz
- Re: [Ace] Overwriting Tokens Stefanie Gerdes
- Re: [Ace] Overwriting Tokens Jim Schaad
- Re: [Ace] Fwd: New Version Notification for draft… Stefanie Gerdes
- Re: [Ace] Fwd: New Version Notification for draft… Ludwig Seitz
- [Ace] Token (In)Security Stefanie Gerdes
- [Ace] Security of the Communication Between C and… Stefanie Gerdes
- Re: [Ace] Token (In)Security Hannes Tschofenig
- Re: [Ace] Token (In)Security Hannes Tschofenig
- Re: [Ace] Security of the Communication Between C… Hannes Tschofenig
- Re: [Ace] Token (In)Security Ludwig Seitz
- Re: [Ace] Security of the Communication Between C… Ludwig Seitz
- Re: [Ace] Security of the Communication Between C… Hannes Tschofenig
- Re: [Ace] Security of the Communication Between C… Hannes Tschofenig
- Re: [Ace] Security of the Communication Between C… Ludwig Seitz
- Re: [Ace] Security of the Communication Between C… Stefanie Gerdes
- Re: [Ace] Security of the Communication Between C… Stefanie Gerdes
- Re: [Ace] Token (In)Security Stefanie Gerdes
- Re: [Ace] Security of the Communication Between C… Hannes Tschofenig
- Re: [Ace] Security of the Communication Between C… Hannes Tschofenig
- Re: [Ace] Security of the Communication Between C… Stefanie Gerdes
- Re: [Ace] Security of the Communication Between C… Hannes Tschofenig
- Re: [Ace] Security of the Communication Between C… Stefanie Gerdes
- Re: [Ace] Security of the Communication Between C… Ludwig Seitz
- Re: [Ace] Security of the Communication Between C… Hannes Tschofenig
- Re: [Ace] Security of the Communication Between C… Ludwig Seitz
- Re: [Ace] Security of the Communication Between C… Jim Schaad
- Re: [Ace] Security of the Communication Between C… Ludwig Seitz
- Re: [Ace] Security of the Communication Between C… Hannes Tschofenig
- Re: [Ace] Security of the Communication Between C… Sebastian Echeverria
- Re: [Ace] Token (In)Security Ludwig Seitz
- Re: [Ace] Token (In)Security Stefanie Gerdes
- Re: [Ace] Security of the Communication Between C… Benjamin Kaduk