Re: [Ace] WGLC on draft-ietf-ace-cwt-proof-of-possession-02

Hannes Tschofenig <Hannes.Tschofenig@arm.com> Wed, 23 May 2018 19:54 UTC

Return-Path: <Hannes.Tschofenig@arm.com>
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 6761412D778; Wed, 23 May 2018 12:54:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level:
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.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 tNftdX5eoDiO; Wed, 23 May 2018 12:54:50 -0700 (PDT)
Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-eopbgr20058.outbound.protection.outlook.com [40.107.2.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4BDB127978; Wed, 23 May 2018 12:54:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=MEG32NFtC9Uegio9UlvWFtOYsZtD++xUUS5K9Vvbz+I=; b=Xo6uH7nPN2t+IJ8C5k5osTt9Z3mD+eoJPtCQSP45XOsFGVNeircQVdwvBtbPEb5ILFlcmS/L3cEAsozWahiERKBEsuuMyn+Q6MOE0Ef3xDb1/OGlkRgpuACXt2+mP80cfMooHFFAfVG7NoOUFP9cINT++x7ydLDB8mHSAqODslE=
Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com (10.173.75.16) by VI1PR0801MB2064.eurprd08.prod.outlook.com (10.173.74.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.776.11; Wed, 23 May 2018 19:54:46 +0000
Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::8a:25f5:af5d:4db4]) by VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::8a:25f5:af5d:4db4%17]) with mapi id 15.20.0776.015; Wed, 23 May 2018 19:54:46 +0000
From: Hannes Tschofenig <Hannes.Tschofenig@arm.com>
To: Jim Schaad <ietf@augustcellars.com>, "draft-ietf-ace-cwt-proof-of-possession@ietf.org" <draft-ietf-ace-cwt-proof-of-possession@ietf.org>
CC: "ace@ietf.org" <ace@ietf.org>
Thread-Topic: [Ace] WGLC on draft-ietf-ace-cwt-proof-of-possession-02
Thread-Index: AdPnGgXMYVrDIRKQRwyiq8BLgNVR0wAN1QSAApWYoLA=
Date: Wed, 23 May 2018 19:54:46 +0000
Message-ID: <VI1PR0801MB21123B11488E06112FFB6B38FA6B0@VI1PR0801MB2112.eurprd08.prod.outlook.com>
References: <359EC4B99E040048A7131E0F4E113AFC014C3AA67D@marchand> <00ad01d3e751$5c1f03a0$145d0ae0$@augustcellars.com>
In-Reply-To: <00ad01d3e751$5c1f03a0$145d0ae0$@augustcellars.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com;
x-originating-ip: [195.149.218.8]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; VI1PR0801MB2064; 7:6yxKk/6mmGK52WTJEw/L367ZH7o2zoTEHb/BNK7MCeHNjc5U5KUMrsowJeMYHE8ownXrLC5HJn1MtZrumJENuXyv5C+bABY302mTWw8NG7reJnTMOGOlEZKZS5BjoOxsvMS/XdLiwwXmOA2JLNdnE2cZyetM2DxKkP5+vkPdVWXXq2VhR/EuzRlsk3CfQLtLFfUPadK+y6Uez/tHvpj4GN0A5vUPV8coDjM1ECSgR8tjcNy52DEKvr8bFgJNq2Up
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(48565401081)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:VI1PR0801MB2064;
x-ms-traffictypediagnostic: VI1PR0801MB2064:
x-microsoft-antispam-prvs: <VI1PR0801MB20648109D832724B7D27FF75FA6B0@VI1PR0801MB2064.eurprd08.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(192374486261705);
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3231254)(944501410)(52105095)(93006095)(93001095)(10201501046)(3002001)(6055026)(149027)(150027)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123560045)(20161123564045)(20161123558120)(6072148)(201708071742011)(7699016); SRVR:VI1PR0801MB2064; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0801MB2064;
x-forefront-prvs: 06818431B9
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(39380400002)(366004)(396003)(346002)(376002)(40434004)(13464003)(51444003)(199004)(189003)(81166006)(81156014)(4326008)(8936002)(102836004)(5660300001)(966005)(3280700002)(6436002)(316002)(55016002)(6506007)(110136005)(9686003)(14454004)(186003)(53546011)(72206003)(26005)(561944003)(74316002)(8676002)(66066001)(33656002)(105586002)(3660700001)(106356001)(2906002)(229853002)(6306002)(68736007)(6116002)(6246003)(478600001)(3846002)(7696005)(476003)(7736002)(11346002)(53936002)(2900100001)(59450400001)(25786009)(99286004)(86362001)(446003)(76176011)(5890100001)(5250100002)(97736004)(305945005)(2501003)(486006); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0801MB2064; H:VI1PR0801MB2112.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: xebrEgCBx+LxknVelUNCoyQTuvzop5KM7HauozCJcTCiGMOacGJCGbIPUrTpc8WVjkTcczde+23dYbcl64Ed5BkThCgUbvNE2UAc6bU5che0bcCACJadCIhfGkn1IHmNgfEInPvkU3CbGhw7uBf8oCKB17j6iyEZXzL0F1meInSK4x+J02yiZVnkDOaMa12B
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Office365-Filtering-Correlation-Id: 20e592ee-f9e1-48eb-a30e-08d5c0e70926
X-OriginatorOrg: arm.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 20e592ee-f9e1-48eb-a30e-08d5c0e70926
X-MS-Exchange-CrossTenant-originalarrivaltime: 23 May 2018 19:54:46.5204 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0801MB2064
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/ZwzgF0RUJkHiAUnirdWd9AN3zDk>
Subject: Re: [Ace] WGLC on draft-ietf-ace-cwt-proof-of-possession-02
X-BeenThere: ace@ietf.org
X-Mailman-Version: 2.1.22
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, 23 May 2018 19:54:54 -0000

