Re: [Rats] Requesting a Nonce from a Verifier

Henk Birkholz <henk.birkholz@ietf.contact> Tue, 27 February 2024 14:35 UTC

Return-Path: <henk.birkholz@ietf.contact>
X-Original-To: rats@ietfa.amsl.com
Delivered-To: rats@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C149C14CE40 for <rats@ietfa.amsl.com>; Tue, 27 Feb 2024 06:35:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.196
X-Spam-Level:
X-Spam-Status: No, score=-2.196 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, NICE_REPLY_A=-0.091, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ietf.contact
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vH9CR1hhkHV2 for <rats@ietfa.amsl.com>; Tue, 27 Feb 2024 06:35:03 -0800 (PST)
Received: from smtp06-ext.udag.de (smtp06-ext.udag.de [62.146.106.76]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 667F6C14F5EB for <rats@ietf.org>; Tue, 27 Feb 2024 06:35:03 -0800 (PST)
Received: from [192.168.39.0] (115x125x248x126.ap115.ftth.ucom.ne.jp [115.125.248.126]) by smtp06-ext.udag.de (Postfix) with ESMTPA id 6B61CE0150 for <rats@ietf.org>; Tue, 27 Feb 2024 15:35:00 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ietf.contact; s=uddkim-202310; t=1709044501; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=5YRvb+oT8lxZGOc1gfCx7dhIV1jsEsze47wwoIoAt6U=; b=IsmALIiJh20KZvqRczpI/W0UiSlrE1NEG0kPzEJXflniS5/GLgiwC8B/FpH5qy9alNbH4b ubQM4/Q3ITGTFhwPAh12mLClBwCRN9KTjHGujL2X2qKWmuqv0O/nrgbb06g2HqjydhEhDb W9aRjdd6kfK9SokcmZEURBOpkteoa3c3L5UVlZJzRmHrEYMUCP0/ydd85Ig51Z1QFtuDqL TQzqLbfrdjeFRxMQRnCOp04n9BKDbPymigzszcMHI5/3kYI/nzbXc300lA9pS13rYTvnnP I02P4RpTB2tZ6gfVH/JDMRHJnlLogeTviho5lavxfA26FRf4AJuRbptAQkropA==
Message-ID: <ecf9ac86-82f2-80b7-160a-bdde42387ef0@ietf.contact>
Date: Tue, 27 Feb 2024 15:34:57 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.11.0
Content-Language: en-US
To: rats@ietf.org
References: <02c501da6987$d2d64490$7882cdb0$@gmx.net>
From: Henk Birkholz <henk.birkholz@ietf.contact>
In-Reply-To: <02c501da6987$d2d64490$7882cdb0$@gmx.net>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Authentication-Results: smtp06-ext.udag.de; auth=pass smtp.auth=henk.birkholz@ietf.contact smtp.mailfrom=henk.birkholz@ietf.contact
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/_QmqjieQLyRBm5gH6Da7p0inRh0>
Subject: Re: [Rats] Requesting a Nonce from a Verifier
X-BeenThere: rats@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Remote ATtestation procedureS <rats.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rats>, <mailto:rats-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rats/>
List-Post: <mailto:rats@ietf.org>
List-Help: <mailto:rats-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rats>, <mailto:rats-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 27 Feb 2024 14:35:07 -0000

Hi Hannes,

I am in a weird TZ offset, so just a quick reply.

On 27.02.24 15:18, hannes.tschofenig=40gmx.net@dmarc.ietf.org wrote:
> Hi all,
> 
> Hendrik and I have been working on an update of the CMP/EST extensions, 
> which allow an Attester to request a nonce via the Relying Party (in the 
> background check model). This “nonce draft”, see 
> draft-tschofenig-lamps-nonce-cmp-est, aims to provide freshness for the 
> CSR attestation draft (see draft-ietf-lamps-csr-attestation).

Why focus on a nonce for a combination of recentness and freshness, when 
you could also use an epoch marker?

> 
> We have been wondering about the design of this protocol interface. At a 
> minimum, the attester needs to indicate the length of the nonce being 
> requested from the verifier.

Why? It can cut it short, the Verifier will understand? Are there 
obvious security considerations that I am missing here? The nonce is 
requested via an authenticated channel, I assum?

> EAT, however, supports also an array of 
> nonces in the nonce claim. Should such a protocol interface allow a 
> request for multiple nonces?

Sure, the you do not have to request a nonce for ever interaction and 
the Verifier can keep track.

> Furthermore, the Attester may also need to 
> provide information about the Verifier. This is necessary when there are 
> many Verifiers in the system and not everyone of them might be able to 
> successfully verify the Evidence. Should the request for a nonce also 
> include information about the attestation technology supported by the 
> attester?

Discovery of appropriate Verifier and "requesting nonces" (which kinda 
is still shooting from the back into the eye) are different things. You 
can compose both protocol action, but my initial reply would be: 
Discovery, Feature negotiation, and then epoch marker requests are quite 
different things.

> 
> We thought that this type of foundational feature is described in detail 
> in one of the RATS working group documents and the 
> draft-ietf-rats-reference-interaction-models seemed like a good starting 
> point for such details. Unfortunately, this document falls short in 
> explaining these types of aspects because it is heavily focused on a 
> specific TPM deployment.

That is bad. Please help us fix that.

> 
> Has someone in the group thought about this aspect already or has 
> otherwise gained experience with this aspect?

Requesting a nonce and therefore taking on the role of a challenger in 
arequest/response interaction model to then get a nonce to provide a 
solicited push of Evidence is bit of a flaky procedure, isn't it?

How do you assure that the recently received nonce is used to convey 
fresh evidence? Is there a timeout? Can you cache it? (like with the 
array of nonces). Why can't the Attester just trigger the Verifier to do 
the challenge/response? That seems a bit more straight forward? Maybe I 
am missing something very obvious here.

> 
> Ciao
> 
> Hannes
> 
> 

Viele Grüße,

Henk

> _______________________________________________
> RATS mailing list
> RATS@ietf.org
> https://www.ietf.org/mailman/listinfo/rats