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
>
>
>