Re: [Teep] Working Group Last Call for draft-ietf-teep-architecture

"Konda, Tirumaleswar Reddy" <TirumaleswarReddy_Konda@McAfee.com> Tue, 07 January 2020 06:38 UTC

Return-Path: <tirumaleswarreddy_konda@mcafee.com>
X-Original-To: teep@ietfa.amsl.com
Delivered-To: teep@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5A71120091 for <teep@ietfa.amsl.com>; Mon, 6 Jan 2020 22:38:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.99
X-Spam-Level:
X-Spam-Status: No, score=-1.99 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mcafee.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 UFd95vFjpOAk for <teep@ietfa.amsl.com>; Mon, 6 Jan 2020 22:38:52 -0800 (PST)
Received: from us-smtp-delivery-140.mimecast.com (us-smtp-delivery-140.mimecast.com [63.128.21.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B497E12001B for <teep@ietf.org>; Mon, 6 Jan 2020 22:38:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=mimecast20190606; t=1578379130; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=QCNq4nn9b6KaXAY7Fw47K616Un1MTePiFjTl2RXAzdw=; b=dKa4mYbfb1NFuxR2HvHRnnbQ+zL8zjQy0Z914q/G4GN8YK34rhmomr1L/tnsMeYKaydGYJ /MI0F/f/yFxlhmShhX5IVCA9x4KTp5d7Vu3ZrT54o7t6+u++ht8MuQHdWZuEECFQUlK37p dKVQZXY1f3C6x63tC+F9iMRrWqg4fc8=
Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02lp2051.outbound.protection.outlook.com [104.47.38.51]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-380-FUPAHjO1NH28CV-cE5HbTg-1; Tue, 07 Jan 2020 01:38:47 -0500
Received: from CY4PR1601MB1254.namprd16.prod.outlook.com (10.172.118.12) by CY4PR1601MB1112.namprd16.prod.outlook.com (10.172.117.10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2602.12; Tue, 7 Jan 2020 06:38:44 +0000
Received: from CY4PR1601MB1254.namprd16.prod.outlook.com ([fe80::a50e:f380:4d5e:71ea]) by CY4PR1601MB1254.namprd16.prod.outlook.com ([fe80::a50e:f380:4d5e:71ea%6]) with mapi id 15.20.2602.015; Tue, 7 Jan 2020 06:38:44 +0000
From: "Konda, Tirumaleswar Reddy" <TirumaleswarReddy_Konda@McAfee.com>
To: Dave Thaler <dthaler@microsoft.com>, "teep@ietf.org" <teep@ietf.org>
Thread-Topic: Working Group Last Call for draft-ietf-teep-architecture
Thread-Index: AdW5iepOELmpRRFXSAWsc0EhHQP19ALfbySAAAc0BIA=
Date: Tue, 07 Jan 2020 06:38:44 +0000
Message-ID: <CY4PR1601MB125400678B0DA9EE37683FBBEA3F0@CY4PR1601MB1254.namprd16.prod.outlook.com>
References: <CY4PR1601MB1254CD83B0DAADAA67A54CF3EA2E0@CY4PR1601MB1254.namprd16.prod.outlook.com> <BL0PR2101MB10278417515DEF077714D693A33F0@BL0PR2101MB1027.namprd21.prod.outlook.com>
In-Reply-To: <BL0PR2101MB10278417515DEF077714D693A33F0@BL0PR2101MB1027.namprd21.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Owner=dthaler@ntdev.microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2020-01-07T03:14:02.9467153Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Application=Microsoft Azure Information Protection; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=113fc599-cef6-4df9-bb00-5e0a626ea5d7; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic
dlp-product: dlpe-windows
dlp-version: 11.4.0.45
dlp-reaction: no-action
x-originating-ip: [49.37.206.28]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: cac19ac2-e1db-4f58-4df3-08d7933c3e42
x-ms-traffictypediagnostic: CY4PR1601MB1112:
x-microsoft-antispam-prvs: <CY4PR1601MB11129DD9BB8075D3767F1464EA3F0@CY4PR1601MB1112.namprd16.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:8882;
x-forefront-prvs: 027578BB13
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(376002)(136003)(346002)(366004)(39860400002)(396003)(53754006)(32952001)(199004)(189003)(8676002)(81166006)(64756008)(71200400001)(7696005)(45080400002)(8936002)(76116006)(66946007)(81156014)(26005)(66476007)(21615005)(186003)(66556008)(66446008)(478600001)(33656002)(66574012)(52536014)(9686003)(55016002)(2906002)(966005)(86362001)(316002)(110136005)(53546011)(6506007)(5660300002)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:CY4PR1601MB1112; H:CY4PR1601MB1254.namprd16.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: hLBivJ7ZFZxsvoK4pimJGXvpUjowS9XXCM0XculBdJCGZUnVdEIoibphHYH3/OAs/Rr7IQPvZWm7Z6scGsAVIyxVvTppDUQ30He58Zfni0TK+gshI3iFbkoaisaJquXOB5Se2acZJm7O/KoCa7rQWGCNBQ2bDIV0dvbsnoKpJNCrJoH+bW6XmftHc6c1ySVEY0tMLfOF6riVJNyklPO10mH9T1j9Htr8h5ZnU2qvut6M50HoEE/YBe6HQjRrvZ/MRBzkD7qFHbrgIqGF4p7YWWws2Vr/Fm4d0HsgoT5hXkTaIvRGZrCVmUUHUN/FdzfRlfsMn8ijKMLYwfe3thvFVhh3lM3F0ybmsFunt6Xs7cRbfEfngXG3i1zwK+v9B+zWrjW68xwpD4bSbebLCg4VHvks47U/+n6QVzLik/K6dFBomGfxlI8NdjUfTkDcD/Xy60KdTseG9AC8ZPh+QXQ9m+xjNMNHosufD4Acwk8hBqG9iSS8khiwrlexUa6AnGP3aTBgmfuefQCIkD0FwJvYfhRZ4oDQ8JwQb20RcxvanaHl8e4FXJuINWgQgWWPr2CmxopG4l4XQt394ao+NOy4Wg==
x-ms-exchange-transport-forked: True
MIME-Version: 1.0
X-OriginatorOrg: mcafee.com
X-MS-Exchange-CrossTenant-Network-Message-Id: cac19ac2-e1db-4f58-4df3-08d7933c3e42
X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Jan 2020 06:38:44.6778 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: Viaf1kY1TLnmsQFXYcne/r1sWn4hs/PWG+t3qWP7eAqMhydqKBX5cOFJBfZjUGDyrXvhQfuY/VYqwmoxEDhHDUNTIg2bSJSo1C9m/mxn/olagW3WfOlknxt4EdYn9vkX
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR1601MB1112
X-MC-Unique: FUPAHjO1NH28CV-cE5HbTg-1
X-Mimecast-Spam-Score: 0
Content-Type: multipart/alternative; boundary="_000_CY4PR1601MB125400678B0DA9EE37683FBBEA3F0CY4PR1601MB1254_"
Archived-At: <https://mailarchive.ietf.org/arch/msg/teep/ajMzxW1nc5vYlgAnpPlXb8LEMWw>
Subject: Re: [Teep] Working Group Last Call for draft-ietf-teep-architecture
X-BeenThere: teep@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A Protocol for Dynamic Trusted Execution Environment Enablement <teep.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/teep>, <mailto:teep-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/teep/>
List-Post: <mailto:teep@ietf.org>
List-Help: <mailto:teep-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/teep>, <mailto:teep-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 07 Jan 2020 06:38:56 -0000

[As an individual]

Hi Dave,



I have reviewed the draft and have comments and nits listed below:



a) It is not clear from the Introduction how TEE is different from a Closed OS like Google Chromebook or Windows 10S ?

     The benefit of Payment application running in Closed OS verses in TEE is not evident from the description. What part of the Payment application runs in the REE and TEE respectively ?

     If biometric identification information is securely stored in TEE for identification, how does the TEE identify the biometric identification information is not retrieved by an malicious agent in the REE.

     Section 3.3 (Internet of things), How does the architecture ensure the sensitive data is retrieved by a legitimate application in the REE and not by an malicious application ?



b) Why should the list of trust anchors on the device be managed by the Device's network carrier ?

     (you may want to define the term "network carrier").



c) If the REE is compromised (for example by malware), it could terminate the TEEP broker in REE. How is this attack mitigated ?



