Re: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of-possession-02
Samuel Erdtman <samuel@erdtman.se> Fri, 29 June 2018 06:10 UTC
Return-Path: <samuel@erdtman.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 4E177130DC4 for <ace@ietfa.amsl.com>; Thu, 28 Jun 2018 23:10:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level:
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=erdtman-se.20150623.gappssmtp.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 vgaq1yNfMYfQ for <ace@ietfa.amsl.com>; Thu, 28 Jun 2018 23:10:01 -0700 (PDT)
Received: from mail-pf0-x236.google.com (mail-pf0-x236.google.com [IPv6:2607:f8b0:400e:c00::236]) (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 659F7130E36 for <ace@ietf.org>; Thu, 28 Jun 2018 23:10:01 -0700 (PDT)
Received: by mail-pf0-x236.google.com with SMTP id u16-v6so3727224pfh.3 for <ace@ietf.org>; Thu, 28 Jun 2018 23:10:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=erdtman-se.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=D9f5yuW5q8+FlPInZHJ4xWVhujmekujcUMoLgBZzLq0=; b=peedWGkVMwkPZEESWaoOe8/UE1aOK4ZO1ajpeapae9ywnqeVvXhp9d4RbJm+7X3Qkq O1rhtDsMyL6TvN1NtFUIp4o+3CVXB/K50AqhnCFQsp6BpVpy4HNDoUqZwOIyKvO3+7G4 9KABOHMqIO3DxhpGlJgcEN0MSw1IKln54G8sgr8lEEDx4P5Z8+pyMkEAk7rXfZY1M/VM NHUeM6iO0Ea/22NrKM7oSpZJZZRZZP2WAVRnLR3NOc+cttSQ8O4JV6Ks4S3ij+Qu12jI CiTmQto5F7sAG2Kf8LwfPAxKcwziCPtwjMoYI9DWqNBYKVG0iy18HZxcG6Ut7A8VshP1 mGOg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=D9f5yuW5q8+FlPInZHJ4xWVhujmekujcUMoLgBZzLq0=; b=pByGr4ALC2NIL+K6UBKe9G2HYXbWG1zAkJ4wjfBiurSxIB/qvFCWcgVFt38f8JS0On /ELe4pL1x2nRSIpI3dP16iv7D7C5wgv84H7IFJ53qDNHrBN4G9W3iOmtKZrTkoZvJ0R2 MbfBZWUdwX4xocwcmA7PUgVmukcT5lJEL5MtteFrCkDGyOWmMp0SEU+PftQeUbwVdafg ySWpR9kqm25VFy1HwVMSvHH/VqbY42wrmR3GXxhubGdBcl+Fwn0+2yszuVLneBDPJAlW 7BqsQNK3yOJiiHun6C3YGUXnelTnuk9Y37w9W586pyRQSIUkXVkRBiGeYRavA1+6aK6p rjwQ==
X-Gm-Message-State: APt69E0bfF2H0MlT3ZliozxIfuu31RzrfYr7tP3cRVVglnigQyNfpi2e EaevWhRQWk5KCwpOSdVCCoHHyYhG0TTPDM3k+JvSbA==
X-Google-Smtp-Source: ADUXVKIF3RjsfvRbUFm1FXwi1JigHQxe8OBIYOZCFVmH80y6i8OwpdcZzqJiUD+5HuKFAHYztoCeKkk08ZYQvpH8RNA=
X-Received: by 2002:a65:594b:: with SMTP id g11-v6mr11667497pgu.260.1530252600634; Thu, 28 Jun 2018 23:10:00 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a17:90a:d598:0:0:0:0 with HTTP; Thu, 28 Jun 2018 23:09:59 -0700 (PDT)
In-Reply-To: <027e01d40f6e$01e326b0$05a97410$@augustcellars.com>
References: <VI1PR0801MB2112C4D6D3CED7C15D9AE886FA750@VI1PR0801MB2112.eurprd08.prod.outlook.com> <20180622204344.GP64617@kduck.kaduk.org> <MW2PR00MB02986BC1E87754046C8CDC6AF5750@MW2PR00MB0298.namprd00.prod.outlook.com> <20180623212956.GE99689@kduck.kaduk.org> <027401d40b93$6b73b470$425b1d50$@augustcellars.com> <VI1PR0801MB2112611C298A9E68AC9B2402FA490@VI1PR0801MB2112.eurprd08.prod.outlook.com> <00e701d40d6e$c09b3db0$41d1b910$@augustcellars.com> <CAOB_DJkX_gA8Yyv7sQZWWFSYMjShLgsArGuH2M1MQ6TxpQRZEQ@mail.gmail.com> <013301d40de7$39660220$ac320660$@augustcellars.com> <CAF2hCbagrxvd5Nd6t2R4=HRiXVSA+R4HMpD9gA_EqqoN67mQjQ@mail.gmail.com> <027e01d40f6e$01e326b0$05a97410$@augustcellars.com>
From: Samuel Erdtman <samuel@erdtman.se>
Date: Fri, 29 Jun 2018 08:09:59 +0200
Message-ID: <CAF2hCbZ5jthbnqQPnAwm96YfsXsGeByc8oac+uONkjmNt8LkWQ@mail.gmail.com>
To: Jim Schaad <ietf@augustcellars.com>
Cc: Samuel Erdtman <erdtman@spotify.com>, draft-ietf-ace-cwt-proof-of-possession@ietf.org, Mike Jones <Michael.Jones@microsoft.com>, Hannes Tschofenig <Hannes.Tschofenig@arm.com>, Benjamin Kaduk <kaduk@mit.edu>, ace <ace@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000ad8305056fc1b2d6"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/5P4MWcYbBXUEaWWe0gF6Ur787ro>
Subject: Re: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of-possession-02
X-BeenThere: ace@ietf.org
X-Mailman-Version: 2.1.26
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: Fri, 29 Jun 2018 06:10:07 -0000
see inline On Fri, Jun 29, 2018 at 7:57 AM, Jim Schaad <ietf@augustcellars.com> wrote: > > > > > *From:* Samuel Erdtman <samuel@erdtman.se> > *Sent:* Thursday, June 28, 2018 5:40 PM > *To:* Jim Schaad <ietf@augustcellars.com> > *Cc:* Samuel Erdtman <erdtman@spotify.com>; draft-ietf-ace-cwt-proof-of- > possession@ietf.org; Mike Jones <Michael.Jones@microsoft.com>; Hannes > Tschofenig <Hannes.Tschofenig@arm.com>; Benjamin Kaduk <kaduk@mit.edu>; > ace <ace@ietf.org> > *Subject:* Re: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of- > possession-02 > > > > Thanks for the clarifying comments here comes a few replies since I will > not be able to join the IETF meeting :-( > > > > see inline > > > > On Wed, Jun 27, 2018 at 9:19 AM, Jim Schaad <ietf@augustcellars.com> > wrote: > > > > > > *From:* Samuel Erdtman <erdtman@spotify.com> > *Sent:* Wednesday, June 27, 2018 8:18 AM > *To:* Jim Schaad <ietf@augustcellars.com> > *Cc:* Hannes Tschofenig <Hannes.Tschofenig@arm.com>; Benjamin Kaduk < > kaduk@mit.edu>; Mike Jones <Michael.Jones@microsoft.com>; > draft-ietf-ace-cwt-proof-of-possession@ietf.org; ace@ietf.org > *Subject:* Re: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-proof-of- > possession-02 > > > > Jim, are you saying that if the client can pick the key identifier and if > it has seen a key identifier of another client it could request a PoP token > with the observed key-id and the observed subject but with an new key. > I guess this is a potential scenario that could be worth mentioning in > security considerations. > > [JLS] No I am not assuming that the observed subject is also chosen by the > attacker, just the observed key-id. > > OK, see comments below on why I think the attacker would have to know the > subject too. > > > > > If we look at ACE-OAuth there are as far as I can tell a few things that > makes this a hard attack to do. > > When the client makes the token request it is authenticated. > > [JLS] Unclear why this is relevant. I am asking for this new token as > myself. > > In my opinion authentication of the client will significantly lessen the > number of attackers since they need to have some initial access. i.e. no > absolute protection but one layer. > > > > [JLS] I am already in the system and have full credentials. I am trying > to get the same permissions that you have. Not all attackers are external > to the system. > I agree, but the number of such attackers are fewer and you could revoke access to such users. It is not perfect but it is better than nothing. > > > > And with the subject being the authenticated client cannot control what > goes into the cwt as subject > > [JLS] You are making an assumption that a) the subject is actually going > to be populated rather than be left empty and thus be anonymous and 2) that > the resource server is going to make any enforcement based on the subject. > I expect it to be done based on audience and scope only. > > My assumption is that RS will uniquely identify the key with Issuer, > Subject and Key-ID. If subject is omitted for an anonymous token I assume > that the AS (Issuer) makes sure the key-id is unique during the lifetime of > the token. If issuer is left out I assume it is identified by the CWT > signing key or that the RS only accept tokens from one AS. > > When the key is found and has been used to authenticate the user of the > token I too expect that the RS does the authorization based on audience and > scope. > > > > [JLS] I am not sure how this is going to work. As the CS I do a DTLS > connect to the RS and put the Key-ID into the PSK identifier field. The RS > now has the Key-ID, but does not have the Issuer or Subject information. > Are you using this triple value binding someplace else? > I would not send the key-id in the PSK identifier I would send the full token as described in draft-ietf-ace-dtls-authorize (4.1. DTLS Channel Setup Between C and RS). > > > > Since the cwt with the PoP key is signed there is no way for the attacking > client to retro-fit the token to suit its needs e.g. change subject or > key-id. > > [JLS] I am asking for a new token not trying to modify an existing token > so this is not especially relevant. > > Based on my previous statement you should not be able to impersonate the > observed key with a token issued for you. > > > > [JLS] Given two anonymous subject fields, the subject would not be a > differentiator > I agree so the AS (issuer) MUST keep key-id unique for the lifetime of the token. > > Finally I think it is preferable if the server selects key identifier. > > [JLS] I would agree, however if you have two AS that are operating in the > same authorization range and are not tightly linked then this is not easy > for doing an additional privilege token where the POP is identified by the > KID. This is even harder if an RS is going to allow two different AS from > different scopes to be authoritative as they would never coordinate > together. > > In the case of RS accepting tokens from multiple ASs I think the RS must > use the issuer (in the CWT) to do key lookup. > > > > [JLS] That may be true, however I have still not seen how to do the > processing of getting a supplementary CWT and thus don’t know how it > works. I was assuming that the Client would send a KID as part of it’s > request to the AS so one now has interesting questions of how the server > does the assignment. Also having a KID as part of an asymmetric key is > probably going to be normal operating procedure so this is another case > where the Client is providing one. > > > > Jim > > > > > > Best regards > //Samuel > > On Tue, 26 Jun 2018 at 18:57, Jim Schaad <ietf@augustcellars.com> wrote: > > Hannes, > > My worry is not about implementers getting this correct and picking random > key ids. My worry is about an attacker seeing the key id of somebody and > trying to use it either with the same or a different AS and getting a key > and then getting permissions associated with the initial key that they > should not be doing. > > This is about an attack not about getting things to generally work right. > > Jim > > > > -----Original Message----- > > From: Hannes Tschofenig <Hannes.Tschofenig@arm.com> > > Sent: Tuesday, June 26, 2018 6:09 PM > > To: Jim Schaad <ietf@augustcellars.com>; 'Benjamin Kaduk' > > <kaduk@mit.edu>; 'Mike Jones' <Michael.Jones@microsoft.com> > > Cc: draft-ietf-ace-cwt-proof-of-possession@ietf.org; ace@ietf.org > > > Subject: RE: [Ace] Key IDs .... RE: WGLC on draft-ietf-ace-cwt-proof-of- > > possession-02 > > > > Hi Jim, > > > > you are essentially proposing that we should not directly use the key id > that > > is in the CWT-PoP but rather use it as input in a key derivation > function. > The > > details of that key derivation function are specified outside the CWT-POP > > document and most likely in the context of the various profiles. > > Your proposals below suggest to use, among other things, the session key > as > > input to that function. That sounds pretty straight forward but raises > the > > question why we fail to trust the implementer to create random key ids > but > > then still trust them to create random keys. > > > > That's fine for me nevertheless. > > > > Ciao > > Hannes > > > > -----Original Message----- > > From: Jim Schaad [mailto:ietf@augustcellars.com] > > Sent: 24 June 2018 10:15 > > To: 'Benjamin Kaduk'; 'Mike Jones' > > Cc: Hannes Tschofenig; draft-ietf-ace-cwt-proof-of-possession@ietf.org; > > ace@ietf.org > > > Subject: RE: [Ace] Key IDs .... RE: WGLC on draft-ietf-ace-cwt-proof-of- > > possession-02 > > > > Thinking things through, I would be more comfortable with something like > > the > > following: > > > > 1. Create a confirmation called 'computed key id'. This has two basic > > values: What is the computation method? What is the proof value? You > can > > optionally have an unprotected KID value used to filter the set of keys > on > the > > RS down to a reasonable set to enumerate (hopefully one). > > > > 2. For RPK and TLS: Define a method called hash of SPKI which has a > hash > > method as a parameter. Given that this can be computed independently by > > all entities based on a Public Key value and it will be unique then you > have a > > key identifier that will not have collisions independent of who issues > the > > CWT. > > > > 3. For PSK and TLS: Define a method which takes some parameters > including > > the key value, the CWT issuer identity and perhaps some random string and > > compute a proof of possession value on the PSK. > > > > 4. For PSK and OSCORE: Define a similar method the question would be > what > > the key value is to be used but that can be defined as part of OSCORE > > > > When using the keys for TLS > > > > For RPK the key is carried in the handshake and the server/client can > > generate the computed key id and compare it to what the AS distributed. > > > The server can identify which CWTs are applicable by either comparison of > > the RPKs or the computed key id. This means you have a high probability > > that you will not make a mistake and match to the wrong key. > > > > For PSK the identifier is carried in the handshake which is used to look > up a > > key value and the handshake is performed. By matching computed key ids > > with the secret value one can ensure to a high probably that only CWTs > that > > reference the same secret are going to be used for permissions even if > they > > come from different AS entities. > > > > For OSCORE it is similar, the identifier is used to look up a key value > and by > > decrypting the CWT the key value is proofed. You then match computed key > > ids in the same manner. > > > > If you really want to have something that is not cryptographically > computed > > and point to something else, then it makes more sense to me to reference > a > > CWT issued by the same entity and say "use the same conformation method > > as this CWT does". > > > > jim > > > > > -----Original Message----- > > > From: Benjamin Kaduk <kaduk@mit.edu> > > > Sent: Saturday, June 23, 2018 11:30 PM > > > To: Mike Jones <Michael.Jones@microsoft.com> > > > Cc: Hannes Tschofenig <Hannes.Tschofenig@arm.com>; Jim Schaad > > > <ietf@augustcellars.com>; > > > draft-ietf-ace-cwt-proof-of-possession@ietf.org; > > > ace@ietf.org > > > Subject: Re: [Ace] Key IDs ... RE: WGLC on > > > draft-ietf-ace-cwt-proof-of- > > > possession-02 > > > > > > On Fri, Jun 22, 2018 at 08:48:35PM +0000, Mike Jones wrote: > > > > See my note just now proposing this text to Jim: > > > > > > > > "Likewise, if PoP keys are used for multiple different kinds of CWTs > > > > in > > an > > > application and the PoP keys are identified by Key IDs, care must be > > > taken > > to > > > keep the keys for the different kinds of CWTs segregated so that an > > attacker > > > cannot cause the wrong PoP key to be used by using a valid Key ID for > > > the wrong kind of CWT." > > > > > > > > As long as the PoP keys for different contexts are kept segregated, > > > > Key > > ID > > > collisions or reuse cause no problems. > > > > > > If we trust everyone to implement things properly. We should probably > > only > > > take that risk if we get some other benefit from it, though. Jim > > mentioned > > > (off-list?) a scenario involving giving the same client additional > > privileges, and > > > of course we can gain some simplicity savings if we don't need to > > > enforce global key-id uniqueness (for appropriate values of "global"). > > > So this > > may > > > well be the right thing to do; I just don't think it's without > > > tradeoffs > > as your > > > text seems to imply. > > > > > > -Ben > > > > IMPORTANT NOTICE: The contents of this email and any attachments are > > confidential and may also be privileged. If you are not the intended > recipient, > > please notify the sender immediately and do not disclose the contents to > any > > other person, use it for any purpose, or store or copy the information in > any > > medium. Thank you. > > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace > > >
- Re: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-… Jim Schaad
- [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-cwt-… Hannes Tschofenig
- Re: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-… Jim Schaad
- Re: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-… Hannes Tschofenig
- Re: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-… Hannes Tschofenig
- Re: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-… Jim Schaad
- Re: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-… Jim Schaad
- Re: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-… Benjamin Kaduk
- Re: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-… Hannes Tschofenig
- Re: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-… Hannes Tschofenig
- Re: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-… Benjamin Kaduk
- Re: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-… Hannes Tschofenig
- Re: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-… Benjamin Kaduk
- Re: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-… Hannes Tschofenig
- Re: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-… Ludwig Seitz
- Re: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-… Benjamin Kaduk
- Re: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-… Mike Jones
- Re: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-… Jim Schaad
- Re: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-… Jim Schaad
- Re: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-… Mike Jones
- Re: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-… Samuel Erdtman
- Re: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-… Jim Schaad
- Re: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-… Jim Schaad
- Re: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-… Mike Jones
- Re: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-… Benjamin Kaduk
- Re: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-… Samuel Erdtman
- Re: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-… Samuel Erdtman
- Re: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-… Jim Schaad
- Re: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-… Ludwig Seitz
- Re: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-… Ludwig Seitz
- Re: [Ace] Key IDs ... RE: WGLC on draft-ietf-ace-… Mike Jones