Hi Jim,

A few remarks below.

-----Original Message-----
From: Jim Schaad [mailto:ietf@augustcellars.com]
Sent: 09 May 2018 05:51
To: draft-ietf-ace-cwt-proof-of-possession@ietf.org
Cc: ace@ietf.org
Subject: RE: [Ace] WGLC on draft-ietf-ace-cwt-proof-of-possession-02

I'll pull out the list of comments that I wrote a month ago but didn't start that computer up recently.

1.  Are all of the authors necessary?  As a chair I need to justify a count of more than 5 to the IESG.

[Hannes] As mentioned by Mike already, this was the result of a draft merger. The text initially came from an OAuth document (since this work had its history in the OAuth WG).

2.  Is the last sentence in section 1 necessary?  Are you actually defining any strings that could be case-sensitive?

[Hannes] I think we could get rid of that sentence.

3.  Terminology: In the definition of Issuer please make 'its' clearer.  It is not clear whose claims are being bound.

[Hannes] How about:

   Issuer
      Party that creates the CWT and binds the claims to the proof-of-
      possession key.


4.  Terminology: I still think this is 'Presenter' is a very strange term to use for this definition.  I would really like to see it be made something that makes sense and then say the term is the same as this in JWT.  The term has a model of use with it that I do not believe can be sustained even for the ACE Oauth case but really not in other cases.

[Hannes] It is a strange term but we used it also in the OAuth JWT PoP document and hence it wouldn't make sense to change it now.

5.  Terminology: Recipient matches presenter, and it matches the OAuth model
and not a trust model world.   Relying party or service provider make far
more sense to me.

[Hannes] Same comment as above. I prefer to be in alignment with the OAuth work here. I am wondering whether we should also copy the figures from Section 1 of https://tools.ietf.org/html/rfc7800 to make the architecture clearer.

6.  Under what circumstances would a 'sub' claim be present and it is not the presenter?  I can see that a holder of the key may be implicitly (or
anonymously) named, but putting something in the subject field which is not identifying the presenter is something that I would reject without a good presentation of why in the document.

