From nobody Thu Oct 1 10:13:28 2020 Return-Path: X-Original-To: rum@ietf.org Delivered-To: rum@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F35AC3A0ABD; Thu, 1 Oct 2020 10:13:25 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: pkyzivat@alum.mit.edu, superuser@gmail.com, rum-chairs@ietf.org, rum@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.17.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160157240547.6121.12187458065137054514@ietfa.amsl.com> Date: Thu, 01 Oct 2020 10:13:25 -0700 Archived-At: Subject: [Rum] rum - New Meeting Session Request for IETF 109 X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Oct 2020 17:13:26 -0000 A new meeting session request has just been submitted by Paul Kyzivat, a Chair of the rum working group. --------------------------------------------------------- Working Group Name: Relay User Machine Area Name: Applications and Real-Time Area Session Requester: Paul Kyzivat Number of Sessions: 1 Length of Session(s): 1 Hour Number of Attendees: 20 Conflicts to Avoid: Chair Conflict: avtcore dispatch sipcore ecrit mmusic Technology Overlap: quic People who must be present: Murray Kucherawy Brian Rosen Paul Kyzivat Resources Requested: Special Requests: --------------------------------------------------------- From nobody Mon Oct 5 08:15:45 2020 Return-Path: X-Original-To: rum@ietfa.amsl.com Delivered-To: rum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 715AD3A0B50 for ; Mon, 5 Oct 2020 08:15:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.886 X-Spam-Level: X-Spam-Status: No, score=-1.886 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_EMBEDS=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=brianrosen-net.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 q_0XH4s6vEzk for ; Mon, 5 Oct 2020 08:15:41 -0700 (PDT) Received: from mail-io1-xd2d.google.com (mail-io1-xd2d.google.com [IPv6:2607:f8b0:4864:20::d2d]) (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 4DEB63A07C4 for ; Mon, 5 Oct 2020 08:15:41 -0700 (PDT) Received: by mail-io1-xd2d.google.com with SMTP id y20so9458333iod.5 for ; Mon, 05 Oct 2020 08:15:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=mUwmvTTVDKK54cPTOw5+8YQZ19hsVbhNvYTlOJcgXtM=; b=lQuJLeJenT0Dgx7SoOO84XoTdG1ssSJwKUD1Mo/78V3I2IhGxXr5kUQlQaQt7FssCS +Nsyx8Fci91vL2FBPo8ceqGGsVjoEM9A+D/KaDT7wiN99EqNKfbFia/MjtzX4ZZqfEaV NHUDtpJLHOmldG7W7qiuuZXBG3gMOJ2j3f59K2LpIFcayCshQfYXgTE6BdmdWVeKKAy9 dTsRp7jESfcVBY4M5iXTdrI6CwUyeEvL/1TOs+3NTMrxlTh6BIxs6VwQjUaqe3SAI+q2 Ghscjw7Vq6NaRqxyzQyQzsdA+Xjwyz21OVcuLiUWLYpoQZZw48JPFceAMVQvJOZ9kXRj 9wqA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=mUwmvTTVDKK54cPTOw5+8YQZ19hsVbhNvYTlOJcgXtM=; b=CWAGWKvNbNT8/YXIDXrKfTQP2ulBmJzH5m6Xty55R98XLNNN3f1EJZO1cftYwiWeyc xjhdPTU08GvDAKPJzcUR8kgYhjxsIkKJHllmTpdqjYJwH40tzpyVDSRSjdXN2rG3jYI5 0H0mV+a1/hLNHFLvvEXczC4AsRwiYJyDY1KHNp6Tk6VRWtayGHtF0TD7i34fDewIdkbt Q/eDzeQWE1C0ISxeu0pA7nncy5dDmVkrxHPChnG6lG7++2Y9/ANltndHDGdXb9qAu5M1 yoXr5FGF13Uo3ewilnH+8dHFAtxfNGpKCohnoImZm/6inamXQInj3K4anE74j8e/17Tq Injg== X-Gm-Message-State: AOAM533Pq2U7aLa6fzVSjfNtviCS1Ikf6jVnrmK0Yl3vA5uDS2/kU1z3 maIU0uhyuFa84fGNN/wIOXsew+Mptn04hBMm X-Google-Smtp-Source: ABdhPJx9q3ZthCmTeYsObaQ/WjEUCl4KFKLJoSv+3yv1pfGcmhPX8RuOK2JrL8l5DRHewsQW3uY4qA== X-Received: by 2002:a05:6602:2a45:: with SMTP id k5mr258898iov.1.1601910940325; Mon, 05 Oct 2020 08:15:40 -0700 (PDT) Received: from brians-mbp-2871.lan (dynamic-acs-24-154-119-158.zoominternet.net. [24.154.119.158]) by smtp.gmail.com with ESMTPSA id v1sm100685ioe.0.2020.10.05.08.15.39 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 05 Oct 2020 08:15:39 -0700 (PDT) From: Brian Rosen Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_03013753-061D-420D-A537-360F3ADCAAA1" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Date: Mon, 5 Oct 2020 11:15:38 -0400 In-Reply-To: <1600679072074.473@purple.us> Cc: "rum@ietf.org" To: James Hamlin References: <1600679072074.473@purple.us> X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [Rum] I-D Action: draft-ietf-rum-rue-03.txt X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Oct 2020 15:15:43 -0000 --Apple-Mail=_03013753-061D-420D-A537-360F3ADCAAA1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I deleted the line in my -04 working copy, because you are correct. I = do hope providers do implement those blocks, but as you say, that is = beyond the scope of this document. Brian > On Sep 21, 2020, at 5:04 AM, James Hamlin = wrote: >=20 > Brian >=20 > Thanks for the new draft. >=20 > I think the final sentence in section 5.2.5. "Emergency Calls" is out = of scope, as it tries to define the interface between the VRS provider = and the PSAP. =46rom the rest of the text, the purpose of the data = exchange between RUE and VRS provider is already clear; the final = sentence could be dropped without detracting from the description of the = RUM interface. I propose dropping the text: "Providers MUST implement = Data Provider and Service Information blocks as the call is forwarded to = the PSAP.". >=20 > Best Regards=20 >=20 > James >=20 > James Hamlin > Contractor > Purple, a Division of ZP Better Together, LLC > purplevrs.com > The information contained in this e-mail message is intended only for = the personal and confidential use of the recipient(s) named above. If = you have received this communication in error, please notify us = immediately by e-mail, and delete the original message. > --=20 > Rum mailing list > Rum@ietf.org > https://www.ietf.org/mailman/listinfo/rum = --Apple-Mail=_03013753-061D-420D-A537-360F3ADCAAA1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii I = deleted the line in my -04 working copy, because you are correct. =  I do hope providers do implement those blocks, but as you say, = that is beyond the scope of this document.

Brian


On Sep 21, 2020, at 5:04 AM, James Hamlin <james.hamlin@purple.us> wrote:

Brian

Thanks for the new draft.

I think the final sentence in section = 5.2.5. "Emergency Calls" is out of scope, as it tries to = define the interface between the VRS provider and the PSAP. = =46rom the rest of the text, the purpose of the data exchange between = RUE and VRS provider is already clear; the final = sentence could be dropped without detracting = from the description of the RUM interface. I propose = dropping the text: "Providers MUST implement Data = Provider and Service Information blocks as the call is forwarded to the = PSAP.".

Best Regards 

James

James Hamlin
Contractor
Purple, a Division of ZP Better = Together, LLC
purplevrs.com
The information contained in this e-mail = message is intended only for the personal and confidential use of the = recipient(s) named above. If you have received this communication in = error, please notify us immediately by e-mail, and delete the original = message.
-- Rum mailing list
Rum@ietf.org
https://www.ietf.org/mailman/listinfo/rum

= --Apple-Mail=_03013753-061D-420D-A537-360F3ADCAAA1-- From nobody Thu Oct 15 12:31:00 2020 Return-Path: X-Original-To: rum@ietfa.amsl.com Delivered-To: rum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 621843A0FC2 for ; Thu, 15 Oct 2020 12:30:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sorenson.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 Zu1Tw3tLwQRv for ; Thu, 15 Oct 2020 12:30:57 -0700 (PDT) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-eopbgr760074.outbound.protection.outlook.com [40.107.76.74]) (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 3286B3A0CBE for ; Thu, 15 Oct 2020 12:30:56 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=UL/FmLy8qmZRzyZS5Ctc7VB77Sn+C4HF6jjnnuP5RxACiMObCWsNauaKrTHywHeZtCe0kOCrj6VoeUMuZS5Vi2wub+EIO5CJuYwQ1CPaX/VQXl8+byGLfbwGWMcxlZQ+SWcFA2uUGOuDax81SagMxIkOT6YHo+vJBMQc7lLunxNxdAOSN03Owt8Tno0g0xPyrPpDwPp80AkCcr1g6mo/um+LuOe6tS+bnItB//EN3b08n5NbvKwuoiQkGAYKstwFP7wb48r49sQVzXe9rcRISTu3RB6OlJ4d1AluMvHWlKGU+vP4ICdRP8R5lPZjxSDaOFMsuDSM3JcpIJJnAB/cCA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=7dXo1D2bmMSM/qIoxd5q+BkmMaSrWddW9H0f5gj4hgg=; b=e1wn92ZaVrPm9boPta0oAKIHkrtRmZWNKjg77cyAwhR52m8kBMnJxm6W70uKK2ANeWIK3areHx1zduDbW/o+bDXVzW0hKqeBQqkja05GyeCQF4pOXOV0w5yrsRoMwMi/4DYxmcDqaK6y5J0KHBmR1gFON09LjwTxGEvLAE9ANRoiTM6BK/s+a4ukvssXrQpAJ2IsIMekgDnTeknz6jCbgCp3/yaWpBecJSeE8F8ukacbUc6BAfXI+eTZXUqwYTd2191lSf4VV7u4QZgmtxogBvc5iber/PDtBTrCfx7foevUaIK9lriRZan2S6TLdGqJG4oi1QVNJUnGpceweVK2ow== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=sorenson.com; dmarc=pass action=none header.from=sorenson.com; dkim=pass header.d=sorenson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sorenson.onmicrosoft.com; s=selector2-sorenson-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=7dXo1D2bmMSM/qIoxd5q+BkmMaSrWddW9H0f5gj4hgg=; b=SSHlm6cbtmOyuOIknRiJrRINJFR/gXmc9dSNR4boIAHTWUPPn4roxZclsdrQz0MOO1z/vw7HCw77VtcBelPlR3zUvEgz01BX0imom/EuxctZwWcJOC8+duAzdUMAHl8xd66XoRVuoe1QyF5DUBj/eaME73ukXfJMbNalm/bc/Ls= Received: from BYAPR04MB4983.namprd04.prod.outlook.com (2603:10b6:a03:41::29) by BYAPR04MB4103.namprd04.prod.outlook.com (2603:10b6:a02:ad::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3455.24; Thu, 15 Oct 2020 19:30:53 +0000 Received: from BYAPR04MB4983.namprd04.prod.outlook.com ([fe80::e09a:6be0:ccf6:a8b1]) by BYAPR04MB4983.namprd04.prod.outlook.com ([fe80::e09a:6be0:ccf6:a8b1%7]) with mapi id 15.20.3477.020; Thu, 15 Oct 2020 19:30:53 +0000 From: Eugene Christensen To: Brian Rosen CC: "rum@ietf.org" Thread-Topic: [Rum] [EXT] RUM security model Thread-Index: AQHWlnxQD9PXpaMUFE6N0jV2IR9mp6mBxBhggAAW2wCAF0rLoA== Date: Thu, 15 Oct 2020 19:30:52 +0000 Message-ID: References: <159838856681.32208.2945571627178413540@ietfa.amsl.com> <3757_1601140882_5F6F7891_3757_32_1_a4a62f53-1571-56ec-35b9-7faecd4fa480@alum.mit.edu> <927a8854-51b9-c768-ee1e-5d0c4b76a45f@alum.mit.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: brianrosen.net; dkim=none (message not signed) header.d=none;brianrosen.net; dmarc=none action=none header.from=sorenson.com; x-originating-ip: [75.146.88.198] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 16d8f6b8-d9d7-4b6e-5d8a-08d87140d49b x-ms-traffictypediagnostic: BYAPR04MB4103: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: X3qg4MBljddtMIl6NmrS12jpGijmwABW9OIDppH9qMkiAwy7FjZhY8UY2evWk3WJ7ycWYZflhhngaYm9S+/eezqrth1Fyk/odRgWxuyVwYHKwCMo1zbfXjMpu0EP0J7eDvuTeow4s3ZjGL0uPFl5KlU2v2xi5aAQpSZMKbxjWsE5Bxe/nSGGTVpC+yAtHWj4dcOOINnEUCdlF8ToRMZwJehO4EXyvtkwPZqFGiiiXP5aiqEKrDEG4rX2xA3er0iBkAUDt++yO28esn39mbz9LxpSqHCYocz9GTBjSl8JAWrt10IDlnV7AQX2JZVDZU5DUD16kapas5Ut3ijxsyhPjUDFzVWNEfsFONUZyWcewbKu7TtvaUvHpIES4I2uE9ydF4DhsdO1+IdzIzm4J1UBpA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BYAPR04MB4983.namprd04.prod.outlook.com; PTR:; CAT:NONE; SFS:(39850400004)(396003)(366004)(376002)(136003)(346002)(6916009)(2906002)(83380400001)(64756008)(33656002)(66446008)(52536014)(6506007)(26005)(66556008)(66946007)(7696005)(15650500001)(4326008)(316002)(76116006)(186003)(86362001)(55016002)(166002)(5660300002)(478600001)(53546011)(8676002)(66476007)(966005)(9686003)(71200400001)(8936002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: NBcbRpWtGLbpug6V1px3DGWXABvmWwOfwAFZy527Oho+d6Q/U9Xo7RM3ZM6jIhheIFrCLx++aR0mG6JA1X30MPcC3aCnMP303NnKnNa5+pN7aeVprmuP/xKLsCy9yspcXlV9IsJWmZQ/u3GQ95Yf3lDsyNO6VVGRZKapP1YuBxql8LY+Tafej1Qce54aFnBRo+F4g0mG5FAiUz1ORJXDiOZUx3F6b7I2pRHBagAPqQCWzKyS74EYELY8OrMoaraGj/kssnVz7X/yJZP5ddj2Y0e3a6DUhTHTeyyOxgJRACXXRQrqoRSfAPDpu586enOMgbXP/O7W1QXz8IFnjWWdIAdG4NquF1CTa5D3L6/2VDr9OUa5VfJPVHqKVGsbEfPK/Khb0jn8R/QFd7Cr220bN7QxjfDuHtcXX3OyzZdcnoSlFK8pfW2FBuijwc93ISJjsvcmh/yZT3OuDkP6smLN+r3GNP4Q9UzZF2jBAThOg8Z9h++f5hAfouxZZ3Snnd54AFLiGCtmlsfOnDWOMmEu7fSbUAYM3jGz/Z5kArBB4b+d96XeuhSy6LswBcgunhcr6JuA6P6FQ8uRtzQT6JqOVz4s3obl3lxlUkJKyVhOs3jdPxdWujCrDx0KQ1ST7/1cRNlkaWkWjwuhIC78DL0MPg== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_BYAPR04MB49831BE0D5B16E3DC64433C9A3020BYAPR04MB4983namp_" MIME-Version: 1.0 X-OriginatorOrg: sorenson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BYAPR04MB4983.namprd04.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 16d8f6b8-d9d7-4b6e-5d8a-08d87140d49b X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Oct 2020 19:30:52.8034 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 6b03ef08-a104-48c4-a951-f18d295428d5 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: Q9wt8VqEyWVtRnCSexvxvz+x5JQSyEwGuWsEykoBmS01wn9q91ROKzdKG9RcQ0WxKX0++eq5Kqu22miy+1iQ3NOCYoFy0nDrBsvK0XtP0Fc= X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR04MB4103 Archived-At: Subject: Re: [Rum] [EXT] RUM security model X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2020 19:30:59 -0000 --_000_BYAPR04MB49831BE0D5B16E3DC64433C9A3020BYAPR04MB4983namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QnJpYW4sDQoNCkFkbWl0dGVkbHkgSSBkbyBub3QgZnVsbHkgdW5kZXJzdGFuZCBjZXJ0aWZpY2F0 ZXMgYW5kIGF1dGhlbnRpY2F0aW9uIGJ1dCB3b3VsZCBjbGllbnQgY2VydGlmaWNhdGVzIG9yIG11 dHVhbCBhdXRoZW50aWNhdGlvbiB3aXRoIGEgc2hhcmVkIHNlY3JldCB3b3JrIGhlcmU/DQoNClRo YW5rIHlvdS4NCg0KRXVnZW5lDQoNCkNPTkZJREVOVElBTElUWSBOT1RJQ0UuIFRoaXMgZS1tYWls IHRyYW5zbWlzc2lvbiwgYW5kIGFueSBkb2N1bWVudHMsIGZpbGVzIG9yIHByZXZpb3VzIGUtbWFp bCBtZXNzYWdlcyBhdHRhY2hlZCB0byBpdCwgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIGFuZCBw cm9wcmlldGFyeSBpbmZvcm1hdGlvbi4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lw aWVudCwgb3IgYSBwZXJzb24gcmVzcG9uc2libGUgZm9yIGRlbGl2ZXJpbmcgaXQgdG8gdGhlIGlu dGVuZGVkIHJlY2lwaWVudCwgeW91IGFyZSBoZXJlYnkgbm90aWZpZWQgdGhhdCBhbnkgZGlzY2xv c3VyZSwgY29weWluZywgZGlzdHJpYnV0aW9uIG9yIHVzZSBvZiBhbnkgb2YgdGhlIGluZm9ybWF0 aW9uIGNvbnRhaW5lZCBpbiBvciBhdHRhY2hlZCB0byB0aGlzIG1lc3NhZ2UgaXMgU1RSSUNUTFkg UFJPSElCSVRFRC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyB0cmFuc21pc3Npb24gaW4gZXJy b3IsIHBsZWFzZSBpbW1lZGlhdGVseSBub3RpZnkgbWUgYnkgcmVwbHkgZS1tYWlsIGF0IGVjaHJp c3RlbnNlbkBzb3JlbnNvbi5jb208bWFpbHRvOmVjaHJpc3RlbnNlbkBzb3JlbnNvbi5jb20+IG9y IGJ5IHRlbGVwaG9uZSBhdCArMSAoODAxKSAyODctOTQxOSwgYW5kIGRlc3Ryb3kgdGhlIG9yaWdp bmFsIHRyYW5zbWlzc2lvbiBhbmQgaXRzIGF0dGFjaG1lbnRzIHdpdGhvdXQgcmVhZGluZyB0aGVt IG9yIHNhdmluZyB0aGVtIHRvIGRpc2suDQoNCkZyb206IEJyaWFuIFJvc2VuIDxickBicmlhbnJv c2VuLm5ldD4NClNlbnQ6IFdlZG5lc2RheSwgU2VwdGVtYmVyIDMwLCAyMDIwIDU6NDcgUE0NClRv OiBFdWdlbmUgQ2hyaXN0ZW5zZW4gPGVjaHJpc3RlbnNlbkBzb3JlbnNvbi5jb20+DQpDYzogcnVt QGlldGYub3JnDQpTdWJqZWN0OiBSZTogW1J1bV0gW0VYVF0gUlVNIHNlY3VyaXR5IG1vZGVsDQoN CltFWFRFUk5BTF0NCkkgdGhpbmsgd2UgdW5kZXJzdGFuZCB3aHkgeW91IHdhbnQgaXQuIFdoYXQg d2UgZG9u4oCZdCB1bmRlcnN0YW5kIGlzIHdoYXQgbWVjaGFuaXNtIHdvdWxkIHByb3ZpZGUgaXQu IEkgYW0gZ2VuZXJhbGx5IGF3YXJlIG9mIHRoaXMgY2xhc3Mgb2YgcHJvYmxlbSBhbmQgSeKAmW0g bm90IGF3YXJlIG9mIGEgc29sdXRpb24gdGhhdCB3aWxsIHdvcmsuICBTbyB3aGF0IHdlIG5lZWQg aXMgYSBzdWdnZXN0ZWQgbWVjaGFuaXNtIHRoYXQgcHJvdmlkZXMgdGhlIGFzc3VyYW5jZSB5b3Ug d2FudCB0aGF0IGlzIHRlY2huaWNhbGx5IHNvdW5kLg0KDQpCcmlhbg0KDQpPbiBXZWQsIFNlcCAz MCwgMjAyMCBhdCA2OjMwIFBNIEV1Z2VuZSBDaHJpc3RlbnNlbiA8ZWNocmlzdGVuc2VuQHNvcmVu c29uLmNvbTxtYWlsdG86ZWNocmlzdGVuc2VuQHNvcmVuc29uLmNvbT4+IHdyb3RlOg0KVGhhbmtz IGZvciBjb25zaWRlcmluZyBob3cgd2UgbWlnaHQgaW1wbGVtZW50IHRoaXMgc2VjdXJpdHkgbWVj aGFuaXNtLiAgTWF5IEkgYWRkIG15IHZvaWNlIHRoYXQgaXQgaXMgZXNzZW50aWFsIHRoYXQgd2Ug ZmluZCBhbiBvcHRpb24gZm9yIHByb3ZpZGluZyB0aGlzIGRlc2lyZWQgc2VjdXJpdHksIHdoYXRl dmVyIGl0IGlzLiAgSXQgY291bGQgYmUgZGV0cmltZW50YWwgdG8gdGhlIFZSUyBwcm92aWRlcnMg dG8gaGF2ZSBVQXMgb3V0IHRoZXJlLCB3aXRoIHRoZSBhYmlsaXR5IHRvIHJlZ2lzdGVyIHdpdGgg VlJTIHByb3ZpZGVycyB3aXRob3V0IGZpcnN0IGJlaW5nIGZ1bGx5IHZldHRlZC4gIEl0IGlzIG91 ciBwcmFjdGljZSBhbnl0aW1lIHdlIG1ha2UgdXBkYXRlcyB0byBvdXIgVUFzIHRvIHRlc3QgaG93 IHRoZXkgd29yayB3aXRoIG91ciBVQVMgYmVmb3JlIHdlIGV2ZXIgcmVsZWFzZSB0aGUgbmV3IFVB IHNvZnR3YXJlIGludG8gb3VyIHByb2R1Y3Rpb24gZW52aXJvbm1lbnQuICBXZSBvbmx5IHdhbnQg VUFzIHJlZ2lzdGVyaW5nIHRoYXQgaGF2ZSB1bmRlcmdvbmUgdGhpcyByaWdvcm91cyB0ZXN0aW5n IHdpdGggb3VyIHN5c3RlbXMgYW5kIHRoZW4gb25seSB3aXRoIHVzZXJzIHdoaWNoIHdlIGhhdmUg YXdhcmVuZXNzIG9mLg0KDQoNCg0KVGhhbmtzLA0KDQpFdWdlbmUgQ2hyaXN0ZW5zZW4NCg0KDQoN CkNPTkZJREVOVElBTElUWSBOT1RJQ0UuIFRoaXMgZS1tYWlsIHRyYW5zbWlzc2lvbiwgYW5kIGFu eSBkb2N1bWVudHMsIGZpbGVzIG9yIHByZXZpb3VzIGUtbWFpbCBtZXNzYWdlcyBhdHRhY2hlZCB0 byBpdCwgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIGFuZCBwcm9wcmlldGFyeSBpbmZvcm1hdGlv bi4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgb3IgYSBwZXJzb24gcmVz cG9uc2libGUgZm9yIGRlbGl2ZXJpbmcgaXQgdG8gdGhlIGludGVuZGVkIHJlY2lwaWVudCwgeW91 IGFyZSBoZXJlYnkgbm90aWZpZWQgdGhhdCBhbnkgZGlzY2xvc3VyZSwgY29weWluZywgZGlzdHJp YnV0aW9uIG9yIHVzZSBvZiBhbnkgb2YgdGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiBvciBh dHRhY2hlZCB0byB0aGlzIG1lc3NhZ2UgaXMgU1RSSUNUTFkgUFJPSElCSVRFRC4gSWYgeW91IGhh dmUgcmVjZWl2ZWQgdGhpcyB0cmFuc21pc3Npb24gaW4gZXJyb3IsIHBsZWFzZSBpbW1lZGlhdGVs eSBub3RpZnkgbWUgYnkgcmVwbHkgZS1tYWlsIGF0IGVjaHJpc3RlbnNlbkBzb3JlbnNvbi5jb208 bWFpbHRvOmVjaHJpc3RlbnNlbkBzb3JlbnNvbi5jb20+IG9yIGJ5IHRlbGVwaG9uZSBhdCArMSAo ODAxKSAyODctOTQxOSwgYW5kIGRlc3Ryb3kgdGhlIG9yaWdpbmFsIHRyYW5zbWlzc2lvbiBhbmQg aXRzIGF0dGFjaG1lbnRzIHdpdGhvdXQgcmVhZGluZyB0aGVtIG9yIHNhdmluZyB0aGVtIHRvIGRp c2suDQoNCg0KDQotLQ0KDQpSdW0gbWFpbGluZyBsaXN0DQoNClJ1bUBpZXRmLm9yZzxtYWlsdG86 UnVtQGlldGYub3JnPg0KDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J1 bQ0K --_000_BYAPR04MB49831BE0D5B16E3DC64433C9A3020BYAPR04MB4983namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgN Cgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28t c3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJp Zjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEu MGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2Vj dGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVm YXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48 IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxv OmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwh W2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5r PSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkJyaWFuLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BZG1pdHRlZGx5IEkgZG8gbm90IGZ1 bGx5IHVuZGVyc3RhbmQgY2VydGlmaWNhdGVzIGFuZCBhdXRoZW50aWNhdGlvbiBidXQgd291bGQg Y2xpZW50IGNlcnRpZmljYXRlcyBvciBtdXR1YWwgYXV0aGVudGljYXRpb24gd2l0aCBhIHNoYXJl ZCBzZWNyZXQgd29yayBoZXJlPzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGFuayB5b3UuPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkV1Z2VuZTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6bmF2eSI+Q09ORklERU5USUFMSVRZIE5PVElDRS48L3NwYW4+PC9i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjpuYXZ5Ij4gVGhpcyBlLW1haWwgdHJhbnNtaXNzaW9uLCBhbmQg YW55IGRvY3VtZW50cywgZmlsZXMgb3INCiBwcmV2aW91cyBlLW1haWwgbWVzc2FnZXMgYXR0YWNo ZWQgdG8gaXQsIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBhbmQgcHJvcHJpZXRhcnkgaW5mb3Jt YXRpb24uIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIG9yIGEgcGVyc29u IHJlc3BvbnNpYmxlIGZvciBkZWxpdmVyaW5nIGl0IHRvIHRoZSBpbnRlbmRlZCByZWNpcGllbnQs IHlvdSBhcmUgaGVyZWJ5IG5vdGlmaWVkIHRoYXQgYW55IGRpc2Nsb3N1cmUsIGNvcHlpbmcsDQog ZGlzdHJpYnV0aW9uIG9yIHVzZSBvZiBhbnkgb2YgdGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBp biBvciBhdHRhY2hlZCB0byB0aGlzIG1lc3NhZ2UgaXMgU1RSSUNUTFkgUFJPSElCSVRFRC4gSWYg eW91IGhhdmUgcmVjZWl2ZWQgdGhpcyB0cmFuc21pc3Npb24gaW4gZXJyb3IsIHBsZWFzZSBpbW1l ZGlhdGVseSBub3RpZnkgbWUgYnkgcmVwbHkgZS1tYWlsIGF0DQo8L3NwYW4+PGEgaHJlZj0ibWFp bHRvOmVjaHJpc3RlbnNlbkBzb3JlbnNvbi5jb20iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+ZWNocmlzdGVuc2Vu QHNvcmVuc29uLmNvbTwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250 LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOm5hdnkiPiBvciBieSB0 ZWxlcGhvbmUgYXQgKzEgKDgwMSkgMjg3LTk0MTksDQogYW5kIGRlc3Ryb3kgdGhlIG9yaWdpbmFs IHRyYW5zbWlzc2lvbiBhbmQgaXRzIGF0dGFjaG1lbnRzIHdpdGhvdXQgcmVhZGluZyB0aGVtIG9y IHNhdmluZyB0aGVtIHRvIGRpc2suPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQi PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+RnJvbTo8L2I+IEJyaWFuIFJvc2Vu ICZsdDtickBicmlhbnJvc2VuLm5ldCZndDsgPGJyPg0KPGI+U2VudDo8L2I+IFdlZG5lc2RheSwg U2VwdGVtYmVyIDMwLCAyMDIwIDU6NDcgUE08YnI+DQo8Yj5Ubzo8L2I+IEV1Z2VuZSBDaHJpc3Rl bnNlbiAmbHQ7ZWNocmlzdGVuc2VuQHNvcmVuc29uLmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+IHJ1 bUBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW1J1bV0gW0VYVF0gUlVNIHNlY3Vy aXR5IG1vZGVsPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpyZWQi PltFWFRFUk5BTF08L3NwYW4+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+SSB0aGluayB3ZSB1bmRlcnN0YW5kIHdoeSB5b3Ugd2FudCBpdC4gV2hhdCB3 ZSBkb27igJl0IHVuZGVyc3RhbmQgaXMgd2hhdCBtZWNoYW5pc20gd291bGQgcHJvdmlkZSBpdC4g SSBhbSBnZW5lcmFsbHkgYXdhcmUgb2YgdGhpcyBjbGFzcyBvZiBwcm9ibGVtIGFuZCBJ4oCZbSBu b3QgYXdhcmUgb2YgYSBzb2x1dGlvbiB0aGF0IHdpbGwgd29yay4mbmJzcDsgU28gd2hhdCB3ZSBu ZWVkIGlzIGEgc3VnZ2VzdGVkIG1lY2hhbmlzbQ0KIHRoYXQgcHJvdmlkZXMgdGhlIGFzc3VyYW5j ZSB5b3Ugd2FudCB0aGF0IGlzIHRlY2huaWNhbGx5IHNvdW5kLiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5CcmlhbjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFdlZCwgU2VwIDMw LCAyMDIwIGF0IDY6MzAgUE0gRXVnZW5lIENocmlzdGVuc2VuICZsdDs8YSBocmVmPSJtYWlsdG86 ZWNocmlzdGVuc2VuQHNvcmVuc29uLmNvbSI+ZWNocmlzdGVuc2VuQHNvcmVuc29uLmNvbTwvYT4m Z3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4g MGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5UaGFua3MgZm9yIGNvbnNp ZGVyaW5nIGhvdyB3ZSBtaWdodCBpbXBsZW1lbnQgdGhpcyBzZWN1cml0eSBtZWNoYW5pc20uJm5i c3A7IE1heSBJIGFkZCBteSB2b2ljZSB0aGF0IGl0IGlzIGVzc2VudGlhbCB0aGF0IHdlIGZpbmQg YW4gb3B0aW9uIGZvciBwcm92aWRpbmcgdGhpcyBkZXNpcmVkIHNlY3VyaXR5LCB3aGF0ZXZlciBp dCBpcy4mbmJzcDsgSXQgY291bGQgYmUgZGV0cmltZW50YWwNCiB0byB0aGUgVlJTIHByb3ZpZGVy cyB0byBoYXZlIFVBcyBvdXQgdGhlcmUsIHdpdGggdGhlIGFiaWxpdHkgdG8gcmVnaXN0ZXIgd2l0 aCBWUlMgcHJvdmlkZXJzIHdpdGhvdXQgZmlyc3QgYmVpbmcgZnVsbHkgdmV0dGVkLiZuYnNwOyBJ dCBpcyBvdXIgcHJhY3RpY2UgYW55dGltZSB3ZSBtYWtlIHVwZGF0ZXMgdG8gb3VyIFVBcyB0byB0 ZXN0IGhvdyB0aGV5IHdvcmsgd2l0aCBvdXIgVUFTIGJlZm9yZSB3ZSBldmVyIHJlbGVhc2UgdGhl IG5ldyBVQSBzb2Z0d2FyZQ0KIGludG8gb3VyIHByb2R1Y3Rpb24gZW52aXJvbm1lbnQuJm5ic3A7 IFdlIG9ubHkgd2FudCBVQXMgcmVnaXN0ZXJpbmcgdGhhdCBoYXZlIHVuZGVyZ29uZSB0aGlzIHJp Z29yb3VzIHRlc3Rpbmcgd2l0aCBvdXIgc3lzdGVtcyBhbmQgdGhlbiBvbmx5IHdpdGggdXNlcnMg d2hpY2ggd2UgaGF2ZSBhd2FyZW5lc3Mgb2YuPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KVGhhbmtz LCA8YnI+DQo8YnI+DQpFdWdlbmUgQ2hyaXN0ZW5zZW48YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQpD T05GSURFTlRJQUxJVFkgTk9USUNFLiBUaGlzIGUtbWFpbCB0cmFuc21pc3Npb24sIGFuZCBhbnkg ZG9jdW1lbnRzLCBmaWxlcyBvciBwcmV2aW91cyBlLW1haWwgbWVzc2FnZXMgYXR0YWNoZWQgdG8g aXQsIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBhbmQgcHJvcHJpZXRhcnkgaW5mb3JtYXRpb24u IElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIG9yIGEgcGVyc29uIHJlc3Bv bnNpYmxlIGZvciBkZWxpdmVyaW5nIGl0IHRvDQogdGhlIGludGVuZGVkIHJlY2lwaWVudCwgeW91 IGFyZSBoZXJlYnkgbm90aWZpZWQgdGhhdCBhbnkgZGlzY2xvc3VyZSwgY29weWluZywgZGlzdHJp YnV0aW9uIG9yIHVzZSBvZiBhbnkgb2YgdGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiBvciBh dHRhY2hlZCB0byB0aGlzIG1lc3NhZ2UgaXMgU1RSSUNUTFkgUFJPSElCSVRFRC4gSWYgeW91IGhh dmUgcmVjZWl2ZWQgdGhpcyB0cmFuc21pc3Npb24gaW4gZXJyb3IsIHBsZWFzZSBpbW1lZGlhdGVs eQ0KIG5vdGlmeSBtZSBieSByZXBseSBlLW1haWwgYXQgPGEgaHJlZj0ibWFpbHRvOmVjaHJpc3Rl bnNlbkBzb3JlbnNvbi5jb20iIHRhcmdldD0iX2JsYW5rIj4NCmVjaHJpc3RlbnNlbkBzb3JlbnNv bi5jb208L2E+IG9yIGJ5IHRlbGVwaG9uZSBhdCArMSAoODAxKSAyODctOTQxOSwgYW5kIGRlc3Ry b3kgdGhlIG9yaWdpbmFsIHRyYW5zbWlzc2lvbiBhbmQgaXRzIGF0dGFjaG1lbnRzIHdpdGhvdXQg cmVhZGluZyB0aGVtIG9yIHNhdmluZyB0aGVtIHRvIGRpc2suPGJyPg0KPGJyPg0KPGJyPg0KPGJy Pg0KLS0gPGJyPg0KPGJyPg0KUnVtIG1haWxpbmcgbGlzdDxicj4NCjxicj4NCjxhIGhyZWY9Im1h aWx0bzpSdW1AaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5SdW1AaWV0Zi5vcmc8L2E+PGJyPg0K PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydW0i IHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J1 bTwvYT48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_BYAPR04MB49831BE0D5B16E3DC64433C9A3020BYAPR04MB4983namp_-- From nobody Thu Oct 15 15:29:55 2020 Return-Path: X-Original-To: rum@ietfa.amsl.com Delivered-To: rum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17A143A0CF8 for ; Thu, 15 Oct 2020 15:29:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.214 X-Spam-Level: X-Spam-Status: No, score=-2.214 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, NICE_REPLY_A=-0.213, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=alum.mit.edu 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 Xs8PrSnlMWF3 for ; Thu, 15 Oct 2020 15:29:46 -0700 (PDT) Received: from NAM10-DM6-obe.outbound.protection.outlook.com (mail-dm6nam10on2060.outbound.protection.outlook.com [40.107.93.60]) (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 0E1C63A0CF1 for ; Thu, 15 Oct 2020 15:29:39 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=maJYSrHnFXxbO7Ox+KrsR8wll6ZwFwtsx7daHtxhynrtNWfg7xinK9Zlftvz5EtS8VP4MdMFz8P00gCl/NtO+N3hJp7iZAjkpRR2t6VMYtecRlO7JpLzu3wOGFiTpNReNeM5N5uw6xkwy2TYnhdwUkd7Xc/zwrIFk56GkdwFgbP41f29H2fTdUbGH/oHU/Wfc2zz0IvjCibe+Ex6U0ZwMMzW99Y8uBkZ8r8XzMVM9DWzvi7POXosXNVFXMPs1aI1htR4DM+qYt1X+2nK9ogFw7/7LkQy8ImSSNzkwY2ztsdoYr4HoL/yMroLTNZKSWbrt4cEbnHoOu2F2tn3HtlGAw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=EVcS+NUSxDgmdmMhOPjSIcS8B0cH8938aeh8gvBozl4=; b=jVUBJm+fL/PXR9dE877mm2uIWqI7GSHdzlm/LkZYlzEvtsBfMUoYzd4gKL8+8DOi1CqyMcBm1GgITVVoNk4v9nYMeZMpz6Pe4/bBBxF01zNa0mXNF2oH7cvwqo7CTdpoa9//1d/KpwTdpkuEHO4IGrEl/Y50+v7S93lFrb5YG2fkU+HZ5h8aplqv/eDE0E3I9zjwBl0/ppurk3CcKUjhV0C1Gxp+P/xSIJBj0rfnvfkbNYNDSs5YdZAQ4ygAMP6fU3CmGcnSCCazlzscnTQzwsx5sclwWXGhKC7NRTOvtUJTxvY5TvHaqN31zgi7vmAu9znc59JTKOUTHTG7l51dZg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 18.7.68.33) smtp.rcpttodomain=ietf.org smtp.mailfrom=alum.mit.edu; dmarc=bestguesspass action=none header.from=alum.mit.edu; dkim=none (message not signed); arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alum.mit.edu; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=EVcS+NUSxDgmdmMhOPjSIcS8B0cH8938aeh8gvBozl4=; b=KGI6HfwkceQX5qcJBQ29lUcBbtecX/7Bnvnoe3byF0HgG5uw8mvbGBJ6xdF5OXOHobeS3H3sKJwrhxi8nCiUMZA1eCrGdTVP2oNineIu15gixSygfdu2gQ8JYKhgV8yEsfnat7jpeOqMyDqUP26VyLf9o92kTsLY7AitoLRnxC4= Received: from SN6PR01CA0003.prod.exchangelabs.com (2603:10b6:805:b6::16) by CY4PR1201MB0086.namprd12.prod.outlook.com (2603:10b6:910:17::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3455.25; Thu, 15 Oct 2020 22:29:34 +0000 Received: from SN1NAM02FT025.eop-nam02.prod.protection.outlook.com (2603:10b6:805:b6:cafe::62) by SN6PR01CA0003.outlook.office365.com (2603:10b6:805:b6::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3477.21 via Frontend Transport; Thu, 15 Oct 2020 22:29:34 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 18.7.68.33) smtp.mailfrom=alum.mit.edu; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=alum.mit.edu; Received-SPF: Pass (protection.outlook.com: domain of alum.mit.edu designates 18.7.68.33 as permitted sender) receiver=protection.outlook.com; client-ip=18.7.68.33; helo=outgoing-alum.mit.edu; Received: from outgoing-alum.mit.edu (18.7.68.33) by SN1NAM02FT025.mail.protection.outlook.com (10.152.72.87) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3477.21 via Frontend Transport; Thu, 15 Oct 2020 22:29:33 +0000 Received: from PaulKyzivatsMBP.localdomain (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.14.7/8.12.4) with ESMTP id 09FMTWhH028759 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT) for ; Thu, 15 Oct 2020 18:29:32 -0400 To: rum@ietf.org References: <159838856681.32208.2945571627178413540@ietfa.amsl.com> <3757_1601140882_5F6F7891_3757_32_1_a4a62f53-1571-56ec-35b9-7faecd4fa480@alum.mit.edu> <927a8854-51b9-c768-ee1e-5d0c4b76a45f@alum.mit.edu> From: Paul Kyzivat Message-ID: <4d6ba97f-a83d-3d36-14a9-c6e84dd5b874@alum.mit.edu> Date: Thu, 15 Oct 2020 18:29:31 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:78.0) Gecko/20100101 Thunderbird/78.3.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 09f3a256-55b7-4d18-c7fd-08d87159cab2 X-MS-TrafficTypeDiagnostic: CY4PR1201MB0086: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: qawFJVxTeNXNklxNc8JtSFbxJWtw2ekn97s9gqMQj0ipHfuksiIuCwsX2fNRN4APVH50BhNDrlc8h18lnv3gAwp58PhW8MudD9k6x3Q3efYVO6eXWAQNSaDRcNs3r4dqbU3kfKpkJyUmdu29jLjGX8PFmkpKf0nuN4xnjDahyL8jxvyVKziRtJGmC/ujn0GaAPK0p996J1/e/sBmgK4KG6lP1bNxGFD+e4EGPKevl+3+8j6LLSb333wzyaOCZg6s7TJItIp6SnGcM94ABFxCZnKOkzVd90Le37Jjm0sGfYVbrDvjgvDm1+hMfcFkkDG5XsOgGXGuAjjOkTdtc++b4yo+msetMMslkeDKyA2FlzLH79InEWexfQ11Iyg98iK/KU5xxE7L4eDYWC6ADrh+89/ePsGoXKiY6k7zpWUxvjMXpuDNi29Sv6LgMUi9vGlSjKdyV2qWelAcQQeRQ1mOoMuTqbE8YJpel2h4KgAD5F06zQSNooOcJ12cPwuSCwDA X-Forefront-Antispam-Report: CIP:18.7.68.33; CTRY:US; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:outgoing-alum.mit.edu; PTR:outgoing-alum.mit.edu; CAT:NONE; SFS:(396003)(376002)(136003)(39860400002)(346002)(46966005)(83380400001)(786003)(82740400003)(956004)(316002)(2616005)(7596003)(47076004)(70206006)(70586007)(26005)(36906005)(53546011)(356005)(336012)(82310400003)(186003)(31686004)(86362001)(8676002)(2906002)(31696002)(6916009)(75432002)(15650500001)(966005)(478600001)(5660300002)(8936002)(43740500002); DIR:OUT; SFP:1101; X-OriginatorOrg: alum.mit.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Oct 2020 22:29:33.7865 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 09f3a256-55b7-4d18-c7fd-08d87159cab2 X-MS-Exchange-CrossTenant-Id: 3326b102-c043-408b-a990-b89e477d582f X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3326b102-c043-408b-a990-b89e477d582f; Ip=[18.7.68.33]; Helo=[outgoing-alum.mit.edu] X-MS-Exchange-CrossTenant-AuthSource: SN1NAM02FT025.eop-nam02.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR1201MB0086 Archived-At: Subject: Re: [Rum] [EXT] RUM security model X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2020 22:29:54 -0000 Eugene, On 10/15/20 3:30 PM, Eugene Christensen wrote: > Brian, > > Admittedly I do not fully understand certificates and authentication but > would client certificates or mutual authentication with a shared secret > work here? I'm also not a security expert. To my understanding, the key problem is that you want a proof that an implementation has passed some sort of test. That is more or less equivalent to having a special certification authority that is able to assign a certificate based on the passing of a test. But for the system to work that certificate needs to be bound to the entity (hw/sw) that passed the test. It can't be possible to transfer that certificate to a different device. A possible alternative would be for each provider to have its own test service. When a user gets a new device/application, as part of the initial registration of their device with the provider, this test would be run. Then the result of that would be granting of credentials for that device to access that provider's system. Thanks, Paul > Thank you. > > Eugene > > *CONFIDENTIALITY NOTICE.*This e-mail transmission, and any documents, > files or previous e-mail messages attached to it, may contain > confidential and proprietary information. If you are not the intended > recipient, or a person responsible for delivering it to the intended > recipient, you are hereby notified that any disclosure, copying, > distribution or use of any of the information contained in or attached > to this message is STRICTLY PROHIBITED. If you have received this > transmission in error, please immediately notify me by reply e-mail at > echristensen@sorenson.com or by > telephone at +1 (801) 287-9419, and destroy the original transmission > and its attachments without reading them or saving them to disk. > > *From:* Brian Rosen > *Sent:* Wednesday, September 30, 2020 5:47 PM > *To:* Eugene Christensen > *Cc:* rum@ietf.org > *Subject:* Re: [Rum] [EXT] RUM security model > > [EXTERNAL] > > I think we understand why you want it. What we don’t understand is what > mechanism would provide it. I am generally aware of this class of > problem and I’m not aware of a solution that will work.  So what we need > is a suggested mechanism that provides the assurance you want that is > technically sound. > > Brian > > On Wed, Sep 30, 2020 at 6:30 PM Eugene Christensen > > wrote: > > Thanks for considering how we might implement this security > mechanism.  May I add my voice that it is essential that we find an > option for providing this desired security, whatever it is.  It > could be detrimental to the VRS providers to have UAs out there, > with the ability to register with VRS providers without first being > fully vetted.  It is our practice anytime we make updates to our UAs > to test how they work with our UAS before we ever release the new UA > software into our production environment.  We only want UAs > registering that have undergone this rigorous testing with our > systems and then only with users which we have awareness of. > > > > Thanks, > > Eugene Christensen > > > > CONFIDENTIALITY NOTICE. This e-mail transmission, and any documents, > files or previous e-mail messages attached to it, may contain > confidential and proprietary information. If you are not the > intended recipient, or a person responsible for delivering it to the > intended recipient, you are hereby notified that any disclosure, > copying, distribution or use of any of the information contained in > or attached to this message is STRICTLY PROHIBITED. If you have > received this transmission in error, please immediately notify me by > reply e-mail at echristensen@sorenson.com > or by telephone at +1 (801) > 287-9419, and destroy the original transmission and its attachments > without reading them or saving them to disk. > > > > -- > > Rum mailing list > > Rum@ietf.org > > https://www.ietf.org/mailman/listinfo/rum > > > From nobody Thu Oct 15 16:52:46 2020 Return-Path: X-Original-To: rum@ietfa.amsl.com Delivered-To: rum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0048F3A0CE1 for ; Thu, 15 Oct 2020 16:52:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.888 X-Spam-Level: X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=brianrosen-net.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 WotNRPbLB1An for ; Thu, 15 Oct 2020 16:52:42 -0700 (PDT) Received: from mail-il1-x12c.google.com (mail-il1-x12c.google.com [IPv6:2607:f8b0:4864:20::12c]) (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 A5DA53A0AE4 for ; Thu, 15 Oct 2020 16:52:42 -0700 (PDT) Received: by mail-il1-x12c.google.com with SMTP id t18so524175ilo.12 for ; Thu, 15 Oct 2020 16:52:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=cXs6ZaqHUaBkKBcaW2ZDtavBz71MH5zN78kbPO1R0dY=; b=SBzOaOH21DwB303sxH+2cE+aIISCN1FGWhSQ3OTMyfkNfrqiNwzztLgs9TJBuVcLFo Xoy4wngvp9jwVF+5/q1TBZADbmd1UuiFaLclh7krhEvCn4yAu8wwakjA2H4pEP2YAmXs 9ZM7sDztc1YBbCMViLtY3ijbvvEvPQQqqWRSKGNZf8sMtcV1l3blzvSX+0Xj0xvPQMa+ ognjcnIk38Kjukg1S06Nh7a+Odq3VC0HbyG0gN5p7NxraXVCm3I2olG25OalVuwIznUX Jfa2X7R6+2udqM7EZrJPo1eIkPXKF3JP6nzoYTxl2Ah9IfEi5zsQ7zkNKFzgc1AUf0KI QppQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=cXs6ZaqHUaBkKBcaW2ZDtavBz71MH5zN78kbPO1R0dY=; b=Mgpsr/ht0x7/VULfdtzAIzl3xm56TH6zQZ2ZcqL4nDJH+K2Sb64D/n+f5Hb+dHBQTq SpPL4+28374Oh6HsH1vx17RFvCKPH55byJEze9bub/lbpDtYKH0T8tFek4T/1cfO3liO dYbdp/3J2jWz+QejAvujhJMpxC8Gr91VWdHcLt419I5N6CK1Rbs7JMTcY8eDV2+2f061 jVPLkWoED4ZXGNxEW3d5onzOeoWWxoS2Sv4IrXYtM2plCSaaL5O/eqt49zzhc0jfEGIM 0Te7JXv/LmR2PBSpjIM8vlbGsOYD9rgxBuBTSrijkUbY7x5VLMKoy+PcOmPy5gRKEty6 fLNw== X-Gm-Message-State: AOAM5334goEKKxl+Ey10yr2hPD3GpWNLKt5E25Fn0TisT+39ePXjeQcP i7jxYXFbB9A2c27Oyc62W6lZ9AaL95kawuwB X-Google-Smtp-Source: ABdhPJyj31t9sr0VHoC0E0B1yXMLyMsiiRPhcb+Tl7Y7k3ZUaQq9IASjTE7Ub3aw/9/VTdrozhXJ4g== X-Received: by 2002:a92:c206:: with SMTP id j6mr809547ilo.16.1602805961442; Thu, 15 Oct 2020 16:52:41 -0700 (PDT) Received: from [192.168.86.43] (dynamic-acs-24-154-119-158.zoominternet.net. [24.154.119.158]) by smtp.gmail.com with ESMTPSA id z200sm700473iof.47.2020.10.15.16.52.40 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 15 Oct 2020 16:52:40 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Brian Rosen Mime-Version: 1.0 (1.0) Date: Thu, 15 Oct 2020 19:52:39 -0400 Message-Id: <7A11F680-9EA6-4477-9BD8-6A7755AD0054@brianrosen.net> References: <4d6ba97f-a83d-3d36-14a9-c6e84dd5b874@alum.mit.edu> Cc: rum@ietf.org In-Reply-To: <4d6ba97f-a83d-3d36-14a9-c6e84dd5b874@alum.mit.edu> To: Paul Kyzivat X-Mailer: iPhone Mail (18A393) Archived-At: Subject: Re: [Rum] [EXT] RUM security model X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2020 23:52:45 -0000 I don=E2=80=99t think even that would work because there isn=E2=80=99t any w= ay to know that the app that was approved is the app that is being used.=20 What systems like iOS does is rely on the fact that you can=E2=80=99t downlo= ad and run an app that hasn=E2=80=99t been vetted. The code is signed and th= e signature is checked every time the app starts. We don=E2=80=99t have an e= nvironment like that. We can=E2=80=99t control what is downloaded and we ca= n=E2=80=99t check signatures.=20 I don=E2=80=99t think there is a reliable way to do this. If someone has an i= dea, please explain it, but we can=E2=80=99t be in a =E2=80=9Cyou do somethi= ng=E2=80=9D position without a clue as to how.=20 Now, if the app was an iOS app, then the right thing happens. There are few o= ther systems that are wired down like that. Android, for example, allows you= to download and run from arbitrary sites if the device is configured to all= ow that.=20 Brian > On Oct 15, 2020, at 6:30 PM, Paul Kyzivat wrote: >=20 > =EF=BB=BFEugene, >=20 >> On 10/15/20 3:30 PM, Eugene Christensen wrote: >> Brian, >> Admittedly I do not fully understand certificates and authentication but w= ould client certificates or mutual authentication with a shared secret work h= ere? >=20 > I'm also not a security expert. To my understanding, the key problem is th= at you want a proof that an implementation has passed some sort of test. Tha= t is more or less equivalent to having a special certification authority tha= t is able to assign a certificate based on the passing of a test. But for th= e system to work that certificate needs to be bound to the entity (hw/sw) th= at passed the test. It can't be possible to transfer that certificate to a d= ifferent device. >=20 > A possible alternative would be for each provider to have its own test ser= vice. When a user gets a new device/application, as part of the initial regi= stration of their device with the provider, this test would be run. Then the= result of that would be granting of credentials for that device to access t= hat provider's system. >=20 > Thanks, > Paul >=20 >> Thank you. >> Eugene >> *CONFIDENTIALITY NOTICE.*This e-mail transmission, and any documents, fil= es or previous e-mail messages attached to it, may contain confidential and p= roprietary information. If you are not the intended recipient, or a person r= esponsible for delivering it to the intended recipient, you are hereby notif= ied that any disclosure, copying, distribution or use of any of the informat= ion contained in or attached to this message is STRICTLY PROHIBITED. If you h= ave received this transmission in error, please immediately notify me by rep= ly e-mail at echristensen@sorenson.com or b= y telephone at +1 (801) 287-9419, and destroy the original transmission and i= ts attachments without reading them or saving them to disk. >> *From:* Brian Rosen >> *Sent:* Wednesday, September 30, 2020 5:47 PM >> *To:* Eugene Christensen >> *Cc:* rum@ietf.org >> *Subject:* Re: [Rum] [EXT] RUM security model >> [EXTERNAL] >> I think we understand why you want it. What we don=E2=80=99t understand i= s what mechanism would provide it. I am generally aware of this class of pro= blem and I=E2=80=99m not aware of a solution that will work. So what we nee= d is a suggested mechanism that provides the assurance you want that is tech= nically sound. >> Brian >> On Wed, Sep 30, 2020 at 6:30 PM Eugene Christensen > wrote: >> Thanks for considering how we might implement this security >> mechanism. May I add my voice that it is essential that we find an >> option for providing this desired security, whatever it is. It >> could be detrimental to the VRS providers to have UAs out there, >> with the ability to register with VRS providers without first being >> fully vetted. It is our practice anytime we make updates to our UAs >> to test how they work with our UAS before we ever release the new UA >> software into our production environment. We only want UAs >> registering that have undergone this rigorous testing with our >> systems and then only with users which we have awareness of. >> Thanks, >> Eugene Christensen >> CONFIDENTIALITY NOTICE. This e-mail transmission, and any documents, >> files or previous e-mail messages attached to it, may contain >> confidential and proprietary information. If you are not the >> intended recipient, or a person responsible for delivering it to the >> intended recipient, you are hereby notified that any disclosure, >> copying, distribution or use of any of the information contained in >> or attached to this message is STRICTLY PROHIBITED. If you have >> received this transmission in error, please immediately notify me by >> reply e-mail at echristensen@sorenson.com >> or by telephone at +1 (801) >> 287-9419, and destroy the original transmission and its attachments >> without reading them or saving them to disk. >> -- Rum mailing list >> Rum@ietf.org >> https://www.ietf.org/mailman/listinfo/rum >> >=20 > --=20 > Rum mailing list > Rum@ietf.org > https://www.ietf.org/mailman/listinfo/rum From nobody Thu Oct 15 17:19:50 2020 Return-Path: X-Original-To: rum@ietfa.amsl.com Delivered-To: rum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 479EC3A0D32 for ; Thu, 15 Oct 2020 17:19:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.214 X-Spam-Level: X-Spam-Status: No, score=-2.214 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, NICE_REPLY_A=-0.213, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=alum.mit.edu 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 FSOPKaB2Fgzm for ; Thu, 15 Oct 2020 17:19:47 -0700 (PDT) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-eopbgr760073.outbound.protection.outlook.com [40.107.76.73]) (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 7B74A3A0D2C for ; Thu, 15 Oct 2020 17:19:47 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=TxX3XsGI/RJiDP/iKAjJUCGyk6nEUgQ3zwxtNg5YFJ7Bl582x3j0wVew06wDXxbJ7PAhue69R+1ncmqeuwKAzmW1ZjI35J9xm48MKiRnpXB5KOdJfFSPr8m+tV1xMwKoOS/vQGU80HXVDSk5lD3F2OuTL7ekL9Ma+tP56ChYygpIvWZXMaTsp+CV8xwvzfRYQgb3Gm/TcqEcwfzAbCKFjjM2DNcwwYyolLafr0aHsEmwR++OiElj6rb9/48LXKuF3ZlMwKIHZ0YeHOj2qDqiGOKA/O0hAN0S0/GLM9Hf3BaQl4S9kbcvrD9oDfeeUZjeqF0ZnJuJ2wMxx90agH+mjw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=9+pw9854nO3xJQBqKSJkoi5Q8xk7oiGmXrDd1kVW+vs=; b=C+aoCfLpAo5qHJabLS/cIw+Goo0D4cCtwigtZpi/X/I1Uf/lCqvIqg/B+ZFE1e8Rubr3d36RVCsLJe/JrCnsxlcH0MiAQBR7d9YprBkfPgC45iN72kel95DueG94eZwKTZYaFYdyqBUEqKVxQKPDvPzi8N8Wag+mNOZ8odk3VmFzt/B4pL2ckNkYnwYKHNVAFxBkpO3/y/kEIj3dg6Ta18JCqaq8iVVJ6Fy3ri6cCHxA5iPDLucNS6aEQpUhcIPVGyfolTPtyv+9Ztz03FOx3XAQulD0gai9lqL623P6iukbejA3r4rscxDZWZjnO1c+AZ5Iq7OB35+lv4/po9ZHYg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none (sender ip is 18.7.68.33) smtp.rcpttodomain=brianrosen.net smtp.mailfrom=alum.mit.edu; dmarc=none action=none header.from=alum.mit.edu; dkim=none (message not signed); arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alum.mit.edu; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=9+pw9854nO3xJQBqKSJkoi5Q8xk7oiGmXrDd1kVW+vs=; b=jKfJkDGF64A2CW4ptTUKO152UZXz3sIt/bpFpLy1isW6EaNm/THSNep2pcDatV/qy0C0uhV5xTKZYQ1V1tLqv2qAlAprwaRWuQC1NF+atiSSo2ryEGThFlmLvZ0mxPlaQGRJ0YM9/wYtLgsTG0uyOXaWr2NWiSSEgIf43ZjpM+s= Received: from SN4PR0201CA0008.namprd02.prod.outlook.com (2603:10b6:803:2b::18) by CY4PR12MB1605.namprd12.prod.outlook.com (2603:10b6:910:f::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3477.20; Fri, 16 Oct 2020 00:19:40 +0000 Received: from SN1NAM02FT049.eop-nam02.prod.protection.outlook.com (2603:10b6:803:2b:cafe::64) by SN4PR0201CA0008.outlook.office365.com (2603:10b6:803:2b::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3477.21 via Frontend Transport; Fri, 16 Oct 2020 00:19:40 +0000 X-MS-Exchange-Authentication-Results: spf=none (sender IP is 18.7.68.33) smtp.mailfrom=alum.mit.edu; brianrosen.net; dkim=none (message not signed) header.d=none;brianrosen.net; dmarc=none action=none header.from=alum.mit.edu; Received-SPF: None (protection.outlook.com: alum.mit.edu does not designate permitted sender hosts) Received: from outgoing-alum.mit.edu (18.7.68.33) by SN1NAM02FT049.mail.protection.outlook.com (10.152.72.166) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3477.21 via Frontend Transport; Fri, 16 Oct 2020 00:19:40 +0000 Received: from PaulKyzivatsMBP.localdomain (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.14.7/8.12.4) with ESMTP id 09G0JbGW004217 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Thu, 15 Oct 2020 20:19:38 -0400 To: Brian Rosen Cc: rum@ietf.org References: <4d6ba97f-a83d-3d36-14a9-c6e84dd5b874@alum.mit.edu> <7A11F680-9EA6-4477-9BD8-6A7755AD0054@brianrosen.net> From: Paul Kyzivat Message-ID: <7fdb95e6-e954-7275-60f7-462cf07eff0e@alum.mit.edu> Date: Thu, 15 Oct 2020 20:19:37 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:78.0) Gecko/20100101 Thunderbird/78.3.2 MIME-Version: 1.0 In-Reply-To: <7A11F680-9EA6-4477-9BD8-6A7755AD0054@brianrosen.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: c582b5b3-7a5b-427f-f9a5-08d871692c63 X-MS-TrafficTypeDiagnostic: CY4PR12MB1605: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 0tg5yf7wO9K2FrihyWPJZSXlri6t1YjXaP9hRyhco5RGqrWckalAgVf62lqjrZkeRKFYjgjRmARoLElGfVkdR4tJWZfaBMUrvruynGU9dFzcBe9sgvuBaXiz9gN//7k/B0k3po4yJEQU6C+naTOSUFk8whqPnbSE9zTlTLZNVMZFhxyjews55VXxNjNfNhz/qy9aNz+ynu7yRf5iBKHxtVIZXUPDziMR+Kj1IMqYyrI2toypCxgjlERsFzGqIxb3I9XopSoYmdnjIrz00naCtuBWnXXaRtavRnF+D4I6VHxYRKGiEkEFtacP+jaD67nw2rCQUfKvVkbkcSW992pMB4t5OqLL8ucYTnODy6UVib8NvVqrUBe293bTYxH0hWsMv8bhpllNYafw8sE+3d/vh8I++DO1dB9WJ11/2zjnriNQwPRkPaydk5VIMwwSXh1AEiOu7pI2g8bYFVhmyKOPIlRfaxAgctOUS48TUTi865GEmdebic0lMDgD8WRE9Ynw X-Forefront-Antispam-Report: CIP:18.7.68.33; CTRY:US; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:outgoing-alum.mit.edu; PTR:outgoing-alum.mit.edu; CAT:NONE; SFS:(136003)(376002)(396003)(346002)(39860400002)(46966005)(356005)(478600001)(36906005)(8676002)(8936002)(86362001)(316002)(83380400001)(7596003)(47076004)(2906002)(4326008)(82740400003)(786003)(82310400003)(5660300002)(956004)(53546011)(2616005)(31696002)(966005)(336012)(186003)(75432002)(70206006)(6916009)(26005)(70586007)(15650500001)(31686004)(43740500002); DIR:OUT; SFP:1101; X-OriginatorOrg: alum.mit.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Oct 2020 00:19:40.1160 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: c582b5b3-7a5b-427f-f9a5-08d871692c63 X-MS-Exchange-CrossTenant-Id: 3326b102-c043-408b-a990-b89e477d582f X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3326b102-c043-408b-a990-b89e477d582f; Ip=[18.7.68.33]; Helo=[outgoing-alum.mit.edu] X-MS-Exchange-CrossTenant-AuthSource: SN1NAM02FT049.eop-nam02.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR12MB1605 Archived-At: Subject: Re: [Rum] [EXT] RUM security model X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2020 00:19:49 -0000 On 10/15/20 7:52 PM, Brian Rosen wrote: > I don’t think even that would work because there isn’t any way to know that the app that was approved is the app that is being used. Yes, I guess you are right. But at least it would require the end user to enter into a conspiracy with the app developers, and be able to get the credential out of one app and into another. Thanks, Paul > What systems like iOS does is rely on the fact that you can’t download and run an app that hasn’t been vetted. The code is signed and the signature is checked every time the app starts. We don’t have an environment like that. We can’t control what is downloaded and we can’t check signatures. > I don’t think there is a reliable way to do this. If someone has an idea, please explain it, but we can’t be in a “you do something” position without a clue as to how. > > Now, if the app was an iOS app, then the right thing happens. There are few other systems that are wired down like that. Android, for example, allows you to download and run from arbitrary sites if the device is configured to allow that. > > Brian > > >> On Oct 15, 2020, at 6:30 PM, Paul Kyzivat wrote: >> >> Eugene, >> >>> On 10/15/20 3:30 PM, Eugene Christensen wrote: >>> Brian, >>> Admittedly I do not fully understand certificates and authentication but would client certificates or mutual authentication with a shared secret work here? >> >> I'm also not a security expert. To my understanding, the key problem is that you want a proof that an implementation has passed some sort of test. That is more or less equivalent to having a special certification authority that is able to assign a certificate based on the passing of a test. But for the system to work that certificate needs to be bound to the entity (hw/sw) that passed the test. It can't be possible to transfer that certificate to a different device. >> >> A possible alternative would be for each provider to have its own test service. When a user gets a new device/application, as part of the initial registration of their device with the provider, this test would be run. Then the result of that would be granting of credentials for that device to access that provider's system. >> >> Thanks, >> Paul >> >>> Thank you. >>> Eugene >>> *CONFIDENTIALITY NOTICE.*This e-mail transmission, and any documents, files or previous e-mail messages attached to it, may contain confidential and proprietary information. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are hereby notified that any disclosure, copying, distribution or use of any of the information contained in or attached to this message is STRICTLY PROHIBITED. If you have received this transmission in error, please immediately notify me by reply e-mail at echristensen@sorenson.com or by telephone at +1 (801) 287-9419, and destroy the original transmission and its attachments without reading them or saving them to disk. >>> *From:* Brian Rosen >>> *Sent:* Wednesday, September 30, 2020 5:47 PM >>> *To:* Eugene Christensen >>> *Cc:* rum@ietf.org >>> *Subject:* Re: [Rum] [EXT] RUM security model >>> [EXTERNAL] >>> I think we understand why you want it. What we don’t understand is what mechanism would provide it. I am generally aware of this class of problem and I’m not aware of a solution that will work. So what we need is a suggested mechanism that provides the assurance you want that is technically sound. >>> Brian >>> On Wed, Sep 30, 2020 at 6:30 PM Eugene Christensen > wrote: >>> Thanks for considering how we might implement this security >>> mechanism. May I add my voice that it is essential that we find an >>> option for providing this desired security, whatever it is. It >>> could be detrimental to the VRS providers to have UAs out there, >>> with the ability to register with VRS providers without first being >>> fully vetted. It is our practice anytime we make updates to our UAs >>> to test how they work with our UAS before we ever release the new UA >>> software into our production environment. We only want UAs >>> registering that have undergone this rigorous testing with our >>> systems and then only with users which we have awareness of. >>> Thanks, >>> Eugene Christensen >>> CONFIDENTIALITY NOTICE. This e-mail transmission, and any documents, >>> files or previous e-mail messages attached to it, may contain >>> confidential and proprietary information. If you are not the >>> intended recipient, or a person responsible for delivering it to the >>> intended recipient, you are hereby notified that any disclosure, >>> copying, distribution or use of any of the information contained in >>> or attached to this message is STRICTLY PROHIBITED. If you have >>> received this transmission in error, please immediately notify me by >>> reply e-mail at echristensen@sorenson.com >>> or by telephone at +1 (801) >>> 287-9419, and destroy the original transmission and its attachments >>> without reading them or saving them to disk. >>> -- Rum mailing list >>> Rum@ietf.org >>> https://www.ietf.org/mailman/listinfo/rum >>> >> >> -- >> Rum mailing list >> Rum@ietf.org >> https://www.ietf.org/mailman/listinfo/rum From nobody Thu Oct 15 17:24:47 2020 Return-Path: X-Original-To: rum@ietfa.amsl.com Delivered-To: rum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AC0B3A0D36 for ; Thu, 15 Oct 2020 17:24:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=brianrosen-net.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 Ng6YQaHTcE1N for ; Thu, 15 Oct 2020 17:24:43 -0700 (PDT) Received: from mail-qt1-x829.google.com (mail-qt1-x829.google.com [IPv6:2607:f8b0:4864:20::829]) (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 E1CD03A0D33 for ; Thu, 15 Oct 2020 17:24:42 -0700 (PDT) Received: by mail-qt1-x829.google.com with SMTP id c15so641511qtc.2 for ; Thu, 15 Oct 2020 17:24:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=vckQu6xMJ3+oqAklqe4RrN/nqV0t4JF6vmf6SLGwSxM=; b=InNEXxiJBYUA6k2uXhijzNdaJZK+ziHfeaGx6QI6RBDyE49gpww5J7qTJAwTxYMJcN wBfGtxgNJBpZbmU1S8x1TR1OKkKLCxAiUvsHGMUTmBrzDWNKdPbgDyaRSfTbWoyuthAz LFMWcT2uRLlM34gYdsYUwyZgMDf5xfPH7KcBG6J+rKmqLghIYZvuaZSUhI7tEPfaZs+H yU/4usYF+9la9qPDuC53+2liqx7UpU1Np+BRgkjFjhvc7zJtunuwJgkOTackgBpmXN0E UC3XMf79vqcuDns7g2jx7xkFVozKK2vsHGJbc8+LZK6NmB3DeitC5dV6W+dPj/8MGho6 idEA== 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=vckQu6xMJ3+oqAklqe4RrN/nqV0t4JF6vmf6SLGwSxM=; b=AeCE0YRH95cwBesrPmwulfyjya3OORvtkj1y0TKrSSbS4IpVNZ6b8IKAIDOvrH2kdW pOK6OUc5I2MQgPelOK/IIxVv9loAa2fPUrv7MDTRY/H9fauqkb9qQhW5SWDDP4VAzUwT XlwoQ1297l9xui4sOudvKaUjuk31L3+RWqJwdUZAbwtvseRBy27DGSPZsJFpg/0WK1yT Y2PHoPwosVqhIpyEvrUkr9Qn5PLB0Ihpubk0ws9vLJWjcBZb1GY/EQ8BXSXEmSiUKx7W XIh0y1Poo63qWAJpZLNCyYVCi56X2xQsSc3RnpASqF76a+SrQYENUGUhjQe8HxIpNy+3 qUCw== X-Gm-Message-State: AOAM532j9bFUaOkgPPUnBFwRjeUp+ee4Cf5BRoqlwm9gXhJykMcFi+ua QhS4sxSZZ51Fnqh+HJwPHoCpxtyS/a7osXQaM/gNdA== X-Google-Smtp-Source: ABdhPJyT8AYeypeNH3QtfSGKJL6r2z/tBRVwhYH3Gb7qCVRR/NGq0mmo8WkyHWSkdrhxZyLvUkPyBrP/D6kbks2qRYE= X-Received: by 2002:ac8:44bc:: with SMTP id a28mr951625qto.214.1602807881891; Thu, 15 Oct 2020 17:24:41 -0700 (PDT) MIME-Version: 1.0 References: <4d6ba97f-a83d-3d36-14a9-c6e84dd5b874@alum.mit.edu> <7A11F680-9EA6-4477-9BD8-6A7755AD0054@brianrosen.net> <7fdb95e6-e954-7275-60f7-462cf07eff0e@alum.mit.edu> In-Reply-To: <7fdb95e6-e954-7275-60f7-462cf07eff0e@alum.mit.edu> From: Brian Rosen Date: Thu, 15 Oct 2020 20:24:31 -0400 Message-ID: To: Paul Kyzivat Cc: rum@ietf.org Content-Type: multipart/alternative; boundary="000000000000719bc405b1becaff" Archived-At: Subject: Re: [Rum] [EXT] RUM security model X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2020 00:24:45 -0000 --000000000000719bc405b1becaff Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Nope, it just takes a hacker to create a piece of code that patches an app to look like another app. On Thu, Oct 15, 2020 at 8:19 PM Paul Kyzivat wrote: > On 10/15/20 7:52 PM, Brian Rosen wrote: > > I don=E2=80=99t think even that would work because there isn=E2=80=99t = any way to know > that the app that was approved is the app that is being used. > > Yes, I guess you are right. But at least it would require the end user > to enter into a conspiracy with the app developers, and be able to get > the credential out of one app and into another. > > Thanks, > Paul > > > What systems like iOS does is rely on the fact that you can=E2=80=99t d= ownload > and run an app that hasn=E2=80=99t been vetted. The code is signed and th= e > signature is checked every time the app starts. We don=E2=80=99t have an > environment like that. We can=E2=80=99t control what is downloaded and w= e can=E2=80=99t > check signatures. > > > I don=E2=80=99t think there is a reliable way to do this. If someone ha= s an > idea, please explain it, but we can=E2=80=99t be in a =E2=80=9Cyou do som= ething=E2=80=9D position > without a clue as to how. > > > > Now, if the app was an iOS app, then the right thing happens. There are > few other systems that are wired down like that. Android, for example, > allows you to download and run from arbitrary sites if the device is > configured to allow that. > > > > Brian > > > > > >> On Oct 15, 2020, at 6:30 PM, Paul Kyzivat > wrote: > >> > >> =EF=BB=BFEugene, > >> > >>> On 10/15/20 3:30 PM, Eugene Christensen wrote: > >>> Brian, > >>> Admittedly I do not fully understand certificates and authentication > but would client certificates or mutual authentication with a shared secr= et > work here? > >> > >> I'm also not a security expert. To my understanding, the key problem i= s > that you want a proof that an implementation has passed some sort of test= . > That is more or less equivalent to having a special certification authori= ty > that is able to assign a certificate based on the passing of a test. But > for the system to work that certificate needs to be bound to the entity > (hw/sw) that passed the test. It can't be possible to transfer that > certificate to a different device. > >> > >> A possible alternative would be for each provider to have its own test > service. When a user gets a new device/application, as part of the initia= l > registration of their device with the provider, this test would be run. > Then the result of that would be granting of credentials for that device = to > access that provider's system. > >> > >> Thanks, > >> Paul > >> > >>> Thank you. > >>> Eugene > >>> *CONFIDENTIALITY NOTICE.*This e-mail transmission, and any documents, > files or previous e-mail messages attached to it, may contain confidentia= l > and proprietary information. If you are not the intended recipient, or a > person responsible for delivering it to the intended recipient, you are > hereby notified that any disclosure, copying, distribution or use of any = of > the information contained in or attached to this message is STRICTLY > PROHIBITED. If you have received this transmission in error, please > immediately notify me by reply e-mail at echristensen@sorenson.com > or by telephone at +1 (801) 287-9419, > and destroy the original transmission and its attachments without reading > them or saving them to disk. > >>> *From:* Brian Rosen > >>> *Sent:* Wednesday, September 30, 2020 5:47 PM > >>> *To:* Eugene Christensen > >>> *Cc:* rum@ietf.org > >>> *Subject:* Re: [Rum] [EXT] RUM security model > >>> [EXTERNAL] > >>> I think we understand why you want it. What we don=E2=80=99t understa= nd is > what mechanism would provide it. I am generally aware of this class of > problem and I=E2=80=99m not aware of a solution that will work. So what = we need is > a suggested mechanism that provides the assurance you want that is > technically sound. > >>> Brian > >>> On Wed, Sep 30, 2020 at 6:30 PM Eugene Christensen < > echristensen@sorenson.com > wrote: > >>> Thanks for considering how we might implement this security > >>> mechanism. May I add my voice that it is essential that we find = an > >>> option for providing this desired security, whatever it is. It > >>> could be detrimental to the VRS providers to have UAs out there, > >>> with the ability to register with VRS providers without first bei= ng > >>> fully vetted. It is our practice anytime we make updates to our > UAs > >>> to test how they work with our UAS before we ever release the new > UA > >>> software into our production environment. We only want UAs > >>> registering that have undergone this rigorous testing with our > >>> systems and then only with users which we have awareness of. > >>> Thanks, > >>> Eugene Christensen > >>> CONFIDENTIALITY NOTICE. This e-mail transmission, and any > documents, > >>> files or previous e-mail messages attached to it, may contain > >>> confidential and proprietary information. If you are not the > >>> intended recipient, or a person responsible for delivering it to > the > >>> intended recipient, you are hereby notified that any disclosure, > >>> copying, distribution or use of any of the information contained = in > >>> or attached to this message is STRICTLY PROHIBITED. If you have > >>> received this transmission in error, please immediately notify me > by > >>> reply e-mail at echristensen@sorenson.com > >>> or by telephone at +1 (801) > >>> 287-9419, and destroy the original transmission and its attachmen= ts > >>> without reading them or saving them to disk. > >>> -- Rum mailing list > >>> Rum@ietf.org > >>> https://www.ietf.org/mailman/listinfo/rum > >>> > >> > >> -- > >> Rum mailing list > >> Rum@ietf.org > >> https://www.ietf.org/mailman/listinfo/rum > > --000000000000719bc405b1becaff Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Nope, it just takes a hacker to create a piece of code th= at patches an app to look like another app.=C2=A0

On Thu, Oct 15, 2020= at 8:19 PM Paul Kyzivat <pkyzi= vat@alum.mit.edu> wrote:
On = 10/15/20 7:52 PM, Brian Rosen wrote:
> I don=E2=80=99t think even that would work because there isn=E2=80=99t= any way to know that the app that was approved is the app that is being us= ed.

Yes, I guess you are right. But at least it would require the end user
to enter into a conspiracy with the app developers, and be able to get
the credential out of one app and into another.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Thanks,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Paul

> What systems like iOS does is rely on the fact that you can=E2=80=99t = download and run an app that hasn=E2=80=99t been vetted. The code is signed= and the signature is checked every time the app starts. We don=E2=80=99t h= ave an environment like that.=C2=A0 We can=E2=80=99t control what is downlo= aded and we can=E2=80=99t check signatures.

> I don=E2=80=99t think there is a reliable way to do this. If someone h= as an idea, please explain it, but we can=E2=80=99t be in a =E2=80=9Cyou do= something=E2=80=9D position without a clue as to how.
>
> Now, if the app was an iOS app, then the right thing happens. There ar= e few other systems that are wired down like that. Android, for example, al= lows you to download and run from arbitrary sites if the device is configur= ed to allow that.
>
> Brian
>
>
>> On Oct 15, 2020, at 6:30 PM, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:=
>>
>> =EF=BB=BFEugene,
>>
>>> On 10/15/20 3:30 PM, Eugene Christensen wrote:
>>> Brian,
>>> Admittedly I do not fully understand certificates and authenti= cation but would client certificates or mutual authentication with a shared= secret work here?
>>
>> I'm also not a security expert. To my understanding, the key p= roblem is that you want a proof that an implementation has passed some sort= of test. That is more or less equivalent to having a special certification= authority that is able to assign a certificate based on the passing of a t= est. But for the system to work that certificate needs to be bound to the e= ntity (hw/sw) that passed the test. It can't be possible to transfer th= at certificate to a different device.
>>
>> A possible alternative would be for each provider to have its own = test service. When a user gets a new device/application, as part of the ini= tial registration of their device with the provider, this test would be run= . Then the result of that would be granting of credentials for that device = to access that provider's system.
>>
>>=C2=A0 =C2=A0 =C2=A0Thanks,
>>=C2=A0 =C2=A0 =C2=A0Paul
>>
>>> Thank you.
>>> Eugene
>>> *CONFIDENTIALITY NOTICE.*This e-mail transmission, and any doc= uments, files or previous e-mail messages attached to it, may contain confi= dential and proprietary information. If you are not the intended recipient,= or a person responsible for delivering it to the intended recipient, you a= re hereby notified that any disclosure, copying, distribution or use of any= of the information contained in or attached to this message is STRICTLY PR= OHIBITED. If you have received this transmission in error, please immediate= ly notify me by reply e-mail at echristensen@sorenson.com <mailto:echristensen@sorenson.com<= /a>>or by telephone at +1 (801) 287-9419, and destroy the original trans= mission and its attachments without reading them or saving them to disk. >>> *From:* Brian Rosen <br@brianrosen.net>
>>> *Sent:* Wednesday, September 30, 2020 5:47 PM
>>> *To:* Eugene Christensen <echristensen@sorenson.com>
>>> *Cc:* rum@ie= tf.org
>>> *Subject:* Re: [Rum] [EXT] RUM security model
>>> [EXTERNAL]
>>> I think we understand why you want it. What we don=E2=80=99t u= nderstand is what mechanism would provide it. I am generally aware of this = class of problem and I=E2=80=99m not aware of a solution that will work.=C2= =A0 So what we need is a suggested mechanism that provides the assurance yo= u want that is technically sound.
>>> Brian
>>> On Wed, Sep 30, 2020 at 6:30 PM Eugene Christensen <echristensen@sorens= on.com <mailto:echristensen@sorenson.com>> wrote:
>>>=C2=A0 =C2=A0 =C2=A0Thanks for considering how we might impleme= nt this security
>>>=C2=A0 =C2=A0 =C2=A0mechanism.=C2=A0 May I add my voice that it= is essential that we find an
>>>=C2=A0 =C2=A0 =C2=A0option for providing this desired security,= whatever it is.=C2=A0 It
>>>=C2=A0 =C2=A0 =C2=A0could be detrimental to the VRS providers t= o have UAs out there,
>>>=C2=A0 =C2=A0 =C2=A0with the ability to register with VRS provi= ders without first being
>>>=C2=A0 =C2=A0 =C2=A0fully vetted.=C2=A0 It is our practice anyt= ime we make updates to our UAs
>>>=C2=A0 =C2=A0 =C2=A0to test how they work with our UAS before w= e ever release the new UA
>>>=C2=A0 =C2=A0 =C2=A0software into our production environment.= =C2=A0 We only want UAs
>>>=C2=A0 =C2=A0 =C2=A0registering that have undergone this rigoro= us testing with our
>>>=C2=A0 =C2=A0 =C2=A0systems and then only with users which we h= ave awareness of.
>>>=C2=A0 =C2=A0 =C2=A0Thanks,
>>>=C2=A0 =C2=A0 =C2=A0Eugene Christensen
>>>=C2=A0 =C2=A0 =C2=A0CONFIDENTIALITY NOTICE. This e-mail transmi= ssion, and any documents,
>>>=C2=A0 =C2=A0 =C2=A0files or previous e-mail messages attached = to it, may contain
>>>=C2=A0 =C2=A0 =C2=A0confidential and proprietary information. I= f you are not the
>>>=C2=A0 =C2=A0 =C2=A0intended recipient, or a person responsible= for delivering it to the
>>>=C2=A0 =C2=A0 =C2=A0intended recipient, you are hereby notified= that any disclosure,
>>>=C2=A0 =C2=A0 =C2=A0copying, distribution or use of any of the = information contained in
>>>=C2=A0 =C2=A0 =C2=A0or attached to this message is STRICTLY PRO= HIBITED. If you have
>>>=C2=A0 =C2=A0 =C2=A0received this transmission in error, please= immediately notify me by
>>>=C2=A0 =C2=A0 =C2=A0reply e-mail at echristensen@sorenson.com
>>>=C2=A0 =C2=A0 =C2=A0<mailto:echristensen@sorenson.com> or by tele= phone at +1 (801)
>>>=C2=A0 =C2=A0 =C2=A0287-9419, and destroy the original transmis= sion and its attachments
>>>=C2=A0 =C2=A0 =C2=A0without reading them or saving them to disk= .
>>>=C2=A0 =C2=A0 =C2=A0--=C2=A0 =C2=A0 =C2=A0Rum mailing list
>>>=C2=A0 =C2=A0 =C2=A0Rum@ietf.org <mailto:Rum@ietf.org>
>>>=C2=A0 =C2=A0 =C2=A0https://www.ietf.org/mailma= n/listinfo/rum
>>>=C2=A0 =C2=A0 =C2=A0<https://www.ietf.org/ma= ilman/listinfo/rum>
>>
>> --
>> Rum mailing list
>> Rum@ietf.org=
>> https://www.ietf.org/mailman/listinfo/rum

--000000000000719bc405b1becaff-- From nobody Fri Oct 16 04:13:29 2020 Return-Path: X-Original-To: rum@ietfa.amsl.com Delivered-To: rum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C0373A0EA7 for ; Fri, 16 Oct 2020 04:13:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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 (1024-bit key) header.d=rbbn.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 9JcfAIuD1KFz for ; Fri, 16 Oct 2020 04:13:24 -0700 (PDT) Received: from us-smtp-delivery-181.mimecast.com (us-smtp-delivery-181.mimecast.com [216.205.24.181]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9987D3A0EA8 for ; Fri, 16 Oct 2020 04:13:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rbbn.com; s=mimecast20180816; t=1602846803; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=4bDLa5r0YdcQ2KF+/ECqG4mmv8EV6D1BX3RYnfn/vjc=; b=kEppe2mb82KsiEOE0qJ19DqxK993EiQafMlCn1CoeiPC4xg5P6ytFLUH3fY4tFVtwH+W6L QaDsO16doTD6alBnhcuu2rVvaBehBwwGsGC3GQciEx0/mX4JUt1MAlogSBK1JGlvgTZtUx bTi4OJapBNrH+tUZt2jfNzgiK5PutOw= Received: from NAM11-CO1-obe.outbound.protection.outlook.com (mail-co1nam11lp2175.outbound.protection.outlook.com [104.47.56.175]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-229-fTT2bFhlMGC8MgJV9AHBug-1; Fri, 16 Oct 2020 07:13:20 -0400 Received: from BN7PR03MB3827.namprd03.prod.outlook.com (2603:10b6:408:23::13) by BN7PR03MB4324.namprd03.prod.outlook.com (2603:10b6:408:d::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3477.21; Fri, 16 Oct 2020 11:13:18 +0000 Received: from BN7PR03MB3827.namprd03.prod.outlook.com ([fe80::80a3:233e:f637:82ce]) by BN7PR03MB3827.namprd03.prod.outlook.com ([fe80::80a3:233e:f637:82ce%4]) with mapi id 15.20.3477.021; Fri, 16 Oct 2020 11:13:17 +0000 From: "Asveren, Tolga" To: Brian Rosen , Paul Kyzivat CC: "rum@ietf.org" Thread-Topic: [Rum] [EXT] RUM security model Thread-Index: AQHWlnxNAnUfnXXxW02AjUdBdxV5TKmBxBhggAAW2wCAF0rLoIAAMpaAgAAXOoCAAAeJgIAAAV6AgAC02rA= Date: Fri, 16 Oct 2020 11:13:17 +0000 Message-ID: References: <4d6ba97f-a83d-3d36-14a9-c6e84dd5b874@alum.mit.edu> <7A11F680-9EA6-4477-9BD8-6A7755AD0054@brianrosen.net> <7fdb95e6-e954-7275-60f7-462cf07eff0e@alum.mit.edu> In-Reply-To: Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [73.80.74.66] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 97782a19-a1b1-4518-8610-08d871c47bbd x-ms-traffictypediagnostic: BN7PR03MB4324: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0 x-microsoft-antispam-message-info: Ei6VJUTV4Ryj4tg2X6T2pBok+hg8f90Uo9Fkfn7+OaxCqYAwXzG1FtKRn683FKwDwX7mMFxp42K9KpOAhwlVjsxj+o6Ubnm47GJjWpF/fgjZoCw9r/ql7OAgXqPkPt2NSVmB4cq04mNadpmtQsLAFwgmXivRERU3dusLiZY93cv4hbvG46Tgba7sKzkNoxCUCAvGO3UZqbQSiJPphgaHZ0wtnpaGXISxwiOE9F6YnQgpRvIa3b8iCv7LhcFN+My145zTKQz1UgDyemGZBEmJis2EtsLlBn9LNX+XEZwGNMeyyT+u2BeGON1uFqqt9200/ms35Q7jyFDLJZerRKc2mBRtTjixcsuyAmIh+Dyzo9BiaIYmcs2f4N8whwRjGcwee0K5cgWUVXRc9PGoxeQEhQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BN7PR03MB3827.namprd03.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(376002)(136003)(396003)(346002)(39860400002)(2906002)(76116006)(55016002)(5660300002)(6506007)(4326008)(33656002)(53546011)(86362001)(110136005)(66946007)(26005)(316002)(186003)(71200400001)(15650500001)(66476007)(66556008)(64756008)(66446008)(83380400001)(52536014)(7696005)(966005)(478600001)(8936002)(8676002)(166002)(9686003); DIR:OUT; SFP:1101 x-ms-exchange-antispam-messagedata: SdQt3hSFvJmgbakAcAQh34BMYtfBAZjmXDH9IJI5QnubOm8aBda/1ExmnbK7zxmicMRFsp5G2nys1P/TTPhajlG9YFL+VYzDDOKhsxicMJQCjqbA7lEEVUkv8xVgU/HMLBVfg1s5wqCnrjFqnj5214n3a2m348xOcXDm6YR24hfpiqQ2vOXUAjbTZJhWF+3a2HKRuoYjiH69XhGHTlmL/PBD0eWSrVQoV10nPu+oG1rNsm4N/3XKE/4t5xDVoWpPvyQZtSO0QBKPti4k4q8TRDUamPypEOwt3UlthQ5l5M01sRc2FU0ziiWUgVZo8qB9kEDtzn/0dBCLMLWMjeoQErgNAQuYdkAYfABF7xe8LIz9Mirw0AlKieTa88MMMAyR95ghlYhvs2zHaoO29bq/jFe7oXBiuZuiwnBXwtNHODhp11PC1RgEOS12p4mjR4I6rTYmSx5FlzbhalBcISGNjedT18EPkpHhNYy0dQJhU35dA+NYmQK7EWMDSn3QbwoiLleSAhaS22J1ySmyoSHOVBmLtXJfpImP9C13WvicxgFpbvo0/5rt2Xb3OWKvso8Q91S1szsE7nbVShEgL8ojG56Pm3YeE0kRRk56jAKq7+pBsgucBFdOqHHS7rEQMqhEj/+9IxGlesNP53jmDgkrCg== x-ms-exchange-transport-forked: True x-mc-unique: fTT2bFhlMGC8MgJV9AHBug-1 x-originatororg: rbbn.com x-ms-exchange-crosstenant-authas: Internal x-ms-exchange-crosstenant-authsource: BN7PR03MB3827.namprd03.prod.outlook.com x-ms-exchange-crosstenant-network-message-id: 97782a19-a1b1-4518-8610-08d871c47bbd x-ms-exchange-crosstenant-originalarrivaltime: 16 Oct 2020 11:13:17.4143 (UTC) x-ms-exchange-crosstenant-fromentityheader: Hosted x-ms-exchange-crosstenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3 x-ms-exchange-crosstenant-mailboxtype: HOSTED x-ms-exchange-crosstenant-userprincipalname: cyDUgg4eJf68E2TmAv8+zy/yAYyvMUiFNxViGVsF84+x1KXas8Rj9jEJZeOqgmv7zpSmOunEvjhjiFEBhJXwGg== x-ms-exchange-transport-crosstenantheadersstamped: BN7PR03MB4324 MIME-Version: 1.0 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA81A106 smtp.mailfrom=tasveren@rbbn.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: rbbn.com Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_BN7PR03MB38274F0EC8862307B0C02284A5030BN7PR03MB3827namp_" Archived-At: Subject: Re: [Rum] [EXT] RUM security model X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2020 11:13:27 -0000 --_000_BN7PR03MB38274F0EC8862307B0C02284A5030BN7PR03MB3827namp_ Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 QSBmcmFtZXdvcmsgYmFzZWQgb24gVFBNIGNvdWxkIGhlbHAgYnV0IEkgYW0gbm90IHN1cmUgd2hl dGhlciBtYW5kYXRpbmcgdGhhdCBpcyB0aGUgcmlnaHQgYXBwcm9hY2ggZm9yIHRoaXMgZG9jdW1l bnQuIEl0IG1heSBiZSBzdWZmaWNpZW50IHRvIG1lbnRpb24gYWJvdXQgdGhlIHRocmVhdC9wb3Nz aWJsZSByZW1lZHkgaW4gdGhlIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zIHNlY3Rpb24uDQoNClRo YW5rcywNClRvbGdhDQoNCkZyb206IFJ1bSA8cnVtLWJvdW5jZXNAaWV0Zi5vcmc+IE9uIEJlaGFs ZiBPZiBCcmlhbiBSb3Nlbg0KU2VudDogVGh1cnNkYXksIE9jdG9iZXIgMTUsIDIwMjAgODoyNSBQ TQ0KVG86IFBhdWwgS3l6aXZhdCA8cGt5eml2YXRAYWx1bS5taXQuZWR1Pg0KQ2M6IHJ1bUBpZXRm Lm9yZw0KU3ViamVjdDogUmU6IFtSdW1dIFtFWFRdIFJVTSBzZWN1cml0eSBtb2RlbA0KDQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KTk9USUNFOiBUaGlzIGVtYWlsIHdhcyByZWNl aXZlZCBmcm9tIGFuIEVYVEVSTkFMIHNlbmRlcg0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCg0KTm9wZSwgaXQganVzdCB0YWtlcyBhIGhhY2tlciB0byBjcmVhdGUgYSBwaWVjZSBv ZiBjb2RlIHRoYXQgcGF0Y2hlcyBhbiBhcHAgdG8gbG9vayBsaWtlIGFub3RoZXIgYXBwLg0KDQpP biBUaHUsIE9jdCAxNSwgMjAyMCBhdCA4OjE5IFBNIFBhdWwgS3l6aXZhdCA8cGt5eml2YXRAYWx1 bS5taXQuZWR1PG1haWx0bzpwa3l6aXZhdEBhbHVtLm1pdC5lZHU+PiB3cm90ZToNCk9uIDEwLzE1 LzIwIDc6NTIgUE0sIEJyaWFuIFJvc2VuIHdyb3RlOg0KPiBJIGRvbuKAmXQgdGhpbmsgZXZlbiB0 aGF0IHdvdWxkIHdvcmsgYmVjYXVzZSB0aGVyZSBpc27igJl0IGFueSB3YXkgdG8ga25vdyB0aGF0 IHRoZSBhcHAgdGhhdCB3YXMgYXBwcm92ZWQgaXMgdGhlIGFwcCB0aGF0IGlzIGJlaW5nIHVzZWQu DQoNClllcywgSSBndWVzcyB5b3UgYXJlIHJpZ2h0LiBCdXQgYXQgbGVhc3QgaXQgd291bGQgcmVx dWlyZSB0aGUgZW5kIHVzZXINCnRvIGVudGVyIGludG8gYSBjb25zcGlyYWN5IHdpdGggdGhlIGFw cCBkZXZlbG9wZXJzLCBhbmQgYmUgYWJsZSB0byBnZXQNCnRoZSBjcmVkZW50aWFsIG91dCBvZiBv bmUgYXBwIGFuZCBpbnRvIGFub3RoZXIuDQoNCiAgICAgICAgVGhhbmtzLA0KICAgICAgICBQYXVs DQoNCj4gV2hhdCBzeXN0ZW1zIGxpa2UgaU9TIGRvZXMgaXMgcmVseSBvbiB0aGUgZmFjdCB0aGF0 IHlvdSBjYW7igJl0IGRvd25sb2FkIGFuZCBydW4gYW4gYXBwIHRoYXQgaGFzbuKAmXQgYmVlbiB2 ZXR0ZWQuIFRoZSBjb2RlIGlzIHNpZ25lZCBhbmQgdGhlIHNpZ25hdHVyZSBpcyBjaGVja2VkIGV2 ZXJ5IHRpbWUgdGhlIGFwcCBzdGFydHMuIFdlIGRvbuKAmXQgaGF2ZSBhbiBlbnZpcm9ubWVudCBs aWtlIHRoYXQuICBXZSBjYW7igJl0IGNvbnRyb2wgd2hhdCBpcyBkb3dubG9hZGVkIGFuZCB3ZSBj YW7igJl0IGNoZWNrIHNpZ25hdHVyZXMuDQoNCj4gSSBkb27igJl0IHRoaW5rIHRoZXJlIGlzIGEg cmVsaWFibGUgd2F5IHRvIGRvIHRoaXMuIElmIHNvbWVvbmUgaGFzIGFuIGlkZWEsIHBsZWFzZSBl eHBsYWluIGl0LCBidXQgd2UgY2Fu4oCZdCBiZSBpbiBhIOKAnHlvdSBkbyBzb21ldGhpbmfigJ0g cG9zaXRpb24gd2l0aG91dCBhIGNsdWUgYXMgdG8gaG93Lg0KPg0KPiBOb3csIGlmIHRoZSBhcHAg d2FzIGFuIGlPUyBhcHAsIHRoZW4gdGhlIHJpZ2h0IHRoaW5nIGhhcHBlbnMuIFRoZXJlIGFyZSBm ZXcgb3RoZXIgc3lzdGVtcyB0aGF0IGFyZSB3aXJlZCBkb3duIGxpa2UgdGhhdC4gQW5kcm9pZCwg Zm9yIGV4YW1wbGUsIGFsbG93cyB5b3UgdG8gZG93bmxvYWQgYW5kIHJ1biBmcm9tIGFyYml0cmFy eSBzaXRlcyBpZiB0aGUgZGV2aWNlIGlzIGNvbmZpZ3VyZWQgdG8gYWxsb3cgdGhhdC4NCj4NCj4g QnJpYW4NCj4NCj4NCj4+IE9uIE9jdCAxNSwgMjAyMCwgYXQgNjozMCBQTSwgUGF1bCBLeXppdmF0 IDxwa3l6aXZhdEBhbHVtLm1pdC5lZHU8bWFpbHRvOnBreXppdmF0QGFsdW0ubWl0LmVkdT4+IHdy b3RlOg0KPj4NCj4+IO+7v0V1Z2VuZSwNCj4+DQo+Pj4gT24gMTAvMTUvMjAgMzozMCBQTSwgRXVn ZW5lIENocmlzdGVuc2VuIHdyb3RlOg0KPj4+IEJyaWFuLA0KPj4+IEFkbWl0dGVkbHkgSSBkbyBu b3QgZnVsbHkgdW5kZXJzdGFuZCBjZXJ0aWZpY2F0ZXMgYW5kIGF1dGhlbnRpY2F0aW9uIGJ1dCB3 b3VsZCBjbGllbnQgY2VydGlmaWNhdGVzIG9yIG11dHVhbCBhdXRoZW50aWNhdGlvbiB3aXRoIGEg c2hhcmVkIHNlY3JldCB3b3JrIGhlcmU/DQo+Pg0KPj4gSSdtIGFsc28gbm90IGEgc2VjdXJpdHkg ZXhwZXJ0LiBUbyBteSB1bmRlcnN0YW5kaW5nLCB0aGUga2V5IHByb2JsZW0gaXMgdGhhdCB5b3Ug d2FudCBhIHByb29mIHRoYXQgYW4gaW1wbGVtZW50YXRpb24gaGFzIHBhc3NlZCBzb21lIHNvcnQg b2YgdGVzdC4gVGhhdCBpcyBtb3JlIG9yIGxlc3MgZXF1aXZhbGVudCB0byBoYXZpbmcgYSBzcGVj aWFsIGNlcnRpZmljYXRpb24gYXV0aG9yaXR5IHRoYXQgaXMgYWJsZSB0byBhc3NpZ24gYSBjZXJ0 aWZpY2F0ZSBiYXNlZCBvbiB0aGUgcGFzc2luZyBvZiBhIHRlc3QuIEJ1dCBmb3IgdGhlIHN5c3Rl bSB0byB3b3JrIHRoYXQgY2VydGlmaWNhdGUgbmVlZHMgdG8gYmUgYm91bmQgdG8gdGhlIGVudGl0 eSAoaHcvc3cpIHRoYXQgcGFzc2VkIHRoZSB0ZXN0LiBJdCBjYW4ndCBiZSBwb3NzaWJsZSB0byB0 cmFuc2ZlciB0aGF0IGNlcnRpZmljYXRlIHRvIGEgZGlmZmVyZW50IGRldmljZS4NCj4+DQo+PiBB IHBvc3NpYmxlIGFsdGVybmF0aXZlIHdvdWxkIGJlIGZvciBlYWNoIHByb3ZpZGVyIHRvIGhhdmUg aXRzIG93biB0ZXN0IHNlcnZpY2UuIFdoZW4gYSB1c2VyIGdldHMgYSBuZXcgZGV2aWNlL2FwcGxp Y2F0aW9uLCBhcyBwYXJ0IG9mIHRoZSBpbml0aWFsIHJlZ2lzdHJhdGlvbiBvZiB0aGVpciBkZXZp Y2Ugd2l0aCB0aGUgcHJvdmlkZXIsIHRoaXMgdGVzdCB3b3VsZCBiZSBydW4uIFRoZW4gdGhlIHJl c3VsdCBvZiB0aGF0IHdvdWxkIGJlIGdyYW50aW5nIG9mIGNyZWRlbnRpYWxzIGZvciB0aGF0IGRl dmljZSB0byBhY2Nlc3MgdGhhdCBwcm92aWRlcidzIHN5c3RlbS4NCj4+DQo+PiAgICAgVGhhbmtz LA0KPj4gICAgIFBhdWwNCj4+DQo+Pj4gVGhhbmsgeW91Lg0KPj4+IEV1Z2VuZQ0KPj4+ICpDT05G SURFTlRJQUxJVFkgTk9USUNFLipUaGlzIGUtbWFpbCB0cmFuc21pc3Npb24sIGFuZCBhbnkgZG9j dW1lbnRzLCBmaWxlcyBvciBwcmV2aW91cyBlLW1haWwgbWVzc2FnZXMgYXR0YWNoZWQgdG8gaXQs IG1heSBjb250YWluIGNvbmZpZGVudGlhbCBhbmQgcHJvcHJpZXRhcnkgaW5mb3JtYXRpb24uIElm IHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIG9yIGEgcGVyc29uIHJlc3BvbnNp YmxlIGZvciBkZWxpdmVyaW5nIGl0IHRvIHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHlvdSBhcmUg aGVyZWJ5IG5vdGlmaWVkIHRoYXQgYW55IGRpc2Nsb3N1cmUsIGNvcHlpbmcsIGRpc3RyaWJ1dGlv biBvciB1c2Ugb2YgYW55IG9mIHRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gb3IgYXR0YWNo ZWQgdG8gdGhpcyBtZXNzYWdlIGlzIFNUUklDVExZIFBST0hJQklURUQuIElmIHlvdSBoYXZlIHJl Y2VpdmVkIHRoaXMgdHJhbnNtaXNzaW9uIGluIGVycm9yLCBwbGVhc2UgaW1tZWRpYXRlbHkgbm90 aWZ5IG1lIGJ5IHJlcGx5IGUtbWFpbCBhdCBlY2hyaXN0ZW5zZW5Ac29yZW5zb24uY29tPG1haWx0 bzplY2hyaXN0ZW5zZW5Ac29yZW5zb24uY29tPiA8bWFpbHRvOmVjaHJpc3RlbnNlbkBzb3JlbnNv bi5jb208bWFpbHRvOmVjaHJpc3RlbnNlbkBzb3JlbnNvbi5jb20+Pm9yIGJ5IHRlbGVwaG9uZSBh dCArMSAoODAxKSAyODctOTQxOSwgYW5kIGRlc3Ryb3kgdGhlIG9yaWdpbmFsIHRyYW5zbWlzc2lv biBhbmQgaXRzIGF0dGFjaG1lbnRzIHdpdGhvdXQgcmVhZGluZyB0aGVtIG9yIHNhdmluZyB0aGVt IHRvIGRpc2suDQo+Pj4gKkZyb206KiBCcmlhbiBSb3NlbiA8YnJAYnJpYW5yb3Nlbi5uZXQ8bWFp bHRvOmJyQGJyaWFucm9zZW4ubmV0Pj4NCj4+PiAqU2VudDoqIFdlZG5lc2RheSwgU2VwdGVtYmVy IDMwLCAyMDIwIDU6NDcgUE0NCj4+PiAqVG86KiBFdWdlbmUgQ2hyaXN0ZW5zZW4gPGVjaHJpc3Rl bnNlbkBzb3JlbnNvbi5jb208bWFpbHRvOmVjaHJpc3RlbnNlbkBzb3JlbnNvbi5jb20+Pg0KPj4+ ICpDYzoqIHJ1bUBpZXRmLm9yZzxtYWlsdG86cnVtQGlldGYub3JnPg0KPj4+ICpTdWJqZWN0Oiog UmU6IFtSdW1dIFtFWFRdIFJVTSBzZWN1cml0eSBtb2RlbA0KPj4+IFtFWFRFUk5BTF0NCj4+PiBJ IHRoaW5rIHdlIHVuZGVyc3RhbmQgd2h5IHlvdSB3YW50IGl0LiBXaGF0IHdlIGRvbuKAmXQgdW5k ZXJzdGFuZCBpcyB3aGF0IG1lY2hhbmlzbSB3b3VsZCBwcm92aWRlIGl0LiBJIGFtIGdlbmVyYWxs eSBhd2FyZSBvZiB0aGlzIGNsYXNzIG9mIHByb2JsZW0gYW5kIEnigJltIG5vdCBhd2FyZSBvZiBh IHNvbHV0aW9uIHRoYXQgd2lsbCB3b3JrLiAgU28gd2hhdCB3ZSBuZWVkIGlzIGEgc3VnZ2VzdGVk IG1lY2hhbmlzbSB0aGF0IHByb3ZpZGVzIHRoZSBhc3N1cmFuY2UgeW91IHdhbnQgdGhhdCBpcyB0 ZWNobmljYWxseSBzb3VuZC4NCj4+PiBCcmlhbg0KPj4+IE9uIFdlZCwgU2VwIDMwLCAyMDIwIGF0 IDY6MzAgUE0gRXVnZW5lIENocmlzdGVuc2VuIDxlY2hyaXN0ZW5zZW5Ac29yZW5zb24uY29tPG1h aWx0bzplY2hyaXN0ZW5zZW5Ac29yZW5zb24uY29tPiA8bWFpbHRvOmVjaHJpc3RlbnNlbkBzb3Jl bnNvbi5jb208bWFpbHRvOmVjaHJpc3RlbnNlbkBzb3JlbnNvbi5jb20+Pj4gd3JvdGU6DQo+Pj4g ICAgIFRoYW5rcyBmb3IgY29uc2lkZXJpbmcgaG93IHdlIG1pZ2h0IGltcGxlbWVudCB0aGlzIHNl Y3VyaXR5DQo+Pj4gICAgIG1lY2hhbmlzbS4gIE1heSBJIGFkZCBteSB2b2ljZSB0aGF0IGl0IGlz IGVzc2VudGlhbCB0aGF0IHdlIGZpbmQgYW4NCj4+PiAgICAgb3B0aW9uIGZvciBwcm92aWRpbmcg dGhpcyBkZXNpcmVkIHNlY3VyaXR5LCB3aGF0ZXZlciBpdCBpcy4gIEl0DQo+Pj4gICAgIGNvdWxk IGJlIGRldHJpbWVudGFsIHRvIHRoZSBWUlMgcHJvdmlkZXJzIHRvIGhhdmUgVUFzIG91dCB0aGVy ZSwNCj4+PiAgICAgd2l0aCB0aGUgYWJpbGl0eSB0byByZWdpc3RlciB3aXRoIFZSUyBwcm92aWRl cnMgd2l0aG91dCBmaXJzdCBiZWluZw0KPj4+ICAgICBmdWxseSB2ZXR0ZWQuICBJdCBpcyBvdXIg cHJhY3RpY2UgYW55dGltZSB3ZSBtYWtlIHVwZGF0ZXMgdG8gb3VyIFVBcw0KPj4+ICAgICB0byB0 ZXN0IGhvdyB0aGV5IHdvcmsgd2l0aCBvdXIgVUFTIGJlZm9yZSB3ZSBldmVyIHJlbGVhc2UgdGhl IG5ldyBVQQ0KPj4+ICAgICBzb2Z0d2FyZSBpbnRvIG91ciBwcm9kdWN0aW9uIGVudmlyb25tZW50 LiAgV2Ugb25seSB3YW50IFVBcw0KPj4+ICAgICByZWdpc3RlcmluZyB0aGF0IGhhdmUgdW5kZXJn b25lIHRoaXMgcmlnb3JvdXMgdGVzdGluZyB3aXRoIG91cg0KPj4+ICAgICBzeXN0ZW1zIGFuZCB0 aGVuIG9ubHkgd2l0aCB1c2VycyB3aGljaCB3ZSBoYXZlIGF3YXJlbmVzcyBvZi4NCj4+PiAgICAg VGhhbmtzLA0KPj4+ICAgICBFdWdlbmUgQ2hyaXN0ZW5zZW4NCj4+PiAgICAgQ09ORklERU5USUFM SVRZIE5PVElDRS4gVGhpcyBlLW1haWwgdHJhbnNtaXNzaW9uLCBhbmQgYW55IGRvY3VtZW50cywN Cj4+PiAgICAgZmlsZXMgb3IgcHJldmlvdXMgZS1tYWlsIG1lc3NhZ2VzIGF0dGFjaGVkIHRvIGl0 LCBtYXkgY29udGFpbg0KPj4+ICAgICBjb25maWRlbnRpYWwgYW5kIHByb3ByaWV0YXJ5IGluZm9y bWF0aW9uLiBJZiB5b3UgYXJlIG5vdCB0aGUNCj4+PiAgICAgaW50ZW5kZWQgcmVjaXBpZW50LCBv ciBhIHBlcnNvbiByZXNwb25zaWJsZSBmb3IgZGVsaXZlcmluZyBpdCB0byB0aGUNCj4+PiAgICAg aW50ZW5kZWQgcmVjaXBpZW50LCB5b3UgYXJlIGhlcmVieSBub3RpZmllZCB0aGF0IGFueSBkaXNj bG9zdXJlLA0KPj4+ICAgICBjb3B5aW5nLCBkaXN0cmlidXRpb24gb3IgdXNlIG9mIGFueSBvZiB0 aGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluDQo+Pj4gICAgIG9yIGF0dGFjaGVkIHRvIHRoaXMg bWVzc2FnZSBpcyBTVFJJQ1RMWSBQUk9ISUJJVEVELiBJZiB5b3UgaGF2ZQ0KPj4+ICAgICByZWNl aXZlZCB0aGlzIHRyYW5zbWlzc2lvbiBpbiBlcnJvciwgcGxlYXNlIGltbWVkaWF0ZWx5IG5vdGlm eSBtZSBieQ0KPj4+ICAgICByZXBseSBlLW1haWwgYXQgZWNocmlzdGVuc2VuQHNvcmVuc29uLmNv bTxtYWlsdG86ZWNocmlzdGVuc2VuQHNvcmVuc29uLmNvbT4NCj4+PiAgICAgPG1haWx0bzplY2hy aXN0ZW5zZW5Ac29yZW5zb24uY29tPG1haWx0bzplY2hyaXN0ZW5zZW5Ac29yZW5zb24uY29tPj4g b3IgYnkgdGVsZXBob25lIGF0ICsxICg4MDEpDQo+Pj4gICAgIDI4Ny05NDE5LCBhbmQgZGVzdHJv eSB0aGUgb3JpZ2luYWwgdHJhbnNtaXNzaW9uIGFuZCBpdHMgYXR0YWNobWVudHMNCj4+PiAgICAg d2l0aG91dCByZWFkaW5nIHRoZW0gb3Igc2F2aW5nIHRoZW0gdG8gZGlzay4NCj4+PiAgICAgLS0g ICAgIFJ1bSBtYWlsaW5nIGxpc3QNCj4+PiAgICAgUnVtQGlldGYub3JnPG1haWx0bzpSdW1AaWV0 Zi5vcmc+IDxtYWlsdG86UnVtQGlldGYub3JnPG1haWx0bzpSdW1AaWV0Zi5vcmc+Pg0KPj4+ICAg ICBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J1bTxodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J1bT4NCj4+PiAgICAgPGh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vcnVtPGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vcnVtPj4NCj4+DQo+PiAtLQ0KPj4gUnVtIG1haWxpbmcgbGlzdA0KPj4gUnVtQGlldGYu b3JnPG1haWx0bzpSdW1AaWV0Zi5vcmc+DQo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL3J1bTxodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J1bT4N Cg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLQ0KTm90aWNlOiBUaGlzIGUtbWFpbCB0b2dldGhlciB3aXRoIGFueSBhdHRhY2ht ZW50cyBtYXkgY29udGFpbiBpbmZvcm1hdGlvbiBvZiBSaWJib24gQ29tbXVuaWNhdGlvbnMgSW5j LiB0aGF0DQppcyBjb25maWRlbnRpYWwgYW5kL29yIHByb3ByaWV0YXJ5IGZvciB0aGUgc29sZSB1 c2Ugb2YgdGhlIGludGVuZGVkIHJlY2lwaWVudC4gIEFueSByZXZpZXcsIGRpc2Nsb3N1cmUsIHJl bGlhbmNlIG9yDQpkaXN0cmlidXRpb24gYnkgb3RoZXJzIG9yIGZvcndhcmRpbmcgd2l0aG91dCBl eHByZXNzIHBlcm1pc3Npb24gaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4gIElmIHlvdSBhcmUgbm90 IHRoZSBpbnRlbmRlZA0KcmVjaXBpZW50LCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRp YXRlbHkgYW5kIHRoZW4gZGVsZXRlIGFsbCBjb3BpZXMsIGluY2x1ZGluZyBhbnkgYXR0YWNobWVu dHMuDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLQ0K --_000_BN7PR03MB38274F0EC8862307B0C02284A5030BN7PR03MB3827namp_ Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9InRl eHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRlbnQ9 Ik1pY3Jvc29mdCBXb3JkIDE1IChmaWx0ZXJlZCBtZWRpdW0pIj4NCjwhLS1baWYgIW1zb10+PHN0 eWxlPnZcOioge2JlaGF2aW9yOnVybCgjZGVmYXVsdCNWTUwpO30NCm9cOioge2JlaGF2aW9yOnVy bCgjZGVmYXVsdCNWTUwpO30NCndcOioge2JlaGF2aW9yOnVybCgjZGVmYXVsdCNWTUwpO30NCi5z aGFwZSB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0KPC9zdHlsZT48IVtlbmRpZl0tLT48 c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFjZQ0KCXtmb250LWZh bWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBm b250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIg NCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05v cm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJ Zm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVy bGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29y YXRpb246dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBl cnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9y OndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9u bHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVp biAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2Vj dGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28g OV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+ DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5 b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9v OnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPjxib2R5IGxhbmc9IkVOLVVT IiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIiBzdHlsZT0id29yZC13cmFwOmJyZWFrLXdvcmQi Pg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkEgZnJh bWV3b3JrIGJhc2VkIG9uIFRQTSBjb3VsZCBoZWxwIGJ1dCBJIGFtIG5vdCBzdXJlIHdoZXRoZXIg bWFuZGF0aW5nIHRoYXQgaXMgdGhlIHJpZ2h0IGFwcHJvYWNoIGZvciB0aGlzIGRvY3VtZW50LiBJ dCBtYXkgYmUgc3VmZmljaWVudCB0byBtZW50aW9uIGFib3V0IHRoZSB0aHJlYXQvcG9zc2libGUg cmVtZWR5IGluIHRoZSBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyBzZWN0aW9uLjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5UaGFua3MsPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5Ub2xnYTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xp ZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGI+RnJvbTo8L2I+IFJ1bSAmbHQ7cnVtLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7IDxi Pk9uIEJlaGFsZiBPZiA8L2I+DQpCcmlhbiBSb3Nlbjxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2Rh eSwgT2N0b2JlciAxNSwgMjAyMCA4OjI1IFBNPGJyPg0KPGI+VG86PC9iPiBQYXVsIEt5eml2YXQg Jmx0O3BreXppdmF0QGFsdW0ubWl0LmVkdSZndDs8YnI+DQo8Yj5DYzo8L2I+IHJ1bUBpZXRmLm9y Zzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW1J1bV0gW0VYVF0gUlVNIHNlY3VyaXR5IG1vZGVs PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2IGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJjZW50ZXIi IHN0eWxlPSJ0ZXh0LWFsaWduOmNlbnRlciI+DQo8aHIgc2l6ZT0iMiIgd2lkdGg9IjEwMCUiIGFs aWduPSJjZW50ZXIiPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5OT1RJQ0U6IFRoaXMg ZW1haWwgd2FzIHJlY2VpdmVkIGZyb20gYW4gRVhURVJOQUwgc2VuZGVyPG86cD48L286cD48L3A+ DQo8ZGl2IGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJjZW50ZXIiIHN0eWxlPSJ0ZXh0LWFsaWdu OmNlbnRlciI+DQo8aHIgc2l6ZT0iMiIgd2lkdGg9IjEwMCUiIGFsaWduPSJjZW50ZXIiPg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5Ob3BlLCBpdCBqdXN0IHRha2VzIGEgaGFja2VyIHRvIGNyZWF0 ZSBhIHBpZWNlIG9mIGNvZGUgdGhhdCBwYXRjaGVzIGFuIGFwcCB0byBsb29rIGxpa2UgYW5vdGhl ciBhcHAuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+T24gVGh1LCBPY3QgMTUsIDIwMjAgYXQgODoxOSBQTSBQYXVsIEt5eml2YXQgJmx0 OzxhIGhyZWY9Im1haWx0bzpwa3l6aXZhdEBhbHVtLm1pdC5lZHUiPnBreXppdmF0QGFsdW0ubWl0 LmVkdTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5n OjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5PbiAxMC8x NS8yMCA3OjUyIFBNLCBCcmlhbiBSb3NlbiB3cm90ZTo8YnI+DQomZ3Q7IEkgZG9u4oCZdCB0aGlu ayBldmVuIHRoYXQgd291bGQgd29yayBiZWNhdXNlIHRoZXJlIGlzbuKAmXQgYW55IHdheSB0byBr bm93IHRoYXQgdGhlIGFwcCB0aGF0IHdhcyBhcHByb3ZlZCBpcyB0aGUgYXBwIHRoYXQgaXMgYmVp bmcgdXNlZC48YnI+DQo8YnI+DQpZZXMsIEkgZ3Vlc3MgeW91IGFyZSByaWdodC4gQnV0IGF0IGxl YXN0IGl0IHdvdWxkIHJlcXVpcmUgdGhlIGVuZCB1c2VyIDxicj4NCnRvIGVudGVyIGludG8gYSBj b25zcGlyYWN5IHdpdGggdGhlIGFwcCBkZXZlbG9wZXJzLCBhbmQgYmUgYWJsZSB0byBnZXQgPGJy Pg0KdGhlIGNyZWRlbnRpYWwgb3V0IG9mIG9uZSBhcHAgYW5kIGludG8gYW5vdGhlci48YnI+DQo8 YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgVGhhbmtzLDxicj4NCiZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyBQYXVsPGJyPg0KPGJyPg0KJmd0OyBXaGF0IHN5c3RlbXMgbGlrZSBp T1MgZG9lcyBpcyByZWx5IG9uIHRoZSBmYWN0IHRoYXQgeW91IGNhbuKAmXQgZG93bmxvYWQgYW5k IHJ1biBhbiBhcHAgdGhhdCBoYXNu4oCZdCBiZWVuIHZldHRlZC4gVGhlIGNvZGUgaXMgc2lnbmVk IGFuZCB0aGUgc2lnbmF0dXJlIGlzIGNoZWNrZWQgZXZlcnkgdGltZSB0aGUgYXBwIHN0YXJ0cy4g V2UgZG9u4oCZdCBoYXZlIGFuIGVudmlyb25tZW50IGxpa2UgdGhhdC4mbmJzcDsgV2UgY2Fu4oCZ dCBjb250cm9sIHdoYXQgaXMgZG93bmxvYWRlZA0KIGFuZCB3ZSBjYW7igJl0IGNoZWNrIHNpZ25h dHVyZXMuPGJyPg0KPGJyPg0KJmd0OyBJIGRvbuKAmXQgdGhpbmsgdGhlcmUgaXMgYSByZWxpYWJs ZSB3YXkgdG8gZG8gdGhpcy4gSWYgc29tZW9uZSBoYXMgYW4gaWRlYSwgcGxlYXNlIGV4cGxhaW4g aXQsIGJ1dCB3ZSBjYW7igJl0IGJlIGluIGEg4oCceW91IGRvIHNvbWV0aGluZ+KAnSBwb3NpdGlv biB3aXRob3V0IGEgY2x1ZSBhcyB0byBob3cuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IE5vdywgaWYg dGhlIGFwcCB3YXMgYW4gaU9TIGFwcCwgdGhlbiB0aGUgcmlnaHQgdGhpbmcgaGFwcGVucy4gVGhl cmUgYXJlIGZldyBvdGhlciBzeXN0ZW1zIHRoYXQgYXJlIHdpcmVkIGRvd24gbGlrZSB0aGF0LiBB bmRyb2lkLCBmb3IgZXhhbXBsZSwgYWxsb3dzIHlvdSB0byBkb3dubG9hZCBhbmQgcnVuIGZyb20g YXJiaXRyYXJ5IHNpdGVzIGlmIHRoZSBkZXZpY2UgaXMgY29uZmlndXJlZCB0byBhbGxvdyB0aGF0 Ljxicj4NCiZndDsgPGJyPg0KJmd0OyBCcmlhbjxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQom Z3Q7Jmd0OyBPbiBPY3QgMTUsIDIwMjAsIGF0IDY6MzAgUE0sIFBhdWwgS3l6aXZhdCAmbHQ7PGEg aHJlZj0ibWFpbHRvOnBreXppdmF0QGFsdW0ubWl0LmVkdSIgdGFyZ2V0PSJfYmxhbmsiPnBreXpp dmF0QGFsdW0ubWl0LmVkdTwvYT4mZ3Q7IHdyb3RlOjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZn dDsg77u/RXVnZW5lLDxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7IE9uIDEwLzE1LzIw IDM6MzAgUE0sIEV1Z2VuZSBDaHJpc3RlbnNlbiB3cm90ZTo8YnI+DQomZ3Q7Jmd0OyZndDsgQnJp YW4sPGJyPg0KJmd0OyZndDsmZ3Q7IEFkbWl0dGVkbHkgSSBkbyBub3QgZnVsbHkgdW5kZXJzdGFu ZCBjZXJ0aWZpY2F0ZXMgYW5kIGF1dGhlbnRpY2F0aW9uIGJ1dCB3b3VsZCBjbGllbnQgY2VydGlm aWNhdGVzIG9yIG11dHVhbCBhdXRoZW50aWNhdGlvbiB3aXRoIGEgc2hhcmVkIHNlY3JldCB3b3Jr IGhlcmU/PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBJJ20gYWxzbyBub3QgYSBzZWN1cml0 eSBleHBlcnQuIFRvIG15IHVuZGVyc3RhbmRpbmcsIHRoZSBrZXkgcHJvYmxlbSBpcyB0aGF0IHlv dSB3YW50IGEgcHJvb2YgdGhhdCBhbiBpbXBsZW1lbnRhdGlvbiBoYXMgcGFzc2VkIHNvbWUgc29y dCBvZiB0ZXN0LiBUaGF0IGlzIG1vcmUgb3IgbGVzcyBlcXVpdmFsZW50IHRvIGhhdmluZyBhIHNw ZWNpYWwgY2VydGlmaWNhdGlvbiBhdXRob3JpdHkgdGhhdCBpcyBhYmxlIHRvIGFzc2lnbiBhIGNl cnRpZmljYXRlDQogYmFzZWQgb24gdGhlIHBhc3Npbmcgb2YgYSB0ZXN0LiBCdXQgZm9yIHRoZSBz eXN0ZW0gdG8gd29yayB0aGF0IGNlcnRpZmljYXRlIG5lZWRzIHRvIGJlIGJvdW5kIHRvIHRoZSBl bnRpdHkgKGh3L3N3KSB0aGF0IHBhc3NlZCB0aGUgdGVzdC4gSXQgY2FuJ3QgYmUgcG9zc2libGUg dG8gdHJhbnNmZXIgdGhhdCBjZXJ0aWZpY2F0ZSB0byBhIGRpZmZlcmVudCBkZXZpY2UuPGJyPg0K Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBBIHBvc3NpYmxlIGFsdGVybmF0aXZlIHdvdWxkIGJlIGZv ciBlYWNoIHByb3ZpZGVyIHRvIGhhdmUgaXRzIG93biB0ZXN0IHNlcnZpY2UuIFdoZW4gYSB1c2Vy IGdldHMgYSBuZXcgZGV2aWNlL2FwcGxpY2F0aW9uLCBhcyBwYXJ0IG9mIHRoZSBpbml0aWFsIHJl Z2lzdHJhdGlvbiBvZiB0aGVpciBkZXZpY2Ugd2l0aCB0aGUgcHJvdmlkZXIsIHRoaXMgdGVzdCB3 b3VsZCBiZSBydW4uIFRoZW4gdGhlIHJlc3VsdCBvZiB0aGF0IHdvdWxkIGJlIGdyYW50aW5nDQog b2YgY3JlZGVudGlhbHMgZm9yIHRoYXQgZGV2aWNlIHRvIGFjY2VzcyB0aGF0IHByb3ZpZGVyJ3Mg c3lzdGVtLjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwO1Ro YW5rcyw8YnI+DQomZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7UGF1bDxicj4NCiZndDsmZ3Q7 PGJyPg0KJmd0OyZndDsmZ3Q7IFRoYW5rIHlvdS48YnI+DQomZ3Q7Jmd0OyZndDsgRXVnZW5lPGJy Pg0KJmd0OyZndDsmZ3Q7ICpDT05GSURFTlRJQUxJVFkgTk9USUNFLipUaGlzIGUtbWFpbCB0cmFu c21pc3Npb24sIGFuZCBhbnkgZG9jdW1lbnRzLCBmaWxlcyBvciBwcmV2aW91cyBlLW1haWwgbWVz c2FnZXMgYXR0YWNoZWQgdG8gaXQsIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBhbmQgcHJvcHJp ZXRhcnkgaW5mb3JtYXRpb24uIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQs IG9yIGEgcGVyc29uIHJlc3BvbnNpYmxlIGZvciBkZWxpdmVyaW5nIGl0DQogdG8gdGhlIGludGVu ZGVkIHJlY2lwaWVudCwgeW91IGFyZSBoZXJlYnkgbm90aWZpZWQgdGhhdCBhbnkgZGlzY2xvc3Vy ZSwgY29weWluZywgZGlzdHJpYnV0aW9uIG9yIHVzZSBvZiBhbnkgb2YgdGhlIGluZm9ybWF0aW9u IGNvbnRhaW5lZCBpbiBvciBhdHRhY2hlZCB0byB0aGlzIG1lc3NhZ2UgaXMgU1RSSUNUTFkgUFJP SElCSVRFRC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyB0cmFuc21pc3Npb24gaW4gZXJyb3Is IHBsZWFzZSBpbW1lZGlhdGVseQ0KIG5vdGlmeSBtZSBieSByZXBseSBlLW1haWwgYXQgPGEgaHJl Zj0ibWFpbHRvOmVjaHJpc3RlbnNlbkBzb3JlbnNvbi5jb20iIHRhcmdldD0iX2JsYW5rIj4NCmVj aHJpc3RlbnNlbkBzb3JlbnNvbi5jb208L2E+ICZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOmVj aHJpc3RlbnNlbkBzb3JlbnNvbi5jb20iIHRhcmdldD0iX2JsYW5rIj5lY2hyaXN0ZW5zZW5Ac29y ZW5zb24uY29tPC9hPiZndDtvciBieSB0ZWxlcGhvbmUgYXQgJiM0MzsxICg4MDEpIDI4Ny05NDE5 LCBhbmQgZGVzdHJveSB0aGUgb3JpZ2luYWwgdHJhbnNtaXNzaW9uIGFuZCBpdHMgYXR0YWNobWVu dHMgd2l0aG91dCByZWFkaW5nIHRoZW0gb3Igc2F2aW5nIHRoZW0NCiB0byBkaXNrLjxicj4NCiZn dDsmZ3Q7Jmd0OyAqRnJvbToqIEJyaWFuIFJvc2VuICZsdDs8YSBocmVmPSJtYWlsdG86YnJAYnJp YW5yb3Nlbi5uZXQiIHRhcmdldD0iX2JsYW5rIj5ickBicmlhbnJvc2VuLm5ldDwvYT4mZ3Q7PGJy Pg0KJmd0OyZndDsmZ3Q7ICpTZW50OiogV2VkbmVzZGF5LCBTZXB0ZW1iZXIgMzAsIDIwMjAgNTo0 NyBQTTxicj4NCiZndDsmZ3Q7Jmd0OyAqVG86KiBFdWdlbmUgQ2hyaXN0ZW5zZW4gJmx0OzxhIGhy ZWY9Im1haWx0bzplY2hyaXN0ZW5zZW5Ac29yZW5zb24uY29tIiB0YXJnZXQ9Il9ibGFuayI+ZWNo cmlzdGVuc2VuQHNvcmVuc29uLmNvbTwvYT4mZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7ICpDYzoqIDxh IGhyZWY9Im1haWx0bzpydW1AaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5ydW1AaWV0Zi5vcmc8 L2E+PGJyPg0KJmd0OyZndDsmZ3Q7ICpTdWJqZWN0OiogUmU6IFtSdW1dIFtFWFRdIFJVTSBzZWN1 cml0eSBtb2RlbDxicj4NCiZndDsmZ3Q7Jmd0OyBbRVhURVJOQUxdPGJyPg0KJmd0OyZndDsmZ3Q7 IEkgdGhpbmsgd2UgdW5kZXJzdGFuZCB3aHkgeW91IHdhbnQgaXQuIFdoYXQgd2UgZG9u4oCZdCB1 bmRlcnN0YW5kIGlzIHdoYXQgbWVjaGFuaXNtIHdvdWxkIHByb3ZpZGUgaXQuIEkgYW0gZ2VuZXJh bGx5IGF3YXJlIG9mIHRoaXMgY2xhc3Mgb2YgcHJvYmxlbSBhbmQgSeKAmW0gbm90IGF3YXJlIG9m IGEgc29sdXRpb24gdGhhdCB3aWxsIHdvcmsuJm5ic3A7IFNvIHdoYXQgd2UgbmVlZCBpcyBhIHN1 Z2dlc3RlZCBtZWNoYW5pc20gdGhhdCBwcm92aWRlcyB0aGUNCiBhc3N1cmFuY2UgeW91IHdhbnQg dGhhdCBpcyB0ZWNobmljYWxseSBzb3VuZC48YnI+DQomZ3Q7Jmd0OyZndDsgQnJpYW48YnI+DQom Z3Q7Jmd0OyZndDsgT24gV2VkLCBTZXAgMzAsIDIwMjAgYXQgNjozMCBQTSBFdWdlbmUgQ2hyaXN0 ZW5zZW4gJmx0OzxhIGhyZWY9Im1haWx0bzplY2hyaXN0ZW5zZW5Ac29yZW5zb24uY29tIiB0YXJn ZXQ9Il9ibGFuayI+ZWNocmlzdGVuc2VuQHNvcmVuc29uLmNvbTwvYT4gJmx0O21haWx0bzo8YSBo cmVmPSJtYWlsdG86ZWNocmlzdGVuc2VuQHNvcmVuc29uLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmVj aHJpc3RlbnNlbkBzb3JlbnNvbi5jb208L2E+Jmd0OyZndDsgd3JvdGU6PGJyPg0KJmd0OyZndDsm Z3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDtUaGFua3MgZm9yIGNvbnNpZGVyaW5nIGhvdyB3ZSBtaWdo dCBpbXBsZW1lbnQgdGhpcyBzZWN1cml0eTxicj4NCiZndDsmZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsg Jm5ic3A7bWVjaGFuaXNtLiZuYnNwOyBNYXkgSSBhZGQgbXkgdm9pY2UgdGhhdCBpdCBpcyBlc3Nl bnRpYWwgdGhhdCB3ZSBmaW5kIGFuPGJyPg0KJmd0OyZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJz cDtvcHRpb24gZm9yIHByb3ZpZGluZyB0aGlzIGRlc2lyZWQgc2VjdXJpdHksIHdoYXRldmVyIGl0 IGlzLiZuYnNwOyBJdDxicj4NCiZndDsmZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7Y291bGQg YmUgZGV0cmltZW50YWwgdG8gdGhlIFZSUyBwcm92aWRlcnMgdG8gaGF2ZSBVQXMgb3V0IHRoZXJl LDxicj4NCiZndDsmZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7d2l0aCB0aGUgYWJpbGl0eSB0 byByZWdpc3RlciB3aXRoIFZSUyBwcm92aWRlcnMgd2l0aG91dCBmaXJzdCBiZWluZzxicj4NCiZn dDsmZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ZnVsbHkgdmV0dGVkLiZuYnNwOyBJdCBpcyBv dXIgcHJhY3RpY2UgYW55dGltZSB3ZSBtYWtlIHVwZGF0ZXMgdG8gb3VyIFVBczxicj4NCiZndDsm Z3Q7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7dG8gdGVzdCBob3cgdGhleSB3b3JrIHdpdGggb3Vy IFVBUyBiZWZvcmUgd2UgZXZlciByZWxlYXNlIHRoZSBuZXcgVUE8YnI+DQomZ3Q7Jmd0OyZndDsm bmJzcDsgJm5ic3A7ICZuYnNwO3NvZnR3YXJlIGludG8gb3VyIHByb2R1Y3Rpb24gZW52aXJvbm1l bnQuJm5ic3A7IFdlIG9ubHkgd2FudCBVQXM8YnI+DQomZ3Q7Jmd0OyZndDsmbmJzcDsgJm5ic3A7 ICZuYnNwO3JlZ2lzdGVyaW5nIHRoYXQgaGF2ZSB1bmRlcmdvbmUgdGhpcyByaWdvcm91cyB0ZXN0 aW5nIHdpdGggb3VyPGJyPg0KJmd0OyZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDtzeXN0ZW1z IGFuZCB0aGVuIG9ubHkgd2l0aCB1c2VycyB3aGljaCB3ZSBoYXZlIGF3YXJlbmVzcyBvZi48YnI+ DQomZ3Q7Jmd0OyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwO1RoYW5rcyw8YnI+DQomZ3Q7Jmd0OyZn dDsmbmJzcDsgJm5ic3A7ICZuYnNwO0V1Z2VuZSBDaHJpc3RlbnNlbjxicj4NCiZndDsmZ3Q7Jmd0 OyZuYnNwOyAmbmJzcDsgJm5ic3A7Q09ORklERU5USUFMSVRZIE5PVElDRS4gVGhpcyBlLW1haWwg dHJhbnNtaXNzaW9uLCBhbmQgYW55IGRvY3VtZW50cyw8YnI+DQomZ3Q7Jmd0OyZndDsmbmJzcDsg Jm5ic3A7ICZuYnNwO2ZpbGVzIG9yIHByZXZpb3VzIGUtbWFpbCBtZXNzYWdlcyBhdHRhY2hlZCB0 byBpdCwgbWF5IGNvbnRhaW48YnI+DQomZ3Q7Jmd0OyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwO2Nv bmZpZGVudGlhbCBhbmQgcHJvcHJpZXRhcnkgaW5mb3JtYXRpb24uIElmIHlvdSBhcmUgbm90IHRo ZTxicj4NCiZndDsmZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7aW50ZW5kZWQgcmVjaXBpZW50 LCBvciBhIHBlcnNvbiByZXNwb25zaWJsZSBmb3IgZGVsaXZlcmluZyBpdCB0byB0aGU8YnI+DQom Z3Q7Jmd0OyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwO2ludGVuZGVkIHJlY2lwaWVudCwgeW91IGFy ZSBoZXJlYnkgbm90aWZpZWQgdGhhdCBhbnkgZGlzY2xvc3VyZSw8YnI+DQomZ3Q7Jmd0OyZndDsm bmJzcDsgJm5ic3A7ICZuYnNwO2NvcHlpbmcsIGRpc3RyaWJ1dGlvbiBvciB1c2Ugb2YgYW55IG9m IHRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW48YnI+DQomZ3Q7Jmd0OyZndDsmbmJzcDsgJm5i c3A7ICZuYnNwO29yIGF0dGFjaGVkIHRvIHRoaXMgbWVzc2FnZSBpcyBTVFJJQ1RMWSBQUk9ISUJJ VEVELiBJZiB5b3UgaGF2ZTxicj4NCiZndDsmZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7cmVj ZWl2ZWQgdGhpcyB0cmFuc21pc3Npb24gaW4gZXJyb3IsIHBsZWFzZSBpbW1lZGlhdGVseSBub3Rp ZnkgbWUgYnk8YnI+DQomZ3Q7Jmd0OyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwO3JlcGx5IGUtbWFp bCBhdCA8YSBocmVmPSJtYWlsdG86ZWNocmlzdGVuc2VuQHNvcmVuc29uLmNvbSIgdGFyZ2V0PSJf YmxhbmsiPg0KZWNocmlzdGVuc2VuQHNvcmVuc29uLmNvbTwvYT48YnI+DQomZ3Q7Jmd0OyZndDsm bmJzcDsgJm5ic3A7ICZuYnNwOyZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOmVjaHJpc3RlbnNl bkBzb3JlbnNvbi5jb20iIHRhcmdldD0iX2JsYW5rIj5lY2hyaXN0ZW5zZW5Ac29yZW5zb24uY29t PC9hPiZndDsgb3IgYnkgdGVsZXBob25lIGF0ICYjNDM7MSAoODAxKTxicj4NCiZndDsmZ3Q7Jmd0 OyZuYnNwOyAmbmJzcDsgJm5ic3A7Mjg3LTk0MTksIGFuZCBkZXN0cm95IHRoZSBvcmlnaW5hbCB0 cmFuc21pc3Npb24gYW5kIGl0cyBhdHRhY2htZW50czxicj4NCiZndDsmZ3Q7Jmd0OyZuYnNwOyAm bmJzcDsgJm5ic3A7d2l0aG91dCByZWFkaW5nIHRoZW0gb3Igc2F2aW5nIHRoZW0gdG8gZGlzay48 YnI+DQomZ3Q7Jmd0OyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOy0tJm5ic3A7ICZuYnNwOyAmbmJz cDtSdW0gbWFpbGluZyBsaXN0PGJyPg0KJmd0OyZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDs8 YSBocmVmPSJtYWlsdG86UnVtQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+UnVtQGlldGYub3Jn PC9hPiAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzpSdW1AaWV0Zi5vcmciIHRhcmdldD0iX2Js YW5rIj5SdW1AaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsg Jm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydW0i IHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J1 bTwvYT48YnI+DQomZ3Q7Jmd0OyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyZsdDs8YSBocmVmPSJo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J1bSIgdGFyZ2V0PSJfYmxhbmsi Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnVtPC9hPiZndDs8YnI+DQom Z3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IC0tIDxicj4NCiZndDsmZ3Q7IFJ1bSBtYWlsaW5nIGxpc3Q8 YnI+DQomZ3Q7Jmd0OyA8YSBocmVmPSJtYWlsdG86UnVtQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFu ayI+UnVtQGlldGYub3JnPC9hPjxicj4NCiZndDsmZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vcnVtIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J1bTwvYT48bzpwPjwvbzpwPjwvcD4NCjwvYmxv Y2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCg0KDQo8YnI+PGJyPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTpBcmlhbDsgRm9udC1zaXplOjguMHB0Ij4gPGhyPiBOb3RpY2U6IFRoaXMg ZS1tYWlsIHRvZ2V0aGVyIHdpdGggYW55IGF0dGFjaG1lbnRzIG1heSBjb250YWluIGluZm9ybWF0 aW9uIG9mIFJpYmJvbiBDb21tdW5pY2F0aW9ucyBJbmMuIHRoYXQgaXMgY29uZmlkZW50aWFsIGFu ZC9vciBwcm9wcmlldGFyeSBmb3IgdGhlIHNvbGUgdXNlIG9mIHRoZSBpbnRlbmRlZCByZWNpcGll bnQuICBBbnkgcmV2aWV3LCBkaXNjbG9zdXJlLCByZWxpYW5jZSBvciBkaXN0cmlidXRpb24gYnkg b3RoZXJzIG9yIGZvcndhcmRpbmcgd2l0aG91dCBleHByZXNzIHBlcm1pc3Npb24gaXMgc3RyaWN0 bHkgcHJvaGliaXRlZC4gIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBs ZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBhbmQgdGhlbiBkZWxldGUgYWxsIGNv cGllcywgaW5jbHVkaW5nIGFueSBhdHRhY2htZW50cy48aHI+IDwvc3Bhbj48L2JvZHk+PC9odG1s Pg0K --_000_BN7PR03MB38274F0EC8862307B0C02284A5030BN7PR03MB3827namp_-- From nobody Fri Oct 16 08:17:34 2020 Return-Path: X-Original-To: rum@ietfa.amsl.com Delivered-To: rum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D94D3A0F97 for ; Fri, 16 Oct 2020 08:17:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.214 X-Spam-Level: X-Spam-Status: No, score=-2.214 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, NICE_REPLY_A=-0.213, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=alum.mit.edu 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 F2n_-v3dvwbO for ; Fri, 16 Oct 2020 08:17:29 -0700 (PDT) Received: from NAM11-CO1-obe.outbound.protection.outlook.com (mail-co1nam11on2058.outbound.protection.outlook.com [40.107.220.58]) (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 B87863A005C for ; Fri, 16 Oct 2020 08:17:29 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Dh2K4SEFgGme+aStjCa9YTdeuvgiuJmjg/RFCKypOwIhM0Mv6XFNMdIV62nnqh6jRihdXxZw21J27X39c0Iz8T2UHp5HiCVUmYoYJLqTdZSOn1PHCTUAzsvL54/S7a2G2Ctc38nBTiqFCAJJ0Pk8iUT7sa+u1+26YhYABw9wh/95beVDIFV/v2tDfWC83SmWaFCXRG7oMm7BrmzCNH1FtVxn6p5Lyi4lUp91vf5/RgoqEJ8IDX+B1XMVGvn5SXM06XTzwLEaeXPKJxob0gayqZYncuRaKtTWB7NDmZVPCHzd9wKkokOvBrD2YtOryNA0w1sFf4Zi/5gP9nVS35pp+w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Mm31r6XoW94wj/pxDNC+eSZsi9yfNbM+OfwVY5+0kX8=; b=TrZu0G4YtLalex80XPkDjhgkK/LEXfCqzsbzGIBvIJnRNcU5szEAw6sL5AUqKXJv8trbja6Zb+FCjuABYd4RRo0f84dccAW+oHNIhFkbYRpYLgVZZ5VtxgdYPlXppNTlO1t4ykTTkGzR7g/TzEHLI3wkRYtc4/lLcEO3binKJ1mUTYOU+V/Qgh7n+UJOscsXdxxDb5luwqdMW6CPYMOeykh0mEF4mUlsYNGgcsCLwFyQwI+AFDMaGpEZllOV/zjnh32CZyTIEovpuOLFVhtXERIhNufxdB+gPIwzkMpc8aRwQeRtDJocushyKzo+Fs14F6OmEmxM9McqeHic0IFhBw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 18.7.68.33) smtp.rcpttodomain=brianrosen.net smtp.mailfrom=alum.mit.edu; dmarc=bestguesspass action=none header.from=alum.mit.edu; dkim=none (message not signed); arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alum.mit.edu; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Mm31r6XoW94wj/pxDNC+eSZsi9yfNbM+OfwVY5+0kX8=; b=c/W51b9urv3KGG4eiRQ9oD+lA8iCm2oUb2ncjtJwA1m6vKGU0lJPSTNUjIbib4KNz2Xn0yce4BzHyjr5zvaiJesdGuaPwFNBOV7fAf3ldSqHCblHQGCNJItTbvxKCu/bGETudemJcV3xi+buH/N+KkJ6Eiup5VcXNj0k78fwqI0= Received: from SN4PR0501CA0050.namprd05.prod.outlook.com (2603:10b6:803:41::27) by BY5PR12MB4966.namprd12.prod.outlook.com (2603:10b6:a03:1da::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3477.21; Fri, 16 Oct 2020 15:17:28 +0000 Received: from SN1NAM02FT015.eop-nam02.prod.protection.outlook.com (2603:10b6:803:41:cafe::31) by SN4PR0501CA0050.outlook.office365.com (2603:10b6:803:41::27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3499.8 via Frontend Transport; Fri, 16 Oct 2020 15:17:28 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 18.7.68.33) smtp.mailfrom=alum.mit.edu; brianrosen.net; dkim=none (message not signed) header.d=none;brianrosen.net; dmarc=bestguesspass action=none header.from=alum.mit.edu; Received-SPF: Pass (protection.outlook.com: domain of alum.mit.edu designates 18.7.68.33 as permitted sender) receiver=protection.outlook.com; client-ip=18.7.68.33; helo=outgoing-alum.mit.edu; Received: from outgoing-alum.mit.edu (18.7.68.33) by SN1NAM02FT015.mail.protection.outlook.com (10.152.72.109) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3477.21 via Frontend Transport; Fri, 16 Oct 2020 15:17:27 +0000 Received: from PaulKyzivatsMBP.localdomain (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.14.7/8.12.4) with ESMTP id 09GFHP66031073 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Fri, 16 Oct 2020 11:17:26 -0400 To: Brian Rosen Cc: rum@ietf.org References: <4d6ba97f-a83d-3d36-14a9-c6e84dd5b874@alum.mit.edu> <7A11F680-9EA6-4477-9BD8-6A7755AD0054@brianrosen.net> <7fdb95e6-e954-7275-60f7-462cf07eff0e@alum.mit.edu> From: Paul Kyzivat Message-ID: <92b5d34b-2fbf-0e2b-8562-8f7d11c5123b@alum.mit.edu> Date: Fri, 16 Oct 2020 11:17:25 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:78.0) Gecko/20100101 Thunderbird/78.3.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 61357d98-1008-4b98-c960-08d871e697f8 X-MS-TrafficTypeDiagnostic: BY5PR12MB4966: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: Fw+wbDV0Tt37Wb2sxj1hg+FK3wV94GO+GU/cTI4sSd/EwbEWTSAOlWoHrXweq0orfkrAZDnGlWZQHJ5peYg03wIMqJmrYqbqyMMkarUUzSX7RgpS+3LOlhwaV3yfWPq6fussbskckDeWdsadhs2RAkgHAKdFMHUtsVngNBTwiCMmCh0vCbVsNTdEq363BAR/O1BA3GbFXRdX/2auBwM7kUT4jA9PD+APHJx2xJo/tA2uZcndnHWd7qF4YYvSqFs1bkuufUbv2R81BqsHZLLVQUZkHnZehWFDNDVB09PLgX1ogrYeRfZT9aPyYiWmu9WRNcPyQ9kT2x1M1n87uNgjmzrOv/vCTHYRxqhJnAaMUbXohoTy8G5CPYEwysZPjgenM3haR5h0UILydVdF42uX3ybr3pm2M0xWB8dz6IDfehhcKF88wlXj028aYZWiZq/w0PneDg4b+dktowD97v+5cQ7E4QqGlYOZHiB2TnxtDnFMY2njNhv4WalJ8LBeuOJw X-Forefront-Antispam-Report: CIP:18.7.68.33; CTRY:US; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:outgoing-alum.mit.edu; PTR:outgoing-alum.mit.edu; CAT:NONE; SFS:(136003)(376002)(346002)(396003)(39860400002)(46966005)(47076004)(8936002)(36906005)(2616005)(2906002)(956004)(5660300002)(786003)(316002)(31696002)(6916009)(186003)(70206006)(26005)(356005)(8676002)(83380400001)(86362001)(82740400003)(53546011)(75432002)(7596003)(966005)(4326008)(478600001)(336012)(82310400003)(15650500001)(70586007)(31686004)(43740500002); DIR:OUT; SFP:1101; X-OriginatorOrg: alum.mit.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Oct 2020 15:17:27.5887 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 61357d98-1008-4b98-c960-08d871e697f8 X-MS-Exchange-CrossTenant-Id: 3326b102-c043-408b-a990-b89e477d582f X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3326b102-c043-408b-a990-b89e477d582f; Ip=[18.7.68.33]; Helo=[outgoing-alum.mit.edu] X-MS-Exchange-CrossTenant-AuthSource: SN1NAM02FT015.eop-nam02.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR12MB4966 Archived-At: Subject: Re: [Rum] [EXT] RUM security model X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2020 15:17:32 -0000 On 10/15/20 8:24 PM, Brian Rosen wrote: > Nope, it just takes a hacker to create a piece of code that patches an > app to look like another app. I don't follow. A user gets a device capable of passing the tests. He requests to enroll it with is provider as one of his devices. As part of that, a test is run between the device and the provider's enrollment server. Then the provider gives the device some sort of cert that can be used when registering. Next, the user decides to try out some other rogue device on his account. Normally he would repeat the above, and the device would fail the test. Instead, he might cause the rogue device to steal the cert from the device that passed. I think he can't help but know he is doing something illicit. I guess if these were both just apps, then a remote attack on the device could install a rogue app that impersonates the valid one and steals its credentials. Is that what you had in mind? Perhaps we need to spend some time with the providers enumerating the attacks they are concerned with. Thanks, Paul > On Thu, Oct 15, 2020 at 8:19 PM Paul Kyzivat > wrote: > > On 10/15/20 7:52 PM, Brian Rosen wrote: > > I don’t think even that would work because there isn’t any way to > know that the app that was approved is the app that is being used. > > Yes, I guess you are right. But at least it would require the end user > to enter into a conspiracy with the app developers, and be able to get > the credential out of one app and into another. > >         Thanks, >         Paul > > > What systems like iOS does is rely on the fact that you can’t > download and run an app that hasn’t been vetted. The code is signed > and the signature is checked every time the app starts. We don’t > have an environment like that.  We can’t control what is downloaded > and we can’t check signatures. > > > I don’t think there is a reliable way to do this. If someone has > an idea, please explain it, but we can’t be in a “you do something” > position without a clue as to how. > > > > Now, if the app was an iOS app, then the right thing happens. > There are few other systems that are wired down like that. Android, > for example, allows you to download and run from arbitrary sites if > the device is configured to allow that. > > > > Brian > > > > > >> On Oct 15, 2020, at 6:30 PM, Paul Kyzivat > wrote: > >> > >> Eugene, > >> > >>> On 10/15/20 3:30 PM, Eugene Christensen wrote: > >>> Brian, > >>> Admittedly I do not fully understand certificates and > authentication but would client certificates or mutual > authentication with a shared secret work here? > >> > >> I'm also not a security expert. To my understanding, the key > problem is that you want a proof that an implementation has passed > some sort of test. That is more or less equivalent to having a > special certification authority that is able to assign a certificate > based on the passing of a test. But for the system to work that > certificate needs to be bound to the entity (hw/sw) that passed the > test. It can't be possible to transfer that certificate to a > different device. > >> > >> A possible alternative would be for each provider to have its > own test service. When a user gets a new device/application, as part > of the initial registration of their device with the provider, this > test would be run. Then the result of that would be granting of > credentials for that device to access that provider's system. > >> > >>     Thanks, > >>     Paul > >> > >>> Thank you. > >>> Eugene > >>> *CONFIDENTIALITY NOTICE.*This e-mail transmission, and any > documents, files or previous e-mail messages attached to it, may > contain confidential and proprietary information. If you are not the > intended recipient, or a person responsible for delivering it to the > intended recipient, you are hereby notified that any disclosure, > copying, distribution or use of any of the information contained in > or attached to this message is STRICTLY PROHIBITED. If you have > received this transmission in error, please immediately notify me by > reply e-mail at echristensen@sorenson.com > >or by telephone at +1 (801) > 287-9419, and destroy the original transmission and its attachments > without reading them or saving them to disk. > >>> *From:* Brian Rosen > > >>> *Sent:* Wednesday, September 30, 2020 5:47 PM > >>> *To:* Eugene Christensen > > >>> *Cc:* rum@ietf.org > >>> *Subject:* Re: [Rum] [EXT] RUM security model > >>> [EXTERNAL] > >>> I think we understand why you want it. What we don’t understand > is what mechanism would provide it. I am generally aware of this > class of problem and I’m not aware of a solution that will work.  So > what we need is a suggested mechanism that provides the assurance > you want that is technically sound. > >>> Brian > >>> On Wed, Sep 30, 2020 at 6:30 PM Eugene Christensen > > >> wrote: > >>>     Thanks for considering how we might implement this security > >>>     mechanism.  May I add my voice that it is essential that we > find an > >>>     option for providing this desired security, whatever it is.  It > >>>     could be detrimental to the VRS providers to have UAs out > there, > >>>     with the ability to register with VRS providers without > first being > >>>     fully vetted.  It is our practice anytime we make updates > to our UAs > >>>     to test how they work with our UAS before we ever release > the new UA > >>>     software into our production environment.  We only want UAs > >>>     registering that have undergone this rigorous testing with our > >>>     systems and then only with users which we have awareness of. > >>>     Thanks, > >>>     Eugene Christensen > >>>     CONFIDENTIALITY NOTICE. This e-mail transmission, and any > documents, > >>>     files or previous e-mail messages attached to it, may contain > >>>     confidential and proprietary information. If you are not the > >>>     intended recipient, or a person responsible for delivering > it to the > >>>     intended recipient, you are hereby notified that any > disclosure, > >>>     copying, distribution or use of any of the information > contained in > >>>     or attached to this message is STRICTLY PROHIBITED. If you have > >>>     received this transmission in error, please immediately > notify me by > >>>     reply e-mail at echristensen@sorenson.com > > >>>      > or by telephone at +1 (801) > >>>     287-9419, and destroy the original transmission and its > attachments > >>>     without reading them or saving them to disk. > >>>     --     Rum mailing list > >>> Rum@ietf.org > > >>> https://www.ietf.org/mailman/listinfo/rum > > >>>      > > >> > >> -- > >> Rum mailing list > >> Rum@ietf.org > >> https://www.ietf.org/mailman/listinfo/rum > > From nobody Tue Oct 20 07:10:35 2020 Return-Path: X-Original-To: rum@ietfa.amsl.com Delivered-To: rum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB3043A0BF7 for ; Tue, 20 Oct 2020 07:10:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.888 X-Spam-Level: X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=brianrosen-net.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 Q1z-WyUSqw4h for ; Tue, 20 Oct 2020 07:10:32 -0700 (PDT) Received: from mail-io1-xd2a.google.com (mail-io1-xd2a.google.com [IPv6:2607:f8b0:4864:20::d2a]) (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 81C2A3A09B5 for ; Tue, 20 Oct 2020 07:10:32 -0700 (PDT) Received: by mail-io1-xd2a.google.com with SMTP id u62so1376670iod.8 for ; Tue, 20 Oct 2020 07:10:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=KkDho8ONaMLloqhfDglmIjD6NarXV6+a0xiwncRQpJY=; b=T0MNSKhykamdwTld5yd2pnafTVv5hTk1iSG/Xp0+H4khJQc/eJVBl6ZwSbWsNr6Yow m8ljtzaUlbxQwYhMrWx1RCoD7bwntajUBZcZQuArZQQ0xfGQdXuK3156LodsnkT1uWDU XQgt8j6uPl9a7FHllU4IFtakvUuuBl/iCq2c00EEEpyYnn6y3M3cE7FODTggKXa5Q6va NsZlBTnV62vThW6Lfgqu+SyliX4XMdsJMAl7UggbeY/a8qR3Ex4IodqYCtbzvcSyT5OH ejJEXHtDHcEl6yAh7UaAxYLkop1BpVtFDE+HY+KC6LESH+D61GSCwYlF4iEv88sDW3tf fNig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=KkDho8ONaMLloqhfDglmIjD6NarXV6+a0xiwncRQpJY=; b=bsoym9ru5P8ylkggmrVQw8ln1VDzN+LJR7UxnR8E3JpqScmfU1aaUyB8F02f2/5b40 6bIAelVfJPymh08OIIsr6FXo5b6vbXg2d16NliSEECzo8XnnuARLisz0iIpW0yb+SY0k sehWDu3JrfCXtGFHMXyh+fxjS8MAgFSMkpn4ALOHWd8Ij7QtNxKwqhNbXeRErd5j/bAz SHUNmJELZ/4C3ZA6MYddgoNhsLZnZsGyTamt+jqvT30afd+SbeLmnuHR4gNM6GjAFOOg uh5VlFsUHcgO4MZOWQsu0XVuPY8WcoPzNY8rWnlQnicn3feii4WqcJjqXX82+HP0qEvU MgFw== X-Gm-Message-State: AOAM531rnGdpRkF3A0kFhwslfJa9xcBLOoFCTCawEMPKgbPr4NKTI51W N889hcnSApV0j0OHEInruY8UjQ== X-Google-Smtp-Source: ABdhPJzSBZmAln/VA5I43VmW/czjZ8jaPK9Q/I+eRbIlaOq+6zeg0wtUH8eV42rvoyxqhtK8asWbcg== X-Received: by 2002:a6b:f610:: with SMTP id n16mr2280519ioh.103.1603203030777; Tue, 20 Oct 2020 07:10:30 -0700 (PDT) Received: from brians-mbp-2871.lan (dynamic-acs-24-154-119-158.zoominternet.net. [24.154.119.158]) by smtp.gmail.com with ESMTPSA id w23sm1668516iod.45.2020.10.20.07.10.29 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 20 Oct 2020 07:10:30 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) From: Brian Rosen In-Reply-To: <92b5d34b-2fbf-0e2b-8562-8f7d11c5123b@alum.mit.edu> Date: Tue, 20 Oct 2020 10:10:28 -0400 Cc: rum@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <4d6ba97f-a83d-3d36-14a9-c6e84dd5b874@alum.mit.edu> <7A11F680-9EA6-4477-9BD8-6A7755AD0054@brianrosen.net> <7fdb95e6-e954-7275-60f7-462cf07eff0e@alum.mit.edu> <92b5d34b-2fbf-0e2b-8562-8f7d11c5123b@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [Rum] [EXT] RUM security model X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2020 14:10:35 -0000 Yes, both apps, one app steals the credential from the other (same = machine, same user). I also don=E2=80=99t think a downloaded test would be particularly = helpful unless we built in a bunch of mechanism that allowed automation = of testing. And then, what would stop an app from playing nice with a test, and then = nasty when it wanted to? Both of these exploits do assume that the app developer intends to = flaunt approval in some way. If that=E2=80=99s not a threat that is = important to guard against then a simple magic number for an app is = enough. An app gets tested by a provider, and is given a magic number = that it provides, securely, in some way. As long as the providers trust = the app developer to not misuse the magic number, it=E2=80=99s an = indication that the app (at a particular version presumably) was = trusted. As long as malicious actors can be ignored, I think we could do = something. I don=E2=80=99t think that is worth much, but if it is, I = can write text. If you want to protect against malicious actors, then I don=E2=80=99t = know how. TPM won=E2=80=99t work - doesn=E2=80=99t work in Android/iOS. = It=E2=80=99s mostly a PC thing. Even with TPM, what you need is = something like a digest of the code. You can=E2=80=99t get that. Brian > On Oct 16, 2020, at 11:17 AM, Paul Kyzivat = wrote: >=20 > On 10/15/20 8:24 PM, Brian Rosen wrote: >> Nope, it just takes a hacker to create a piece of code that patches = an app to look like another app. >=20 > I don't follow. >=20 > A user gets a device capable of passing the tests. He requests to = enroll it with is provider as one of his devices. As part of that, a = test is run between the device and the provider's enrollment server. = Then the provider gives the device some sort of cert that can be used = when registering. >=20 > Next, the user decides to try out some other rogue device on his = account. Normally he would repeat the above, and the device would fail = the test. Instead, he might cause the rogue device to steal the cert = from the device that passed. I think he can't help but know he is doing = something illicit. >=20 > I guess if these were both just apps, then a remote attack on the = device could install a rogue app that impersonates the valid one and = steals its credentials. Is that what you had in mind? >=20 > Perhaps we need to spend some time with the providers enumerating the = attacks they are concerned with. >=20 > Thanks, > Paul >=20 >> On Thu, Oct 15, 2020 at 8:19 PM Paul Kyzivat > wrote: >> On 10/15/20 7:52 PM, Brian Rosen wrote: >> > I don=E2=80=99t think even that would work because there = isn=E2=80=99t any way to >> know that the app that was approved is the app that is being used. >> Yes, I guess you are right. But at least it would require the end = user >> to enter into a conspiracy with the app developers, and be able to = get >> the credential out of one app and into another. >> Thanks, >> Paul >> > What systems like iOS does is rely on the fact that you can=E2=80= =99t >> download and run an app that hasn=E2=80=99t been vetted. The code = is signed >> and the signature is checked every time the app starts. We don=E2=80= =99t >> have an environment like that. We can=E2=80=99t control what is = downloaded >> and we can=E2=80=99t check signatures. >> > I don=E2=80=99t think there is a reliable way to do this. If = someone has >> an idea, please explain it, but we can=E2=80=99t be in a =E2=80=9Cyo= u do something=E2=80=9D >> position without a clue as to how. >> > >> > Now, if the app was an iOS app, then the right thing happens. >> There are few other systems that are wired down like that. = Android, >> for example, allows you to download and run from arbitrary sites = if >> the device is configured to allow that. >> > >> > Brian >> > >> > >> >> On Oct 15, 2020, at 6:30 PM, Paul Kyzivat = > > wrote: >> >> >> >> =EF=BB=BFEugene, >> >> >> >>> On 10/15/20 3:30 PM, Eugene Christensen wrote: >> >>> Brian, >> >>> Admittedly I do not fully understand certificates and >> authentication but would client certificates or mutual >> authentication with a shared secret work here? >> >> >> >> I'm also not a security expert. To my understanding, the key >> problem is that you want a proof that an implementation has passed >> some sort of test. That is more or less equivalent to having a >> special certification authority that is able to assign a = certificate >> based on the passing of a test. But for the system to work that >> certificate needs to be bound to the entity (hw/sw) that passed = the >> test. It can't be possible to transfer that certificate to a >> different device. >> >> >> >> A possible alternative would be for each provider to have its >> own test service. When a user gets a new device/application, as = part >> of the initial registration of their device with the provider, = this >> test would be run. Then the result of that would be granting of >> credentials for that device to access that provider's system. >> >> >> >> Thanks, >> >> Paul >> >> >> >>> Thank you. >> >>> Eugene >> >>> *CONFIDENTIALITY NOTICE.*This e-mail transmission, and any >> documents, files or previous e-mail messages attached to it, may >> contain confidential and proprietary information. If you are not = the >> intended recipient, or a person responsible for delivering it to = the >> intended recipient, you are hereby notified that any disclosure, >> copying, distribution or use of any of the information contained = in >> or attached to this message is STRICTLY PROHIBITED. If you have >> received this transmission in error, please immediately notify me = by >> reply e-mail at echristensen@sorenson.com >> = > >or by telephone at +1 (801) >> 287-9419, and destroy the original transmission and its = attachments >> without reading them or saving them to disk. >> >>> *From:* Brian Rosen > >> >>> *Sent:* Wednesday, September 30, 2020 5:47 PM >> >>> *To:* Eugene Christensen > > >> >>> *Cc:* rum@ietf.org >> >>> *Subject:* Re: [Rum] [EXT] RUM security model >> >>> [EXTERNAL] >> >>> I think we understand why you want it. What we don=E2=80=99t = understand >> is what mechanism would provide it. I am generally aware of this >> class of problem and I=E2=80=99m not aware of a solution that will = work. So >> what we need is a suggested mechanism that provides the assurance >> you want that is technically sound. >> >>> Brian >> >>> On Wed, Sep 30, 2020 at 6:30 PM Eugene Christensen >> >> > >> wrote: >> >>> Thanks for considering how we might implement this = security >> >>> mechanism. May I add my voice that it is essential that = we >> find an >> >>> option for providing this desired security, whatever it = is. It >> >>> could be detrimental to the VRS providers to have UAs out >> there, >> >>> with the ability to register with VRS providers without >> first being >> >>> fully vetted. It is our practice anytime we make updates >> to our UAs >> >>> to test how they work with our UAS before we ever release >> the new UA >> >>> software into our production environment. We only want = UAs >> >>> registering that have undergone this rigorous testing = with our >> >>> systems and then only with users which we have awareness = of. >> >>> Thanks, >> >>> Eugene Christensen >> >>> CONFIDENTIALITY NOTICE. This e-mail transmission, and any >> documents, >> >>> files or previous e-mail messages attached to it, may = contain >> >>> confidential and proprietary information. If you are not = the >> >>> intended recipient, or a person responsible for = delivering >> it to the >> >>> intended recipient, you are hereby notified that any >> disclosure, >> >>> copying, distribution or use of any of the information >> contained in >> >>> or attached to this message is STRICTLY PROHIBITED. If = you have >> >>> received this transmission in error, please immediately >> notify me by >> >>> reply e-mail at echristensen@sorenson.com >> >> >>> > > or by telephone at +1 (801) >> >>> 287-9419, and destroy the original transmission and its >> attachments >> >>> without reading them or saving them to disk. >> >>> -- Rum mailing list >> >>> Rum@ietf.org > > >> >>> https://www.ietf.org/mailman/listinfo/rum >> >> >>> > > >> >> >> >> -- >> >> Rum mailing list >> >> Rum@ietf.org >> >> https://www.ietf.org/mailman/listinfo/rum >> >=20 From nobody Tue Oct 20 08:34:29 2020 Return-Path: X-Original-To: rum@ietfa.amsl.com Delivered-To: rum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83D663A10FF for ; Tue, 20 Oct 2020 08:34:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, NICE_REPLY_A=-0.247, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=alum.mit.edu 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 eJCDyTbKhDyQ for ; Tue, 20 Oct 2020 08:34:26 -0700 (PDT) Received: from NAM10-DM6-obe.outbound.protection.outlook.com (mail-dm6nam10on2077.outbound.protection.outlook.com [40.107.93.77]) (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 EDE1D3A10FB for ; Tue, 20 Oct 2020 08:34:25 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=V9P8Wh9NAVsFFr4eDFETbPpTCAFxoT8+wVgtF9WuwL8iBYbDPwLaavKexML1kqaWc6DCJB+1udUBpVdoSTA58WkE2i2Qpabztar5cKmQ7vSiFSUtoF66+5ZzRzmrblpjZUsCPQojd5t+Y7BKOveXLPh2g1rSIfI/4nDFxLZKXUaJjtbqKE65vUPXgSXkD12WYfrt87y4rUFJke3xN1FwniojzPNaXhXGAa4xpjDql1WwplFWax13PnnBMqYm7tKjfWPAk7WyiH7TWFskg0F9tBSIU0xD412gdyNNM1l8DqQmgX276gvVRby/WJiGSUho3oKONFi2cOpnAoDyoUrTzw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=garVt1Y30gU3ioGWbAt9yWTy69BLbohpioQ49GFiTok=; b=L56MygORh0WZsEUMKYYqW1sK2DFTGpULzLBx0XH1fIM/mKxPfUaneuCvLmdA3yt8KDsadc6lsCY1lYpKtOq1QXNzNXaTV9Ro3JFAhJ8XHgUTZ52dXTE55kfU0sbQcvTO1W+s8lnQX+kawwLd/BAe6QW7En49He4ABa1JXNkhT2SL2t7H+9LEhXdHCG9yqIj0QXpWciJUr/bRc9RGgcCLoWH6mLQ3CDs5MINgMQX2urhSgnwbYGxr1nso7Knj2LS1/jWklYnVhptrXmufs3jMdnZAQL9BeTjuEZcfvic5PCFwSkwm2qH9BNxV3e45UybRTWAtfwQ5YeRwcIcNurZ3pA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=temperror (sender ip is 18.7.68.33) smtp.rcpttodomain=brianrosen.net smtp.mailfrom=alum.mit.edu; dmarc=none action=none header.from=alum.mit.edu; dkim=none (message not signed); arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alum.mit.edu; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=garVt1Y30gU3ioGWbAt9yWTy69BLbohpioQ49GFiTok=; b=HVDRbYgSeVK6VQZV5PHgrY9uJl75Br27UFbKgvurdVdN8OYbl5F7l0guz5v3Mhx4adyEVZztAOT3G2fZjSiCJFDEojpzljh3B1LOcMVqMexlaHh7RMAtIgV70l9kp+eMIW0ZWoNKFMe33b/Hc+UeNu6qvLBGqIiSr+O/UV0/7FQ= Received: from SN4PR0201CA0024.namprd02.prod.outlook.com (2603:10b6:803:2b::34) by BYAPR12MB3029.namprd12.prod.outlook.com (2603:10b6:a03:ab::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3477.25; Tue, 20 Oct 2020 15:34:24 +0000 Received: from SN1NAM02FT032.eop-nam02.prod.protection.outlook.com (2603:10b6:803:2b:cafe::d) by SN4PR0201CA0024.outlook.office365.com (2603:10b6:803:2b::34) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3499.18 via Frontend Transport; Tue, 20 Oct 2020 15:34:24 +0000 X-MS-Exchange-Authentication-Results: spf=temperror (sender IP is 18.7.68.33) smtp.mailfrom=alum.mit.edu; brianrosen.net; dkim=none (message not signed) header.d=none;brianrosen.net; dmarc=none action=none header.from=alum.mit.edu; Received-SPF: TempError (protection.outlook.com: error in processing during lookup of alum.mit.edu: DNS Timeout) Received: from outgoing-alum.mit.edu (18.7.68.33) by SN1NAM02FT032.mail.protection.outlook.com (10.152.72.126) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3477.21 via Frontend Transport; Tue, 20 Oct 2020 15:34:22 +0000 Received: from PaulKyzivatsMBP.localdomain (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.14.7/8.12.4) with ESMTP id 09KFYId9029559 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Tue, 20 Oct 2020 11:34:18 -0400 To: Brian Rosen Cc: rum@ietf.org References: <4d6ba97f-a83d-3d36-14a9-c6e84dd5b874@alum.mit.edu> <7A11F680-9EA6-4477-9BD8-6A7755AD0054@brianrosen.net> <7fdb95e6-e954-7275-60f7-462cf07eff0e@alum.mit.edu> <92b5d34b-2fbf-0e2b-8562-8f7d11c5123b@alum.mit.edu> From: Paul Kyzivat Message-ID: <5e6d8446-c267-5113-aff1-fc87576b1317@alum.mit.edu> Date: Tue, 20 Oct 2020 11:34:18 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:78.0) Gecko/20100101 Thunderbird/78.3.3 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 81b5ae37-dced-41c2-8dbc-08d8750d9ea2 X-MS-TrafficTypeDiagnostic: BYAPR12MB3029: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:9508; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 9TbBvX2OBiwRAzeyXNCckdxSk0e3quqOY9w4uPMG+4VhrqvWA4HPLnPr7CwDOWRLUP2PeGCVWtGla7/v2S8ETq5KOGvEC4H/BGRQ8/kDFMTqE4MQcDP2bExBsrxaZjY05RWyTRzEly8TJTg+mTz0JOg/m4Azx/nxL2r+pY1TH+xUl/4MLdMLo0Xm/5drZFKuJ0RQZTvGCdrauXYioWHjty/VwFR5RzoMXBc9SINQd2n5nZaoMXBAg7/cIF77DwMMYDDna5w3hPaHVCpBQP0HnBRbS81IPClxXZn2wlAwBT9at8TQJMAzKybknRU1udwMVZiJoWt3S+T6Qj6xqs2lBxHbhZMK5UEydBogpH1y2/5tOP2rXJ4cQqElnMUPZbA97jZ7BDtICF+PpDFLMpOaXoHBDygeKViafKPul/EAdn/MK1X0lW8gMixkPwQRIlbMSLYLsLiIulILa8SsjrzQCDrFoIq0AgWHJS/F2ZqcrPbBG5ue8ZdXQhQLrSXkCf03 X-Forefront-Antispam-Report: CIP:18.7.68.33; CTRY:US; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:outgoing-alum.mit.edu; PTR:ErrorRetry; CAT:NONE; SFS:(39860400002)(396003)(136003)(376002)(346002)(46966005)(186003)(63350400001)(2616005)(316002)(786003)(36906005)(478600001)(966005)(53546011)(956004)(336012)(6916009)(26005)(83380400001)(86362001)(8936002)(31696002)(82310400003)(31686004)(15650500001)(47076004)(2906002)(356005)(81166007)(82740400003)(4326008)(8676002)(5660300002)(75432002)(70206006)(70586007)(43740500002); DIR:OUT; SFP:1101; X-OriginatorOrg: alum.mit.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Oct 2020 15:34:22.7194 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 81b5ae37-dced-41c2-8dbc-08d8750d9ea2 X-MS-Exchange-CrossTenant-Id: 3326b102-c043-408b-a990-b89e477d582f X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3326b102-c043-408b-a990-b89e477d582f; Ip=[18.7.68.33]; Helo=[outgoing-alum.mit.edu] X-MS-Exchange-CrossTenant-AuthSource: SN1NAM02FT032.eop-nam02.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR12MB3029 Archived-At: Subject: Re: [Rum] [EXT] RUM security model X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2020 15:34:29 -0000 I think this discussion highlights the need to first nail down the threat model that the providers want to protect against. James: can you take a crack at that? Possibly pull in some of the other providers if you think they will be willing. (I wonder if providers currently have any sort of robust protection against malicious impersonation of their devices? I'm guessing it is only security by obscurity.) Thanks, Paul On 10/20/20 10:10 AM, Brian Rosen wrote: > Yes, both apps, one app steals the credential from the other (same machine, same user). > > I also don’t think a downloaded test would be particularly helpful unless we built in a bunch of mechanism that allowed automation of testing. > > And then, what would stop an app from playing nice with a test, and then nasty when it wanted to? > > Both of these exploits do assume that the app developer intends to flaunt approval in some way. If that’s not a threat that is important to guard against then a simple magic number for an app is enough. An app gets tested by a provider, and is given a magic number that it provides, securely, in some way. As long as the providers trust the app developer to not misuse the magic number, it’s an indication that the app (at a particular version presumably) was trusted. > > As long as malicious actors can be ignored, I think we could do something. I don’t think that is worth much, but if it is, I can write text. > > If you want to protect against malicious actors, then I don’t know how. TPM won’t work - doesn’t work in Android/iOS. It’s mostly a PC thing. Even with TPM, what you need is something like a digest of the code. You can’t get that. > > Brian > > >> On Oct 16, 2020, at 11:17 AM, Paul Kyzivat wrote: >> >> On 10/15/20 8:24 PM, Brian Rosen wrote: >>> Nope, it just takes a hacker to create a piece of code that patches an app to look like another app. >> >> I don't follow. >> >> A user gets a device capable of passing the tests. He requests to enroll it with is provider as one of his devices. As part of that, a test is run between the device and the provider's enrollment server. Then the provider gives the device some sort of cert that can be used when registering. >> >> Next, the user decides to try out some other rogue device on his account. Normally he would repeat the above, and the device would fail the test. Instead, he might cause the rogue device to steal the cert from the device that passed. I think he can't help but know he is doing something illicit. >> >> I guess if these were both just apps, then a remote attack on the device could install a rogue app that impersonates the valid one and steals its credentials. Is that what you had in mind? >> >> Perhaps we need to spend some time with the providers enumerating the attacks they are concerned with. >> >> Thanks, >> Paul >> >>> On Thu, Oct 15, 2020 at 8:19 PM Paul Kyzivat > wrote: >>> On 10/15/20 7:52 PM, Brian Rosen wrote: >>> > I don’t think even that would work because there isn’t any way to >>> know that the app that was approved is the app that is being used. >>> Yes, I guess you are right. But at least it would require the end user >>> to enter into a conspiracy with the app developers, and be able to get >>> the credential out of one app and into another. >>> Thanks, >>> Paul >>> > What systems like iOS does is rely on the fact that you can’t >>> download and run an app that hasn’t been vetted. The code is signed >>> and the signature is checked every time the app starts. We don’t >>> have an environment like that. We can’t control what is downloaded >>> and we can’t check signatures. >>> > I don’t think there is a reliable way to do this. If someone has >>> an idea, please explain it, but we can’t be in a “you do something” >>> position without a clue as to how. >>> > >>> > Now, if the app was an iOS app, then the right thing happens. >>> There are few other systems that are wired down like that. Android, >>> for example, allows you to download and run from arbitrary sites if >>> the device is configured to allow that. >>> > >>> > Brian >>> > >>> > >>> >> On Oct 15, 2020, at 6:30 PM, Paul Kyzivat >> > wrote: >>> >> >>> >> Eugene, >>> >> >>> >>> On 10/15/20 3:30 PM, Eugene Christensen wrote: >>> >>> Brian, >>> >>> Admittedly I do not fully understand certificates and >>> authentication but would client certificates or mutual >>> authentication with a shared secret work here? >>> >> >>> >> I'm also not a security expert. To my understanding, the key >>> problem is that you want a proof that an implementation has passed >>> some sort of test. That is more or less equivalent to having a >>> special certification authority that is able to assign a certificate >>> based on the passing of a test. But for the system to work that >>> certificate needs to be bound to the entity (hw/sw) that passed the >>> test. It can't be possible to transfer that certificate to a >>> different device. >>> >> >>> >> A possible alternative would be for each provider to have its >>> own test service. When a user gets a new device/application, as part >>> of the initial registration of their device with the provider, this >>> test would be run. Then the result of that would be granting of >>> credentials for that device to access that provider's system. >>> >> >>> >> Thanks, >>> >> Paul >>> >> >>> >>> Thank you. >>> >>> Eugene >>> >>> *CONFIDENTIALITY NOTICE.*This e-mail transmission, and any >>> documents, files or previous e-mail messages attached to it, may >>> contain confidential and proprietary information. If you are not the >>> intended recipient, or a person responsible for delivering it to the >>> intended recipient, you are hereby notified that any disclosure, >>> copying, distribution or use of any of the information contained in >>> or attached to this message is STRICTLY PROHIBITED. If you have >>> received this transmission in error, please immediately notify me by >>> reply e-mail at echristensen@sorenson.com >>> >> >or by telephone at +1 (801) >>> 287-9419, and destroy the original transmission and its attachments >>> without reading them or saving them to disk. >>> >>> *From:* Brian Rosen > >>> >>> *Sent:* Wednesday, September 30, 2020 5:47 PM >>> >>> *To:* Eugene Christensen >> > >>> >>> *Cc:* rum@ietf.org >>> >>> *Subject:* Re: [Rum] [EXT] RUM security model >>> >>> [EXTERNAL] >>> >>> I think we understand why you want it. What we don’t understand >>> is what mechanism would provide it. I am generally aware of this >>> class of problem and I’m not aware of a solution that will work. So >>> what we need is a suggested mechanism that provides the assurance >>> you want that is technically sound. >>> >>> Brian >>> >>> On Wed, Sep 30, 2020 at 6:30 PM Eugene Christensen >>> >>> >> >> wrote: >>> >>> Thanks for considering how we might implement this security >>> >>> mechanism. May I add my voice that it is essential that we >>> find an >>> >>> option for providing this desired security, whatever it is. It >>> >>> could be detrimental to the VRS providers to have UAs out >>> there, >>> >>> with the ability to register with VRS providers without >>> first being >>> >>> fully vetted. It is our practice anytime we make updates >>> to our UAs >>> >>> to test how they work with our UAS before we ever release >>> the new UA >>> >>> software into our production environment. We only want UAs >>> >>> registering that have undergone this rigorous testing with our >>> >>> systems and then only with users which we have awareness of. >>> >>> Thanks, >>> >>> Eugene Christensen >>> >>> CONFIDENTIALITY NOTICE. This e-mail transmission, and any >>> documents, >>> >>> files or previous e-mail messages attached to it, may contain >>> >>> confidential and proprietary information. If you are not the >>> >>> intended recipient, or a person responsible for delivering >>> it to the >>> >>> intended recipient, you are hereby notified that any >>> disclosure, >>> >>> copying, distribution or use of any of the information >>> contained in >>> >>> or attached to this message is STRICTLY PROHIBITED. If you have >>> >>> received this transmission in error, please immediately >>> notify me by >>> >>> reply e-mail at echristensen@sorenson.com >>> >>> >>> >> > or by telephone at +1 (801) >>> >>> 287-9419, and destroy the original transmission and its >>> attachments >>> >>> without reading them or saving them to disk. >>> >>> -- Rum mailing list >>> >>> Rum@ietf.org >> > >>> >>> https://www.ietf.org/mailman/listinfo/rum >>> >>> >>> >> > >>> >> >>> >> -- >>> >> Rum mailing list >>> >> Rum@ietf.org >>> >> https://www.ietf.org/mailman/listinfo/rum >>> >> > From nobody Tue Oct 20 12:16:18 2020 Return-Path: X-Original-To: rum@ietfa.amsl.com Delivered-To: rum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B969D3A132C for ; Tue, 20 Oct 2020 12:16:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=brianrosen-net.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 HeXc2Z4NIxRS for ; Tue, 20 Oct 2020 12:16:07 -0700 (PDT) Received: from mail-qv1-xf31.google.com (mail-qv1-xf31.google.com [IPv6:2607:f8b0:4864:20::f31]) (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 AC3843A1340 for ; Tue, 20 Oct 2020 12:15:46 -0700 (PDT) Received: by mail-qv1-xf31.google.com with SMTP id cv1so1417678qvb.2 for ; Tue, 20 Oct 2020 12:15:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=kobfG23OF9rjmVNOjA/HleEKR/K+za3tzI1pnUlw0IU=; b=CYrXRbNcpJIHqgRA2hzgga+jRPgFZoOC6y5zFTNzoge9KzrjDckd4iz8xTjhMlUFQM ivz+zg/Y79E+FqzklspQoa4xFm2y7PmoXBy13kMaoeIMb8EZk+O01Wa2v5LltRpoKkf/ Ix5LZEke3x2IQ93N25B31Igyt8ZAfBRJsMhykJEibgiKDdVndAOeRwUFblODJ5Lwriii AYG6WV7YvEB9Yt3rf/RQDOU9u+2GmvlyEl//575YKycQpOlNwGmrgm5MbpN/Srcs1HpI FHtyzR6oMEWssK2RRN8HOn3WjZV4r2FW1HgjXDhTz+7wdctUiP12aRdJLlirumQP9l55 J5Gg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:to; bh=kobfG23OF9rjmVNOjA/HleEKR/K+za3tzI1pnUlw0IU=; b=GCpbBsaqzCBRPDJmuVLF2MjBr9/Is1HNzX7Rquqvuj4rjwgGuXo3bBvNPJTHmroQps EfQR5cPrKCt/FYeX/bFFK6E/KmjZIBuwQGb/52q+6G1Fe2XTLaP4b5rrRKZe/fx24SkN V1xBqoSONEutY362AyzdId1CoxGVs4ZX8S1PfvRaBdrjymyAkJkp8+BkRK+X0Pgq7x6n KDp26Mq0i2RmcYbgzdx37A7T4TDacgAFhWwIUX1E0Dy0elJatOJCHhR7bRh0cVHggTWR gD7pk/sfmetb7G2LXn7pa0UpULm29FBvoNRF+JA44otuQI98xINmjk2TNBD+Y6DPqApg k3QQ== X-Gm-Message-State: AOAM531/XkMbjAVbnBv3Uxa1FXIIwZd5bqwhI/INuBXxw/Ji9hOrJzOH 3yGeUp7kg1GxGAXG08KZLYHJqXfgAcHHa1IT X-Google-Smtp-Source: ABdhPJyBSqRMVEEp5I+Hdc9m5PxefXIUMXIQ6T1UG4wmzEA7bzBnRZkq9a4WTUZNAnae0KrJ/5DzDw== X-Received: by 2002:a05:6214:11ee:: with SMTP id e14mr4773401qvu.25.1603221345301; Tue, 20 Oct 2020 12:15:45 -0700 (PDT) Received: from brians-mbp-2871.lan (dynamic-acs-24-154-119-158.zoominternet.net. [24.154.119.158]) by smtp.gmail.com with ESMTPSA id g11sm842426qkl.30.2020.10.20.12.15.44 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 20 Oct 2020 12:15:44 -0700 (PDT) From: Brian Rosen Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Message-Id: Date: Tue, 20 Oct 2020 15:15:43 -0400 To: rum@ietf.org X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: [Rum] Configuration file X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2020 19:16:18 -0000 This is still an open item and distinct from the =E2=80=9Csigned code=E2=80= =9D issue we=E2=80=99ve been discussing. The current text describes a single file that can have multiple sets of = provider configuration data. This caters to the common case of a user = having more than provider account. The problem with the text is it has = plaintext username/passwords, which is clearly wrong. I see two solutions: require the local implementation to maintain a = password (or other multi factor authentication, and encrypt the file so = that the user needs to authenticate to access the file. Paul is worried = that the login data may be needed more frequently than is reasonable to = enter the authentication data locally. =20 The other is to maintain separate files in provider systems, with a = common authentication mechanism in each provider to access the file. I think Paul=E2=80=99s argument doesn=E2=80=99t really hold much water: = no SIP device I know of requires re-authentication that requires user = interaction very often, so whatever they do now is okay. I think they = just keep the data locally, secure enough to re-use when they need to. = So unlock once, good for a very long time. I=E2=80=99m reluctant to require all providers use the new OAUTH2 = solution, but if they were okay with it, that would be excellent. We = would need some notion of common username, but otherwise it would just = work. Seems way too different from how things work now. Very = attractive, secure, and user-friendly. Brian= From nobody Tue Oct 20 22:28:19 2020 Return-Path: X-Original-To: rum@ietfa.amsl.com Delivered-To: rum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23B8B3A1023 for ; Tue, 20 Oct 2020 22:28:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 9qqP8qZcJI5u for ; Tue, 20 Oct 2020 22:28:12 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) (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 C12723A0ABB for ; Tue, 20 Oct 2020 22:28:11 -0700 (PDT) Received: from macbook-pro.webway.org (h-205-16.A165.corp.bahnhof.se [176.10.205.16]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp7.webway.se (Postfix) with ESMTPSA id 4AE9F2361; Wed, 21 Oct 2020 07:28:07 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) From: "Olle E. Johansson" In-Reply-To: Date: Wed, 21 Oct 2020 07:28:06 +0200 Cc: Olle E Johansson , rum@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <64C1A076-27B1-49FB-B52D-A1E300FF7D0E@edvina.net> References: To: Brian Rosen X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [Rum] Configuration file X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2020 05:28:15 -0000 > On 20 Oct 2020, at 21:15, Brian Rosen wrote: >=20 > This is still an open item and distinct from the =E2=80=9Csigned = code=E2=80=9D issue we=E2=80=99ve been discussing. >=20 > The current text describes a single file that can have multiple sets = of provider configuration data. This caters to the common case of a = user having more than provider account. The problem with the text is it = has plaintext username/passwords, which is clearly wrong. >=20 > I see two solutions: require the local implementation to maintain a = password (or other multi factor authentication, and encrypt the file so = that the user needs to authenticate to access the file. Paul is worried = that the login data may be needed more frequently than is reasonable to = enter the authentication data locally. =20 >=20 > The other is to maintain separate files in provider systems, with a = common authentication mechanism in each provider to access the file. >=20 > I think Paul=E2=80=99s argument doesn=E2=80=99t really hold much = water: no SIP device I know of requires re-authentication that requires = user interaction very often, so whatever they do now is okay. I think = they just keep the data locally, secure enough to re-use when they need = to. So unlock once, good for a very long time. >=20 > I=E2=80=99m reluctant to require all providers use the new OAUTH2 = solution, but if they were okay with it, that would be excellent. We = would need some notion of common username, but otherwise it would just = work. Seems way too different from how things work now. Very = attractive, secure, and user-friendly. To add to your list: Don=E2=80=99t forget about using TLS client certs. = It=E2=80=99s not very hard, can securely be provisioned using Oauth or = other means and can be re-issued often. For the telco business it=E2=80=99s unusal, = but it=E2=80=99s frequently used in other solutions, like VPNs. You can one per provider, based on the same key pair or separate key = pairs. =20 /O= From nobody Wed Oct 21 06:36:49 2020 Return-Path: X-Original-To: rum@ietfa.amsl.com Delivered-To: rum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81B0D3A0AA7 for ; Wed, 21 Oct 2020 06:36:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sorenson.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 TD4FABXhneRP for ; Wed, 21 Oct 2020 06:36:44 -0700 (PDT) Received: from NAM12-DM6-obe.outbound.protection.outlook.com (mail-dm6nam12on2073.outbound.protection.outlook.com [40.107.243.73]) (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 19B803A114E for ; Wed, 21 Oct 2020 06:32:13 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=NJW6PHcg0SzuLysfKTyMntH11SMOyEupsEJMoaqlZB5J/4oW6dzvnQDOktRN6WOHWuFlhSl4Fg40VHfPRUWVg0TKH0kVdLEsNgFxr7joRZbvqaKu9EGpbh6hQe9fGzhQKaSarEJZ9/mdiI9uALqQNMSUZZhhJ00HkssVeAoDSTv4jc+cpZDAkEkqBQDCZKA95zCu04WzzdXO62QAnZvlk+NCqSQ8YwdUszFUFV3ZOnPo9tP7aZ27O7SmYX5spi7BuEzWeBg0i3ouk+zpqsur7TL9QvzDrm0TK0xoazYfUC/1+3a7SD2s+Az349Q+ZjabSbKG2dxUskk31/eN3MDXqA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=QnFY3vlMSvL8BNK22KkApOspCuDEPOT5J6kAGUA223w=; b=RkadJ3Nv1GHcwBQ1WYCyNfefGbPlMVCqsXR/4hvLjpiVygT3F8Jr0Nxw9XyYhZrG6Y/uhGwxmuGtFSbDrDd1UsioBr9cdqpUmE5KqQzU+Y/W9xF4F2aHjDIRpHuTfMzHewnuvzKpQe0FDdg78u6Agl8joHJ5k0VgN3+1q73Hw1pv338yojL999vGgWB/IakgX5ArjsLAwJfM7+nFBmkRdG9fjphEpLjy6Y5BHjts3B2Bz1GocRyqikh7H/c+pvNK42V83r1h/1R4G8uwEpDJv2q5BlhLK1USz10Gj39YqshN3daQhTKhxZGZamxwfzF8nb2FdPGL1MGYUx33UhS0Gw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=sorenson.com; dmarc=pass action=none header.from=sorenson.com; dkim=pass header.d=sorenson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sorenson.onmicrosoft.com; s=selector2-sorenson-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=QnFY3vlMSvL8BNK22KkApOspCuDEPOT5J6kAGUA223w=; b=J4tRMdVHK6P9/RPqKIZIXpz8Dv8AlJfijtnbcUrV2S3OHZ/Q7gVk087eSsC2JQ3upiTu+OPTet1ncf+WvMWvm2F0OMmzjh4srvMZ9dxOPdITpoaC8FeY43Wd17+1PbHi0UsZT+yzp28F7TUdhhLQ4QMGZQttqj9qoYyhP3w6WOM= Received: from BYAPR04MB4983.namprd04.prod.outlook.com (2603:10b6:a03:41::29) by BY5PR04MB6690.namprd04.prod.outlook.com (2603:10b6:a03:22c::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3499.18; Wed, 21 Oct 2020 13:32:10 +0000 Received: from BYAPR04MB4983.namprd04.prod.outlook.com ([fe80::e09a:6be0:ccf6:a8b1]) by BYAPR04MB4983.namprd04.prod.outlook.com ([fe80::e09a:6be0:ccf6:a8b1%7]) with mapi id 15.20.3477.029; Wed, 21 Oct 2020 13:32:10 +0000 From: Eugene Christensen To: Paul Kyzivat , Brian Rosen CC: "rum@ietf.org" Thread-Topic: [Rum] [EXT] RUM security model Thread-Index: AQHWlnxQD9PXpaMUFE6N0jV2IR9mp6mBxBhggAAW2wCAF0rLoIAAMpaAgAAXOoCAAAeJgIAAAV6AgAD5eYCABjafAIAAF2wAgAFtX5A= Date: Wed, 21 Oct 2020 13:32:10 +0000 Message-ID: References: <4d6ba97f-a83d-3d36-14a9-c6e84dd5b874@alum.mit.edu> <7A11F680-9EA6-4477-9BD8-6A7755AD0054@brianrosen.net> <7fdb95e6-e954-7275-60f7-462cf07eff0e@alum.mit.edu> <92b5d34b-2fbf-0e2b-8562-8f7d11c5123b@alum.mit.edu> <5e6d8446-c267-5113-aff1-fc87576b1317@alum.mit.edu> In-Reply-To: <5e6d8446-c267-5113-aff1-fc87576b1317@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: alum.mit.edu; dkim=none (message not signed) header.d=none;alum.mit.edu; dmarc=none action=none header.from=sorenson.com; x-originating-ip: [75.146.88.198] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: abe2f4ea-22f7-4061-2b78-08d875c5b6bc x-ms-traffictypediagnostic: BY5PR04MB6690: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: K0QpzJ0ifb7RcmaW6eWoTQwjHlF/cYpsd0O2TLENOum7t6m/u0SRTSy+lXS9cknODSgcWVX9HiBoUBao3OOU8aFHtlYPT2xSfBLXLt3f2DghtaWzDcwfmV+k6SzaV+6+RAjWjtRK64QEd+VYELfSw9hQjX6M2Y0jTaEuSXlTsVMMkvlfmvKGY9lOnqI3HIRNXF1VlmYRoOGwLLnzxor4WOiP/mJWD4t1KVxLkSXi21pjueKwhZl0pZK5grK6UFzhqTTApkoA4E4xfcP7YZegZqiUHDZHWDVhlmNvu/NMLi38CL4QGx6SfpgeEiovGbwObzhTzkMWTbAUoyb3Xb24bhu2VlY7GLTL3VINSlLINPr5XhWETipSWWkS4lwzzyrY9pvPjuBtwlNg3sQygnvn1g== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BYAPR04MB4983.namprd04.prod.outlook.com; PTR:; CAT:NONE; SFS:(346002)(366004)(376002)(136003)(396003)(39850400004)(83380400001)(66476007)(2906002)(55016002)(66446008)(64756008)(6506007)(66556008)(53546011)(76116006)(316002)(966005)(66946007)(110136005)(478600001)(8936002)(186003)(26005)(8676002)(15650500001)(18074004)(71200400001)(7696005)(9686003)(4326008)(52536014)(33656002)(86362001)(30864003)(5660300002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: pfkuc3rFUh9MOaqs0cKfg2I/4QnLjZdxzjn3ErKE8dSxl2Rkc6xVlIlt/jghkKOoPamkDMhUHt1GeRBvWkH0OTU+hsV3/VvQYCf1/Uo7+jhrQbFq/h2ottnEHnrFRgaJF5hTgPulNnyjqGb1NEhNDc2q02fQbDSdWra4OLdVm++ZW8NC4z49GtCkozuGx8es9hfyZBpw72LhLh3jhuRfBOQnM0PpLh9Ab2slJxdiVr7BV/TlFePDf0u2bOZeTEPnKWqjmyOOt80GRiRb9NmrwusF0dsLxId9Educ1mB2hb8CtoMiqoQIG3OdHHXkg1IM2NUpebHreosHj2xpfIo90zsPRyhuN6LRyN2/H/yCw+LWTHzew4AeXaPinEFYunLbBNamUVqDZozIo6nknXTLZuThfrsDPH91hldZtS2OacYEv1oruq1lN8MLpo9BrmJBsFY8IVNWQ+3EO16nucCD7S23bTHAMiGV40FAWZvb2PQnpHeL7WUQi2mJI+GqGB4n82gbZEvDRZfp13LhMY0H3fetBcbh0Aw7J8kOd60Z3UgjSM6sSNQG4SIRfdTmvqWXAZOCHOWyUVRTh+pAlc+uMzT0s058PHdRioQzjMwXgIGQ05YMPkYMuFbHr2ubNTigP++z/z6TkXg+kHllDzFRJA== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: sorenson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BYAPR04MB4983.namprd04.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: abe2f4ea-22f7-4061-2b78-08d875c5b6bc X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Oct 2020 13:32:10.6158 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 6b03ef08-a104-48c4-a951-f18d295428d5 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 4jPIdjXFkCUVHtck3svQq1q/XUkML3d7W8zPGO+Hea/htVzW8qtfWgRgOQqWhN+n9Ov04hlGcOVHUrZFo7XNNccZZoDbVeycXUkm2Qem1fk= X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR04MB6690 Archived-At: Subject: Re: [Rum] [EXT] RUM security model X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2020 13:36:48 -0000 QnJpYW4sDQoNCllvdSBtZW50aW9uZWQgdGhlIHVzZSBvZiBhIG1hZ2ljIG51bWJlci4gIElzIHRo YXQgdGhlIHNhbWUgYXMgdGhlIHVzZSBvZiBhbiBhdXRob3JpemF0aW9uIGtleSB0aGF0IGlzIGJ1 aWx0IGludG8gdGhlIHByb2R1Y3Qgd2l0aCB0aGUgcmVzcGVjdGl2ZSBwcm92aWRlcidzIGtleShz KT8gIElmIHNvIEkgYmVsaWV2ZSB0aGF0IGNvdWxkIHBvc3NpYmx5IHdvcmsuICBJZiBJIHVuZGVy c3RhbmQgdGhhdCBjb3JyZWN0bHksIHRoZSBwcm92aWRlcidzIHdvdWxkIGdpdmUgYSBrZXkgdG8g dGhlIGRldmVsb3BlciB0aGF0IHdvdWxkIGJlIHVuaXF1ZSB0byB0aGF0IGFwcGxpY2F0aW9uIGFu ZCB2ZXJzaW9uLiAgV2hlbiB0aGF0IGFwcGxpY2F0aW9uIGF0dGVtcHRzIHRvIGNvbm5lY3QgdG8g YSBwcm92aWRlciwgdGhlIHByb3ZpZGVyIHdpbGwga25vdyB3aGF0IGNvbXBhbnkncyBhcHAgYW5k IHZlcnNpb24gaXQgaXMgYW5kIGJlIGFibGUgdG8gYWNjZXB0IHRoZSBjb25uZWN0aW9uIG9uY2Ug aXQgaGFzIGJlZW4gdmVyaWZpZWQgaW4gdGhlIGxhYi4gIElmIGl0IGdvZXMgcm9ndWUgdGhlcmVh ZnRlciwgYXMgSSB1bmRlcnN0YW5kIGl0LCB0aGUgcHJvdmlkZXJzIGNvdWxkIHJldm9rZSB0aGF0 IGFjY2Vzcy4NCg0KUmVnYXJkaW5nIHNvbWUgY29uY2VybnMgd2l0aCBhbiBvcGVuIEFQSSwgaGVy ZSBhcmUgdGhyZWUgdGhhdCBzaG91bGQgYmUgY2FwdHVyZWQ6DQotIEJydXRlIGZvcmNlIGF0dGFj a3MgLSBBIGJhZCBhY3RvciBjb3VsZCB1c2UgYW4gQVBJIHRvIGRldGVybWluZSBhIHVzZXIncyBw YXNzd29yZC4NCi0gVW50ZXN0ZWQgY2xpZW50cyAtIEEgcHJvYmxlbSBjYXVzZWQgdW5pbnRlbnRp b25hbGx5IGJ5IGFuIGVuZHBvaW50IGRldmVsb3BlciB3aXRoIGdvb2QgaW50ZW50aW9ucy4gDQot IERET1MgYXR0YWNrcyAtIEEgYmFkIGFjdG9yIGNvdWxkIHRyeSB0byBicmluZyBhIHN5c3RlbSBk b3duIGJ5IHNlbmRpbmcgbXVsdGlwbGUgcmVxdWVzdHMgZnJvbSBkaWZmZXJlbnQgSVAgYWRkcmVz c2VzIG1ha2luZyBpdCBkaWZmaWN1bHQgdG8gYmxvY2suDQoNCg0KVGhhbmtzLA0KRXVnZW5lLg0K DQpDT05GSURFTlRJQUxJVFkgTk9USUNFLiBUaGlzIGUtbWFpbCB0cmFuc21pc3Npb24sIGFuZCBh bnkgZG9jdW1lbnRzLCBmaWxlcyBvciBwcmV2aW91cyBlLW1haWwgbWVzc2FnZXMgYXR0YWNoZWQg dG8gaXQsIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBhbmQgcHJvcHJpZXRhcnkgaW5mb3JtYXRp b24uIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIG9yIGEgcGVyc29uIHJl c3BvbnNpYmxlIGZvciBkZWxpdmVyaW5nIGl0IHRvIHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHlv dSBhcmUgaGVyZWJ5IG5vdGlmaWVkIHRoYXQgYW55IGRpc2Nsb3N1cmUsIGNvcHlpbmcsIGRpc3Ry aWJ1dGlvbiBvciB1c2Ugb2YgYW55IG9mIHRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gb3Ig YXR0YWNoZWQgdG8gdGhpcyBtZXNzYWdlIGlzIFNUUklDVExZIFBST0hJQklURUQuIElmIHlvdSBo YXZlIHJlY2VpdmVkIHRoaXMgdHJhbnNtaXNzaW9uIGluIGVycm9yLCBwbGVhc2UgaW1tZWRpYXRl bHkgbm90aWZ5IG1lIGJ5IHJlcGx5IGUtbWFpbCBhdCBlY2hyaXN0ZW5zZW5Ac29yZW5zb24uY29t IG9yIGJ5IHRlbGVwaG9uZSBhdCArMSAoODAxKSAyODctOTQxOSwgYW5kIGRlc3Ryb3kgdGhlIG9y aWdpbmFsIHRyYW5zbWlzc2lvbiBhbmQgaXRzIGF0dGFjaG1lbnRzIHdpdGhvdXQgcmVhZGluZyB0 aGVtIG9yIHNhdmluZyB0aGVtIHRvIGRpc2suDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQpGcm9tOiBSdW0gPHJ1bS1ib3VuY2VzQGlldGYub3JnPiBPbiBCZWhhbGYgT2YgUGF1bCBLeXpp dmF0DQpTZW50OiBUdWVzZGF5LCBPY3RvYmVyIDIwLCAyMDIwIDk6MzQgQU0NClRvOiBCcmlhbiBS b3NlbiA8YnJAYnJpYW5yb3Nlbi5uZXQ+DQpDYzogcnVtQGlldGYub3JnDQpTdWJqZWN0OiBSZTog W1J1bV0gW0VYVF0gUlVNIHNlY3VyaXR5IG1vZGVsDQoNCltFWFRFUk5BTF0gDQoNCkkgdGhpbmsg dGhpcyBkaXNjdXNzaW9uIGhpZ2hsaWdodHMgdGhlIG5lZWQgdG8gZmlyc3QgbmFpbCBkb3duIHRo ZSB0aHJlYXQgbW9kZWwgdGhhdCB0aGUgcHJvdmlkZXJzIHdhbnQgdG8gcHJvdGVjdCBhZ2FpbnN0 Lg0KDQpKYW1lczogY2FuIHlvdSB0YWtlIGEgY3JhY2sgYXQgdGhhdD8gUG9zc2libHkgcHVsbCBp biBzb21lIG9mIHRoZSBvdGhlciBwcm92aWRlcnMgaWYgeW91IHRoaW5rIHRoZXkgd2lsbCBiZSB3 aWxsaW5nLg0KDQooSSB3b25kZXIgaWYgcHJvdmlkZXJzIGN1cnJlbnRseSBoYXZlIGFueSBzb3J0 IG9mIHJvYnVzdCBwcm90ZWN0aW9uIGFnYWluc3QgbWFsaWNpb3VzIGltcGVyc29uYXRpb24gb2Yg dGhlaXIgZGV2aWNlcz8gSSdtIGd1ZXNzaW5nIGl0IGlzIG9ubHkgc2VjdXJpdHkgYnkgb2JzY3Vy aXR5LikNCg0KCVRoYW5rcywNCglQYXVsDQoNCk9uIDEwLzIwLzIwIDEwOjEwIEFNLCBCcmlhbiBS b3NlbiB3cm90ZToNCj4gWWVzLCBib3RoIGFwcHMsIG9uZSBhcHAgc3RlYWxzIHRoZSBjcmVkZW50 aWFsIGZyb20gdGhlIG90aGVyIChzYW1lIG1hY2hpbmUsIHNhbWUgdXNlcikuDQo+IA0KPiBJIGFs c28gZG9u4oCZdCB0aGluayBhIGRvd25sb2FkZWQgdGVzdCB3b3VsZCBiZSBwYXJ0aWN1bGFybHkg aGVscGZ1bCB1bmxlc3Mgd2UgYnVpbHQgaW4gYSBidW5jaCBvZiBtZWNoYW5pc20gdGhhdCBhbGxv d2VkIGF1dG9tYXRpb24gb2YgdGVzdGluZy4NCj4gDQo+IEFuZCB0aGVuLCB3aGF0IHdvdWxkIHN0 b3AgYW4gYXBwIGZyb20gcGxheWluZyBuaWNlIHdpdGggYSB0ZXN0LCBhbmQgdGhlbiBuYXN0eSB3 aGVuIGl0IHdhbnRlZCB0bz8NCj4gDQo+IEJvdGggb2YgdGhlc2UgZXhwbG9pdHMgZG8gYXNzdW1l IHRoYXQgdGhlIGFwcCBkZXZlbG9wZXIgaW50ZW5kcyB0byBmbGF1bnQgYXBwcm92YWwgaW4gc29t ZSB3YXkuICBJZiB0aGF04oCZcyBub3QgYSB0aHJlYXQgdGhhdCBpcyBpbXBvcnRhbnQgdG8gZ3Vh cmQgYWdhaW5zdCB0aGVuIGEgc2ltcGxlIG1hZ2ljIG51bWJlciBmb3IgYW4gYXBwIGlzIGVub3Vn aC4gIEFuIGFwcCBnZXRzIHRlc3RlZCBieSBhIHByb3ZpZGVyLCBhbmQgaXMgZ2l2ZW4gYSBtYWdp YyBudW1iZXIgdGhhdCBpdCBwcm92aWRlcywgc2VjdXJlbHksIGluIHNvbWUgd2F5LiAgQXMgbG9u ZyBhcyB0aGUgcHJvdmlkZXJzIHRydXN0IHRoZSBhcHAgZGV2ZWxvcGVyIHRvIG5vdCBtaXN1c2Ug dGhlIG1hZ2ljIG51bWJlciwgaXTigJlzIGFuIGluZGljYXRpb24gdGhhdCB0aGUgYXBwIChhdCBh IHBhcnRpY3VsYXIgdmVyc2lvbiBwcmVzdW1hYmx5KSB3YXMgdHJ1c3RlZC4NCj4gDQo+IEFzIGxv bmcgYXMgbWFsaWNpb3VzIGFjdG9ycyBjYW4gYmUgaWdub3JlZCwgSSB0aGluayB3ZSBjb3VsZCBk byBzb21ldGhpbmcuICBJIGRvbuKAmXQgdGhpbmsgdGhhdCBpcyB3b3J0aCBtdWNoLCBidXQgaWYg aXQgaXMsIEkgY2FuIHdyaXRlIHRleHQuDQo+IA0KPiBJZiB5b3Ugd2FudCB0byBwcm90ZWN0IGFn YWluc3QgbWFsaWNpb3VzIGFjdG9ycywgdGhlbiBJIGRvbuKAmXQga25vdyBob3cuICBUUE0gd29u 4oCZdCB3b3JrIC0gZG9lc27igJl0IHdvcmsgaW4gQW5kcm9pZC9pT1MuICBJdOKAmXMgbW9zdGx5 IGEgUEMgdGhpbmcuICBFdmVuIHdpdGggVFBNLCB3aGF0IHlvdSBuZWVkIGlzIHNvbWV0aGluZyBs aWtlIGEgZGlnZXN0IG9mIHRoZSBjb2RlLiAgWW91IGNhbuKAmXQgZ2V0IHRoYXQuDQo+IA0KPiBC cmlhbg0KPiANCj4gDQo+PiBPbiBPY3QgMTYsIDIwMjAsIGF0IDExOjE3IEFNLCBQYXVsIEt5eml2 YXQgPHBreXppdmF0QGFsdW0ubWl0LmVkdT4gd3JvdGU6DQo+Pg0KPj4gT24gMTAvMTUvMjAgODoy NCBQTSwgQnJpYW4gUm9zZW4gd3JvdGU6DQo+Pj4gTm9wZSwgaXQganVzdCB0YWtlcyBhIGhhY2tl ciB0byBjcmVhdGUgYSBwaWVjZSBvZiBjb2RlIHRoYXQgcGF0Y2hlcyBhbiBhcHAgdG8gbG9vayBs aWtlIGFub3RoZXIgYXBwLg0KPj4NCj4+IEkgZG9uJ3QgZm9sbG93Lg0KPj4NCj4+IEEgdXNlciBn ZXRzIGEgZGV2aWNlIGNhcGFibGUgb2YgcGFzc2luZyB0aGUgdGVzdHMuIEhlIHJlcXVlc3RzIHRv IGVucm9sbCBpdCB3aXRoIGlzIHByb3ZpZGVyIGFzIG9uZSBvZiBoaXMgZGV2aWNlcy4gQXMgcGFy dCBvZiB0aGF0LCBhIHRlc3QgaXMgcnVuIGJldHdlZW4gdGhlIGRldmljZSBhbmQgdGhlIHByb3Zp ZGVyJ3MgZW5yb2xsbWVudCBzZXJ2ZXIuIFRoZW4gdGhlIHByb3ZpZGVyIGdpdmVzIHRoZSBkZXZp Y2Ugc29tZSBzb3J0IG9mIGNlcnQgdGhhdCBjYW4gYmUgdXNlZCB3aGVuIHJlZ2lzdGVyaW5nLg0K Pj4NCj4+IE5leHQsIHRoZSB1c2VyIGRlY2lkZXMgdG8gdHJ5IG91dCBzb21lIG90aGVyIHJvZ3Vl IGRldmljZSBvbiBoaXMgYWNjb3VudC4gTm9ybWFsbHkgaGUgd291bGQgcmVwZWF0IHRoZSBhYm92 ZSwgYW5kIHRoZSBkZXZpY2Ugd291bGQgZmFpbCB0aGUgdGVzdC4gSW5zdGVhZCwgaGUgbWlnaHQg Y2F1c2UgdGhlIHJvZ3VlIGRldmljZSB0byBzdGVhbCB0aGUgY2VydCBmcm9tIHRoZSBkZXZpY2Ug dGhhdCBwYXNzZWQuIEkgdGhpbmsgaGUgY2FuJ3QgaGVscCBidXQga25vdyBoZSBpcyBkb2luZyBz b21ldGhpbmcgaWxsaWNpdC4NCj4+DQo+PiBJIGd1ZXNzIGlmIHRoZXNlIHdlcmUgYm90aCBqdXN0 IGFwcHMsIHRoZW4gYSByZW1vdGUgYXR0YWNrIG9uIHRoZSBkZXZpY2UgY291bGQgaW5zdGFsbCBh IHJvZ3VlIGFwcCB0aGF0IGltcGVyc29uYXRlcyB0aGUgdmFsaWQgb25lIGFuZCBzdGVhbHMgaXRz IGNyZWRlbnRpYWxzLiBJcyB0aGF0IHdoYXQgeW91IGhhZCBpbiBtaW5kPw0KPj4NCj4+IFBlcmhh cHMgd2UgbmVlZCB0byBzcGVuZCBzb21lIHRpbWUgd2l0aCB0aGUgcHJvdmlkZXJzIGVudW1lcmF0 aW5nIHRoZSBhdHRhY2tzIHRoZXkgYXJlIGNvbmNlcm5lZCB3aXRoLg0KPj4NCj4+IAlUaGFua3Ms DQo+PiAJUGF1bA0KPj4NCj4+PiBPbiBUaHUsIE9jdCAxNSwgMjAyMCBhdCA4OjE5IFBNIFBhdWwg S3l6aXZhdCA8cGt5eml2YXRAYWx1bS5taXQuZWR1IDxtYWlsdG86cGt5eml2YXRAYWx1bS5taXQu ZWR1Pj4gd3JvdGU6DQo+Pj4gICAgIE9uIDEwLzE1LzIwIDc6NTIgUE0sIEJyaWFuIFJvc2VuIHdy b3RlOg0KPj4+ICAgICAgPiBJIGRvbuKAmXQgdGhpbmsgZXZlbiB0aGF0IHdvdWxkIHdvcmsgYmVj YXVzZSB0aGVyZSBpc27igJl0IGFueSB3YXkgdG8NCj4+PiAgICAga25vdyB0aGF0IHRoZSBhcHAg dGhhdCB3YXMgYXBwcm92ZWQgaXMgdGhlIGFwcCB0aGF0IGlzIGJlaW5nIHVzZWQuDQo+Pj4gICAg IFllcywgSSBndWVzcyB5b3UgYXJlIHJpZ2h0LiBCdXQgYXQgbGVhc3QgaXQgd291bGQgcmVxdWly ZSB0aGUgZW5kIHVzZXINCj4+PiAgICAgdG8gZW50ZXIgaW50byBhIGNvbnNwaXJhY3kgd2l0aCB0 aGUgYXBwIGRldmVsb3BlcnMsIGFuZCBiZSBhYmxlIHRvIGdldA0KPj4+ICAgICB0aGUgY3JlZGVu dGlhbCBvdXQgb2Ygb25lIGFwcCBhbmQgaW50byBhbm90aGVyLg0KPj4+ICAgICAgICAgICAgICBU aGFua3MsDQo+Pj4gICAgICAgICAgICAgIFBhdWwNCj4+PiAgICAgID4gV2hhdCBzeXN0ZW1zIGxp a2UgaU9TIGRvZXMgaXMgcmVseSBvbiB0aGUgZmFjdCB0aGF0IHlvdSBjYW7igJl0DQo+Pj4gICAg IGRvd25sb2FkIGFuZCBydW4gYW4gYXBwIHRoYXQgaGFzbuKAmXQgYmVlbiB2ZXR0ZWQuIFRoZSBj b2RlIGlzIHNpZ25lZA0KPj4+ICAgICBhbmQgdGhlIHNpZ25hdHVyZSBpcyBjaGVja2VkIGV2ZXJ5 IHRpbWUgdGhlIGFwcCBzdGFydHMuIFdlIGRvbuKAmXQNCj4+PiAgICAgaGF2ZSBhbiBlbnZpcm9u bWVudCBsaWtlIHRoYXQuICBXZSBjYW7igJl0IGNvbnRyb2wgd2hhdCBpcyBkb3dubG9hZGVkDQo+ Pj4gICAgIGFuZCB3ZSBjYW7igJl0IGNoZWNrIHNpZ25hdHVyZXMuDQo+Pj4gICAgICA+IEkgZG9u 4oCZdCB0aGluayB0aGVyZSBpcyBhIHJlbGlhYmxlIHdheSB0byBkbyB0aGlzLiBJZiBzb21lb25l IGhhcw0KPj4+ICAgICBhbiBpZGVhLCBwbGVhc2UgZXhwbGFpbiBpdCwgYnV0IHdlIGNhbuKAmXQg YmUgaW4gYSDigJx5b3UgZG8gc29tZXRoaW5n4oCdDQo+Pj4gICAgIHBvc2l0aW9uIHdpdGhvdXQg YSBjbHVlIGFzIHRvIGhvdy4NCj4+PiAgICAgID4NCj4+PiAgICAgID4gTm93LCBpZiB0aGUgYXBw IHdhcyBhbiBpT1MgYXBwLCB0aGVuIHRoZSByaWdodCB0aGluZyBoYXBwZW5zLg0KPj4+ICAgICBU aGVyZSBhcmUgZmV3IG90aGVyIHN5c3RlbXMgdGhhdCBhcmUgd2lyZWQgZG93biBsaWtlIHRoYXQu IEFuZHJvaWQsDQo+Pj4gICAgIGZvciBleGFtcGxlLCBhbGxvd3MgeW91IHRvIGRvd25sb2FkIGFu ZCBydW4gZnJvbSBhcmJpdHJhcnkgc2l0ZXMgaWYNCj4+PiAgICAgdGhlIGRldmljZSBpcyBjb25m aWd1cmVkIHRvIGFsbG93IHRoYXQuDQo+Pj4gICAgICA+DQo+Pj4gICAgICA+IEJyaWFuDQo+Pj4g ICAgICA+DQo+Pj4gICAgICA+DQo+Pj4gICAgICA+PiBPbiBPY3QgMTUsIDIwMjAsIGF0IDY6MzAg UE0sIFBhdWwgS3l6aXZhdCA8cGt5eml2YXRAYWx1bS5taXQuZWR1DQo+Pj4gICAgIDxtYWlsdG86 cGt5eml2YXRAYWx1bS5taXQuZWR1Pj4gd3JvdGU6DQo+Pj4gICAgICA+Pg0KPj4+ICAgICAgPj4g 77u/RXVnZW5lLA0KPj4+ICAgICAgPj4NCj4+PiAgICAgID4+PiBPbiAxMC8xNS8yMCAzOjMwIFBN LCBFdWdlbmUgQ2hyaXN0ZW5zZW4gd3JvdGU6DQo+Pj4gICAgICA+Pj4gQnJpYW4sDQo+Pj4gICAg ICA+Pj4gQWRtaXR0ZWRseSBJIGRvIG5vdCBmdWxseSB1bmRlcnN0YW5kIGNlcnRpZmljYXRlcyBh bmQNCj4+PiAgICAgYXV0aGVudGljYXRpb24gYnV0IHdvdWxkIGNsaWVudCBjZXJ0aWZpY2F0ZXMg b3IgbXV0dWFsDQo+Pj4gICAgIGF1dGhlbnRpY2F0aW9uIHdpdGggYSBzaGFyZWQgc2VjcmV0IHdv cmsgaGVyZT8NCj4+PiAgICAgID4+DQo+Pj4gICAgICA+PiBJJ20gYWxzbyBub3QgYSBzZWN1cml0 eSBleHBlcnQuIFRvIG15IHVuZGVyc3RhbmRpbmcsIHRoZSBrZXkNCj4+PiAgICAgcHJvYmxlbSBp cyB0aGF0IHlvdSB3YW50IGEgcHJvb2YgdGhhdCBhbiBpbXBsZW1lbnRhdGlvbiBoYXMgcGFzc2Vk DQo+Pj4gICAgIHNvbWUgc29ydCBvZiB0ZXN0LiBUaGF0IGlzIG1vcmUgb3IgbGVzcyBlcXVpdmFs ZW50IHRvIGhhdmluZyBhDQo+Pj4gICAgIHNwZWNpYWwgY2VydGlmaWNhdGlvbiBhdXRob3JpdHkg dGhhdCBpcyBhYmxlIHRvIGFzc2lnbiBhIGNlcnRpZmljYXRlDQo+Pj4gICAgIGJhc2VkIG9uIHRo ZSBwYXNzaW5nIG9mIGEgdGVzdC4gQnV0IGZvciB0aGUgc3lzdGVtIHRvIHdvcmsgdGhhdA0KPj4+ ICAgICBjZXJ0aWZpY2F0ZSBuZWVkcyB0byBiZSBib3VuZCB0byB0aGUgZW50aXR5IChody9zdykg dGhhdCBwYXNzZWQgdGhlDQo+Pj4gICAgIHRlc3QuIEl0IGNhbid0IGJlIHBvc3NpYmxlIHRvIHRy YW5zZmVyIHRoYXQgY2VydGlmaWNhdGUgdG8gYQ0KPj4+ICAgICBkaWZmZXJlbnQgZGV2aWNlLg0K Pj4+ICAgICAgPj4NCj4+PiAgICAgID4+IEEgcG9zc2libGUgYWx0ZXJuYXRpdmUgd291bGQgYmUg Zm9yIGVhY2ggcHJvdmlkZXIgdG8gaGF2ZSBpdHMNCj4+PiAgICAgb3duIHRlc3Qgc2VydmljZS4g V2hlbiBhIHVzZXIgZ2V0cyBhIG5ldyBkZXZpY2UvYXBwbGljYXRpb24sIGFzIHBhcnQNCj4+PiAg ICAgb2YgdGhlIGluaXRpYWwgcmVnaXN0cmF0aW9uIG9mIHRoZWlyIGRldmljZSB3aXRoIHRoZSBw cm92aWRlciwgdGhpcw0KPj4+ICAgICB0ZXN0IHdvdWxkIGJlIHJ1bi4gVGhlbiB0aGUgcmVzdWx0 IG9mIHRoYXQgd291bGQgYmUgZ3JhbnRpbmcgb2YNCj4+PiAgICAgY3JlZGVudGlhbHMgZm9yIHRo YXQgZGV2aWNlIHRvIGFjY2VzcyB0aGF0IHByb3ZpZGVyJ3Mgc3lzdGVtLg0KPj4+ICAgICAgPj4N Cj4+PiAgICAgID4+ICAgICBUaGFua3MsDQo+Pj4gICAgICA+PiAgICAgUGF1bA0KPj4+ICAgICAg Pj4NCj4+PiAgICAgID4+PiBUaGFuayB5b3UuDQo+Pj4gICAgICA+Pj4gRXVnZW5lDQo+Pj4gICAg ICA+Pj4gKkNPTkZJREVOVElBTElUWSBOT1RJQ0UuKlRoaXMgZS1tYWlsIHRyYW5zbWlzc2lvbiwg YW5kIGFueQ0KPj4+ICAgICBkb2N1bWVudHMsIGZpbGVzIG9yIHByZXZpb3VzIGUtbWFpbCBtZXNz YWdlcyBhdHRhY2hlZCB0byBpdCwgbWF5DQo+Pj4gICAgIGNvbnRhaW4gY29uZmlkZW50aWFsIGFu ZCBwcm9wcmlldGFyeSBpbmZvcm1hdGlvbi4gSWYgeW91IGFyZSBub3QgdGhlDQo+Pj4gICAgIGlu dGVuZGVkIHJlY2lwaWVudCwgb3IgYSBwZXJzb24gcmVzcG9uc2libGUgZm9yIGRlbGl2ZXJpbmcg aXQgdG8gdGhlDQo+Pj4gICAgIGludGVuZGVkIHJlY2lwaWVudCwgeW91IGFyZSBoZXJlYnkgbm90 aWZpZWQgdGhhdCBhbnkgZGlzY2xvc3VyZSwNCj4+PiAgICAgY29weWluZywgZGlzdHJpYnV0aW9u IG9yIHVzZSBvZiBhbnkgb2YgdGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbg0KPj4+ICAgICBv ciBhdHRhY2hlZCB0byB0aGlzIG1lc3NhZ2UgaXMgU1RSSUNUTFkgUFJPSElCSVRFRC4gSWYgeW91 IGhhdmUNCj4+PiAgICAgcmVjZWl2ZWQgdGhpcyB0cmFuc21pc3Npb24gaW4gZXJyb3IsIHBsZWFz ZSBpbW1lZGlhdGVseSBub3RpZnkgbWUgYnkNCj4+PiAgICAgcmVwbHkgZS1tYWlsIGF0IGVjaHJp c3RlbnNlbkBzb3JlbnNvbi5jb20NCj4+PiAgICAgPG1haWx0bzplY2hyaXN0ZW5zZW5Ac29yZW5z b24uY29tPiA8bWFpbHRvOmVjaHJpc3RlbnNlbkBzb3JlbnNvbi5jb20NCj4+PiAgICAgPG1haWx0 bzplY2hyaXN0ZW5zZW5Ac29yZW5zb24uY29tPj5vciBieSB0ZWxlcGhvbmUgYXQgKzEgKDgwMSkN Cj4+PiAgICAgMjg3LTk0MTksIGFuZCBkZXN0cm95IHRoZSBvcmlnaW5hbCB0cmFuc21pc3Npb24g YW5kIGl0cyBhdHRhY2htZW50cw0KPj4+ICAgICB3aXRob3V0IHJlYWRpbmcgdGhlbSBvciBzYXZp bmcgdGhlbSB0byBkaXNrLg0KPj4+ICAgICAgPj4+ICpGcm9tOiogQnJpYW4gUm9zZW4gPGJyQGJy aWFucm9zZW4ubmV0IDxtYWlsdG86YnJAYnJpYW5yb3Nlbi5uZXQ+Pg0KPj4+ICAgICAgPj4+ICpT ZW50OiogV2VkbmVzZGF5LCBTZXB0ZW1iZXIgMzAsIDIwMjAgNTo0NyBQTQ0KPj4+ICAgICAgPj4+ ICpUbzoqIEV1Z2VuZSBDaHJpc3RlbnNlbiA8ZWNocmlzdGVuc2VuQHNvcmVuc29uLmNvbQ0KPj4+ ICAgICA8bWFpbHRvOmVjaHJpc3RlbnNlbkBzb3JlbnNvbi5jb20+Pg0KPj4+ICAgICAgPj4+ICpD YzoqIHJ1bUBpZXRmLm9yZyA8bWFpbHRvOnJ1bUBpZXRmLm9yZz4NCj4+PiAgICAgID4+PiAqU3Vi amVjdDoqIFJlOiBbUnVtXSBbRVhUXSBSVU0gc2VjdXJpdHkgbW9kZWwNCj4+PiAgICAgID4+PiBb RVhURVJOQUxdDQo+Pj4gICAgICA+Pj4gSSB0aGluayB3ZSB1bmRlcnN0YW5kIHdoeSB5b3Ugd2Fu dCBpdC4gV2hhdCB3ZSBkb27igJl0IHVuZGVyc3RhbmQNCj4+PiAgICAgaXMgd2hhdCBtZWNoYW5p c20gd291bGQgcHJvdmlkZSBpdC4gSSBhbSBnZW5lcmFsbHkgYXdhcmUgb2YgdGhpcw0KPj4+ICAg ICBjbGFzcyBvZiBwcm9ibGVtIGFuZCBJ4oCZbSBub3QgYXdhcmUgb2YgYSBzb2x1dGlvbiB0aGF0 IHdpbGwgd29yay4gIFNvDQo+Pj4gICAgIHdoYXQgd2UgbmVlZCBpcyBhIHN1Z2dlc3RlZCBtZWNo YW5pc20gdGhhdCBwcm92aWRlcyB0aGUgYXNzdXJhbmNlDQo+Pj4gICAgIHlvdSB3YW50IHRoYXQg aXMgdGVjaG5pY2FsbHkgc291bmQuDQo+Pj4gICAgICA+Pj4gQnJpYW4NCj4+PiAgICAgID4+PiBP biBXZWQsIFNlcCAzMCwgMjAyMCBhdCA2OjMwIFBNIEV1Z2VuZSBDaHJpc3RlbnNlbg0KPj4+ICAg ICA8ZWNocmlzdGVuc2VuQHNvcmVuc29uLmNvbSA8bWFpbHRvOmVjaHJpc3RlbnNlbkBzb3JlbnNv bi5jb20+DQo+Pj4gICAgIDxtYWlsdG86ZWNocmlzdGVuc2VuQHNvcmVuc29uLmNvbQ0KPj4+ICAg ICA8bWFpbHRvOmVjaHJpc3RlbnNlbkBzb3JlbnNvbi5jb20+Pj4gd3JvdGU6DQo+Pj4gICAgICA+ Pj4gICAgIFRoYW5rcyBmb3IgY29uc2lkZXJpbmcgaG93IHdlIG1pZ2h0IGltcGxlbWVudCB0aGlz IHNlY3VyaXR5DQo+Pj4gICAgICA+Pj4gICAgIG1lY2hhbmlzbS4gIE1heSBJIGFkZCBteSB2b2lj ZSB0aGF0IGl0IGlzIGVzc2VudGlhbCB0aGF0IHdlDQo+Pj4gICAgIGZpbmQgYW4NCj4+PiAgICAg ID4+PiAgICAgb3B0aW9uIGZvciBwcm92aWRpbmcgdGhpcyBkZXNpcmVkIHNlY3VyaXR5LCB3aGF0 ZXZlciBpdCBpcy4gIEl0DQo+Pj4gICAgICA+Pj4gICAgIGNvdWxkIGJlIGRldHJpbWVudGFsIHRv IHRoZSBWUlMgcHJvdmlkZXJzIHRvIGhhdmUgVUFzIG91dA0KPj4+ICAgICB0aGVyZSwNCj4+PiAg ICAgID4+PiAgICAgd2l0aCB0aGUgYWJpbGl0eSB0byByZWdpc3RlciB3aXRoIFZSUyBwcm92aWRl cnMgd2l0aG91dA0KPj4+ICAgICBmaXJzdCBiZWluZw0KPj4+ICAgICAgPj4+ICAgICBmdWxseSB2 ZXR0ZWQuICBJdCBpcyBvdXIgcHJhY3RpY2UgYW55dGltZSB3ZSBtYWtlIHVwZGF0ZXMNCj4+PiAg ICAgdG8gb3VyIFVBcw0KPj4+ICAgICAgPj4+ICAgICB0byB0ZXN0IGhvdyB0aGV5IHdvcmsgd2l0 aCBvdXIgVUFTIGJlZm9yZSB3ZSBldmVyIHJlbGVhc2UNCj4+PiAgICAgdGhlIG5ldyBVQQ0KPj4+ ICAgICAgPj4+ICAgICBzb2Z0d2FyZSBpbnRvIG91ciBwcm9kdWN0aW9uIGVudmlyb25tZW50LiAg V2Ugb25seSB3YW50IFVBcw0KPj4+ICAgICAgPj4+ICAgICByZWdpc3RlcmluZyB0aGF0IGhhdmUg dW5kZXJnb25lIHRoaXMgcmlnb3JvdXMgdGVzdGluZyB3aXRoIG91cg0KPj4+ICAgICAgPj4+ICAg ICBzeXN0ZW1zIGFuZCB0aGVuIG9ubHkgd2l0aCB1c2VycyB3aGljaCB3ZSBoYXZlIGF3YXJlbmVz cyBvZi4NCj4+PiAgICAgID4+PiAgICAgVGhhbmtzLA0KPj4+ICAgICAgPj4+ICAgICBFdWdlbmUg Q2hyaXN0ZW5zZW4NCj4+PiAgICAgID4+PiAgICAgQ09ORklERU5USUFMSVRZIE5PVElDRS4gVGhp cyBlLW1haWwgdHJhbnNtaXNzaW9uLCBhbmQgYW55DQo+Pj4gICAgIGRvY3VtZW50cywNCj4+PiAg ICAgID4+PiAgICAgZmlsZXMgb3IgcHJldmlvdXMgZS1tYWlsIG1lc3NhZ2VzIGF0dGFjaGVkIHRv IGl0LCBtYXkgY29udGFpbg0KPj4+ICAgICAgPj4+ICAgICBjb25maWRlbnRpYWwgYW5kIHByb3By aWV0YXJ5IGluZm9ybWF0aW9uLiBJZiB5b3UgYXJlIG5vdCB0aGUNCj4+PiAgICAgID4+PiAgICAg aW50ZW5kZWQgcmVjaXBpZW50LCBvciBhIHBlcnNvbiByZXNwb25zaWJsZSBmb3IgZGVsaXZlcmlu Zw0KPj4+ICAgICBpdCB0byB0aGUNCj4+PiAgICAgID4+PiAgICAgaW50ZW5kZWQgcmVjaXBpZW50 LCB5b3UgYXJlIGhlcmVieSBub3RpZmllZCB0aGF0IGFueQ0KPj4+ICAgICBkaXNjbG9zdXJlLA0K Pj4+ICAgICAgPj4+ICAgICBjb3B5aW5nLCBkaXN0cmlidXRpb24gb3IgdXNlIG9mIGFueSBvZiB0 aGUgaW5mb3JtYXRpb24NCj4+PiAgICAgY29udGFpbmVkIGluDQo+Pj4gICAgICA+Pj4gICAgIG9y IGF0dGFjaGVkIHRvIHRoaXMgbWVzc2FnZSBpcyBTVFJJQ1RMWSBQUk9ISUJJVEVELiBJZiB5b3Ug aGF2ZQ0KPj4+ICAgICAgPj4+ICAgICByZWNlaXZlZCB0aGlzIHRyYW5zbWlzc2lvbiBpbiBlcnJv ciwgcGxlYXNlIGltbWVkaWF0ZWx5DQo+Pj4gICAgIG5vdGlmeSBtZSBieQ0KPj4+ICAgICAgPj4+ ICAgICByZXBseSBlLW1haWwgYXQgZWNocmlzdGVuc2VuQHNvcmVuc29uLmNvbQ0KPj4+ICAgICA8 bWFpbHRvOmVjaHJpc3RlbnNlbkBzb3JlbnNvbi5jb20+DQo+Pj4gICAgICA+Pj4gICAgIDxtYWls dG86ZWNocmlzdGVuc2VuQHNvcmVuc29uLmNvbQ0KPj4+ICAgICA8bWFpbHRvOmVjaHJpc3RlbnNl bkBzb3JlbnNvbi5jb20+PiBvciBieSB0ZWxlcGhvbmUgYXQgKzEgKDgwMSkNCj4+PiAgICAgID4+ PiAgICAgMjg3LTk0MTksIGFuZCBkZXN0cm95IHRoZSBvcmlnaW5hbCB0cmFuc21pc3Npb24gYW5k IGl0cw0KPj4+ICAgICBhdHRhY2htZW50cw0KPj4+ICAgICAgPj4+ICAgICB3aXRob3V0IHJlYWRp bmcgdGhlbSBvciBzYXZpbmcgdGhlbSB0byBkaXNrLg0KPj4+ICAgICAgPj4+ICAgICAtLSAgICAg UnVtIG1haWxpbmcgbGlzdA0KPj4+ICAgICAgPj4+IFJ1bUBpZXRmLm9yZyA8bWFpbHRvOlJ1bUBp ZXRmLm9yZz4gPG1haWx0bzpSdW1AaWV0Zi5vcmcNCj4+PiAgICAgPG1haWx0bzpSdW1AaWV0Zi5v cmc+Pg0KPj4+ICAgICAgPj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v cnVtDQo+Pj4gICAgIDxodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J1bT4N Cj4+PiAgICAgID4+PiAgICAgPGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v cnVtDQo+Pj4gICAgIDxodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J1bT4+ DQo+Pj4gICAgICA+Pg0KPj4+ICAgICAgPj4gLS0NCj4+PiAgICAgID4+IFJ1bSBtYWlsaW5nIGxp c3QNCj4+PiAgICAgID4+IFJ1bUBpZXRmLm9yZyA8bWFpbHRvOlJ1bUBpZXRmLm9yZz4NCj4+PiAg ICAgID4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnVtDQo+Pj4gICAg IDxodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J1bT4NCj4+DQo+IA0KDQot LQ0KUnVtIG1haWxpbmcgbGlzdA0KUnVtQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL3J1bQ0K From nobody Wed Oct 21 07:40:34 2020 Return-Path: X-Original-To: rum@ietfa.amsl.com Delivered-To: rum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 206833A0957 for ; Wed, 21 Oct 2020 07:40:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.888 X-Spam-Level: X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=brianrosen-net.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 zOlDOTQJkTHj for ; Wed, 21 Oct 2020 07:40:30 -0700 (PDT) Received: from mail-qv1-xf2b.google.com (mail-qv1-xf2b.google.com [IPv6:2607:f8b0:4864:20::f2b]) (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 529AA3A1446 for ; Wed, 21 Oct 2020 07:40:13 -0700 (PDT) Received: by mail-qv1-xf2b.google.com with SMTP id g13so1240733qvu.1 for ; Wed, 21 Oct 2020 07:40:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=fvhTn1UPMs6HSbrcrQVEzHr4wdnb78qkRYhU6mCfSIc=; b=msEpSBOXuEWpigRdTCH7Bii56m24yf24OUJZnpIZpcu8CIQYZ3AWJC+hPz6aDlDSLh A3iEvLVZgvc3PkFfXZS8+EJj+DRjIYVwzEy/30VOUbr7OhRwjUMuNiumUyxF/ErhLDWa zGp9i566huCRznZowEdWxNBQBOi3mhy9IIabdabcF4jugbvVasRbtWyq16bHL/TGAKrQ PgLw8vfBC7jgF2wQ+BVeMlrfxgSc7VNyyFlnzaKlKj2iHLcPUYqjLa0xoS4BAKsNCK+m kwjvw5XkwJVaT7f+4hdqXYz5fVczUVK2OeTtVBzCEVgLG+H0IjnN9ztAN1T8YfoKP+CQ gTmw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=fvhTn1UPMs6HSbrcrQVEzHr4wdnb78qkRYhU6mCfSIc=; b=hXhp2fjd+dWG1BTtKC1FFKw2J2ys0tesnVrc2qsb7hMa0zMsUQrxSNlZRKsyglISEh BRNJVlFbWieskI2sDYWdxEpxv5+iV3sPvXqLF+nIy37XL7T/cEQm9z1eaLRLsBbcI7zB +9n3MsxBQJiWgLDMnH6DN63a+YY1lmwWmu7eiOreGR4vyaDSXj3CqNiYiRgslChNFDmA m0h6SR5R0IfxULEY1XEx2rsKme+U/+k0JPeGKAy+SRT9OjoXdp+d1XL0VYRdPFl/FEHR 5jqNne9aeykEH24Cb6SeRjhi5J5aWdaybobL31tXQFauRn1cEd65K5I7dxazdj6rMHy8 nxCg== X-Gm-Message-State: AOAM532DaUx8M/kQMpNBdVxywfPvGthkxiF1OnBVXTmJ8wOhuqFlQVdP WY9PETS3aaiy93A+tbElyIyduQ== X-Google-Smtp-Source: ABdhPJyni+o0l9v/7i8dQt22BXDBxH5up6kFzHZO8rhlQndvy+Euh5wWfvQBY8Nocc4HBSHYdwrUpQ== X-Received: by 2002:a0c:fac6:: with SMTP id p6mr3186255qvo.5.1603291212213; Wed, 21 Oct 2020 07:40:12 -0700 (PDT) Received: from brians-mbp-2871.lan (dynamic-acs-24-154-119-158.zoominternet.net. [24.154.119.158]) by smtp.gmail.com with ESMTPSA id v204sm1437480qka.4.2020.10.21.07.40.11 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 21 Oct 2020 07:40:11 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) From: Brian Rosen In-Reply-To: Date: Wed, 21 Oct 2020 10:40:10 -0400 Cc: Paul Kyzivat , "rum@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <38090A50-6572-4A8E-97D4-C260323365AE@brianrosen.net> References: <4d6ba97f-a83d-3d36-14a9-c6e84dd5b874@alum.mit.edu> <7A11F680-9EA6-4477-9BD8-6A7755AD0054@brianrosen.net> <7fdb95e6-e954-7275-60f7-462cf07eff0e@alum.mit.edu> <92b5d34b-2fbf-0e2b-8562-8f7d11c5123b@alum.mit.edu> <5e6d8446-c267-5113-aff1-fc87576b1317@alum.mit.edu> To: Eugene Christensen X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [Rum] [EXT] RUM security model X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2020 14:40:33 -0000 If a magic number (often this is called an =E2=80=9CAPI Key=E2=80=9D) is = good enough, I can write text for it. The client code would have a = version and the key sent to the server in Registration. The server can = verify the code was one it issued, for that version. The code would be = per-provider. Brute force and DDoS attacks can=E2=80=99t be addressed by this document = except in the Security Consideration section. They are implementation = issues. =20 Brian > On Oct 21, 2020, at 9:32 AM, Eugene Christensen = wrote: >=20 > Brian, >=20 > You mentioned the use of a magic number. Is that the same as the use = of an authorization key that is built into the product with the = respective provider's key(s)? If so I believe that could possibly work. = If I understand that correctly, the provider's would give a key to the = developer that would be unique to that application and version. When = that application attempts to connect to a provider, the provider will = know what company's app and version it is and be able to accept the = connection once it has been verified in the lab. If it goes rogue = thereafter, as I understand it, the providers could revoke that access. >=20 > Regarding some concerns with an open API, here are three that should = be captured: > - Brute force attacks - A bad actor could use an API to determine a = user's password. > - Untested clients - A problem caused unintentionally by an endpoint = developer with good intentions.=20 > - DDOS attacks - A bad actor could try to bring a system down by = sending multiple requests from different IP addresses making it = difficult to block. >=20 >=20 > Thanks, > Eugene. >=20 > CONFIDENTIALITY NOTICE. This e-mail transmission, and any documents, = files or previous e-mail messages attached to it, may contain = confidential and proprietary information. If you are not the intended = recipient, or a person responsible for delivering it to the intended = recipient, you are hereby notified that any disclosure, copying, = distribution or use of any of the information contained in or attached = to this message is STRICTLY PROHIBITED. If you have received this = transmission in error, please immediately notify me by reply e-mail at = echristensen@sorenson.com or by telephone at +1 (801) 287-9419, and = destroy the original transmission and its attachments without reading = them or saving them to disk. >=20 > -----Original Message----- > From: Rum On Behalf Of Paul Kyzivat > Sent: Tuesday, October 20, 2020 9:34 AM > To: Brian Rosen > Cc: rum@ietf.org > Subject: Re: [Rum] [EXT] RUM security model >=20 > [EXTERNAL]=20 >=20 > I think this discussion highlights the need to first nail down the = threat model that the providers want to protect against. >=20 > James: can you take a crack at that? Possibly pull in some of the = other providers if you think they will be willing. >=20 > (I wonder if providers currently have any sort of robust protection = against malicious impersonation of their devices? I'm guessing it is = only security by obscurity.) >=20 > Thanks, > Paul >=20 > On 10/20/20 10:10 AM, Brian Rosen wrote: >> Yes, both apps, one app steals the credential from the other (same = machine, same user). >>=20 >> I also don=E2=80=99t think a downloaded test would be particularly = helpful unless we built in a bunch of mechanism that allowed automation = of testing. >>=20 >> And then, what would stop an app from playing nice with a test, and = then nasty when it wanted to? >>=20 >> Both of these exploits do assume that the app developer intends to = flaunt approval in some way. If that=E2=80=99s not a threat that is = important to guard against then a simple magic number for an app is = enough. An app gets tested by a provider, and is given a magic number = that it provides, securely, in some way. As long as the providers trust = the app developer to not misuse the magic number, it=E2=80=99s an = indication that the app (at a particular version presumably) was = trusted. >>=20 >> As long as malicious actors can be ignored, I think we could do = something. I don=E2=80=99t think that is worth much, but if it is, I = can write text. >>=20 >> If you want to protect against malicious actors, then I don=E2=80=99t = know how. TPM won=E2=80=99t work - doesn=E2=80=99t work in Android/iOS. = It=E2=80=99s mostly a PC thing. Even with TPM, what you need is = something like a digest of the code. You can=E2=80=99t get that. >>=20 >> Brian >>=20 >>=20 >>> On Oct 16, 2020, at 11:17 AM, Paul Kyzivat = wrote: >>>=20 >>> On 10/15/20 8:24 PM, Brian Rosen wrote: >>>> Nope, it just takes a hacker to create a piece of code that patches = an app to look like another app. >>>=20 >>> I don't follow. >>>=20 >>> A user gets a device capable of passing the tests. He requests to = enroll it with is provider as one of his devices. As part of that, a = test is run between the device and the provider's enrollment server. = Then the provider gives the device some sort of cert that can be used = when registering. >>>=20 >>> Next, the user decides to try out some other rogue device on his = account. Normally he would repeat the above, and the device would fail = the test. Instead, he might cause the rogue device to steal the cert = from the device that passed. I think he can't help but know he is doing = something illicit. >>>=20 >>> I guess if these were both just apps, then a remote attack on the = device could install a rogue app that impersonates the valid one and = steals its credentials. Is that what you had in mind? >>>=20 >>> Perhaps we need to spend some time with the providers enumerating = the attacks they are concerned with. >>>=20 >>> Thanks, >>> Paul >>>=20 >>>> On Thu, Oct 15, 2020 at 8:19 PM Paul Kyzivat > wrote: >>>> On 10/15/20 7:52 PM, Brian Rosen wrote: >>>>> I don=E2=80=99t think even that would work because there isn=E2=80=99= t any way to >>>> know that the app that was approved is the app that is being = used. >>>> Yes, I guess you are right. But at least it would require the = end user >>>> to enter into a conspiracy with the app developers, and be able = to get >>>> the credential out of one app and into another. >>>> Thanks, >>>> Paul >>>>> What systems like iOS does is rely on the fact that you can=E2=80=99= t >>>> download and run an app that hasn=E2=80=99t been vetted. The = code is signed >>>> and the signature is checked every time the app starts. We = don=E2=80=99t >>>> have an environment like that. We can=E2=80=99t control what is = downloaded >>>> and we can=E2=80=99t check signatures. >>>>> I don=E2=80=99t think there is a reliable way to do this. If = someone has >>>> an idea, please explain it, but we can=E2=80=99t be in a =E2=80=9C= you do something=E2=80=9D >>>> position without a clue as to how. >>>>>=20 >>>>> Now, if the app was an iOS app, then the right thing happens. >>>> There are few other systems that are wired down like that. = Android, >>>> for example, allows you to download and run from arbitrary sites = if >>>> the device is configured to allow that. >>>>>=20 >>>>> Brian >>>>>=20 >>>>>=20 >>>>>> On Oct 15, 2020, at 6:30 PM, Paul Kyzivat >>> > wrote: >>>>>>=20 >>>>>> =EF=BB=BFEugene, >>>>>>=20 >>>>>>> On 10/15/20 3:30 PM, Eugene Christensen wrote: >>>>>>> Brian, >>>>>>> Admittedly I do not fully understand certificates and >>>> authentication but would client certificates or mutual >>>> authentication with a shared secret work here? >>>>>>=20 >>>>>> I'm also not a security expert. To my understanding, the key >>>> problem is that you want a proof that an implementation has = passed >>>> some sort of test. That is more or less equivalent to having a >>>> special certification authority that is able to assign a = certificate >>>> based on the passing of a test. But for the system to work that >>>> certificate needs to be bound to the entity (hw/sw) that passed = the >>>> test. It can't be possible to transfer that certificate to a >>>> different device. >>>>>>=20 >>>>>> A possible alternative would be for each provider to have its >>>> own test service. When a user gets a new device/application, as = part >>>> of the initial registration of their device with the provider, = this >>>> test would be run. Then the result of that would be granting of >>>> credentials for that device to access that provider's system. >>>>>>=20 >>>>>> Thanks, >>>>>> Paul >>>>>>=20 >>>>>>> Thank you. >>>>>>> Eugene >>>>>>> *CONFIDENTIALITY NOTICE.*This e-mail transmission, and any >>>> documents, files or previous e-mail messages attached to it, may >>>> contain confidential and proprietary information. If you are not = the >>>> intended recipient, or a person responsible for delivering it to = the >>>> intended recipient, you are hereby notified that any disclosure, >>>> copying, distribution or use of any of the information contained = in >>>> or attached to this message is STRICTLY PROHIBITED. If you have >>>> received this transmission in error, please immediately notify = me by >>>> reply e-mail at echristensen@sorenson.com >>>> = >>> >or by telephone at +1 (801) >>>> 287-9419, and destroy the original transmission and its = attachments >>>> without reading them or saving them to disk. >>>>>>> *From:* Brian Rosen > >>>>>>> *Sent:* Wednesday, September 30, 2020 5:47 PM >>>>>>> *To:* Eugene Christensen >>> > >>>>>>> *Cc:* rum@ietf.org >>>>>>> *Subject:* Re: [Rum] [EXT] RUM security model >>>>>>> [EXTERNAL] >>>>>>> I think we understand why you want it. What we don=E2=80=99t = understand >>>> is what mechanism would provide it. I am generally aware of this >>>> class of problem and I=E2=80=99m not aware of a solution that = will work. So >>>> what we need is a suggested mechanism that provides the = assurance >>>> you want that is technically sound. >>>>>>> Brian >>>>>>> On Wed, Sep 30, 2020 at 6:30 PM Eugene Christensen >>>> >>>> >>> >> wrote: >>>>>>> Thanks for considering how we might implement this security >>>>>>> mechanism. May I add my voice that it is essential that we >>>> find an >>>>>>> option for providing this desired security, whatever it is. = It >>>>>>> could be detrimental to the VRS providers to have UAs out >>>> there, >>>>>>> with the ability to register with VRS providers without >>>> first being >>>>>>> fully vetted. It is our practice anytime we make updates >>>> to our UAs >>>>>>> to test how they work with our UAS before we ever release >>>> the new UA >>>>>>> software into our production environment. We only want UAs >>>>>>> registering that have undergone this rigorous testing with = our >>>>>>> systems and then only with users which we have awareness of. >>>>>>> Thanks, >>>>>>> Eugene Christensen >>>>>>> CONFIDENTIALITY NOTICE. This e-mail transmission, and any >>>> documents, >>>>>>> files or previous e-mail messages attached to it, may contain >>>>>>> confidential and proprietary information. If you are not the >>>>>>> intended recipient, or a person responsible for delivering >>>> it to the >>>>>>> intended recipient, you are hereby notified that any >>>> disclosure, >>>>>>> copying, distribution or use of any of the information >>>> contained in >>>>>>> or attached to this message is STRICTLY PROHIBITED. If you = have >>>>>>> received this transmission in error, please immediately >>>> notify me by >>>>>>> reply e-mail at echristensen@sorenson.com >>>> >>>>>>> >>> > or by telephone at +1 (801) >>>>>>> 287-9419, and destroy the original transmission and its >>>> attachments >>>>>>> without reading them or saving them to disk. >>>>>>> -- Rum mailing list >>>>>>> Rum@ietf.org >>> > >>>>>>> https://www.ietf.org/mailman/listinfo/rum >>>> >>>>>>> >>> > >>>>>>=20 >>>>>> -- >>>>>> Rum mailing list >>>>>> Rum@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/rum >>>> >>>=20 >>=20 >=20 > -- > Rum mailing list > Rum@ietf.org > https://www.ietf.org/mailman/listinfo/rum From nobody Wed Oct 21 07:51:11 2020 Return-Path: X-Original-To: rum@ietfa.amsl.com Delivered-To: rum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BBF43A12DD for ; Wed, 21 Oct 2020 07:51:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=brianrosen-net.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 gZVt6m_maURc for ; Wed, 21 Oct 2020 07:51:00 -0700 (PDT) Received: from mail-qt1-x82e.google.com (mail-qt1-x82e.google.com [IPv6:2607:f8b0:4864:20::82e]) (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 A01FD3A124E for ; Wed, 21 Oct 2020 07:51:00 -0700 (PDT) Received: by mail-qt1-x82e.google.com with SMTP id r8so2248478qtp.13 for ; Wed, 21 Oct 2020 07:51:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=FrxqmXx73vL+081sHVyM6/EGDEexYAhW9RQc7Z0TR9Q=; b=jcD8152SrnCjN5jShpaClYZCaV9AGTAcBaq8COZy4JYRHrhYDsPPIco2clsxtpgHLr pB0OFKsy8+HwkQcrtR7TlifDvKTsQmR88y3t+6trH6AUdRSJGpfUZLMMnTtka7dW1yNl IrOitx8HMXaa7rNqCt/9wFVQEPHtpnmtXKMkq3dQkgyZmrOKjuUbtZx29m0+3wLaSgfK eczfZTHLm6CbvcvWsQpY3H2BnFJhHYJEo6+6j4+TBwbR9POnzkvBfFJqoQa1bJtKsC6c C9QHZv+ryUWxlXZ2sqoSf+RoW9F0nzolKYhAU9tA9PvBCltTzMzxlxiQUJH/1YlXyOvW J8zA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=FrxqmXx73vL+081sHVyM6/EGDEexYAhW9RQc7Z0TR9Q=; b=Hg1mlj8OaWqzdSZzAALuO/+C8/S55m+CpB0oIkBtYKazviZE4ZzaMkxwl2MLh/r0o+ N6h4cBFVLtzEYm4IyqVHrogh5U1R4RFtYMdx5u2HFILW3YDOJ3spA0/gRMuhXlJRs9Mj RYKwdSLV92C9J3lmqi0fdQDXBAZ0Ty5R+BKK3zj6pVRxXEpsQIqPoDdMAII2+HRSkqw1 9jWjMcZAPSzXEyUYNHw610CubZODdw7i4vL5Ynrj59NJndOPJfBvZGLOpOcaQbxyJuat 7dY80vMoMfH7CpR/tXGqeln8XsA438bs40XWmgNuq7ogdDAxm2DNopjNJ7YhH8538+Gv ixCw== X-Gm-Message-State: AOAM530LuWm9AkUpi9XBUXf3AMcS2sYXXVzn4VrELgKQUHq4t/wRsAXv JRi/TaTelcc7DdXEVT666FZpGRJLkdBVEZHO X-Google-Smtp-Source: ABdhPJyaaKC5Pn/PHYFRAkN8jUlpGKbo2jQv/9G2TG5fFSdmqpMdb7faxikcdxwfAzpERNsa96+vXQ== X-Received: by 2002:aed:23f1:: with SMTP id k46mr3497117qtc.377.1603291859598; Wed, 21 Oct 2020 07:50:59 -0700 (PDT) Received: from brians-mbp-2871.lan (dynamic-acs-24-154-119-158.zoominternet.net. [24.154.119.158]) by smtp.gmail.com with ESMTPSA id t1sm1438492qkh.19.2020.10.21.07.50.58 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 21 Oct 2020 07:50:59 -0700 (PDT) From: Brian Rosen Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_B365B3AA-965A-4E9B-BBB2-7DA4991E1C68" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Date: Wed, 21 Oct 2020 10:50:58 -0400 In-Reply-To: <64C1A076-27B1-49FB-B52D-A1E300FF7D0E@edvina.net> Cc: rum@ietf.org To: "Olle E. Johansson" References: <64C1A076-27B1-49FB-B52D-A1E300FF7D0E@edvina.net> X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [Rum] Configuration file X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2020 14:51:10 -0000 --Apple-Mail=_B365B3AA-965A-4E9B-BBB2-7DA4991E1C68 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 This is actually a good idea I think. The light bulb for me was =E2=80=9C= same key pair=E2=80=9D. So suppose the device generated a key pair, and used a local passcode or = pass phrase to access the private key. For each provider, the provider = issues a cert, and that cert is used for TLS client authentication. = Same key pair for each provider, different cert. It would work for any = provider to issue a cert that other providers accepted, but it would be = an easier =E2=80=9Csell=E2=80=9D, I think, if they each issued a cert to = their customer. The cert can be used with TLS to retrieve a = per-provider configuration file as well as SIP operations. Persistent = TLS could be used to avoid requiring entering credentials often at the = user end. Would that be acceptable? Brian > On Oct 21, 2020, at 1:28 AM, Olle E. Johansson wrote: >=20 >=20 >=20 >> On 20 Oct 2020, at 21:15, Brian Rosen wrote: >>=20 >> This is still an open item and distinct from the =E2=80=9Csigned = code=E2=80=9D issue we=E2=80=99ve been discussing. >>=20 >> The current text describes a single file that can have multiple sets = of provider configuration data. This caters to the common case of a = user having more than provider account. The problem with the text is it = has plaintext username/passwords, which is clearly wrong. >>=20 >> I see two solutions: require the local implementation to maintain a = password (or other multi factor authentication, and encrypt the file so = that the user needs to authenticate to access the file. Paul is worried = that the login data may be needed more frequently than is reasonable to = enter the authentication data locally. =20 >>=20 >> The other is to maintain separate files in provider systems, with a = common authentication mechanism in each provider to access the file. >>=20 >> I think Paul=E2=80=99s argument doesn=E2=80=99t really hold much = water: no SIP device I know of requires re-authentication that requires = user interaction very often, so whatever they do now is okay. I think = they just keep the data locally, secure enough to re-use when they need = to. So unlock once, good for a very long time. >>=20 >> I=E2=80=99m reluctant to require all providers use the new OAUTH2 = solution, but if they were okay with it, that would be excellent. We = would need some notion of common username, but otherwise it would just = work. Seems way too different from how things work now. Very = attractive, secure, and user-friendly. >=20 > To add to your list: Don=E2=80=99t forget about using TLS client = certs. It=E2=80=99s not very hard, can securely be provisioned using = Oauth or other means > and can be re-issued often. For the telco business it=E2=80=99s = unusal, but it=E2=80=99s frequently used in other solutions, like VPNs. >=20 > You can one per provider, based on the same key pair or separate key = pairs. >=20 > /O --Apple-Mail=_B365B3AA-965A-4E9B-BBB2-7DA4991E1C68 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 This = is actually a good idea I think.  The light bulb for me was =E2=80=9C= same key pair=E2=80=9D.

So suppose the device generated a key pair, and used a local = passcode or pass phrase to access the private key.  For each = provider, the provider issues a cert, and that cert is used for TLS = client authentication.  Same key pair for each provider, different = cert.  It would work for any provider to issue a cert that other = providers accepted, but it would be an easier =E2=80=9Csell=E2=80=9D, I = think, if they each issued a cert to their customer.  The cert can = be used with TLS to retrieve a per-provider configuration file as well = as SIP operations.  Persistent TLS could be used to avoid requiring = entering credentials often at the user end.

Would that be acceptable?

Brian

On Oct 21, 2020, at 1:28 AM, Olle E. Johansson <oej@edvina.net> = wrote:



On 20 = Oct 2020, at 21:15, Brian Rosen <br@brianrosen.net> wrote:

This is still an open item and distinct from the =E2=80=9Csigne= d code=E2=80=9D issue we=E2=80=99ve been discussing.

The current text describes a single file that can have = multiple sets of provider configuration data.  This caters to the = common case of a user having more than provider account.  The = problem with the text is it has plaintext username/passwords, which is = clearly wrong.

I see two solutions: require = the local implementation to maintain a password (or other multi factor = authentication, and encrypt the file so that the user needs to = authenticate to access the file.  Paul is worried that the login = data may be needed more frequently than is reasonable to enter the = authentication data locally.  

The = other is to maintain separate files in provider systems, with a common = authentication mechanism in each provider to access the file.

I think Paul=E2=80=99s argument doesn=E2=80=99t = really hold much water: no SIP device I know of requires = re-authentication that requires user interaction very often, so whatever = they do now is okay.  I think they just keep the data locally, = secure enough to re-use when they need to.  So unlock once, good = for a very long time.

I=E2=80=99m reluctant = to require all providers use the new OAUTH2 solution, but if they were = okay with it, that would be excellent.  We would need some notion = of common username, but otherwise it would just work.  Seems way = too different from how things work now.  Very attractive, secure, = and user-friendly.

To add to your list: Don=E2=80=99t forget about using TLS = client certs. It=E2=80=99s not very hard, can securely be provisioned = using Oauth or other means
and can be re-issued often. For the telco business it=E2=80=99s= unusal, but it=E2=80=99s frequently used in other solutions, like = VPNs.

You can one = per provider, based on the same key pair or separate key = pairs.

/O

= --Apple-Mail=_B365B3AA-965A-4E9B-BBB2-7DA4991E1C68-- From nobody Wed Oct 21 08:55:50 2020 Return-Path: X-Original-To: rum@ietfa.amsl.com Delivered-To: rum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C06D33A12EC for ; Wed, 21 Oct 2020 08:55:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, NICE_REPLY_A=-0.247, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=alum.mit.edu 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 Bnb50zDwnJp0 for ; Wed, 21 Oct 2020 08:55:41 -0700 (PDT) Received: from NAM11-BN8-obe.outbound.protection.outlook.com (mail-bn8nam11on2059.outbound.protection.outlook.com [40.107.236.59]) (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 E7C793A136F for ; Wed, 21 Oct 2020 08:55:39 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=c8TuSdWj+1pLOwgpZGxAZOT6hhqsVbPY3b05Vb4VgOROgeuyal52hj5I3VlhSwkOWH1v4Lzoh/e+7HOO2D4TuKtjEGmpHbKazXSh4pnn61mVyy1PTJYmc+iMXsWycfMiGrwd1dZDuV9UtU5GfpjT5AJvnmZ0rjdX84Rozr83CS0YysgluPLgJ3ZcFBGPx48eSc9jSF88G7FpNz2DBNIQS6RNmKe2LN29IQrAFFJJH1/NTb8JxGG0vC3TpbB0QhAduH/JdRnLWmKk5+QsKhbH9az47e9XtMsxs6kYP+nNXg4PIIegDYT8+6x3Vtcbyyg5lWuMfUrIU9dUfICzw5rb3A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ps8rM6h0/iuW3KLf98fawNY+Q3YkurhPM8qrHYGgxc8=; b=E5+ZrA3tc5Bir2gcl0RW/KaHjJUZ2Da3lk7bhiQwQB1R74LIyJtr+sX+eo5zVfG9uTVn+kD2EMMfkyaxVkd1I+IsF/Sk7N7WXdh9fUnzoZp5whk3g8MVe4Y2gFK3B4nwPuuWQKVZA/zICPG1uUtYiQFfTpMQbLcry4ak2sfl9lRbHDf7/mejCp8fhqLG40qYoDxbCFX88U0x9kGfputvSwhL6Nyon4pCVSel7aGEtURr/KKrR6ol8uXg4AG7bMzZzhLJrFf5MH7OSGvsOzJm/9mbumui0I1sgrv2gpBilpmsAiN4dI2W3ypYLa46JcF01d901vnSExiO1dTlv4ckeQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 18.7.68.33) smtp.rcpttodomain=ietf.org smtp.mailfrom=alum.mit.edu; dmarc=bestguesspass action=none header.from=alum.mit.edu; dkim=none (message not signed); arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alum.mit.edu; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ps8rM6h0/iuW3KLf98fawNY+Q3YkurhPM8qrHYGgxc8=; b=grcuvo2ig/jTv3P7bwraFMi7E9lThVFoSYcd2/A3JiwTDn2xe996Q5mxSdVaMfiBn8I0DCZgY4i9CYcpCl/l6vqNee3rbRpTE9MJEnT5UbYhNAFAaihZD5tp1d11a+bbBiRmj31wLo2GUKoJ1xBuWUBN1cPuocWK4D6Y3aAuEPY= Received: from SN1PR12CA0060.namprd12.prod.outlook.com (2603:10b6:802:20::31) by CY4PR1201MB2500.namprd12.prod.outlook.com (2603:10b6:903:d0::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3477.21; Wed, 21 Oct 2020 15:55:37 +0000 Received: from SN1NAM02FT024.eop-nam02.prod.protection.outlook.com (2603:10b6:802:20:cafe::4d) by SN1PR12CA0060.outlook.office365.com (2603:10b6:802:20::31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3499.18 via Frontend Transport; Wed, 21 Oct 2020 15:55:37 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 18.7.68.33) smtp.mailfrom=alum.mit.edu; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=alum.mit.edu; Received-SPF: Pass (protection.outlook.com: domain of alum.mit.edu designates 18.7.68.33 as permitted sender) receiver=protection.outlook.com; client-ip=18.7.68.33; helo=outgoing-alum.mit.edu; Received: from outgoing-alum.mit.edu (18.7.68.33) by SN1NAM02FT024.mail.protection.outlook.com (10.152.72.127) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3477.21 via Frontend Transport; Wed, 21 Oct 2020 15:55:37 +0000 Received: from PaulKyzivatsMBP.localdomain (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.14.7/8.12.4) with ESMTP id 09LFtZ3j000509 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT) for ; Wed, 21 Oct 2020 11:55:35 -0400 To: rum@ietf.org References: From: Paul Kyzivat Message-ID: Date: Wed, 21 Oct 2020 11:55:34 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:78.0) Gecko/20100101 Thunderbird/78.3.3 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 625d6e20-19c3-4cd4-245b-08d875d9c092 X-MS-TrafficTypeDiagnostic: CY4PR1201MB2500: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: XjSvYcXH3bzclzCRJuGUaFuwnKfzuxgxtkLryMrzOSrnyxtlPb0zLKfrKFVUA6OyRLHiCoKglY7MwvajYr4JBwfSF5G1eeO22Ho3RpxMeqd5O4hp57fPe56EIxhHGmJULV6g1TSCtNCrP8hQa3iGGlefAycEXNbV/8zmy5AuHYZkufQhjCf+qdVvbZoU2hjuBMAjCnXrrRYWCOXYXjKkJjYK79y3RhcQ9KoOsZQw/LMb5q8nZfCGtluodZTNGzygqli15h12JtbDOOF1rfbIH8FJG4oj2MT/Vgx+W2W9Ap8QAwtsaBD00M9P4dyx7FHswpfrKdTOhh/K2niFYKITsdslCcl70tHX5wH9NC9f7ezwRS/7TSOgr0I0ICZa/Z6KrRYNU8VhRcj2HnLnVkH+s+lEbGC70zbbLE5t8Hp2qYm+l5/YCKLY+Mzo6y8RriCL X-Forefront-Antispam-Report: CIP:18.7.68.33; CTRY:US; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:outgoing-alum.mit.edu; PTR:outgoing-alum.mit.edu; CAT:NONE; SFS:(346002)(376002)(396003)(39860400002)(136003)(46966005)(336012)(86362001)(356005)(83380400001)(8936002)(2616005)(75432002)(956004)(8676002)(53546011)(26005)(70206006)(36906005)(70586007)(31686004)(82740400003)(6916009)(31696002)(7596003)(186003)(2906002)(5660300002)(786003)(316002)(478600001)(82310400003)(47076004)(43740500002); DIR:OUT; SFP:1101; X-OriginatorOrg: alum.mit.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Oct 2020 15:55:37.0292 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 625d6e20-19c3-4cd4-245b-08d875d9c092 X-MS-Exchange-CrossTenant-Id: 3326b102-c043-408b-a990-b89e477d582f X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3326b102-c043-408b-a990-b89e477d582f; Ip=[18.7.68.33]; Helo=[outgoing-alum.mit.edu] X-MS-Exchange-CrossTenant-AuthSource: SN1NAM02FT024.eop-nam02.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR1201MB2500 Archived-At: Subject: Re: [Rum] Configuration file X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2020 15:55:49 -0000 On 10/20/20 3:15 PM, Brian Rosen wrote: > This is still an open item and distinct from the “signed code” issue we’ve been discussing. > > The current text describes a single file that can have multiple sets of provider configuration data. This caters to the common case of a user having more than provider account. The problem with the text is it has plaintext username/passwords, which is clearly wrong. > > I see two solutions: require the local implementation to maintain a password (or other multi factor authentication, and encrypt the file so that the user needs to authenticate to access the file. Paul is worried that the login data may be needed more frequently than is reasonable to enter the authentication data locally. > > The other is to maintain separate files in provider systems, with a common authentication mechanism in each provider to access the file. > > I think Paul’s argument doesn’t really hold much water: no SIP device I know of requires re-authentication that requires user interaction very often, so whatever they do now is okay. I think they just keep the data locally, secure enough to re-use when they need to. So unlock once, good for a very long time. > > I’m reluctant to require all providers use the new OAUTH2 solution, but if they were okay with it, that would be excellent. We would need some notion of common username, but otherwise it would just work. Seems way too different from how things work now. Very attractive, secure, and user-friendly. My concern was with one configuration file vs. a separate one for each provider. This is rooted in how the file would be provisioned in the device. My assumption is that this configuration is generated by the provider based on the user doing a web-based enrollment on the provider's web site, followed by the device downloading that configuration. If the user has accounts with different providers then this would happen separately for each, resulting is separate configuration files. Do you have a different model in mind for how this would happen? Thanks, Paul From nobody Wed Oct 21 09:04:20 2020 Return-Path: X-Original-To: rum@ietfa.amsl.com Delivered-To: rum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE5B73A128A for ; Wed, 21 Oct 2020 09:04:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=brianrosen-net.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 zLTuT-BiJBae for ; Wed, 21 Oct 2020 09:04:16 -0700 (PDT) Received: from mail-qv1-xf36.google.com (mail-qv1-xf36.google.com [IPv6:2607:f8b0:4864:20::f36]) (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 882933A10AA for ; Wed, 21 Oct 2020 09:04:16 -0700 (PDT) Received: by mail-qv1-xf36.google.com with SMTP id s17so1351838qvr.11 for ; Wed, 21 Oct 2020 09:04:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=VgH7oWnUyy38aL3duMUteywmvs6B/S8SDqogBjdTZmQ=; b=zN+V0T5CRoKVQH4SjtdBXidc7TTmiu8IpTqH5D5ELf0pVP2sbdx9rvXo/OUZdQ6ZF8 upSIgHBHIMLN5VVg58yDEc5L+ekdMJEzqQHtyM8GuiWMOfn972cfJljL1qcjN7SyoiJV sxLe/tq2qDEscT6jF7bdpU9n9d5Dg9KPeltvWEQdgsZWKPA6XTadjCIyKT6aPCa2L/Mo 2IwPvAh2awNmEKyBjbu0QJkiSm1xq/pOJU4xOuIWQafxRAjwCnT8DciYwG1bWQVFE85H F7wou9cCnp4g9vs5Vroqc+aYLLq4VcwkGC0tx7NrQideyNIgvrYE+MCyj6bzHTEE60HO +5Ng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=VgH7oWnUyy38aL3duMUteywmvs6B/S8SDqogBjdTZmQ=; b=rdZMm1kHYr/lwQqj1CPPW6qlDKjuowKiP1oCkHX2XQxW7gGTaWEvUb+LdPBFai7EK/ lZ0owmczmSG2+35jPuWdKqpH9Fw5j1QlqyhSOsdmSdU7/YI70UwsGFWEMGD9fkdyJupj qH+7Tq3hvGJ/cmQ6OmMDCjsrvaRG9XTmZObEZ63yUELJ0L1rMSPWW2Tg13nqTCD2hhi3 gjxA80oj5l5dtNaaO5GU/euL/mtruy0Xn68wDLK3biXZCm3RbOn/k85SAc93AEAVLV9Y SmPGYVXa4bqe7seyBXi3o1BT2Gp72iBHrWuktWu5AqIWfdY4OlW00YfQuyDIZ5gbyGG3 cShA== X-Gm-Message-State: AOAM531WxPxLL8b9KPkFfa5O5FfLDDYZTYptWQIaT1NDqgUe+T/i5BLQ c4vg3zozYg7Zn5DXFVPnrw50FA== X-Google-Smtp-Source: ABdhPJw0VpR4sYQ+/HHcGGh6mViHgS1eDgjsECsI4oKDboQWW3J5Jpak9TOk1GCbSnNEkruP+03ijA== X-Received: by 2002:a05:6214:180f:: with SMTP id o15mr2752775qvw.16.1603296255397; Wed, 21 Oct 2020 09:04:15 -0700 (PDT) Received: from brians-mbp-2871.lan (dynamic-acs-24-154-119-158.zoominternet.net. [24.154.119.158]) by smtp.gmail.com with ESMTPSA id g15sm1500776qki.107.2020.10.21.09.04.14 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 21 Oct 2020 09:04:14 -0700 (PDT) From: Brian Rosen Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_22627886-4CAC-443D-BE61-F863B93E5923" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Date: Wed, 21 Oct 2020 12:04:13 -0400 In-Reply-To: Cc: rum@ietf.org To: Paul Kyzivat References: X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [Rum] Configuration file X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2020 16:04:19 -0000 --Apple-Mail=_22627886-4CAC-443D-BE61-F863B93E5923 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Yeah, my model was different. It assumed that whatever was done by the = provider, the result was a single local file. I=E2=80=99m not wedded to that. We do need at least a piece of that to = know which providers to look for, but a file per provider, downloaded = when it=E2=80=99s needed is okay. Brian > On Oct 21, 2020, at 11:55 AM, Paul Kyzivat = wrote: >=20 > On 10/20/20 3:15 PM, Brian Rosen wrote: >> This is still an open item and distinct from the =E2=80=9Csigned = code=E2=80=9D issue we=E2=80=99ve been discussing. >> The current text describes a single file that can have multiple sets = of provider configuration data. This caters to the common case of a = user having more than provider account. The problem with the text is it = has plaintext username/passwords, which is clearly wrong. >> I see two solutions: require the local implementation to maintain a = password (or other multi factor authentication, and encrypt the file so = that the user needs to authenticate to access the file. Paul is worried = that the login data may be needed more frequently than is reasonable to = enter the authentication data locally. >> The other is to maintain separate files in provider systems, with a = common authentication mechanism in each provider to access the file. >> I think Paul=E2=80=99s argument doesn=E2=80=99t really hold much = water: no SIP device I know of requires re-authentication that requires = user interaction very often, so whatever they do now is okay. I think = they just keep the data locally, secure enough to re-use when they need = to. So unlock once, good for a very long time. >> I=E2=80=99m reluctant to require all providers use the new OAUTH2 = solution, but if they were okay with it, that would be excellent. We = would need some notion of common username, but otherwise it would just = work. Seems way too different from how things work now. Very = attractive, secure, and user-friendly. >=20 > My concern was with one configuration file vs. a separate one for each = provider. This is rooted in how the file would be provisioned in the = device. >=20 > My assumption is that this configuration is generated by the provider = based on the user doing a web-based enrollment on the provider's web = site, followed by the device downloading that configuration. If the user = has accounts with different providers then this would happen separately = for each, resulting is separate configuration files. >=20 > Do you have a different model in mind for how this would happen? >=20 > Thanks, > Paul >=20 > --=20 > Rum mailing list > Rum@ietf.org > https://www.ietf.org/mailman/listinfo/rum = --Apple-Mail=_22627886-4CAC-443D-BE61-F863B93E5923 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Yeah,= my model was different.  It assumed that whatever was done by the = provider, the result was a single local file.

I=E2=80=99m not wedded to that. =  We do need at least a piece of that to know which providers to = look for, but a file per provider, downloaded when it=E2=80=99s needed = is okay.

Brian


On Oct 21, 2020, at 11:55 AM, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:

On 10/20/20 3:15 PM, Brian Rosen = wrote:
This = is still an open item and distinct from the =E2=80=9Csigned code=E2=80=9D = issue we=E2=80=99ve been discussing.
The current text = describes a single file that can have multiple sets of provider = configuration data.  This caters to the common case of a user = having more than provider account.  The problem with the text is it = has plaintext username/passwords, which is clearly wrong.
I = see two solutions: require the local implementation to maintain a = password (or other multi factor authentication, and encrypt the file so = that the user needs to authenticate to access the file.  Paul is = worried that the login data may be needed more frequently than is = reasonable to enter the authentication data locally.
The = other is to maintain separate files in provider systems, with a common = authentication mechanism in each provider to access the file.
I think Paul=E2=80=99s argument doesn=E2=80=99t really hold = much water: no SIP device I know of requires re-authentication that = requires user interaction very often, so whatever they do now is okay. =  I think they just keep the data locally, secure enough to re-use = when they need to.  So unlock once, good for a very long time.
I=E2=80=99m reluctant to require all providers use the new = OAUTH2 solution, but if they were okay with it, that would be excellent. =  We would need some notion of common username, but otherwise it = would just work.  Seems way too different from how things work now. =  Very attractive, secure, and user-friendly.

My concern was with one configuration file vs. a separate one = for each provider. This is rooted in how the file would be provisioned = in the device.

My assumption is that this configuration is generated by the = provider based on the user doing a web-based enrollment on the = provider's web site, followed by the device downloading that = configuration. If the user has accounts with different providers then = this would happen separately for each, resulting is separate = configuration files.

Do you have a different model in mind for how this would = happen?

Thanks,
= Paul

-- 
Rum mailing list
Rum@ietf.org
https://www.ietf.org/mailman/listinfo/rum

= --Apple-Mail=_22627886-4CAC-443D-BE61-F863B93E5923-- From nobody Wed Oct 21 09:39:42 2020 Return-Path: X-Original-To: rum@ietfa.amsl.com Delivered-To: rum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1EAB3A115D for ; Wed, 21 Oct 2020 09:39:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, NICE_REPLY_A=-0.247, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=alum.mit.edu 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 V4Rf8p1Wg3Gk for ; Wed, 21 Oct 2020 09:39:38 -0700 (PDT) Received: from NAM04-BN3-obe.outbound.protection.outlook.com (mail-eopbgr680065.outbound.protection.outlook.com [40.107.68.65]) (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 9BCC83A0AF9 for ; Wed, 21 Oct 2020 09:39:38 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=SbjC7mXnNQcGGpCSp7mtMvH6DrPL8l5TlxZLhe9n6Gt6JqOqaCsFdIjRf3AJkZlEFAIGDY2c9fMlHN5wSRjyjPxOSQwPnrdO5k6bzaKAXV8HsAzrw8Oh8HS2Y06jVx7QDUpwiRpqM22tEClhTGVPdm45wJVHfDj0ihU01pWc9LEdWZCvcGCp/H3iFQO7AgyWeCfSLQdrD2dwIC2bY3eB3gxUnqP0JUO0YB4RomnqFfWk2X4KWd5SgMnndeTF42HY2ADbl/S38T08q+s/fqc8u2oLenw9cTHfQIsIDZ0PPPPnHo5QDtVs/erGZLLV81aLGmq5uPx89uR25eeajdtOOg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=wF7i/FqtZw7/hx6ixF4so03++frcMuQ06+rYdlnn3D4=; b=QQJ1s29EAMPv2n7ux+ah9p7NtEvJhq3yS86HUo1yliKc6nHfw4+EJjFcx4JEwq2SjRrLH44gV8mWTnQrRaVlVUGLXCnnKsUHEzJvVjjTMxfFSND+1qGw3FKYX+Ww6Eax0oHASEuzPf6gRMoxdaCElohbVe3FnGS/KJpQj2d4Z3v0eREhN/pVz+Yhd9Hqc4EJVJDyPRsEGJT9li0QXdq6DgMyvnzqd5VeeuWxLXwVi88nQGj+Y2vp6IueqmuKdw1r+APNQdfj8U3e5XrksCIb4yBaU6JTPIQ+toD5qi9gymETiEG5yf3vKn3GH6JKMXfk/6hgLEuqF7FHes+SCCEsow== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 18.7.68.33) smtp.rcpttodomain=ietf.org smtp.mailfrom=alum.mit.edu; dmarc=bestguesspass action=none header.from=alum.mit.edu; dkim=none (message not signed); arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alum.mit.edu; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=wF7i/FqtZw7/hx6ixF4so03++frcMuQ06+rYdlnn3D4=; b=YZhC8NuERCRunEpTEswqOgH70XMNdxCH0/I1Yq6B2t6KPdiznUueXEAzc78amdhqXLS3Ofr0EGFrxI3pyzTimbr0fjkxLSBZZWCmkhnA3g/YjqHgoOa0m5R9c/IIz+UidD481GqGottqt/uV2jBrrR+eVg8tLf55lCyrHJtu5z8= Received: from SN4PR0501CA0038.namprd05.prod.outlook.com (2603:10b6:803:41::15) by BYAPR12MB2917.namprd12.prod.outlook.com (2603:10b6:a03:130::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3477.21; Wed, 21 Oct 2020 16:39:30 +0000 Received: from SN1NAM02FT049.eop-nam02.prod.protection.outlook.com (2603:10b6:803:41:cafe::aa) by SN4PR0501CA0038.outlook.office365.com (2603:10b6:803:41::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3499.4 via Frontend Transport; Wed, 21 Oct 2020 16:39:30 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 18.7.68.33) smtp.mailfrom=alum.mit.edu; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=alum.mit.edu; Received-SPF: Pass (protection.outlook.com: domain of alum.mit.edu designates 18.7.68.33 as permitted sender) receiver=protection.outlook.com; client-ip=18.7.68.33; helo=outgoing-alum.mit.edu; Received: from outgoing-alum.mit.edu (18.7.68.33) by SN1NAM02FT049.mail.protection.outlook.com (10.152.72.166) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3477.21 via Frontend Transport; Wed, 21 Oct 2020 16:39:29 +0000 Received: from PaulKyzivatsMBP.localdomain (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.14.7/8.12.4) with ESMTP id 09LGdRXH004029 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT) for ; Wed, 21 Oct 2020 12:39:28 -0400 To: rum@ietf.org References: From: Paul Kyzivat Message-ID: <5e702e6f-b6d5-5f54-d453-d90249e2718d@alum.mit.edu> Date: Wed, 21 Oct 2020 12:39:27 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:78.0) Gecko/20100101 Thunderbird/78.3.3 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: d8beba2a-c6fa-4a6b-d87d-08d875dfe1e2 X-MS-TrafficTypeDiagnostic: BYAPR12MB2917: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:9508; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: m/Ou5hCkxZ4gh50thbee9210PD94GQ2vIlYqbU/J/brl/GqVcO97MVuaIbdy4Serkha4RAya6UdphOFeHfxURLsl2I5CXKSxgNAdu4Y6yqd5ghwBhJI22EDHPsCVGvcMT4pDBLGtQuvh4yepk+unQYkYPYE7P7Vsy0UbTGDfeHUKSgOHhDA6rQeznnHJaVYFXE7M1uZUJt4UjWQD99pwvts5FDlvm2bGPqvlTKeCszOK6FnYb6lx4NCZBe0tkFzRxmMAGHB4ShwPq2i+7fX3CJaRXUDl5HiIOYgc+jVyksYHAFcI++UFmOAy+QSdFwgydSFzRwTSemMNb3aLTu7ZMz7sMOeVu/n36VD4oHhTlws5RttvxqN5RbJzyd7mxWcWfn042Zr7/Dn/vUB6z1pCmZio5z/HwYUjwQvfEGuQRPLjn7koj7Be1ptTYZU2ONs3QfOWrRzgWo7r0K31bPNROfqlzK4ondd0BkJivbVMvPMaylMdEKGBGsTW0+vi90kg X-Forefront-Antispam-Report: CIP:18.7.68.33; CTRY:US; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:outgoing-alum.mit.edu; PTR:outgoing-alum.mit.edu; CAT:NONE; SFS:(136003)(376002)(396003)(39860400002)(346002)(46966005)(8676002)(2616005)(956004)(8936002)(70586007)(31696002)(82310400003)(83380400001)(75432002)(26005)(66574015)(6916009)(966005)(86362001)(2906002)(7596003)(336012)(478600001)(82740400003)(47076004)(31686004)(356005)(53546011)(70206006)(5660300002)(786003)(316002)(186003)(36906005)(43740500002); DIR:OUT; SFP:1101; X-OriginatorOrg: alum.mit.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Oct 2020 16:39:29.8143 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: d8beba2a-c6fa-4a6b-d87d-08d875dfe1e2 X-MS-Exchange-CrossTenant-Id: 3326b102-c043-408b-a990-b89e477d582f X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3326b102-c043-408b-a990-b89e477d582f; Ip=[18.7.68.33]; Helo=[outgoing-alum.mit.edu] X-MS-Exchange-CrossTenant-AuthSource: SN1NAM02FT049.eop-nam02.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR12MB2917 Archived-At: Subject: Re: [Rum] Configuration file X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2020 16:39:41 -0000 On 10/21/20 12:04 PM, Brian Rosen wrote: > Yeah, my model was different.  It assumed that whatever was done by the > provider, the result was a single local file. > > I’m not wedded to that.  We do need at least a piece of that to know > which providers to look for, but a file per provider, downloaded when > it’s needed is okay. Yes, the list of providers needs to be from a single source. That will present some administration challenges. But I don't think it makes sense for the providers to populate that with all the details needed for a RUE to connect to them. It occurs to me that we might be able to get away with using DNS to hold the list of providers - avoiding the need to stand up a special server for that purpose. I'm thinking that the RUE have a way to present the user with a list of available providers. The user would be able to select one and then ask to enroll with it. Then the user would get a browser connection to an enrollment page where he would sign up for service, be assigned a user name, password, and phone number. Then the device would connect to the config download service of the provider and download the configuration file. The RUE would save this. The RUE would then use the configuration info to do a SIP registration and be ready to both receive and initiate calls. The RUE could do this for multiple providers. The result would presumably be a UI for something akin to a multi-line phone. (Remember those from the old days?) Thanks, Paul > Brian > > >> On Oct 21, 2020, at 11:55 AM, Paul Kyzivat > > wrote: >> >> On 10/20/20 3:15 PM, Brian Rosen wrote: >>> This is still an open item and distinct from the “signed code” issue >>> we’ve been discussing. >>> The current text describes a single file that can have multiple sets >>> of provider configuration data.  This caters to the common case of a >>> user having more than provider account.  The problem with the text is >>> it has plaintext username/passwords, which is clearly wrong. >>> I see two solutions: require the local implementation to maintain a >>> password (or other multi factor authentication, and encrypt the file >>> so that the user needs to authenticate to access the file.  Paul is >>> worried that the login data may be needed more frequently than is >>> reasonable to enter the authentication data locally. >>> The other is to maintain separate files in provider systems, with a >>> common authentication mechanism in each provider to access the file. >>> I think Paul’s argument doesn’t really hold much water: no SIP device >>> I know of requires re-authentication that requires user interaction >>> very often, so whatever they do now is okay.  I think they just keep >>> the data locally, secure enough to re-use when they need to.  So >>> unlock once, good for a very long time. >>> I’m reluctant to require all providers use the new OAUTH2 solution, >>> but if they were okay with it, that would be excellent.  We would >>> need some notion of common username, but otherwise it would just >>> work.  Seems way too different from how things work now.  Very >>> attractive, secure, and user-friendly. >> >> My concern was with one configuration file vs. a separate one for each >> provider. This is rooted in how the file would be provisioned in the >> device. >> >> My assumption is that this configuration is generated by the provider >> based on the user doing a web-based enrollment on the provider's web >> site, followed by the device downloading that configuration. If the >> user has accounts with different providers then this would happen >> separately for each, resulting is separate configuration files. >> >> Do you have a different model in mind for how this would happen? >> >> Thanks, >> Paul >> >> -- >> Rum mailing list >> Rum@ietf.org >> https://www.ietf.org/mailman/listinfo/rum >> > > From nobody Wed Oct 21 10:17:13 2020 Return-Path: X-Original-To: rum@ietfa.amsl.com Delivered-To: rum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB62B3A1281 for ; Wed, 21 Oct 2020 10:17:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 vlPJFX9CQoX4 for ; Wed, 21 Oct 2020 10:17:09 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) (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 B96EE3A118F for ; Wed, 21 Oct 2020 10:16:50 -0700 (PDT) Received: from macbook-pro.webway.org (h-205-16.A165.corp.bahnhof.se [176.10.205.16]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp7.webway.se (Postfix) with ESMTPSA id 1060A2361; Wed, 21 Oct 2020 19:16:45 +0200 (CEST) From: "Olle E. Johansson" Message-Id: <3D97FDC3-7B80-4D16-A76B-11DC3562BEF9@edvina.net> Content-Type: multipart/alternative; boundary="Apple-Mail=_30B500B8-4761-4BA7-963C-08621DFFB56C" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Date: Wed, 21 Oct 2020 19:16:44 +0200 In-Reply-To: Cc: Olle E Johansson , rum@ietf.org To: Brian Rosen References: <64C1A076-27B1-49FB-B52D-A1E300FF7D0E@edvina.net> X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [Rum] Configuration file X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2020 17:17:12 -0000 --Apple-Mail=_30B500B8-4761-4BA7-963C-08621DFFB56C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 A problem that has to be solved is key rollover - how do you change the = keys if you have X certificates that signed them? Well, you can generate new CSRs for each provider based on a new key = pairs, which means that you will have certs ready (while the old ones are still in use) and manage your own roll = over. /O > On 21 Oct 2020, at 16:50, Brian Rosen wrote: >=20 > This is actually a good idea I think. The light bulb for me was = =E2=80=9Csame key pair=E2=80=9D. >=20 > So suppose the device generated a key pair, and used a local passcode = or pass phrase to access the private key. For each provider, the = provider issues a cert, and that cert is used for TLS client = authentication. Same key pair for each provider, different cert. It = would work for any provider to issue a cert that other providers = accepted, but it would be an easier =E2=80=9Csell=E2=80=9D, I think, if = they each issued a cert to their customer. The cert can be used with = TLS to retrieve a per-provider configuration file as well as SIP = operations. Persistent TLS could be used to avoid requiring entering = credentials often at the user end. >=20 > Would that be acceptable? >=20 > Brian >=20 >> On Oct 21, 2020, at 1:28 AM, Olle E. Johansson > wrote: >>=20 >>=20 >>=20 >>> On 20 Oct 2020, at 21:15, Brian Rosen > wrote: >>>=20 >>> This is still an open item and distinct from the =E2=80=9Csigned = code=E2=80=9D issue we=E2=80=99ve been discussing. >>>=20 >>> The current text describes a single file that can have multiple sets = of provider configuration data. This caters to the common case of a = user having more than provider account. The problem with the text is it = has plaintext username/passwords, which is clearly wrong. >>>=20 >>> I see two solutions: require the local implementation to maintain a = password (or other multi factor authentication, and encrypt the file so = that the user needs to authenticate to access the file. Paul is worried = that the login data may be needed more frequently than is reasonable to = enter the authentication data locally. =20 >>>=20 >>> The other is to maintain separate files in provider systems, with a = common authentication mechanism in each provider to access the file. >>>=20 >>> I think Paul=E2=80=99s argument doesn=E2=80=99t really hold much = water: no SIP device I know of requires re-authentication that requires = user interaction very often, so whatever they do now is okay. I think = they just keep the data locally, secure enough to re-use when they need = to. So unlock once, good for a very long time. >>>=20 >>> I=E2=80=99m reluctant to require all providers use the new OAUTH2 = solution, but if they were okay with it, that would be excellent. We = would need some notion of common username, but otherwise it would just = work. Seems way too different from how things work now. Very = attractive, secure, and user-friendly. >>=20 >> To add to your list: Don=E2=80=99t forget about using TLS client = certs. It=E2=80=99s not very hard, can securely be provisioned using = Oauth or other means >> and can be re-issued often. For the telco business it=E2=80=99s = unusal, but it=E2=80=99s frequently used in other solutions, like VPNs. >>=20 >> You can one per provider, based on the same key pair or separate key = pairs. >>=20 >> /O >=20 > --=20 > Rum mailing list > Rum@ietf.org > https://www.ietf.org/mailman/listinfo/rum --Apple-Mail=_30B500B8-4761-4BA7-963C-08621DFFB56C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 A = problem that has to be solved is key rollover - how do you change the =  keys if you have X certificates that signed them?
Well, you can generate new CSRs for each provider based on a = new key pairs, which means that you will have certs
ready (while the old ones are still in use) and manage your = own roll over.

/O

On 21 Oct 2020, at 16:50, Brian Rosen <br@brianrosen.net> = wrote:

This is actually a = good idea I think.  The light bulb for me was =E2=80=9Csame key = pair=E2=80=9D.

So = suppose the device generated a key pair, and used a local passcode or = pass phrase to access the private key.  For each provider, the = provider issues a cert, and that cert is used for TLS client = authentication.  Same key pair for each provider, different cert. =  It would work for any provider to issue a cert that other = providers accepted, but it would be an easier =E2=80=9Csell=E2=80=9D, I = think, if they each issued a cert to their customer.  The cert can = be used with TLS to retrieve a per-provider configuration file as well = as SIP operations.  Persistent TLS could be used to avoid requiring = entering credentials often at the user end.

Would that be acceptable?

Brian

On Oct 21, 2020, at 1:28 AM, Olle E. Johansson <oej@edvina.net> = wrote:



On 20 = Oct 2020, at 21:15, Brian Rosen <br@brianrosen.net> wrote:

This is still an open item and distinct from the =E2=80=9Csigne= d code=E2=80=9D issue we=E2=80=99ve been discussing.

The current text describes a single file that can have = multiple sets of provider configuration data.  This caters to the = common case of a user having more than provider account.  The = problem with the text is it has plaintext username/passwords, which is = clearly wrong.

I see two solutions: require = the local implementation to maintain a password (or other multi factor = authentication, and encrypt the file so that the user needs to = authenticate to access the file.  Paul is worried that the login = data may be needed more frequently than is reasonable to enter the = authentication data locally.  

The = other is to maintain separate files in provider systems, with a common = authentication mechanism in each provider to access the file.

I think Paul=E2=80=99s argument doesn=E2=80=99t = really hold much water: no SIP device I know of requires = re-authentication that requires user interaction very often, so whatever = they do now is okay.  I think they just keep the data locally, = secure enough to re-use when they need to.  So unlock once, good = for a very long time.

I=E2=80=99m reluctant = to require all providers use the new OAUTH2 solution, but if they were = okay with it, that would be excellent.  We would need some notion = of common username, but otherwise it would just work.  Seems way = too different from how things work now.  Very attractive, secure, = and user-friendly.

To add to your list: Don=E2=80=99t forget about using TLS = client certs. It=E2=80=99s not very hard, can securely be provisioned = using Oauth or other means
and can be re-issued often. For the telco business it=E2=80=99s= unusal, but it=E2=80=99s frequently used in other solutions, like = VPNs.

You can one = per provider, based on the same key pair or separate key = pairs.

/O

--=
Rum mailing list
Rum@ietf.org
https://www.ietf.org/mailman/listinfo/rum

= --Apple-Mail=_30B500B8-4761-4BA7-963C-08621DFFB56C-- From nobody Wed Oct 21 23:29:36 2020 Return-Path: X-Original-To: rum@ietfa.amsl.com Delivered-To: rum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2839D3A0B8E for ; Wed, 21 Oct 2020 23:29:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 XtOolIkt7Smk for ; Wed, 21 Oct 2020 23:29:31 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) (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 3EF113A0B8C for ; Wed, 21 Oct 2020 23:29:29 -0700 (PDT) Received: from pinguicula.webway.org (h-205-16.A165.corp.bahnhof.se [176.10.205.16]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp7.webway.se (Postfix) with ESMTPSA id 18A7D25F9; Thu, 22 Oct 2020 08:29:26 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) From: "Olle E. Johansson" In-Reply-To: <38090A50-6572-4A8E-97D4-C260323365AE@brianrosen.net> Date: Thu, 22 Oct 2020 08:29:25 +0200 Cc: Olle E Johansson , Eugene Christensen , "rum@ietf.org" , Paul Kyzivat Content-Transfer-Encoding: quoted-printable Message-Id: References: <4d6ba97f-a83d-3d36-14a9-c6e84dd5b874@alum.mit.edu> <7A11F680-9EA6-4477-9BD8-6A7755AD0054@brianrosen.net> <7fdb95e6-e954-7275-60f7-462cf07eff0e@alum.mit.edu> <92b5d34b-2fbf-0e2b-8562-8f7d11c5123b@alum.mit.edu> <5e6d8446-c267-5113-aff1-fc87576b1317@alum.mit.edu> <38090A50-6572-4A8E-97D4-C260323365AE@brianrosen.net> To: Brian Rosen X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [Rum] [EXT] RUM security model X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2020 06:29:35 -0000 > On 21 Oct 2020, at 16:40, Brian Rosen wrote: >=20 > If a magic number (often this is called an =E2=80=9CAPI Key=E2=80=9D) = is good enough, I can write text for it. The client code would have a = version and the key sent to the server in Registration. The server can = verify the code was one it issued, for that version. The code would be = per-provider. Sending API keys or any other tokens in a header in SIP is not a good = idea. Which is why we said MUST encrypt in the SIP/Oauth2 document. Remember that there can be multiple proxys in the path and giving them = the API key is not a good thing. The API key can be used as a secret in a HTTP digest auth with a strong = checksum (hint: Not MD5) >=20 > Brute force and DDoS attacks can=E2=80=99t be addressed by this = document except in the Security Consideration section. They are = implementation issues. =20 If there are specific attack vectors to RUM that doesn=E2=80=99t apply = to SIP implementations in general, yes. /O >=20 > Brian >=20 >=20 >> On Oct 21, 2020, at 9:32 AM, Eugene Christensen = wrote: >>=20 >> Brian, >>=20 >> You mentioned the use of a magic number. Is that the same as the use = of an authorization key that is built into the product with the = respective provider's key(s)? If so I believe that could possibly work. = If I understand that correctly, the provider's would give a key to the = developer that would be unique to that application and version. When = that application attempts to connect to a provider, the provider will = know what company's app and version it is and be able to accept the = connection once it has been verified in the lab. If it goes rogue = thereafter, as I understand it, the providers could revoke that access. >>=20 >> Regarding some concerns with an open API, here are three that should = be captured: >> - Brute force attacks - A bad actor could use an API to determine a = user's password. >> - Untested clients - A problem caused unintentionally by an endpoint = developer with good intentions.=20 >> - DDOS attacks - A bad actor could try to bring a system down by = sending multiple requests from different IP addresses making it = difficult to block. >>=20 >>=20 >> Thanks, >> Eugene. >>=20 >> CONFIDENTIALITY NOTICE. This e-mail transmission, and any documents, = files or previous e-mail messages attached to it, may contain = confidential and proprietary information. If you are not the intended = recipient, or a person responsible for delivering it to the intended = recipient, you are hereby notified that any disclosure, copying, = distribution or use of any of the information contained in or attached = to this message is STRICTLY PROHIBITED. If you have received this = transmission in error, please immediately notify me by reply e-mail at = echristensen@sorenson.com or by telephone at +1 (801) 287-9419, and = destroy the original transmission and its attachments without reading = them or saving them to disk. >>=20 >> -----Original Message----- >> From: Rum On Behalf Of Paul Kyzivat >> Sent: Tuesday, October 20, 2020 9:34 AM >> To: Brian Rosen >> Cc: rum@ietf.org >> Subject: Re: [Rum] [EXT] RUM security model >>=20 >> [EXTERNAL]=20 >>=20 >> I think this discussion highlights the need to first nail down the = threat model that the providers want to protect against. >>=20 >> James: can you take a crack at that? Possibly pull in some of the = other providers if you think they will be willing. >>=20 >> (I wonder if providers currently have any sort of robust protection = against malicious impersonation of their devices? I'm guessing it is = only security by obscurity.) >>=20 >> Thanks, >> Paul >>=20 >> On 10/20/20 10:10 AM, Brian Rosen wrote: >>> Yes, both apps, one app steals the credential from the other (same = machine, same user). >>>=20 >>> I also don=E2=80=99t think a downloaded test would be particularly = helpful unless we built in a bunch of mechanism that allowed automation = of testing. >>>=20 >>> And then, what would stop an app from playing nice with a test, and = then nasty when it wanted to? >>>=20 >>> Both of these exploits do assume that the app developer intends to = flaunt approval in some way. If that=E2=80=99s not a threat that is = important to guard against then a simple magic number for an app is = enough. An app gets tested by a provider, and is given a magic number = that it provides, securely, in some way. As long as the providers trust = the app developer to not misuse the magic number, it=E2=80=99s an = indication that the app (at a particular version presumably) was = trusted. >>>=20 >>> As long as malicious actors can be ignored, I think we could do = something. I don=E2=80=99t think that is worth much, but if it is, I = can write text. >>>=20 >>> If you want to protect against malicious actors, then I don=E2=80=99t = know how. TPM won=E2=80=99t work - doesn=E2=80=99t work in Android/iOS. = It=E2=80=99s mostly a PC thing. Even with TPM, what you need is = something like a digest of the code. You can=E2=80=99t get that. >>>=20 >>> Brian >>>=20 >>>=20 >>>> On Oct 16, 2020, at 11:17 AM, Paul Kyzivat = wrote: >>>>=20 >>>> On 10/15/20 8:24 PM, Brian Rosen wrote: >>>>> Nope, it just takes a hacker to create a piece of code that = patches an app to look like another app. >>>>=20 >>>> I don't follow. >>>>=20 >>>> A user gets a device capable of passing the tests. He requests to = enroll it with is provider as one of his devices. As part of that, a = test is run between the device and the provider's enrollment server. = Then the provider gives the device some sort of cert that can be used = when registering. >>>>=20 >>>> Next, the user decides to try out some other rogue device on his = account. Normally he would repeat the above, and the device would fail = the test. Instead, he might cause the rogue device to steal the cert = from the device that passed. I think he can't help but know he is doing = something illicit. >>>>=20 >>>> I guess if these were both just apps, then a remote attack on the = device could install a rogue app that impersonates the valid one and = steals its credentials. Is that what you had in mind? >>>>=20 >>>> Perhaps we need to spend some time with the providers enumerating = the attacks they are concerned with. >>>>=20 >>>> Thanks, >>>> Paul >>>>=20 >>>>> On Thu, Oct 15, 2020 at 8:19 PM Paul Kyzivat = > wrote: >>>>> On 10/15/20 7:52 PM, Brian Rosen wrote: >>>>>> I don=E2=80=99t think even that would work because there isn=E2=80=99= t any way to >>>>> know that the app that was approved is the app that is being = used. >>>>> Yes, I guess you are right. But at least it would require the = end user >>>>> to enter into a conspiracy with the app developers, and be able = to get >>>>> the credential out of one app and into another. >>>>> Thanks, >>>>> Paul >>>>>> What systems like iOS does is rely on the fact that you can=E2=80=99= t >>>>> download and run an app that hasn=E2=80=99t been vetted. The = code is signed >>>>> and the signature is checked every time the app starts. We = don=E2=80=99t >>>>> have an environment like that. We can=E2=80=99t control what is = downloaded >>>>> and we can=E2=80=99t check signatures. >>>>>> I don=E2=80=99t think there is a reliable way to do this. If = someone has >>>>> an idea, please explain it, but we can=E2=80=99t be in a =E2=80=9C= you do something=E2=80=9D >>>>> position without a clue as to how. >>>>>>=20 >>>>>> Now, if the app was an iOS app, then the right thing happens. >>>>> There are few other systems that are wired down like that. = Android, >>>>> for example, allows you to download and run from arbitrary sites = if >>>>> the device is configured to allow that. >>>>>>=20 >>>>>> Brian >>>>>>=20 >>>>>>=20 >>>>>>> On Oct 15, 2020, at 6:30 PM, Paul Kyzivat >>>> > wrote: >>>>>>>=20 >>>>>>> =EF=BB=BFEugene, >>>>>>>=20 >>>>>>>> On 10/15/20 3:30 PM, Eugene Christensen wrote: >>>>>>>> Brian, >>>>>>>> Admittedly I do not fully understand certificates and >>>>> authentication but would client certificates or mutual >>>>> authentication with a shared secret work here? >>>>>>>=20 >>>>>>> I'm also not a security expert. To my understanding, the key >>>>> problem is that you want a proof that an implementation has = passed >>>>> some sort of test. That is more or less equivalent to having a >>>>> special certification authority that is able to assign a = certificate >>>>> based on the passing of a test. But for the system to work that >>>>> certificate needs to be bound to the entity (hw/sw) that passed = the >>>>> test. It can't be possible to transfer that certificate to a >>>>> different device. >>>>>>>=20 >>>>>>> A possible alternative would be for each provider to have its >>>>> own test service. When a user gets a new device/application, as = part >>>>> of the initial registration of their device with the provider, = this >>>>> test would be run. Then the result of that would be granting of >>>>> credentials for that device to access that provider's system. >>>>>>>=20 >>>>>>> Thanks, >>>>>>> Paul >>>>>>>=20 >>>>>>>> Thank you. >>>>>>>> Eugene >>>>>>>> *CONFIDENTIALITY NOTICE.*This e-mail transmission, and any >>>>> documents, files or previous e-mail messages attached to it, may >>>>> contain confidential and proprietary information. If you are not = the >>>>> intended recipient, or a person responsible for delivering it to = the >>>>> intended recipient, you are hereby notified that any disclosure, >>>>> copying, distribution or use of any of the information contained = in >>>>> or attached to this message is STRICTLY PROHIBITED. If you have >>>>> received this transmission in error, please immediately notify = me by >>>>> reply e-mail at echristensen@sorenson.com >>>>> = >>>> >or by telephone at +1 (801) >>>>> 287-9419, and destroy the original transmission and its = attachments >>>>> without reading them or saving them to disk. >>>>>>>> *From:* Brian Rosen > >>>>>>>> *Sent:* Wednesday, September 30, 2020 5:47 PM >>>>>>>> *To:* Eugene Christensen >>>> > >>>>>>>> *Cc:* rum@ietf.org >>>>>>>> *Subject:* Re: [Rum] [EXT] RUM security model >>>>>>>> [EXTERNAL] >>>>>>>> I think we understand why you want it. What we don=E2=80=99t = understand >>>>> is what mechanism would provide it. I am generally aware of this >>>>> class of problem and I=E2=80=99m not aware of a solution that = will work. So >>>>> what we need is a suggested mechanism that provides the = assurance >>>>> you want that is technically sound. >>>>>>>> Brian >>>>>>>> On Wed, Sep 30, 2020 at 6:30 PM Eugene Christensen >>>>> >>>>> >>>> >> wrote: >>>>>>>> Thanks for considering how we might implement this security >>>>>>>> mechanism. May I add my voice that it is essential that we >>>>> find an >>>>>>>> option for providing this desired security, whatever it is. = It >>>>>>>> could be detrimental to the VRS providers to have UAs out >>>>> there, >>>>>>>> with the ability to register with VRS providers without >>>>> first being >>>>>>>> fully vetted. It is our practice anytime we make updates >>>>> to our UAs >>>>>>>> to test how they work with our UAS before we ever release >>>>> the new UA >>>>>>>> software into our production environment. We only want UAs >>>>>>>> registering that have undergone this rigorous testing with = our >>>>>>>> systems and then only with users which we have awareness of. >>>>>>>> Thanks, >>>>>>>> Eugene Christensen >>>>>>>> CONFIDENTIALITY NOTICE. This e-mail transmission, and any >>>>> documents, >>>>>>>> files or previous e-mail messages attached to it, may contain >>>>>>>> confidential and proprietary information. If you are not the >>>>>>>> intended recipient, or a person responsible for delivering >>>>> it to the >>>>>>>> intended recipient, you are hereby notified that any >>>>> disclosure, >>>>>>>> copying, distribution or use of any of the information >>>>> contained in >>>>>>>> or attached to this message is STRICTLY PROHIBITED. If you = have >>>>>>>> received this transmission in error, please immediately >>>>> notify me by >>>>>>>> reply e-mail at echristensen@sorenson.com >>>>> >>>>>>>> >>>> > or by telephone at +1 (801) >>>>>>>> 287-9419, and destroy the original transmission and its >>>>> attachments >>>>>>>> without reading them or saving them to disk. >>>>>>>> -- Rum mailing list >>>>>>>> Rum@ietf.org >>>> > >>>>>>>> https://www.ietf.org/mailman/listinfo/rum >>>>> >>>>>>>> >>>> > >>>>>>>=20 >>>>>>> -- >>>>>>> Rum mailing list >>>>>>> Rum@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/rum >>>>> >>>>=20 >>>=20 >>=20 >> -- >> Rum mailing list >> Rum@ietf.org >> https://www.ietf.org/mailman/listinfo/rum >=20 > --=20 > Rum mailing list > Rum@ietf.org > https://www.ietf.org/mailman/listinfo/rum From nobody Thu Oct 22 06:11:47 2020 Return-Path: X-Original-To: rum@ietfa.amsl.com Delivered-To: rum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49EEF3A0CC0 for ; Thu, 22 Oct 2020 06:11:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=brianrosen-net.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 4WKVPLbjvMGZ for ; Thu, 22 Oct 2020 06:11:38 -0700 (PDT) Received: from mail-qk1-x72c.google.com (mail-qk1-x72c.google.com [IPv6:2607:f8b0:4864:20::72c]) (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 632B33A0C5E for ; Thu, 22 Oct 2020 06:11:38 -0700 (PDT) Received: by mail-qk1-x72c.google.com with SMTP id h140so1318653qke.7 for ; Thu, 22 Oct 2020 06:11:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=H/lReNynRMCI0gM7xb24g88lp0mo1qIusTCJ/rpnzcM=; b=ISWHAzFE6GaowMDQXnx0ZrRznjR1LhzqOlpmhIeuH1ZhFcnQqBZYVNyaBCflY5OXVD 0jfG8OqQ9JeFYdpuEKPdiyYxkopXKUX/WIA6am7cHuI1AG0s1ikfSJrsGJgvvg3lGFw/ 3gUpTnrpEfFIuXeEu8IqS5rNGHWMp8aLJuX009WIMbJRgON1uEbE5Ka7+l6MVruw90Hl bzXQHPI/pFx28Mmtlow5aswMhP1PLhM4zMEy1tbOG7JxoUox5y9dAVim1CCVf0UYrvaK LlAzFXEG02mYDxF+u58yv7/yYsN5dbQ0BVar/Eyi3AxoynhceXx2PeYAApOgad9Avdbr /QCA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=H/lReNynRMCI0gM7xb24g88lp0mo1qIusTCJ/rpnzcM=; b=JbfkOvYT/QkcC3EYTjrEqrorrs2dNgkJMFk8dpMg3jvsaKrYls3liiymzaggs5jI6o 3pSdF4N5aX6VDVi0gfHxkBYpi6Cm5/CtEMcxt08VguBxpi3brJf5wpeihvbP8xtVLGzJ 3Gk1TnoLjUIjVrVbTTBkkOUxVws6kXtZ9XWrda83t75tQPU7Uoih1ANx2VmkhMzjT6+M 1Mh9BkFztoHgxAUvJAjebj/AGZ7+yb7H0VvFAorDN12PEtPsbKGWf/0JroGyOhXfW9gD WF8NZkeldqGoJoLgbGhRbUE5xJ9pY9OeLCMuM/lw+hm+xqXSAlEeM3atR7YW29NJUpsy Mefg== X-Gm-Message-State: AOAM533hhN3E0qszIGO2s837tpfNlSVrnjqE6xcb8jn3OlIYduX9WWEz FO/WO752PSl2SzE3MBLRWEryUA== X-Google-Smtp-Source: ABdhPJyVb5xaJs9sNB41O3vW3/q7H+5rY7Yuly8R0s3yE68rMJvMudTkaafkWdT9c2hLgNu85XKieQ== X-Received: by 2002:a05:620a:1322:: with SMTP id p2mr2167464qkj.211.1603372297429; Thu, 22 Oct 2020 06:11:37 -0700 (PDT) Received: from brians-mbp-2871.lan (dynamic-acs-24-154-119-158.zoominternet.net. [24.154.119.158]) by smtp.gmail.com with ESMTPSA id d47sm946749qtk.53.2020.10.22.06.11.35 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 22 Oct 2020 06:11:36 -0700 (PDT) From: Brian Rosen Message-Id: <7CB778CD-DB19-497B-9913-6FB4ACBFD941@brianrosen.net> Content-Type: multipart/alternative; boundary="Apple-Mail=_62F9BCAF-65C5-4549-9EE0-9494E50946A7" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Date: Thu, 22 Oct 2020 09:11:35 -0400 In-Reply-To: <3D97FDC3-7B80-4D16-A76B-11DC3562BEF9@edvina.net> Cc: rum@ietf.org To: "Olle E. Johansson" References: <64C1A076-27B1-49FB-B52D-A1E300FF7D0E@edvina.net> <3D97FDC3-7B80-4D16-A76B-11DC3562BEF9@edvina.net> X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [Rum] Configuration file X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2020 13:11:46 -0000 --Apple-Mail=_62F9BCAF-65C5-4549-9EE0-9494E50946A7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Yes, I think that would work fine. We would have to write text that = said that. We also would probably want to have text that made the = upload of CSRs automated. Brian > On Oct 21, 2020, at 1:16 PM, Olle E. Johansson wrote: >=20 > A problem that has to be solved is key rollover - how do you change = the keys if you have X certificates that signed them? > Well, you can generate new CSRs for each provider based on a new key = pairs, which means that you will have certs > ready (while the old ones are still in use) and manage your own roll = over. >=20 > /O >=20 >> On 21 Oct 2020, at 16:50, Brian Rosen > wrote: >>=20 >> This is actually a good idea I think. The light bulb for me was = =E2=80=9Csame key pair=E2=80=9D. >>=20 >> So suppose the device generated a key pair, and used a local passcode = or pass phrase to access the private key. For each provider, the = provider issues a cert, and that cert is used for TLS client = authentication. Same key pair for each provider, different cert. It = would work for any provider to issue a cert that other providers = accepted, but it would be an easier =E2=80=9Csell=E2=80=9D, I think, if = they each issued a cert to their customer. The cert can be used with = TLS to retrieve a per-provider configuration file as well as SIP = operations. Persistent TLS could be used to avoid requiring entering = credentials often at the user end. >>=20 >> Would that be acceptable? >>=20 >> Brian >>=20 >>> On Oct 21, 2020, at 1:28 AM, Olle E. Johansson > wrote: >>>=20 >>>=20 >>>=20 >>>> On 20 Oct 2020, at 21:15, Brian Rosen > wrote: >>>>=20 >>>> This is still an open item and distinct from the =E2=80=9Csigned = code=E2=80=9D issue we=E2=80=99ve been discussing. >>>>=20 >>>> The current text describes a single file that can have multiple = sets of provider configuration data. This caters to the common case of = a user having more than provider account. The problem with the text is = it has plaintext username/passwords, which is clearly wrong. >>>>=20 >>>> I see two solutions: require the local implementation to maintain a = password (or other multi factor authentication, and encrypt the file so = that the user needs to authenticate to access the file. Paul is worried = that the login data may be needed more frequently than is reasonable to = enter the authentication data locally. =20 >>>>=20 >>>> The other is to maintain separate files in provider systems, with a = common authentication mechanism in each provider to access the file. >>>>=20 >>>> I think Paul=E2=80=99s argument doesn=E2=80=99t really hold much = water: no SIP device I know of requires re-authentication that requires = user interaction very often, so whatever they do now is okay. I think = they just keep the data locally, secure enough to re-use when they need = to. So unlock once, good for a very long time. >>>>=20 >>>> I=E2=80=99m reluctant to require all providers use the new OAUTH2 = solution, but if they were okay with it, that would be excellent. We = would need some notion of common username, but otherwise it would just = work. Seems way too different from how things work now. Very = attractive, secure, and user-friendly. >>>=20 >>> To add to your list: Don=E2=80=99t forget about using TLS client = certs. It=E2=80=99s not very hard, can securely be provisioned using = Oauth or other means >>> and can be re-issued often. For the telco business it=E2=80=99s = unusal, but it=E2=80=99s frequently used in other solutions, like VPNs. >>>=20 >>> You can one per provider, based on the same key pair or separate key = pairs. >>>=20 >>> /O >>=20 >> --=20 >> Rum mailing list >> Rum@ietf.org >> https://www.ietf.org/mailman/listinfo/rum >=20 --Apple-Mail=_62F9BCAF-65C5-4549-9EE0-9494E50946A7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Yes, = I think that would work fine.  We would have to write text that = said that.  We also would probably want to have text that made the = upload of CSRs automated.

Brian

On Oct 21, 2020, at 1:16 PM, = Olle E. Johansson <oej@edvina.net> wrote:

A problem that has to = be solved is key rollover - how do you change the  keys if you have = X certificates that signed them?
Well, you can generate = new CSRs for each provider based on a new key pairs, which means that = you will have certs
ready (while the old ones are = still in use) and manage your own roll over.

/O

On 21 = Oct 2020, at 16:50, Brian Rosen <br@brianrosen.net> wrote:

This is actually a = good idea I think.  The light bulb for me was =E2=80=9Csame key = pair=E2=80=9D.

So = suppose the device generated a key pair, and used a local passcode or = pass phrase to access the private key.  For each provider, the = provider issues a cert, and that cert is used for TLS client = authentication.  Same key pair for each provider, different cert. =  It would work for any provider to issue a cert that other = providers accepted, but it would be an easier =E2=80=9Csell=E2=80=9D, I = think, if they each issued a cert to their customer.  The cert can = be used with TLS to retrieve a per-provider configuration file as well = as SIP operations.  Persistent TLS could be used to avoid requiring = entering credentials often at the user end.

Would that be acceptable?

Brian

On Oct 21, 2020, at 1:28 AM, Olle E. Johansson <oej@edvina.net> = wrote:



On 20 = Oct 2020, at 21:15, Brian Rosen <br@brianrosen.net> wrote:

This is still an open item and distinct from the =E2=80=9Csigne= d code=E2=80=9D issue we=E2=80=99ve been discussing.

The current text describes a single file that can have = multiple sets of provider configuration data.  This caters to the = common case of a user having more than provider account.  The = problem with the text is it has plaintext username/passwords, which is = clearly wrong.

I see two solutions: require = the local implementation to maintain a password (or other multi factor = authentication, and encrypt the file so that the user needs to = authenticate to access the file.  Paul is worried that the login = data may be needed more frequently than is reasonable to enter the = authentication data locally.  

The = other is to maintain separate files in provider systems, with a common = authentication mechanism in each provider to access the file.

I think Paul=E2=80=99s argument doesn=E2=80=99t = really hold much water: no SIP device I know of requires = re-authentication that requires user interaction very often, so whatever = they do now is okay.  I think they just keep the data locally, = secure enough to re-use when they need to.  So unlock once, good = for a very long time.

I=E2=80=99m reluctant = to require all providers use the new OAUTH2 solution, but if they were = okay with it, that would be excellent.  We would need some notion = of common username, but otherwise it would just work.  Seems way = too different from how things work now.  Very attractive, secure, = and user-friendly.

To add to your list: Don=E2=80=99t forget about using TLS = client certs. It=E2=80=99s not very hard, can securely be provisioned = using Oauth or other means
and can be re-issued often. For the telco business it=E2=80=99s= unusal, but it=E2=80=99s frequently used in other solutions, like = VPNs.

You can one = per provider, based on the same key pair or separate key = pairs.

/O

--=
Rum mailing list
Rum@ietf.org
https://www.ietf.org/mailman/listinfo/rum


= --Apple-Mail=_62F9BCAF-65C5-4549-9EE0-9494E50946A7-- From nobody Thu Oct 22 06:18:03 2020 Return-Path: X-Original-To: rum@ietfa.amsl.com Delivered-To: rum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E0523A0B9D for ; Thu, 22 Oct 2020 06:18:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=brianrosen-net.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 gXMS_774dJq1 for ; Thu, 22 Oct 2020 06:17:59 -0700 (PDT) Received: from mail-qv1-xf2c.google.com (mail-qv1-xf2c.google.com [IPv6:2607:f8b0:4864:20::f2c]) (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 C2B233A0BAB for ; Thu, 22 Oct 2020 06:17:58 -0700 (PDT) Received: by mail-qv1-xf2c.google.com with SMTP id cv1so801741qvb.2 for ; Thu, 22 Oct 2020 06:17:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=cAgnmkJEHhEvJaAttXRbnQ260FKkJVqUAAIzIQh9H50=; b=WjcZ3c20gam65uNriDK2FH1xbzVsE+Xn7Dvpvc69ePY+z5boRNRSDE7SSHdirPjvcR jLI5mom7e9cC/AIcl7UEFSGXkuhyJjQHv1fIHzWmiwdSZmtxOiPdU5BlsgfieIOrHgZ9 8kOyd92vbbHXW4vsUW9q2zc/mQ84HvxjXO+Y7J5uDV5hXsg4hSB1PACxR7LGLoCGQlM+ vRdQXoAgdRXJomXKfrvd3h7m1Tj7BoqLiR0TUSCUH3gGB+LDEevgc/7iUTwAENHXAiBv MeqHbbaS5Ugap2S2TQWLnJ4Jz6/DD0vjj/AHCCQEHGI7CC7xswSqT60C/U1SV/ZBJLai jcvw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=cAgnmkJEHhEvJaAttXRbnQ260FKkJVqUAAIzIQh9H50=; b=DUymFN8nLsli1mmXGw/2AckMOXOAOg1xj29FmxRRaX6MCQC6i4vqRDO2OMRMleAWFC bB84JbLFp7WeO2rw+OAWvnYWtxCQGcC0En3fG80bfvhvWWp96uyTz4Eoztoh45uDaW0d 4A2SbAO8UzzrHPmwZPCGHwEcO6fSaqJ6wFGoQFwq5++s52SjlBh/sKBBKnkGrbu++kyf HvklgH3cvDwjI5NQa7yTgHWwVY5ti5Ti00h7GysNwLt2peaNxfKMB5dNqXSxyhm+k1d0 KbcVfif1UUGBF2Y9lrzi/O2CXYwQszcQVq/xd/WDqHi2OLXaAiPfUsze0WNSLdjXqMAJ DoOg== X-Gm-Message-State: AOAM532fA1paIcWt6r0IMJNqR4H9lVst4qb+YM1Mgh7rkY9UCYzM1g9S Ai79Ji74tk5FTQfQFc8fa4kmR3e/vHC2aCDo X-Google-Smtp-Source: ABdhPJwYbvw+MgfbhrENFAPeD7Kt2CtUn+1woeItZ+e+egX7pK6SbxmIpheTeMxteeIrnye9/UwGGQ== X-Received: by 2002:a0c:eacc:: with SMTP id y12mr2325836qvp.31.1603372677737; Thu, 22 Oct 2020 06:17:57 -0700 (PDT) Received: from brians-mbp-2871.lan (dynamic-acs-24-154-119-158.zoominternet.net. [24.154.119.158]) by smtp.gmail.com with ESMTPSA id g11sm918432qkl.30.2020.10.22.06.17.56 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 22 Oct 2020 06:17:56 -0700 (PDT) From: Brian Rosen Message-Id: <8047B5E7-D235-446E-9B9C-E0B871C6E48C@brianrosen.net> Content-Type: multipart/alternative; boundary="Apple-Mail=_B036D211-DBCB-4576-858D-60358BA6AB50" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Date: Thu, 22 Oct 2020 09:17:55 -0400 In-Reply-To: <5e702e6f-b6d5-5f54-d453-d90249e2718d@alum.mit.edu> Cc: rum@ietf.org To: Paul Kyzivat References: <5e702e6f-b6d5-5f54-d453-d90249e2718d@alum.mit.edu> X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [Rum] Configuration file X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2020 13:18:02 -0000 --Apple-Mail=_B036D211-DBCB-4576-858D-60358BA6AB50 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 How would we use DNS to hold the list of providers? Seems to me that = the official list, at least in some places like the US, is controlled by = the regulator. That isn=E2=80=99t the case in other countries. Where = it is, there is an authoritative source. Could we make the list a = registry, make it country specific, and have an expert decide if a = provider should be added to the list? I think your description of signup and config is good. Yes, I remember multi-line phones. I have a SIP multi-line phone on my = desk that has =E2=80=9Clines=E2=80=9D from multiple providers. Brian > On Oct 21, 2020, at 12:39 PM, Paul Kyzivat = wrote: >=20 > On 10/21/20 12:04 PM, Brian Rosen wrote: >> Yeah, my model was different. It assumed that whatever was done by = the provider, the result was a single local file. >> I=E2=80=99m not wedded to that. We do need at least a piece of that = to know which providers to look for, but a file per provider, downloaded = when it=E2=80=99s needed is okay. >=20 > Yes, the list of providers needs to be from a single source. That will = present some administration challenges. But I don't think it makes sense = for the providers to populate that with all the details needed for a RUE = to connect to them. >=20 > It occurs to me that we might be able to get away with using DNS to = hold the list of providers - avoiding the need to stand up a special = server for that purpose. >=20 > I'm thinking that the RUE have a way to present the user with a list = of available providers. The user would be able to select one and then = ask to enroll with it. Then the user would get a browser connection to = an enrollment page where he would sign up for service, be assigned a = user name, password, and phone number. Then the device would connect to = the config download service of the provider and download the = configuration file. The RUE would save this. The RUE would then use the = configuration info to do a SIP registration and be ready to both receive = and initiate calls. >=20 > The RUE could do this for multiple providers. The result would = presumably be a UI for something akin to a multi-line phone. (Remember = those from the old days?) >=20 > Thanks, > Paul >=20 >> Brian >>> On Oct 21, 2020, at 11:55 AM, Paul Kyzivat >> wrote: >>>=20 >>> On 10/20/20 3:15 PM, Brian Rosen wrote: >>>> This is still an open item and distinct from the =E2=80=9Csigned = code=E2=80=9D issue we=E2=80=99ve been discussing. >>>> The current text describes a single file that can have multiple = sets of provider configuration data. This caters to the common case of a = user having more than provider account. The problem with the text is it = has plaintext username/passwords, which is clearly wrong. >>>> I see two solutions: require the local implementation to maintain a = password (or other multi factor authentication, and encrypt the file so = that the user needs to authenticate to access the file. Paul is worried = that the login data may be needed more frequently than is reasonable to = enter the authentication data locally. >>>> The other is to maintain separate files in provider systems, with a = common authentication mechanism in each provider to access the file. >>>> I think Paul=E2=80=99s argument doesn=E2=80=99t really hold much = water: no SIP device I know of requires re-authentication that requires = user interaction very often, so whatever they do now is okay. I think = they just keep the data locally, secure enough to re-use when they need = to. So unlock once, good for a very long time. >>>> I=E2=80=99m reluctant to require all providers use the new OAUTH2 = solution, but if they were okay with it, that would be excellent. We = would need some notion of common username, but otherwise it would just = work. Seems way too different from how things work now. Very = attractive, secure, and user-friendly. >>>=20 >>> My concern was with one configuration file vs. a separate one for = each provider. This is rooted in how the file would be provisioned in = the device. >>>=20 >>> My assumption is that this configuration is generated by the = provider based on the user doing a web-based enrollment on the = provider's web site, followed by the device downloading that = configuration. If the user has accounts with different providers then = this would happen separately for each, resulting is separate = configuration files. >>>=20 >>> Do you have a different model in mind for how this would happen? >>>=20 >>> Thanks, >>> Paul >>>=20 >>> -- >>> Rum mailing list >>> Rum@ietf.org > >>> https://www.ietf.org/mailman/listinfo/rum = = > >=20 > --=20 > Rum mailing list > Rum@ietf.org > https://www.ietf.org/mailman/listinfo/rum = --Apple-Mail=_B036D211-DBCB-4576-858D-60358BA6AB50 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 How = would we use DNS to hold the list of providers?  Seems to me that = the official list, at least in some places like the US, is controlled by = the regulator.  That isn=E2=80=99t the case in other countries. =  Where it is, there is an authoritative source.  Could we make = the list a registry, make it country specific, and have an expert decide = if a provider should be added to the list?

I think your description of signup and = config is good.

Yes, I remember multi-line phones.  I have a SIP = multi-line phone on my desk that has =E2=80=9Clines=E2=80=9D from = multiple providers.

Brian


On Oct = 21, 2020, at 12:39 PM, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:

On 10/21/20 12:04 PM, Brian = Rosen wrote:
Yeah, = my model was different.  It assumed that whatever was done by the = provider, the result was a single local file.
I=E2=80=99m = not wedded to that.  We do need at least a piece of that to know = which providers to look for, but a file per provider, downloaded when = it=E2=80=99s needed is okay.

Yes, the list of providers needs = to be from a single source. That will present some administration = challenges. But I don't think it makes sense for the providers to = populate that with all the details needed for a RUE to connect to = them.

It occurs to = me that we might be able to get away with using DNS to hold the list of = providers - avoiding the need to stand up a special server for that = purpose.

I'm thinking = that the RUE have a way to present the user with a list of available = providers. The user would be able to select one and then ask to enroll = with it. Then the user would get a browser connection to an enrollment = page where he would sign up for service, be assigned a user name, = password, and phone number. Then the device would connect to the config = download service of the provider and download the configuration file. = The RUE would save this. The RUE would then use the configuration info = to do a SIP registration and be ready to both receive and initiate = calls.

The RUE could = do this for multiple providers. The result would presumably be a UI for = something akin to a multi-line phone. (Remember those from the old = days?)

Thanks,
= Paul

Brian
On = Oct 21, 2020, at 11:55 AM, Paul Kyzivat <pkyzivat@alum.mit.edu<mailto:pkyzivat@alum.mit.edu>> wrote:

On 10/20/20 3:15 PM, Brian Rosen wrote:
This is still an open = item and distinct from the =E2=80=9Csigned code=E2=80=9D issue we=E2=80=99= ve been discussing.
The current text describes a single = file that can have multiple sets of provider configuration data. This = caters to the common case of a user having more than provider account. =  The problem with the text is it has plaintext username/passwords, = which is clearly wrong.
I see two solutions: require the = local implementation to maintain a password (or other multi factor = authentication, and encrypt the file so that the user needs to = authenticate to access the file.  Paul is worried that the login = data may be needed more frequently than is reasonable to enter the = authentication data locally.
The other is to maintain = separate files in provider systems, with a common authentication = mechanism in each provider to access the file.
I think = Paul=E2=80=99s argument doesn=E2=80=99t really hold much water: no SIP = device I know of requires re-authentication that requires user = interaction very often, so whatever they do now is okay.  I think = they just keep the data locally, secure enough to re-use when they need = to.  So unlock once, good for a very long time.
I=E2=80= =99m reluctant to require all providers use the new OAUTH2 solution, but = if they were okay with it, that would be excellent.  We would need = some notion of common username, but otherwise it would just work. =  Seems way too different from how things work now.  Very = attractive, secure, and user-friendly.

My concern was with one configuration file vs. a separate one = for each provider. This is rooted in how the file would be provisioned = in the device.

My assumption is that this = configuration is generated by the provider based on the user doing a = web-based enrollment on the provider's web site, followed by the device = downloading that configuration. If the user has accounts with different = providers then this would happen separately for each, resulting is = separate configuration files.

Do you have a = different model in mind for how this would happen?

Thanks,
Paul

--
Rum mailing list
Rum@ietf.org <mailto:Rum@ietf.org>
https://www.ietf.org/mailman/listinfo/rum <https://www.ietf.org/mailman/listinfo/rum>

-- Rum mailing list
Rum@ietf.org
https://www.ietf.org/mailman/listinfo/rum

= --Apple-Mail=_B036D211-DBCB-4576-858D-60358BA6AB50-- From nobody Thu Oct 22 08:33:51 2020 Return-Path: X-Original-To: rum@ietfa.amsl.com Delivered-To: rum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 324913A1047 for ; Thu, 22 Oct 2020 08:33:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, NICE_REPLY_A=-0.247, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=alum.mit.edu 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 7LhyQvvS_xFQ for ; Thu, 22 Oct 2020 08:33:47 -0700 (PDT) Received: from NAM12-MW2-obe.outbound.protection.outlook.com (mail-mw2nam12on2074.outbound.protection.outlook.com [40.107.244.74]) (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 427F53A0C24 for ; Thu, 22 Oct 2020 08:33:47 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=MP9jdMawNzAoSSwi6N8gOUm8I9MUI11M0dcVRtQRrIEgQkk8rTp1zAwkyr2gdPg0Pji7SQxtToKRn6nNFnjgPxQrpNcMxlsAWun7YmvRxKEEDW2LJoZUd9iHlGHMIgkVT/DxyvikWXSDfheWfNakfst/Z9LngVnMliwIgum3D/tWZ+FO+femA7A/xnBJaQcEZ8h7lEworaJIVtC3Qi/3i5bLi4URYNGNFzMTdxCWcNJ2O3JqVvHfg2NmDbRL/Rslfiwux4pVykn5MGBYaHQpThTsN3vB+RjBRFb4GpCZv8E2XdOVeoxmaYNbJ9n/FIocWzCL46Otm27+uySbz7bSjw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=pco0b/W5Wz3mfFUc62kUt4Ld+TV9Zs7ZIvyf8m7ugkc=; b=FuJQRYCg8hHld/1S2jAT4avfwoXiR7ZMQw3FdzvvSJBUu9FhGzrV2nLpSMiOuS4JiS7XneatrW4GbdK64OiNaqAmWLiIcEW8nfFMfC3thJAdj1Wk1rqtp2QA4z1sSPNDYEWb/SxIjJ0C6Kj3DkZst9zQcmAcJE48bj/i+wWfy+MLdTDXt4zWhDJM9BqU/Spi3TBPXhgO/qzaskMKl+xwujrXwJwaepL51UbfDnx3Livyk83VinBgUp269Y5BY/lG0i+3TvXgZNipChT+MpWbfIAFylfm1fB7zdCEszEgooKjVNQuOqzEEfA86NRLpjI6Lc7KMQaQeea/kBKXhSG6kA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 18.7.68.33) smtp.rcpttodomain=edvina.net smtp.mailfrom=alum.mit.edu; dmarc=bestguesspass action=none header.from=alum.mit.edu; dkim=none (message not signed); arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alum.mit.edu; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=pco0b/W5Wz3mfFUc62kUt4Ld+TV9Zs7ZIvyf8m7ugkc=; b=N7m27AosujV4QQhZG4hI8RtpwpZPMRE/CeHa9vxks/EZzrz4G8emDsnzCAjdUa97lmLsj3OaFQ9Ip9CkeIqQEhDBaH0RiCrh3huC9Ltw7Tk7YXTnDiyaGUB1YJ7ttrhipib7A1maNB03KC3nh4KsPUWpZSAi1cYfU6PU9QuZpbk= Received: from MN2PR16CA0009.namprd16.prod.outlook.com (2603:10b6:208:134::22) by MN2PR12MB4607.namprd12.prod.outlook.com (2603:10b6:208:a1::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3477.25; Thu, 22 Oct 2020 15:33:45 +0000 Received: from BL2NAM02FT044.eop-nam02.prod.protection.outlook.com (2603:10b6:208:134:cafe::1b) by MN2PR16CA0009.outlook.office365.com (2603:10b6:208:134::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3499.18 via Frontend Transport; Thu, 22 Oct 2020 15:33:45 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 18.7.68.33) smtp.mailfrom=alum.mit.edu; edvina.net; dkim=none (message not signed) header.d=none;edvina.net; dmarc=bestguesspass action=none header.from=alum.mit.edu; Received-SPF: Pass (protection.outlook.com: domain of alum.mit.edu designates 18.7.68.33 as permitted sender) receiver=protection.outlook.com; client-ip=18.7.68.33; helo=outgoing-alum.mit.edu; Received: from outgoing-alum.mit.edu (18.7.68.33) by BL2NAM02FT044.mail.protection.outlook.com (10.152.77.35) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3499.20 via Frontend Transport; Thu, 22 Oct 2020 15:33:44 +0000 Received: from PaulKyzivatsMBP.localdomain (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.14.7/8.12.4) with ESMTP id 09MFXgU8002249 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Thu, 22 Oct 2020 11:33:42 -0400 To: "Olle E. Johansson" , Brian Rosen Cc: Eugene Christensen , "rum@ietf.org" References: <4d6ba97f-a83d-3d36-14a9-c6e84dd5b874@alum.mit.edu> <7A11F680-9EA6-4477-9BD8-6A7755AD0054@brianrosen.net> <7fdb95e6-e954-7275-60f7-462cf07eff0e@alum.mit.edu> <92b5d34b-2fbf-0e2b-8562-8f7d11c5123b@alum.mit.edu> <5e6d8446-c267-5113-aff1-fc87576b1317@alum.mit.edu> <38090A50-6572-4A8E-97D4-C260323365AE@brianrosen.net> From: Paul Kyzivat Message-ID: Date: Thu, 22 Oct 2020 11:33:42 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:78.0) Gecko/20100101 Thunderbird/78.3.3 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 623b0941-3c37-4fff-f915-08d8769fdc8f X-MS-TrafficTypeDiagnostic: MN2PR12MB4607: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:7691; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: LILz7jfi7y1wTt1A2PzP32ZY6oKBXicSNUb/L1RDgtowZD8P2cTVqO6KIVMiPRl98Fwc1Q//HvOnATgrsESOBFQqD+aa7ZMy57BF8YdOiNLb3ffA0aAo1Z6C/eB1DVdD7moJsP9OVhSYvSjgOrJ6cj7vPAoLar8DrnRczM2PW4/PMPZ3FtWdy8D+FZgkYXXkMf8e3X9nXri/aSVGdMkoCCU2h3TybP9POS1iIV4GOYhvRrTGbaabw1TfOOa7ebSNV2huyPSrYilmFHVcxkRlI8+Ol+MDL1V5epopVp0/XrYAEmTU1cw28z+T6NszPQ/v2EDa00svtxUnAWQ2TPXGzA88aft5nDh7EFn10m7YRdl+/7gDt9gY28J3GU532C8O/D7nmq7fOgnwcERXlK9Dg9/fZXS9bB9ptl4Z4lgwUSIK9zZOJDbarFDcL1Uj2hmu X-Forefront-Antispam-Report: CIP:18.7.68.33; CTRY:US; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:outgoing-alum.mit.edu; PTR:outgoing-alum.mit.edu; CAT:NONE; SFS:(376002)(346002)(136003)(396003)(39860400002)(46966005)(4744005)(70206006)(75432002)(70586007)(956004)(2906002)(82310400003)(2616005)(110136005)(54906003)(5660300002)(86362001)(4326008)(31696002)(336012)(186003)(66574015)(316002)(36906005)(83380400001)(47076004)(15650500001)(26005)(478600001)(786003)(356005)(8936002)(8676002)(7596003)(53546011)(82740400003)(31686004)(43740500002); DIR:OUT; SFP:1101; X-OriginatorOrg: alum.mit.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Oct 2020 15:33:44.3916 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 623b0941-3c37-4fff-f915-08d8769fdc8f X-MS-Exchange-CrossTenant-Id: 3326b102-c043-408b-a990-b89e477d582f X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3326b102-c043-408b-a990-b89e477d582f; Ip=[18.7.68.33]; Helo=[outgoing-alum.mit.edu] X-MS-Exchange-CrossTenant-AuthSource: BL2NAM02FT044.eop-nam02.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR12MB4607 Archived-At: Subject: Re: [Rum] [EXT] RUM security model X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2020 15:33:49 -0000 On 10/22/20 2:29 AM, Olle E. Johansson wrote: [snip] >> Brute force and DDoS attacks can’t be addressed by this document except in the Security Consideration section. They are implementation issues. > If there are specific attack vectors to RUM that doesn’t apply to SIP implementations in general, yes. AFAIK there should be nothing special about VRS that makes it any more vulnerable to attack than any other sip service accessed over the public internet. I'd like to hear from the providers if I am wrong about this. Thanks, Paul From nobody Thu Oct 22 09:04:07 2020 Return-Path: X-Original-To: rum@ietfa.amsl.com Delivered-To: rum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D67663A044E for ; Thu, 22 Oct 2020 09:04:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, NICE_REPLY_A=-0.247, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=alum.mit.edu 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 73VMrXunItgs for ; Thu, 22 Oct 2020 09:04:03 -0700 (PDT) Received: from NAM10-BN7-obe.outbound.protection.outlook.com (mail-bn7nam10on2057.outbound.protection.outlook.com [40.107.92.57]) (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 513E03A0317 for ; Thu, 22 Oct 2020 09:04:02 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=GzMer9FXCieckjw9yfar5o/kvTWH3Zvv7k8yCUdXOJLJhKPNGvwMtbv+V7WP9EyUnFbJI0RTLjthhw3OF2zSqqqcVgq25WmLAONP4UVBm35OH7oeEweVKf2k82ewTCKmQgQ2LWFEO4EfjFyHJGp0eZo98wAvmuyCOPhr4mWJc3zEilRkRF/bX0GFRTdYOUqRQUlH95TdFc9gHHu/EcJAmTr4tLIuyOTBpIxMZjOOKsNMJTkm+ZhyMScQMFCbCw/3skQDGmVHYfrnYIdUAgwbOFLf8Guu84KGo8SS2jXBjD+5p2DH4PbecjN5e8WAZKpp+EKeL/5PcRTbdLnJ0+8HIA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=RfhtV/HbaHwEveT9kOehc0Xoeq9aXp4pz2ICKwTcYPg=; b=FgFjSY8QrYDjcX8akrDNtsYn5S0RItics/PwcRiCtq3dxO8e2Y9ZQaHppDfbRu8Yx7y0ZXNBI4PGGwtUaX0JYhtyzbI8l/V7u1UBlGAoN5+Eni7q7Zn6j0VEkDwORu0UuXVG6Ap+KUkFxKCxHTyijZIP92Y5OfLdcYSQ9ejfwkTZv6LhtFN8cYx+aiUJAwRWiPphPRF/0qSmGUYFIbyHimS1SC0Vw3w2s5rT1/mjIPqRwvZyh4nCP6dYkIkpsS6p3XLK7NWNH54h5oO5MDvx9vihsRUeHIIsgosv8/Njrvh5+CdVr/dOj77+0ItwRaqO6e1yPyX6dhb4fVOOAPwdlw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 18.7.68.33) smtp.rcpttodomain=brianrosen.net smtp.mailfrom=alum.mit.edu; dmarc=bestguesspass action=none header.from=alum.mit.edu; dkim=none (message not signed); arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alum.mit.edu; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=RfhtV/HbaHwEveT9kOehc0Xoeq9aXp4pz2ICKwTcYPg=; b=jfR7pkklC1B+DH7M5V8HtCZFcefHKhQcyRACHNDcbPBqzlpMSrqxgrk0CGNXpiM9i2YkqZIkOvRvm5QONHoVHh2UssKFIGZv8Grw0Spt1USnzvjOIj5P2ZrbVeYsE2GtMzoO7AO53CVF0KjzDzZAHNYBM8DC8vXZUXKfQhrBaqU= Received: from CY4PR07CA0014.namprd07.prod.outlook.com (2603:10b6:903:165::24) by DM5PR12MB1945.namprd12.prod.outlook.com (2603:10b6:3:10f::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3499.18; Thu, 22 Oct 2020 16:04:00 +0000 Received: from CY1NAM02FT003.eop-nam02.prod.protection.outlook.com (2603:10b6:903:165:cafe::d7) by CY4PR07CA0014.outlook.office365.com (2603:10b6:903:165::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3499.18 via Frontend Transport; Thu, 22 Oct 2020 16:04:00 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 18.7.68.33) smtp.mailfrom=alum.mit.edu; brianrosen.net; dkim=none (message not signed) header.d=none;brianrosen.net; dmarc=bestguesspass action=none header.from=alum.mit.edu; Received-SPF: Pass (protection.outlook.com: domain of alum.mit.edu designates 18.7.68.33 as permitted sender) receiver=protection.outlook.com; client-ip=18.7.68.33; helo=outgoing-alum.mit.edu; Received: from outgoing-alum.mit.edu (18.7.68.33) by CY1NAM02FT003.mail.protection.outlook.com (10.152.74.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3499.20 via Frontend Transport; Thu, 22 Oct 2020 16:04:00 +0000 Received: from PaulKyzivatsMBP.localdomain (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.14.7/8.12.4) with ESMTP id 09MG3vMj004564 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Thu, 22 Oct 2020 12:03:58 -0400 To: Brian Rosen Cc: rum@ietf.org References: <5e702e6f-b6d5-5f54-d453-d90249e2718d@alum.mit.edu> <8047B5E7-D235-446E-9B9C-E0B871C6E48C@brianrosen.net> From: Paul Kyzivat Message-ID: Date: Thu, 22 Oct 2020 12:03:57 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:78.0) Gecko/20100101 Thunderbird/78.3.3 MIME-Version: 1.0 In-Reply-To: <8047B5E7-D235-446E-9B9C-E0B871C6E48C@brianrosen.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: f84d66a9-5c06-4737-c007-08d876a416ee X-MS-TrafficTypeDiagnostic: DM5PR12MB1945: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: Jb3eBoeZVPNR4hzJudLex3xeH7MtdPy71du4eswlc2ofwVboI2krlqZmvDraaJ0+61Noz1frFqT9T6AxfNN1SHUIT7tv7bP3JwjslpNn3z4HNxWgC0EjY/zTC6B/VKGewJ7EtCgg+4Q7MwMkv67PBBBE5vO/LQtHWw8uqIeLPS8x3BQfb2wGRo9tB34aOTwsxhAlGqxlqDCNEm3KXJCSb+H/ZP2y2266f0r1UTG42Dj0sYQEe3cDVKaWsUNAbVaqlel2xd3AamN7626cTM+A15uDLZppL3p+5ged01BI2hC9f/QfpX96k+vX8/1OJO9/mTsEa3EbW3QZky2ZxNLTohhF8aiT8BvM1uK/tBRH9HKJT0U52QG3kacs8f7sv1eTBqVl1S+g71i20BYtfvl4zlA5xsOYzGioipTTro6mfnaR8057uU47U8wH7wX+XNpmizavkbWBRtVsPgRHOoy0fkpDVdehiWgeEi+xjB8FCNzJFcTXQ/2GQdUVvqFU+aFS X-Forefront-Antispam-Report: CIP:18.7.68.33; CTRY:US; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:outgoing-alum.mit.edu; PTR:outgoing-alum.mit.edu; CAT:NONE; SFS:(376002)(136003)(39860400002)(396003)(346002)(46966005)(786003)(2616005)(478600001)(966005)(26005)(82740400003)(316002)(6916009)(82310400003)(83380400001)(66574015)(8676002)(7596003)(36906005)(186003)(31686004)(8936002)(47076004)(356005)(956004)(70586007)(53546011)(2906002)(86362001)(31696002)(4326008)(75432002)(5660300002)(336012)(70206006)(43740500002); DIR:OUT; SFP:1101; X-OriginatorOrg: alum.mit.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Oct 2020 16:04:00.2493 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: f84d66a9-5c06-4737-c007-08d876a416ee X-MS-Exchange-CrossTenant-Id: 3326b102-c043-408b-a990-b89e477d582f X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3326b102-c043-408b-a990-b89e477d582f; Ip=[18.7.68.33]; Helo=[outgoing-alum.mit.edu] X-MS-Exchange-CrossTenant-AuthSource: CY1NAM02FT003.eop-nam02.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR12MB1945 Archived-At: Subject: Re: [Rum] Configuration file X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2020 16:04:06 -0000 On 10/22/20 9:17 AM, Brian Rosen wrote: > How would we use DNS to hold the list of providers? We could simply create a zone as the root for a regulatory entity, and then populate it with A and AAAA entries for each provider in the regulatory domain. (There would need to be some way to provision the RUE with the zone to consult.) Or perhaps SRV records could be used for this. My point is simply that a single domain name or URL per provider could be sufficient to bootstrap connecting to the corresponding provider. It would require establishing some conventions for how to do the bootstrapping. > Seems to me that > the official list, at least in some places like the US, is controlled by > the regulator.  That isn’t the case in other countries.  Where it is, > there is an authoritative source.  Could we make the list a registry, > make it country specific, and have an expert decide if a provider should > be added to the list? This *might* work given that the set of providers doesn't change rapidly. But if/when it does change it isn't evident how deployed RUEs would be updated. I guess it might just be treated as part of normal maintenance updates, however they are done. > I think your description of signup and config is good. It is just a rough start. It needs more discussion and fleshing out. I don't know if this needs to be normative. (It might just be something such as a non-normative annex.) The main value is to ensure that the mechanisms needed to support it *are* defined and normative. Thanks, Paul > Yes, I remember multi-line phones.  I have a SIP multi-line phone on my > desk that has “lines” from multiple providers. > > Brian > > >> On Oct 21, 2020, at 12:39 PM, Paul Kyzivat > > wrote: >> >> On 10/21/20 12:04 PM, Brian Rosen wrote: >>> Yeah, my model was different.  It assumed that whatever was done by >>> the provider, the result was a single local file. >>> I’m not wedded to that.  We do need at least a piece of that to know >>> which providers to look for, but a file per provider, downloaded when >>> it’s needed is okay. >> >> Yes, the list of providers needs to be from a single source. That will >> present some administration challenges. But I don't think it makes >> sense for the providers to populate that with all the details needed >> for a RUE to connect to them. >> >> It occurs to me that we might be able to get away with using DNS to >> hold the list of providers - avoiding the need to stand up a special >> server for that purpose. >> >> I'm thinking that the RUE have a way to present the user with a list >> of available providers. The user would be able to select one and then >> ask to enroll with it. Then the user would get a browser connection to >> an enrollment page where he would sign up for service, be assigned a >> user name, password, and phone number. Then the device would connect >> to the config download service of the provider and download the >> configuration file. The RUE would save this. The RUE would then use >> the configuration info to do a SIP registration and be ready to both >> receive and initiate calls. >> >> The RUE could do this for multiple providers. The result would >> presumably be a UI for something akin to a multi-line phone. (Remember >> those from the old days?) >> >> Thanks, >> Paul >> >>> Brian >>>> On Oct 21, 2020, at 11:55 AM, Paul Kyzivat >>> >>> >> wrote: >>>> >>>> On 10/20/20 3:15 PM, Brian Rosen wrote: >>>>> This is still an open item and distinct from the “signed code” >>>>> issue we’ve been discussing. >>>>> The current text describes a single file that can have multiple >>>>> sets of provider configuration data. This caters to the common case >>>>> of a user having more than provider account.  The problem with the >>>>> text is it has plaintext username/passwords, which is clearly wrong. >>>>> I see two solutions: require the local implementation to maintain a >>>>> password (or other multi factor authentication, and encrypt the >>>>> file so that the user needs to authenticate to access the file. >>>>>  Paul is worried that the login data may be needed more frequently >>>>> than is reasonable to enter the authentication data locally. >>>>> The other is to maintain separate files in provider systems, with a >>>>> common authentication mechanism in each provider to access the file. >>>>> I think Paul’s argument doesn’t really hold much water: no SIP >>>>> device I know of requires re-authentication that requires user >>>>> interaction very often, so whatever they do now is okay.  I think >>>>> they just keep the data locally, secure enough to re-use when they >>>>> need to.  So unlock once, good for a very long time. >>>>> I’m reluctant to require all providers use the new OAUTH2 solution, >>>>> but if they were okay with it, that would be excellent.  We would >>>>> need some notion of common username, but otherwise it would just >>>>> work.  Seems way too different from how things work now.  Very >>>>> attractive, secure, and user-friendly. >>>> >>>> My concern was with one configuration file vs. a separate one for >>>> each provider. This is rooted in how the file would be provisioned >>>> in the device. >>>> >>>> My assumption is that this configuration is generated by the >>>> provider based on the user doing a web-based enrollment on the >>>> provider's web site, followed by the device downloading that >>>> configuration. If the user has accounts with different providers >>>> then this would happen separately for each, resulting is separate >>>> configuration files. >>>> >>>> Do you have a different model in mind for how this would happen? >>>> >>>> Thanks, >>>> Paul >>>> >>>> -- >>>> Rum mailing list >>>> Rum@ietf.org >>> > >>>> https://www.ietf.org/mailman/listinfo/rum >>>> >>> > >> >> -- >> Rum mailing list >> Rum@ietf.org >> https://www.ietf.org/mailman/listinfo/rum >> > From nobody Thu Oct 22 09:08:30 2020 Return-Path: X-Original-To: rum@ietfa.amsl.com Delivered-To: rum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 609303A03F8 for ; Thu, 22 Oct 2020 09:08:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 l9g_D8irCCdW for ; Thu, 22 Oct 2020 09:08:25 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) (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 6D4CF3A07B2 for ; Thu, 22 Oct 2020 09:08:24 -0700 (PDT) Received: from pinguicula.webway.org (h-205-16.A165.corp.bahnhof.se [176.10.205.16]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp7.webway.se (Postfix) with ESMTPSA id 961F025F9; Thu, 22 Oct 2020 18:08:20 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) From: "Olle E. Johansson" In-Reply-To: Date: Thu, 22 Oct 2020 18:08:20 +0200 Cc: Olle E Johansson , Brian Rosen , rum@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <5e702e6f-b6d5-5f54-d453-d90249e2718d@alum.mit.edu> <8047B5E7-D235-446E-9B9C-E0B871C6E48C@brianrosen.net> To: Paul Kyzivat X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [Rum] Configuration file X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2020 16:08:28 -0000 Sounds like you are discussing a SAML-like trust model=E2=80=A6 Just hinting. /O > On 22 Oct 2020, at 18:03, Paul Kyzivat wrote: >=20 > On 10/22/20 9:17 AM, Brian Rosen wrote: >> How would we use DNS to hold the list of providers?=20 >=20 > We could simply create a zone as the root for a regulatory entity, and = then populate it with A and AAAA entries for each provider in the = regulatory domain. (There would need to be some way to provision the RUE = with the zone to consult.) >=20 > Or perhaps SRV records could be used for this. >=20 > My point is simply that a single domain name or URL per provider could = be sufficient to bootstrap connecting to the corresponding provider. It = would require establishing some conventions for how to do the = bootstrapping. >=20 >> Seems to me that the official list, at least in some places like the = US, is controlled by the regulator. That isn=E2=80=99t the case in = other countries. Where it is, there is an authoritative source. Could = we make the list a registry, make it country specific, and have an = expert decide if a provider should be added to the list? >=20 > This *might* work given that the set of providers doesn't change = rapidly. But if/when it does change it isn't evident how deployed RUEs = would be updated. I guess it might just be treated as part of normal = maintenance updates, however they are done. >=20 >> I think your description of signup and config is good. >=20 > It is just a rough start. It needs more discussion and fleshing out. I = don't know if this needs to be normative. (It might just be something = such as a non-normative annex.) The main value is to ensure that the = mechanisms needed to support it *are* defined and normative. >=20 > Thanks, > Paul >=20 >> Yes, I remember multi-line phones. I have a SIP multi-line phone on = my desk that has =E2=80=9Clines=E2=80=9D from multiple providers. >> Brian >>> On Oct 21, 2020, at 12:39 PM, Paul Kyzivat > wrote: >>>=20 >>> On 10/21/20 12:04 PM, Brian Rosen wrote: >>>> Yeah, my model was different. It assumed that whatever was done by = the provider, the result was a single local file. >>>> I=E2=80=99m not wedded to that. We do need at least a piece of = that to know which providers to look for, but a file per provider, = downloaded when it=E2=80=99s needed is okay. >>>=20 >>> Yes, the list of providers needs to be from a single source. That = will present some administration challenges. But I don't think it makes = sense for the providers to populate that with all the details needed for = a RUE to connect to them. >>>=20 >>> It occurs to me that we might be able to get away with using DNS to = hold the list of providers - avoiding the need to stand up a special = server for that purpose. >>>=20 >>> I'm thinking that the RUE have a way to present the user with a list = of available providers. The user would be able to select one and then = ask to enroll with it. Then the user would get a browser connection to = an enrollment page where he would sign up for service, be assigned a = user name, password, and phone number. Then the device would connect to = the config download service of the provider and download the = configuration file. The RUE would save this. The RUE would then use the = configuration info to do a SIP registration and be ready to both receive = and initiate calls. >>>=20 >>> The RUE could do this for multiple providers. The result would = presumably be a UI for something akin to a multi-line phone. (Remember = those from the old days?) >>>=20 >>> Thanks, >>> Paul >>>=20 >>>> Brian >>>>> On Oct 21, 2020, at 11:55 AM, Paul Kyzivat >> wrote: >>>>>=20 >>>>> On 10/20/20 3:15 PM, Brian Rosen wrote: >>>>>> This is still an open item and distinct from the =E2=80=9Csigned = code=E2=80=9D issue we=E2=80=99ve been discussing. >>>>>> The current text describes a single file that can have multiple = sets of provider configuration data. This caters to the common case of a = user having more than provider account. The problem with the text is it = has plaintext username/passwords, which is clearly wrong. >>>>>> I see two solutions: require the local implementation to maintain = a password (or other multi factor authentication, and encrypt the file = so that the user needs to authenticate to access the file. Paul is = worried that the login data may be needed more frequently than is = reasonable to enter the authentication data locally. >>>>>> The other is to maintain separate files in provider systems, with = a common authentication mechanism in each provider to access the file. >>>>>> I think Paul=E2=80=99s argument doesn=E2=80=99t really hold much = water: no SIP device I know of requires re-authentication that requires = user interaction very often, so whatever they do now is okay. I think = they just keep the data locally, secure enough to re-use when they need = to. So unlock once, good for a very long time. >>>>>> I=E2=80=99m reluctant to require all providers use the new OAUTH2 = solution, but if they were okay with it, that would be excellent. We = would need some notion of common username, but otherwise it would just = work. Seems way too different from how things work now. Very = attractive, secure, and user-friendly. >>>>>=20 >>>>> My concern was with one configuration file vs. a separate one for = each provider. This is rooted in how the file would be provisioned in = the device. >>>>>=20 >>>>> My assumption is that this configuration is generated by the = provider based on the user doing a web-based enrollment on the = provider's web site, followed by the device downloading that = configuration. If the user has accounts with different providers then = this would happen separately for each, resulting is separate = configuration files. >>>>>=20 >>>>> Do you have a different model in mind for how this would happen? >>>>>=20 >>>>> Thanks, >>>>> Paul >>>>>=20 >>>>> -- >>>>> Rum mailing list >>>>> Rum@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/rum = > >>>=20 >>> -- >>> Rum mailing list >>> Rum@ietf.org >>> https://www.ietf.org/mailman/listinfo/rum = >=20 > --=20 > Rum mailing list > Rum@ietf.org > https://www.ietf.org/mailman/listinfo/rum From nobody Fri Oct 23 14:18:34 2020 Return-Path: X-Original-To: rum@ietf.org Delivered-To: rum@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B65923A115E; Fri, 23 Oct 2020 14:15:50 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: rum@ietf.org, superuser@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 7.20.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160348775073.5087.16759040024799277162@ietfa.amsl.com> Date: Fri, 23 Oct 2020 14:15:50 -0700 Archived-At: Subject: [Rum] rum - Requested session has been scheduled for IETF 109 X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Oct 2020 21:15:54 -0000 Dear Paul Kyzivat, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. rum Session 1 (1:00 requested) Wednesday, 18 November 2020, Session II 1430-1530 Room Name: Room 2 size: 502 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/109/sessions/rum.ics Request Information: --------------------------------------------------------- Working Group Name: Relay User Machine Area Name: Applications and Real-Time Area Session Requester: Paul Kyzivat Number of Sessions: 1 Length of Session(s): 1 Hour Number of Attendees: 20 Conflicts to Avoid: Chair Conflict: avtcore dispatch sipcore ecrit mmusic Technology Overlap: quic People who must be present: Murray Kucherawy Brian Rosen Paul Kyzivat Resources Requested: Special Requests: --------------------------------------------------------- From nobody Fri Oct 30 14:40:50 2020 Return-Path: X-Original-To: rum@ietfa.amsl.com Delivered-To: rum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A95C93A1264 for ; Fri, 30 Oct 2020 14:40:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sorenson.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 EvvpaT-8-Hg9 for ; Fri, 30 Oct 2020 14:40:47 -0700 (PDT) Received: from NAM11-CO1-obe.outbound.protection.outlook.com (mail-co1nam11on2075.outbound.protection.outlook.com [40.107.220.75]) (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 457BC3A1262 for ; Fri, 30 Oct 2020 14:40:47 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=OgKus9qXE2UDNGM5U1Qpa+Lf15WkjYKaKxnUl127/LpI81ggBomZtefY0bJdGejDTVkpq020ylP2c8m95rM2kLiqMqxRZje1cafb6zuzw8jZyR/G9YHfhvlaCSyLnYVsTTZ7sziBEDi5v+hbV5Eoj2LrtWT3QAflBz34rhGaEZpa6FPBQQEA91g80mqg+lPCdI/FVKsXEgtSwZ9p4WSwpspitIHXiFca9DIj/QUqqwstqNocYVgdu7xG5XmSXscj8CIQ97k/FFqwNaRBTvhsfEvnnn7SEstL4STTQnhTTw1e6h5qtFjIaXaq/U/4FABgAhemVxivww1wwWx3zCVyYQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=7c6YaQJR7uydIBJ+pKKFPqIeTDP+2eD4hCzn+G7DlzA=; b=Ssl5cPv3wGcqQtEw8QwbfUQEsrSrLNtTcbwBY9pQEPpawO3mOMiZoJN8mghdLk7VDiL/4pP9ipfn/oViJjPlbtIBFYK4+4Fav7vYcV5ojvBkGKWvWvqazoWIwDVFadGFmG5iGSpUB1wyl2EjtAW/Js0D8e1is3lE3QcjpmphQhyT4BRz6g3k74n7G8qLESyOANy32XkWxbU+Xp62ABRy0VJmOmON+ZajlBAcw30SToCqKl+6Dskj/3+gEhXFy337WdvZfcOyENHcgCFFALxCoWQfwKhWn020if9C4ev0auzYsiNcHaZQGItSo1HBNsIqoFFhV3xVHcOeRsfCcqAydQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=sorenson.com; dmarc=pass action=none header.from=sorenson.com; dkim=pass header.d=sorenson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sorenson.onmicrosoft.com; s=selector2-sorenson-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=7c6YaQJR7uydIBJ+pKKFPqIeTDP+2eD4hCzn+G7DlzA=; b=QmciDhpvBkYvicCSK56AWwY8pzFSb49w4DPgYTGSAc5hUWvogKa2dk1qnbFs3DkMYptXY75ENCYlswM9uRM0Obb0Qm9/v/8AwzPmPl5K6wWmmB2yUuK48xpQzGTxZy0uNChYNx+ZztYDHwwcZyueAXmgznT4I9bmjMPVf9nOvMo= Received: from BYAPR04MB4983.namprd04.prod.outlook.com (2603:10b6:a03:41::29) by BY5PR04MB7123.namprd04.prod.outlook.com (2603:10b6:a03:227::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3499.22; Fri, 30 Oct 2020 21:40:46 +0000 Received: from BYAPR04MB4983.namprd04.prod.outlook.com ([fe80::e09a:6be0:ccf6:a8b1]) by BYAPR04MB4983.namprd04.prod.outlook.com ([fe80::e09a:6be0:ccf6:a8b1%7]) with mapi id 15.20.3477.029; Fri, 30 Oct 2020 21:40:46 +0000 From: Eugene Christensen To: Paul Kyzivat , "Olle E. Johansson" , Brian Rosen CC: "rum@ietf.org" Thread-Topic: [Rum] [EXT] RUM security model Thread-Index: AQHWlnxQD9PXpaMUFE6N0jV2IR9mp6mBxBhggAAW2wCAF0rLoIAAMpaAgAAXOoCAAAeJgIAAAV6AgAD5eYCABjafAIAAF2wAgAFtX5CAABXWAIABCTiAgACYEgCADPFHMA== Date: Fri, 30 Oct 2020 21:40:46 +0000 Message-ID: References: <4d6ba97f-a83d-3d36-14a9-c6e84dd5b874@alum.mit.edu> <7A11F680-9EA6-4477-9BD8-6A7755AD0054@brianrosen.net> <7fdb95e6-e954-7275-60f7-462cf07eff0e@alum.mit.edu> <92b5d34b-2fbf-0e2b-8562-8f7d11c5123b@alum.mit.edu> <5e6d8446-c267-5113-aff1-fc87576b1317@alum.mit.edu> <38090A50-6572-4A8E-97D4-C260323365AE@brianrosen.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: alum.mit.edu; dkim=none (message not signed) header.d=none;alum.mit.edu; dmarc=none action=none header.from=sorenson.com; x-originating-ip: [75.146.88.198] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 2b619152-d038-4b43-02b1-08d87d1c75f4 x-ms-traffictypediagnostic: BY5PR04MB7123: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6430; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: I+FmNYgL8uPvD5gR0/IKHCGxEQzJP1rIAjflWDshnCuKWC59HwXFlInpB3Z29katRlpnaLKYPuTx7U5p2R4JPRCLIZtPNVQpEDIp/Rr/PRONyj7zX0wYQDTAqfEx1qnIyQZAOxw0Il0/ZrdQtATxdgKUUaMB3lbkYdEEhLv4Ozlq/Oeqj/6sN5v1wyk5ndOwzZ0+7hB9HLbEWC54XsE7dr5M1vGvqcxa820ehki86o+Xb/IoY9umBcw3oCFUCtCPPb0pFjCVxpzitYtHu2Ror5lCPmLOVNl36S5KdU62SlSrE8ReLcbyo2rQn9EhhGs4 x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BYAPR04MB4983.namprd04.prod.outlook.com; PTR:; CAT:NONE; SFS:(366004)(396003)(39850400004)(136003)(346002)(376002)(316002)(5660300002)(33656002)(4326008)(9686003)(478600001)(55016002)(15650500001)(71200400001)(8936002)(66446008)(8676002)(64756008)(66946007)(66476007)(66574015)(110136005)(6506007)(2906002)(86362001)(66556008)(76116006)(186003)(52536014)(53546011)(83380400001)(7696005)(26005); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: aJM/RdXO6qXMHT0LhcBC2A+kaIA4u++Ds0UjY51RmHNmcsyq4clYGPfNawZXGTKqP3tjkjuMSog5jzAhEh5gUW7JbJe8Q66joCNJfBP+YvHPthbrdhX+oPOKROu86/ioVtFB+4NF/P46v1lryKLhlOCdDq6GIFyRAiwAw2SKJ7rEx18s5GujiNzn+I3rdvyT3axVs/6YZ433rqSnsxOB+PbulQACQfNSPiJ/9rR9DzDqZ2tfzYRmVgJhtLa7QCCu1drgQJmBtvu3GpKmgFahDNaryrktf3+16ptYnVrrthQqOjyd9Nw1lFtcFfxjaDWW2c7gNWbpYiuojCXHl5+YZ+BVTsmIoOnZrYIadf8WZhRSj+Ua9EJ+5pYJN32maRWdFOeoQWJ3zj9y1mQHGuai/K4fsI7ljSHu55A59HRblxwj93YxrNTcLaOOCmv92fISNICYD27uY08F+JEhSPfrb6EoKEu1pgLOTAWbuujPspfMISfqybnrQVbnYjrb+08k09G+AobKXMQwUNGqSBnFA8YT+503T3+z6wpRRj2QYzESwiMIMQ5bJEh42iHiq7uIPlq0qEfIqcER0geYj9cEjVjo3mn3LTQF3KlZRDdP4C2MTCZqtrLvU5Vwji/9gG2R63wQpGGDIGjh7QKmT3rYSQ== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: sorenson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BYAPR04MB4983.namprd04.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 2b619152-d038-4b43-02b1-08d87d1c75f4 X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Oct 2020 21:40:46.3437 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 6b03ef08-a104-48c4-a951-f18d295428d5 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: Y/SONIQFBfDaKB+OZPVlL7W5vjC4uXCGzrn6PeNXISZvaoKOgmXqS3mq/x7+K+UcYZpOiXjxsjWNDetxqUhNPmGMKuoJ+5IIDQilzsR+nXw= X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR04MB7123 Archived-At: Subject: Re: [Rum] [EXT] RUM security model X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2020 21:40:49 -0000 VGhlcmUgaGFzIHRvIGJlIHNvbWUgYW1vdW50IG9mIHRydXN0IGJldHdlZW4gdGhlIHByb3ZpZGVy cyBzbyBJIHRoaW5rIHdlIHNob3VsZCBjb25zaWRlciB0aGUgdXNlIG9mIGFuIEFQSSBrZXkgZm9y IGFjY2VzcyB0byB0aGUgcHJvdmlkZXIncyBjb25maWd1cmF0aW9uIHNlcnZpY2UuICBJZiBhbiBB UEkga2V5IGlzIGdpdmVuIGFuZCBhbm90aGVyIHByb3ZpZGVyIGFidXNlcyB0aGF0LCBpdCBvYnZp b3VzbHkgY291bGQgcmVzdWx0IGluIHNvbWV0aGluZyBiYWQgYnV0IGl0IGNvdWxkIHF1aWNrbHkg YmUgcmV2b2tlZCBieSB0aGUgcHJvdmlkZXI7IHJpZ2h0PyAgQW5kIHRoZSBjb21wYW55IHRoYXQg aGFzIGFidXNlZCBpdCB3aWxsIGxpa2VseSBub3QgYmUgdHJ1c3RlZCBpbiB0aGUgZnV0dXJlICht b3RpdmF0aW9uIGZvciBtYWludGFpbmluZyB0cnVzdCkuDQoNCldvdWxkIGl0IGFsc28gYmUgd2lz ZSB0byB1c2UgYSBjbGllbnQgY2VydGlmaWNhdGUgZm9yIFNJUCBjb21tdW5pY2F0aW9ucyBvbmNl IHRoZSBSVUUgaGFzIHRoZSBuZWNlc3NhcnkgaW5mbyBmcm9tIHRoZSBjb25maWd1cmF0aW9uIHNl cnZpY2U/ICBUaGUgY2xpZW50IGNlcnRpZmljYXRlIGNvdWxkIGJlIGVtYmVkZGVkIGludG8gdGhl IGFwcGxpY2F0aW9uLg0KDQpJcyB0aGVyZSBhbnkgcmVhc29uIHdlIGNhbm5vdCB1c2UgbGFuZ3Vh Z2UgdGhhdCBtYWtlcyB0aGUgdXNlIG9mIHRoZSBBUEkga2V5IGFuZCBjbGllbnQgY2VydGlmaWNh dGUgb3B0aW9uYWwsIGF0IHRoZSBkaXNjcmV0aW9uIG9mIHRoZSBwcm92aWRlcj8gIChlLmcuIFRo ZSBwcm92aWRlcnMgTUFZIHJlcXVpcmUgYW4gQVBJIGtleSBmb3IgdGhlaXIgY29uZmlndXJhdGlv biBzZXJ2aWNlIGFuZC9vciBhIGNsaWVudCBjZXJ0aWZpY2F0ZSBmb3IgU0lQIGNvbW11bmljYXRp b25zKS4NCg0KVGhhbmtzLA0KDQpFdWdlbmUuDQoNCkNPTkZJREVOVElBTElUWSBOT1RJQ0UuIFRo aXMgZS1tYWlsIHRyYW5zbWlzc2lvbiwgYW5kIGFueSBkb2N1bWVudHMsIGZpbGVzIG9yIHByZXZp b3VzIGUtbWFpbCBtZXNzYWdlcyBhdHRhY2hlZCB0byBpdCwgbWF5IGNvbnRhaW4gY29uZmlkZW50 aWFsIGFuZCBwcm9wcmlldGFyeSBpbmZvcm1hdGlvbi4gSWYgeW91IGFyZSBub3QgdGhlIGludGVu ZGVkIHJlY2lwaWVudCwgb3IgYSBwZXJzb24gcmVzcG9uc2libGUgZm9yIGRlbGl2ZXJpbmcgaXQg dG8gdGhlIGludGVuZGVkIHJlY2lwaWVudCwgeW91IGFyZSBoZXJlYnkgbm90aWZpZWQgdGhhdCBh bnkgZGlzY2xvc3VyZSwgY29weWluZywgZGlzdHJpYnV0aW9uIG9yIHVzZSBvZiBhbnkgb2YgdGhl IGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiBvciBhdHRhY2hlZCB0byB0aGlzIG1lc3NhZ2UgaXMg U1RSSUNUTFkgUFJPSElCSVRFRC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyB0cmFuc21pc3Np b24gaW4gZXJyb3IsIHBsZWFzZSBpbW1lZGlhdGVseSBub3RpZnkgbWUgYnkgcmVwbHkgZS1tYWls IGF0IGVjaHJpc3RlbnNlbkBzb3JlbnNvbi5jb20gb3IgYnkgdGVsZXBob25lIGF0ICsxICg4MDEp IDI4Ny05NDE5LCBhbmQgZGVzdHJveSB0aGUgb3JpZ2luYWwgdHJhbnNtaXNzaW9uIGFuZCBpdHMg YXR0YWNobWVudHMgd2l0aG91dCByZWFkaW5nIHRoZW0gb3Igc2F2aW5nIHRoZW0gdG8gZGlzay4N Cg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFBhdWwgS3l6aXZhdCA8cGt5eml2 YXRAYWx1bS5taXQuZWR1PiANClNlbnQ6IFRodXJzZGF5LCBPY3RvYmVyIDIyLCAyMDIwIDk6MzQg QU0NClRvOiBPbGxlIEUuIEpvaGFuc3NvbiA8b2VqQGVkdmluYS5uZXQ+OyBCcmlhbiBSb3NlbiA8 YnJAYnJpYW5yb3Nlbi5uZXQ+DQpDYzogRXVnZW5lIENocmlzdGVuc2VuIDxlY2hyaXN0ZW5zZW5A c29yZW5zb24uY29tPjsgcnVtQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW1J1bV0gW0VYVF0gUlVN IHNlY3VyaXR5IG1vZGVsDQoNCltFWFRFUk5BTF0gDQoNCk9uIDEwLzIyLzIwIDI6MjkgQU0sIE9s bGUgRS4gSm9oYW5zc29uIHdyb3RlOg0KDQpbc25pcF0NCg0KPj4gQnJ1dGUgZm9yY2UgYW5kIERE b1MgYXR0YWNrcyBjYW7igJl0IGJlIGFkZHJlc3NlZCBieSB0aGlzIGRvY3VtZW50IGV4Y2VwdCBp biB0aGUgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbiBzZWN0aW9uLiAgVGhleSBhcmUgaW1wbGVtZW50 YXRpb24gaXNzdWVzLg0KPiBJZiB0aGVyZSBhcmUgc3BlY2lmaWMgYXR0YWNrIHZlY3RvcnMgdG8g UlVNIHRoYXQgZG9lc27igJl0IGFwcGx5IHRvIFNJUCBpbXBsZW1lbnRhdGlvbnMgaW4gZ2VuZXJh bCwgeWVzLg0KDQpBRkFJSyB0aGVyZSBzaG91bGQgYmUgbm90aGluZyBzcGVjaWFsIGFib3V0IFZS UyB0aGF0IG1ha2VzIGl0IGFueSBtb3JlIHZ1bG5lcmFibGUgdG8gYXR0YWNrIHRoYW4gYW55IG90 aGVyIHNpcCBzZXJ2aWNlIGFjY2Vzc2VkIG92ZXIgdGhlIHB1YmxpYyBpbnRlcm5ldC4NCg0KSSdk IGxpa2UgdG8gaGVhciBmcm9tIHRoZSBwcm92aWRlcnMgaWYgSSBhbSB3cm9uZyBhYm91dCB0aGlz Lg0KDQoJVGhhbmtzLA0KCVBhdWwNCg==