Re: [Teep] draft-tschofenig-teep-otrp-v2-00

Anders Rundgren <anders.rundgren.net@gmail.com> Tue, 09 July 2019 15:48 UTC

Return-Path: <anders.rundgren.net@gmail.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 801ED12063F for <teep@ietfa.amsl.com>; Tue, 9 Jul 2019 08:48:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.703
X-Spam-Level:
X-Spam-Status: No, score=-0.703 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, PDS_NO_HELO_DNS=1.295, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 OinQewK704pe for <teep@ietfa.amsl.com>; Tue, 9 Jul 2019 08:48:46 -0700 (PDT)
Received: from mail-lf1-x132.google.com (mail-lf1-x132.google.com [IPv6:2a00:1450:4864:20::132]) (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 3E50912063B for <teep@ietf.org>; Tue, 9 Jul 2019 08:48:46 -0700 (PDT)
Received: by mail-lf1-x132.google.com with SMTP id s19so13049721lfb.9 for <teep@ietf.org>; Tue, 09 Jul 2019 08:48:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=3PAimWLM6Z0yC06i9Gwc8IB8P/ZjL20kR7YdY158qnE=; b=PoR4u8KsF+C1dHKMuwYrCFwJgUc9HdGNGiPlCFRnL3avJb5rYo3yxYE/JTV89cdKNp nC18aW0JVfQ0CnR+Din4xQapqyJ7Y598Sn4cOE0CFh6vdQ2/5ZrFnLA+N647vdbm1mCR dQ1ZqS6TJz4gVFCtZ0qQT9EqBfwFjZSYpaGvxHlZ4XatzeRyuHBojgczzixKUB5lBNqD s3I/N6gJmn8aCaJLSWNb5IyMhGEP9dttQE3QRwIeIv63Pwey5vVpn3rBrNNogaLMY00g ovUTRzhC3WauLAcQJ/5PbZVnvn3zecHYOuu+wE19pXjkHXSeef0sb6MIj63sd6ROS+fb HBDQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=3PAimWLM6Z0yC06i9Gwc8IB8P/ZjL20kR7YdY158qnE=; b=K85lcM10uFmcd64f0oYYi2e2PoDsXQyuXqxuQQCwtiqu4LySz02zwoM0iTOC5hd/n5 LzUmolj0GI0Lt0OOUX1jsohu4i4HE8Oi/0ER/DsjOMGEQjwt8orIFc6ncWwYwhExJQ0r taEjoSIDiQiauMqZqUPvBH+yqBf08AK2T5Xga957i+X1rqGnLf6xk13xaZnVZ2t495l2 OPAGVfIHSVwIbltaqiMN8jj/3+i2QSqxy97hOt7hfNfg4MIcvu1hRb7Xo+L33uF6+ghk 9MxtXjLPp1rD6Stm/gOnRGOX8JtTfrFraG8b/GdmTmm9WQrJRgyF2SYHB0vMQQxd6k/l Ks8Q==
X-Gm-Message-State: APjAAAXdMDKvuiMH9sFEsB319FwllAcsx63Ezvk1nkvb9w2mYLxnj6oI U0F+e7pSHOuJcDJem1gUwmqYlsg1HCQ=
X-Google-Smtp-Source: APXvYqx8KiAl4Ef8koDCTVuBbZaI87xaxe0mo7B0zs8SEFjNi7i3TEJQSfYdVbwBQB+qXNhTRL/whg==
X-Received: by 2002:ac2:4d1c:: with SMTP id r28mr11586571lfi.159.1562687323902; Tue, 09 Jul 2019 08:48:43 -0700 (PDT)
Received: from [192.168.0.101] (212-107-132-189.customers.ownit.se. [212.107.132.189]) by smtp.googlemail.com with ESMTPSA id 24sm4963417ljs.63.2019.07.09.08.48.42 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 09 Jul 2019 08:48:43 -0700 (PDT)
To: Hannes Tschofenig <Hannes.Tschofenig@arm.com>, "teep@ietf.org" <teep@ietf.org>
References: <VI1PR08MB536037A16BACD104800B358FFAF10@VI1PR08MB5360.eurprd08.prod.outlook.com> <da0a237b-58ed-ffc7-02c2-ca00d1797955@gmail.com> <VI1PR08MB5360540D41C46C07015302E4FAF10@VI1PR08MB5360.eurprd08.prod.outlook.com> <edb1abf1-9f76-f5ad-5aaf-8480efe8718d@gmail.com> <VI1PR08MB536027C1ECB8DF85F3727880FAF10@VI1PR08MB5360.eurprd08.prod.outlook.com>
From: Anders Rundgren <anders.rundgren.net@gmail.com>
Message-ID: <76656d88-5bfb-17fb-a1db-204e88746d2f@gmail.com>
Date: Tue, 09 Jul 2019 17:48:39 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.7.2
MIME-Version: 1.0
In-Reply-To: <VI1PR08MB536027C1ECB8DF85F3727880FAF10@VI1PR08MB5360.eurprd08.prod.outlook.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/teep/SlzztgjBnHsFQpo7DwGssFMyrd8>
Subject: Re: [Teep] draft-tschofenig-teep-otrp-v2-00
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, 09 Jul 2019 15:48:49 -0000

On 2019-07-09 16:41, Hannes Tschofenig wrote:
> Let's look at a specific example,

That's the way to go :-)

> the QueryRequest message:
> 
>     QueryRequest = (
>          TYPE : int,
>          TOKEN : bstr,
>          REQUEST : [+data_items],
>          ? CIPHER_SUITE : [+suite],
>          ? NONCE : bstr,
>          ? VERSION : [+version],
>          ? OCSP_DATA : bstr,
>          * $$extensions
>     )

It would not make much sense doing a direct translation because in the session based scheme lots of data is exchanged in the initialization phase and does not need to be repeated.

The (not shown) Msg_AuthEnc_Wrapper would for example become redundant.

> 
> What does it mean to separating the API from the protocol?

It for example means that you can aggregate API calls protocol-wise.  In my particular case it also enables the provisioning proxy running in the REE to perform some additional tasks but that probably does not apply to TEEP scenarios.


> I believe the NONCE, the OCSP_DATA, the TOKEN, the REQUEST and the CIPHER_SUIT need to be made available to the OTrP Agent running inside the secure world to make some meaningful decisions.
Most likely TOKEN, CIPHER_SUITE, NONCE and VERSION would not be needed because they are already better dealt with during session creation.


 > This data has to be encoded somehow.

Right, all data needs to be encoded but the API would only bother about a single encoding which I believe would be binary and CBOR-encoded blobs in most cases.  MACs only operate on the raw API data.


> In that list the only item that is missing is the TYPE and it would have to be mapped into an API to make sense.

Yes, TYPE is the API method.


> The issue is: there is not much of a protocol left in the current design that can be terminated outside the secure world without making the computations in the secure world meaningless.

Well, the intent at least is not terminating any secure operation outside the secure world.

Anyway, a transformation of a static scheme into a session-based ditto certainly isn't something you can do in one day since it might spill back on the architecture as well.

I leave it there, but anybody is free pinging me anytime on this topic.  Session-based provisioning rocks!

Best
Anders


> 
> Ciao
> Hannes
> 
> -----Original Message-----
> From: Anders Rundgren <anders.rundgren.net@gmail.com>
> Sent: Dienstag, 9. Juli 2019 16:26
> To: Hannes Tschofenig <Hannes.Tschofenig@arm.com>; teep@ietf.org
> Subject: Re: [Teep] draft-tschofenig-teep-otrp-v2-00
> 
> On 2019-07-09 15:59, Hannes Tschofenig wrote:
>> Hi Anders,
>>
>>> A wise decision!  BTW, I never understood the point making an IETF copy (it was?) of another standard.
>>
>> Actually, it was the other way around.
> 
> Thanx, I didn't know that.
> 
>>
>>> I have said it before and I say it again: By separating the API from the Protocol and rather use a session-based scheme you get a cleaner and more powerful system [*] in the end.  Yeah, the initial task will be 30-50% bigger but that difference is zeroed out when you have both protocol encodings in place.
>>
>> "Executive Level" description: https://cyberphone.github.io/doc/research/session-based-remote-attestation.pdf
>>
>> Certainly a good point but I fear that it is not really design a secure system when the protocol does not terminate the secure world.
> 
> Every step of the protocol is supposed to be secured through MAC signatures.  If the protocol doesn't obey the API (which is running in the secure world [*]), the session terminates and the accumulated operations are rolled back.
> 
> Verifying my claims regarding the security of this scheme is non-trivial but it is not entirely different to TLS which you are an expert on.
> 
> Regards,
> Anders
> 
> *] potentially extending into a security processor doing all cryptographic operations based on encrypted key material.
> 
>>
>>
>> Ciao
>> Hannes
>>
>> IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
>>
> 
> IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
>