[Hannes] Mike provided his perspective on this issue already. CWT is similar to JWT a somewhat flexible building block. What claims should, must or may be included in a given deployment depends a bit on the use case. Not including the subject claim may be useful for privacy purposes, for example. In other cases you definitely want to convey that information.

7.  I would disagree with the claim that if the 'sub' claim is missing then it would normally be the issuer.  For the world of IoT, I would expect that the subject would not be present because there is no need to identify the subject to the recipient.  I.e. it is an anonymous subject.

[Hannes] I am not sure that this is always the case in an IoT deployment. For example, imagine if a technician accesses some industrial device then I want to have the information about the person accessing those devices in my audit trail.

8.  It is not clear to me that either of the sub and iss claims would normally be present.  They might be present but neither is needed.  The subject can be anonymous and the issuer is identified by the key used to validate the security on the CWT.

[Hannes] In many deployments they may well not be present. That's completely fine. Fewer claims can sometimes be better.

9.  In section 3.1 the first two sentences appear to be contradictory.
Members are used to identify the POP key.  Other things than a POP key can be used than a POP key.  If they are used to identify the POP key- why would they not deal with the POP key?  I think that you should do a separation and define the 'cnf' file which can hold any number of confirmation methods and then have a section on defining some POP cnf method field holders.

[Hannes] How does this sound:


Section 3.1.  Confirmation Claim


FROM:

   The "cnf" claim is used in the JWT to contain members used to
   identify the proof-of-possession key.  Other members of the "cnf"
   object may be defined because a proof-of-possession key may not be
   the only means of confirming the authenticity of the token.  This is
   analogous to the SAML 2.0 [OASIS.saml-core-2.0-os]
   SubjectConfirmation element in which a number of different subject
   confirmation methods can be included (including proof-of-possession
   key information).

TO:

The "cnf" claim in the JWT is used to carry confirmation methods, some of
them use proof-of-possession keys while others do not. This design is
analogous to the SAML 2.0 [OASIS.saml-core-2.0-os] SubjectConfirmation
element in which a number of different subject confirmation methods can
be included (including proof-of-possession key information).




10.  In section 3.1 P1 - I am not sure why you have something here about confirming the authenticity of the token as oppose to confirming the identity of the presenter.  Why would that type of information be placed here where it is not useful.

[Hannes] I believe this part would be clarified with my wording change to Section 3.1 as proposed in #9.

11.  In section 3.1 P2 - We are back to the same argument that existed for a CWT in general.  Not knowing that a CWT is for a specific application means that it can be used in a different application and checking that the first application would have done is ignored by the second one because it will ignore fields it does not understand.

[Hannes] Mike provided a detailed response to this item already.

12. I am unclear why there should be a restriction on the number of POP keys that can be in a 'cnf' object.  If there are multiple keys, then any or all of them are of equal value in doing the confirmation.  Just like there can be multiple confirmation methods and an application could choose to use any one of them.

[Hannes] I believe we should not place such a restriction in there. A profile should place restrictions on the number of allowed "cnf" claims there. Changing the names of the claims, as a proposed alternative to get around this limit, appears a bit problematic since we have to register them in the IANA registry.
Hence, my proposal is to change the text

FROM:

  The "cnf" claim value MUST represent only a single proof-of-
   possession key; thus, at most one of the "jwk", "jwe", and "jku" (JWK
   Set URL) confirmation values defined below may be present.  Note that
   if an application needs to represent multiple proof-of-possession
   keys in the same JWT, one way for it to achieve this is to use other
   claim names, in addition to "cnf", to hold the additional proof-of-
   possession key information.

TO:

  The "cnf" claim value may contain one or multiple proof-of-
   possession keys. Hence, more than one "jwk", "jwe", and/or "jku" (JWK
   Set URL) confirmation values  may be present in a CWT.  A profile may impose
   further restrictions on the number of PoP keys that are present and
   also whether all or a only a subset of them needs to be utilized by in
   a given application domain.


~~~snip  ~~~

I will respond to the other questions in a second email; ran out of time.

Ciao
Hannes

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.