d) What happens if the malicious agent acting as TEEP broker launches attacks (e.g. garbage data, replay attack, DoS of messages etc.,) on the TEEP agent, and how will the TEEP agent defend itself ?



e) The below line is not clear to me:

Enumeration and access to the appropriate TEEP Broker is up to the Rich Execution Environment and the Untrusted Applications.



h) A use case explaining the use of multiple TAM, multiple TEEP brokers on a device, and multiple TEE would be useful to the reader of the specification.



i) When a TEEP Broker receives a request from an Untrusted Application

   to install a TA, a list of TAM URIs may be provided for that TA, and

   the request is passed to the TEEP Agent.  If the TEEP Agent decides

   that the TA needs to be installed, the TEEP Agent selects a single

   TAM URI that is consistent with the list of trusted TAMs provisioned

   on the device invokes the HTTP transport for TEEP to connect to the

   TAM URI and begins a TEEP protocol exchange.



Comment> I am not sure why the architecture draft is discussing the protocol aspects like HTTP for TEEP ?



j) What if the malware in REE instructs the TEEP agent via TEEP broker to keep installing/uninstalling TA (over-whelm the TEEP agent and TEE or installing un-necessary TA to have no memory for the required TA) ?



i) What is the use case for "Personalization data" ?



j) Why is Section 4.5 discussing Case 1 when it not in use ?



