[saag] idevid-considerations at -- SecDispatch/IETF108

Michael Richardson <mcr+ietf@sandelman.ca> Thu, 06 August 2020 03:35 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id F1FC03A0DC9; Wed, 5 Aug 2020 20:35:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
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=unavailable autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id uhZRs6MvVBI9; Wed, 5 Aug 2020 20:35:03 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B46F63A0DCA; Wed, 5 Aug 2020 20:35:02 -0700 (PDT)
Received: from localhost (localhost []) by tuna.sandelman.ca (Postfix) with ESMTP id 00C6B389AA; Wed, 5 Aug 2020 23:14:21 -0400 (EDT)
Received: from tuna.sandelman.ca ([]) by localhost (localhost []) (amavisd-new, port 10024) with LMTP id r2qNV-yGByKc; Wed, 5 Aug 2020 23:14:19 -0400 (EDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 68A3F389A9; Wed, 5 Aug 2020 23:14:19 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id A669C63E; Wed, 5 Aug 2020 23:34:58 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: "saag\@ietf.org" <saag@ietf.org>, t2trg@irtf.org, secdispatch@ietf.org
CC: Leif Johansson <leifj@mnt.se>, Robin Wilton <wilton@isoc.org>
In-Reply-To: <47C264DC-D59D-49E8-B087-BAF0E23527DD@ericsson.com>
References: <47C264DC-D59D-49E8-B087-BAF0E23527DD@ericsson.com>
X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature"
Date: Wed, 05 Aug 2020 23:34:58 -0400
Message-ID: <17177.1596684898@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/saag/hozdb0y-eLEIyYMxYMZefXd9iew>
Subject: [saag] idevid-considerations at -- SecDispatch/IETF108
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Advisory Group <saag.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/saag>, <mailto:saag-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/saag/>
List-Post: <mailto:saag@ietf.org>
List-Help: <mailto:saag-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/saag>, <mailto:saag-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 06 Aug 2020 03:35:05 -0000

Francesca Palombini <francesca.palombini=40ericsson.com@dmarc.ietf.org> wrote:
    > The SECDISPATCH WG met on Thursday July 30.  The agenda items were dispatched as follows:

    > (1) IDevID considerations (Michael Richardson)
    > * specification: https://tools.ietf.org/html/draft-richardson-secdispatch-idevid-considerations-00
    --> Needs vendor involvement - get more people from the industry and then
    > possibly bring it back.

Hi, so I heard the feedback strongly to go talk to more
industrial/manufacturing types.

It was also suggested that T2TRG would welcome it.

with a possible title of:
  A Toxonomy of Operational Security of manufacturer installed keys and anchors

A pointer was sent me about RFC6711:
   An IANA Registry for Level of Assurance (LoA) Profiles

This might be fine as a place to store/reference the palette of mechanisms,
but it does not, I think, help in creating the content of each palette.

It references: http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-assurance-profile.html
But, I didn't quite understand it.  I think that it's about communicating between
verifiers and relying parties, the degree to which the verifier has validated
the identity of a SAML Identity.

Kantara Initiative Identity Assurange Framework (KIIAF) was referenced, and
Kantara Initiative was also mentioned by private message during secdispatch.
Kantara is, as far as I can understand, a conformity assessment and assurance
entity, which works against NIST 800-63-3.
I hope to have further conversations with them.

So, going to that NIST document, which was also mentioned:

This document has a lot of commonalities, but yet it is not about how keys
are protected.  It is about how to communicate about the confidence an entity
has about the identities it is asserting.  It is "Identity Proofing" for humans.

Now, NIST SP 800-63B _Authentication and Lifecycle Management_, has lots and
lots of good stuff.  Nothing that says how to evaluate how many intermediate
CAs are appropriate when issuing certificates to put into the hardware authenticators.

It's clear that this document is relevant to a manufacturer who might need to
consider how to authenticate and authorize access to private keys.  For
instance, AAL2 (maybe even AAL3) is probably appropriate for access to the
signing key for a software update.  (There is an interesting recursive
element here where where cryptographic authenticators are used...)

NIST Special Publication 800-63C: _Digital Identity Guidelines: Federation and Assertions_
deals in SAML, OpenID Connect, and Kerberos, at the level of assertions, not
keys.  Really nice diagrams.

Michael Richardson <mcr+IETF@sandelman.ca>ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-