Re: [Rats] Use case document -05

Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> Tue, 08 October 2019 10:50 UTC

Return-Path: <kathleen.moriarty.ietf@gmail.com>
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 8769D1200F6 for <rats@ietfa.amsl.com>; Tue, 8 Oct 2019 03:50:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 (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 vRZ4E9uHJkQj for <rats@ietfa.amsl.com>; Tue, 8 Oct 2019 03:50:10 -0700 (PDT)
Received: from mail-oi1-x22e.google.com (mail-oi1-x22e.google.com [IPv6:2607:f8b0:4864:20::22e]) (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 0830A1200E7 for <rats@ietf.org>; Tue, 8 Oct 2019 03:50:09 -0700 (PDT)
Received: by mail-oi1-x22e.google.com with SMTP id t84so14344646oih.10 for <rats@ietf.org>; Tue, 08 Oct 2019 03:50:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Y0J2VRrctnTEUx9fgdRRNtSu6czbR62rWvPmjxg1Ilw=; b=MRgQIvhFxP+uJMMBimul7AIKCohk+SIVEHqxm0RZt6YMdgWloG4GXb8fYO0PukbwSG PplTWW8aPL/dakSBXJB3dvNz8FeMtjXXkecPYzRh0sidhaNRpdwaTu8DB4hVepInRv7M dJIMshhnAjmg48ltF7RFA3Jdj8EkyLniyil5BlA5NMZSEzyIF98j/fQ6LT9+/h1jH7hS iiAUcjgNWyNsZF4RaMMrxZbYVamUeXaTNPCP4WGKmkjCztEtBDtc5tq3TKI1Mrs0wVX7 hUNN6H4g0PgoNcojTejQtsUt6K+KmIZ/hC6w/1nwZ6ajsH4InGqV/ytPUUeB33539F1w IICg==
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=Y0J2VRrctnTEUx9fgdRRNtSu6czbR62rWvPmjxg1Ilw=; b=Qil0We9noE49VTSeY8AtNGBNM8yuAWrZ1LHwQvj2rG0PQhW5v2vg9tHLNYswDiu4Of sQj9DRIn3GhuvYJvEpHhHzCQXqowpPauGpRic3QKy8yHhjc7p/Ty2sAQWVgzBCrfE6BE V8Tsna4M8gDuUtn66VozMhCJPvYi2nyincpnK02FIqRurHGHpBpUl/0Zsyr4Nzg0Ug1c BNr9Qr3rfbYXklFxNTsKXEMKgFR/Y8rgEn4l9Jimq/gMfQyZt6yGtjWSKYjSwKuHFQnA +zUx6p5dzbBMVSsBk5rWIbnxRZSpGuBWoR4WTuA6VUapLgw5VXpgrjX1X/H7AzUCt03V 9hBQ==
X-Gm-Message-State: APjAAAXWGWNucLvXG7EfxkF40uFFrRaXK1XriAbLj5ZHq3HT2I+BEGVl hqN6/lnY+7+qly6n2UE4KY7p8kHOQJ7sXnDoeHn8sRr/
X-Google-Smtp-Source: APXvYqwPX99vNwK5qMCCKXLpJbeh1r4/Z0ihqXcXoEc3Fh3fOTrUcxaniyqdwS3sv85tvIoiSyEa1ZaI5XjLffFPJr8=
X-Received: by 2002:a54:4187:: with SMTP id 7mr3328598oiy.158.1570531809055; Tue, 08 Oct 2019 03:50:09 -0700 (PDT)
MIME-Version: 1.0
References: <B07A4355-94CB-4343-9570-63C01A310A37@gmail.com> <24525.1570522873@dooku.sandelman.ca>
In-Reply-To: <24525.1570522873@dooku.sandelman.ca>
From: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>
Date: Tue, 08 Oct 2019 06:49:32 -0400
Message-ID: <CAHbuEH68vHWH8FtxSKotqa__shDc5mne6duw1Ndq5Yd94wsi7w@mail.gmail.com>
To: Michael Richardson <mcr@sandelman.ca>
Cc: rats@ietf.org
Content-Type: multipart/alternative; boundary="000000000000965abb059463eef9"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/37ekx5z0Mr8ibuesnv9_UIy2Vr4>
Subject: Re: [Rats] Use case document -05
X-BeenThere: rats@ietf.org
X-Mailman-Version: 2.1.29
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, 08 Oct 2019 10:50:13 -0000

Hi Michael,

On Tue, Oct 8, 2019 at 4:20 AM Michael Richardson <mcr@sandelman.ca> wrote:

>
> Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> wrote:
>     > I just did a quick review and sent one nit separately before coming
> up
>     > with some more clarification questions/suggestions.
>
>     > Nit in 5.1.4:
>
>     > The
>     > infrastructure is in control of a single operator and is already
> trusted.
>
>     > I think you meant “is in the control”.
>
>     > Otherwise, we are in trouble. :-)
>
> Oh, yes, that is an interesting change in meaning by the loss of an
> article.
> ("I for one, welcome our new skynet overloads")
>
>     > Also, what is being validated?  The running and configured software
>     > from root of trust and/or the software from vendors as provided?
>
> My understanding is that this use case is primarily about the NEA
> situation.
> Desktops have to provide attestation that they are running a valid
> configuration.
>

OK, NEA is about validating software and controls on systems, it requires
an agent to interrogate systems and is too cumbersome for many to deploy
and manage. Here we will be evaluating a JWT or CWT if EAT is used, ideally
leveraging OTrPv2 from TEEP.  There's the attestations that could come from
the state of the running system from the "root of trust", let's say TEE.
Vendors could also provide an attestation on shipped software that relies
upon other software packages as that vendor has tested and is willing to
provide an assurance on.


>     > 5.1.5
>     > Would each system really do the assessments themselves?  Wouldn’t it
> be
>     > easier to have a relying party (management station/repository) of
>     > collected information from each administrative domain?  How do you
>     > scale the interactions in a highly complex data center scenario with
>     > virtualized systems that are also isolating tenants in container
>     > clusters for instance?
>
> okay, let me think about how to rephrase this.
> Individual data centers/buildings would act like 5.1.4, but then would have
> to cross-attest.   That's why the N:1:M process.
> This is the large university with many departments, each of which might
> have
> their own IT standards, or the government with multiple agencies.
>
>     > 5.1.6 - my question above spills into this one.
>     > Also note the typo of having medium in this one.
>
> This is the case where it's every mobile phone in an operator, and many of
> the phones are BYO.
>
>     > 5.5 critical infrastructure
>     > Are you providing protection from malware by only allowing specific
>     > signers or specific attested code  or both forms of white listing?
> Or
>     > something else?  I’m assuming both forms of white listing and it
> would
>     > be good to explain that if it’s the case.
>
> This comes out of the side-meeting, about having some critical system
> (some safety valve, plant-shutdown switch, Starship
> Enterprise-Self-Destruct)
> want to know more about the device sending the critical instruction.
> I'm not sure what it would be.
>
> I can see it invoking much of the FIDO stuff too: making sure that the
> device
> that authenticated the authorizing human was sane.
>
>     > Excellent work on this document!  I think we should formally adopt
> it.
>
> Sure, that's a good idea so that it occupy 1st class WG schedule time.
>

Thank you for your quick response and consideration.
Kathleen

>
> --
> ]               Never tell me the odds!                 | ipv6 mesh
> networks [
> ]   Michael Richardson, Sandelman Software Works        | network
> architect  [
> ]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on
> rails    [
>
>

-- 

Best regards,
Kathleen