k) The below line is not clear to me (please elaborate):

Consequently, a TAM generally communicates with an Untrusted Application about how it gets messages that originate from a TEE inside a device.



l) What is the use case for one TA and multiple SP ?



m) what is the use case for keeping the TA binary secret from the TAM ?



n) We allow a way for an Untrusted Application to check the trustworthiness of a TA.



Comment> You may want to re-phrase the above line, and remove "we".



o) A notification that an incoming TEEP session is being requested by a TEEP Agent.



Comment> What you meant by "incoming TEEP session" ?



p) How does the TEEP broker communicate with the TEEP agent ?



q) Section 5.3 says the architecture uses PKI but Section 9.1 discusses self-signed certificates. Please fix.



r) In Figure 4, for the purpose of "Code signing" my understanding is the location of corresponding CA certs is both TEE and TAM.



s)I have seen several malicious apps in App store in both Android and iOS, it is possible for an malicious App developer to publish both malicious untrusted applications

   and malicious trusted applications.  I don't think the TEEP architecture prevents this attack and it is the responsibility of TAM and App store to remove such apps

    (see https://android-developers.googleblog.com/2018/01/how-we-fought-bad-apps-and-malicious.html)



Cheers,

-Tiru


From: Dave Thaler <dthaler@microsoft.com>
Sent: Tuesday, January 7, 2020 8:44 AM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; teep@ietf.org
Subject: RE: Working Group Last Call for draft-ietf-teep-architecture


CAUTION: External email. Do not click links or open attachments unless you recognize the sender and know the content is safe.

________________________________
I opened one pull request for editorial issues (https://github.com/ietf-teep/architecture/pull/109),
and filed seven other issues listed at https://github.com/ietf-teep/architecture/issues

110) Service Provider discussion is confusing<https://github.com/ietf-teep/architecture/issues/110>
111) Terminology section is not consistently ordered<https://github.com/ietf-teep/architecture/issues/111>
112) Text about carriers is confusing<https://github.com/ietf-teep/architecture/issues/112>
113) Section 6.2.3 contradicts section 4.2<https://github.com/ietf-teep/architecture/issues/113>
114) Figure 3 is too hard to understand<https://github.com/ietf-teep/architecture/issues/114>
115) Reference to IANA number<https://github.com/ietf-teep/architecture/issues/115>
116) Incorrect/obsolete statements about TEEP Broker<https://github.com/ietf-teep/architecture/issues/116>

I have ideas about how to address all of them, but if others have comments, please speak up.

The possibly(?) contentious one might be that in #110 I am proposing to use the term
"App Developer" throughout, instead of using "Service Provider" in some places and "App Developer" in others
and then saying they're synonymous like it does now.   (I'd be ok with mentioning that in some contexts an App Developer
might be known as a "Service Provider" if that is important to GlobalPlatform folks.)

Dave

From: TEEP <teep-bounces@ietf.org<mailto:teep-bounces@ietf.org>> On Behalf Of Konda, Tirumaleswar Reddy
Sent: Monday, December 23, 2019 4:17 AM
To: teep@ietf.org<mailto:teep@ietf.org>
Subject: [Teep] Working Group Last Call for draft-ietf-teep-architecture

Hi all,

This message starts a Work Group Last Call (WGLC) for TEEP architecture.  The version to be reviewed is https://tools.ietf.org/html/draft-ietf-teep-architecture-05<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-teep-architecture-05&data=02%7C01%7Cdthaler%40microsoft.com%7C88bfc467b880468e461e08d787a2196d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637127002642640827&sdata=aallqAzJH3MqV2bbzMzwvD3OXhpRFyPJVHeaWye4x40%3D&reserved=0>

The WGLC will last for 4 weeks and will end on 20 January 2020.

Please send your comments to the list before this date and your assessment of whether or not it is ready to proceed to publication.

Regards,
Tiru & Nancy