Re: [icnrg] recursive key Lookup in CCNX

Marc Mosko <mmosko@parc.com> Mon, 04 May 2020 23:55 UTC

Return-Path: <mmosko@parc.com>
X-Original-To: icnrg@ietfa.amsl.com
Delivered-To: icnrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECA283A12F1 for <icnrg@ietfa.amsl.com>; Mon, 4 May 2020 16:55:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=parc.onmicrosoft.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 Th8ICP8aEvF0 for <icnrg@ietfa.amsl.com>; Mon, 4 May 2020 16:55:00 -0700 (PDT)
Received: from NAM11-BN8-obe.outbound.protection.outlook.com (mail-bn8nam11on2079.outbound.protection.outlook.com [40.107.236.79]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3381B3A12DB for <icnrg@irtf.org>; Mon, 4 May 2020 16:54:58 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=aEZ0OOqsaIPYpgG68VaIK1f7nw8xC4yOE3J09BiuVcc0bqDOllDfgvo/N60XMvKXNyl988osP6DR6aLm25gD22MPG8lndmjdVB17Y88IiDpIxJVOuazhr9vsbGy7oYLAbs0SpkBKFwD9TrrpNKf5TxHwwZMv/maG4Gu7nsMHFimlrxe5d0MJ3T2/Nix6c7kjTEjumfdgis8sEtPUXDm+PmP4gZ5yw0sKXcOGDtPlysugxaWmsiJHTZznOKK7pWj0+Rzct33WAnEyUj7PXMoeGPbx7jndGl4ns6dPvPpV4e6vvU51Yl2+2pcvkET+82eoGOGf81ozU2Wpw4AODh72UA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=vrFSYSHbCY5AU8oq54ue3aLX9oTk2u7Gn9bDcwmWupA=; b=BwVYc+6oGCFlmVBNv53H+I7e+yfzk6/0eNtn50lqLAMVjnEDrDAn4KQnReqdU1u8QxDVs9WW3MjpYsPQxMWpb3iQXjDK6XdiSriJZEs8x6LnEDFpKYOeJ3eFUVSSxM0f+xhwrw8T/WdK912HF8xVbxcIT6KKHOiBN3Vt8pNgZOXjUWdEau2wVt1IGF6W+5GJq5Vfip8k3BUnASnsyu4cMOV3+/qV72QqEddHKn+ThY529SF0lNZssuPpARa8ihq2j3NbDFx176MhUi3sJzzN1+2QJF5mJxSwUW13eRQ4WAqPdnG6+KAkDxriXXzWayb/fctAgor4krMQuy+9Zo9bpQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=parc.com; dmarc=pass action=none header.from=parc.com; dkim=pass header.d=parc.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parc.onmicrosoft.com; s=selector2-parc-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=vrFSYSHbCY5AU8oq54ue3aLX9oTk2u7Gn9bDcwmWupA=; b=tWGlMAJv05d588se+YZfE+o4qVHrGXBa6XKbOVD82zrXUH+oz8dzxKBnzxLp7jvCroRYwN0SgpoNFf98eGR6tK61Nz29KuBf8UKhvjEEQYwjrc/U7qhoqjno4TTuGLSDYjrt8irL79vSCXXlh/sN6xbjwLC9D0/TMlQUgRHvecY=
Received: from BYAPR15MB3238.namprd15.prod.outlook.com (2603:10b6:a03:106::29) by BYAPR15MB2822.namprd15.prod.outlook.com (2603:10b6:a03:15b::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2958.29; Mon, 4 May 2020 23:54:56 +0000
Received: from BYAPR15MB3238.namprd15.prod.outlook.com ([fe80::e56e:1f6e:a036:156c]) by BYAPR15MB3238.namprd15.prod.outlook.com ([fe80::e56e:1f6e:a036:156c%4]) with mapi id 15.20.2958.030; Mon, 4 May 2020 23:54:56 +0000
From: Marc Mosko <mmosko@parc.com>
To: Ken Calvert <calvert@netlab.uky.edu>
CC: "icnrg@irtf.org" <icnrg@irtf.org>
Thread-Topic: [icnrg] recursive key Lookup in CCNX
Thread-Index: AQHWHCObAI+sMBrnCEeZ6mpy7a+GbaiMxiQAgAWxVQCABbm3AA==
Date: Mon, 04 May 2020 23:54:56 +0000
Message-ID: <445C0FB8-12E3-45FE-888D-A87634497F2C@parc.com>
References: <91F2CCB5-F962-4DEF-A8C2-B8BCCD32F185@netlab.uky.edu> <AA95366C-99BF-4333-B6BC-366BE12990F5@parc.com> <74542F45-9E40-485F-A891-CAA92956CC1B@netlab.uky.edu>
In-Reply-To: <74542F45-9E40-485F-A891-CAA92956CC1B@netlab.uky.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/16.36.20041300
authentication-results: netlab.uky.edu; dkim=none (message not signed) header.d=none;netlab.uky.edu; dmarc=none action=none header.from=parc.com;
x-originating-ip: [50.0.67.90]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: eed6f055-febb-4fee-c069-08d7f0868c31
x-ms-traffictypediagnostic: BYAPR15MB2822:
x-microsoft-antispam-prvs: <BYAPR15MB282290EAFF92D7D0756F2934ADA60@BYAPR15MB2822.namprd15.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 03932714EB
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: klUgnl2w2AnceiYMsSDVMnlKu6kHyEuI9MmbrxAmHtXOf8APNHnqRC3oV2pZOQFJDl+iqEcGCKmwtLg8EvlfakIe7jeDReOsA+X8iU0LSy4tH0krH6Sc6/TR5/sbolrPnpMKFzJBUNC5YX6VAp+Klq+8C7twkP3xZ2fXGdh73aP/e4s6/VO+8Ua14BqdS3SNQe6Z+Y6TKV6hgEOXso0Nl5nuh07ks/19dhTVgTbmfzs5mXrxDLHccPfkUfb+WOnoc3C8udPiSFAczhK0M9PBEDDApy1g/rYYc5G7PzfujTrb49LTnRS2mkiVTtFlzGlKGx9BKBq3G8A7Kl4gbIMjVMB0iulxomw7Qmx13H+wM5KlT6Op3BnnPoRQnNdqNgXMwlizOLNSRQWIPiICDiG9BiyE8PAK+qzkilJUEPYmyIpH5qntuUpRDesjZqHlwqXnk/Cck9iXXgrS42o1WnB4jD4u42l6sRnUPElVeawLvlA52TUX6/V/DEZAitRJDq9mp2lHhW/ct808cH6Sib2UtxLRqtQk3icltYiCstpKUwjEPt8elzjPtuNlVxHBHk4x7jIoCdcT+GccnFZGTQvcUetPhywzwjbyC8N1kvYy4Vc=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BYAPR15MB3238.namprd15.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(39850400004)(396003)(376002)(366004)(136003)(346002)(33430700001)(36756003)(76116006)(66574012)(2616005)(6512007)(66556008)(6486002)(66946007)(66446008)(66476007)(64756008)(966005)(33656002)(33440700001)(478600001)(6916009)(8936002)(2906002)(53546011)(186003)(26005)(316002)(296002)(86362001)(6506007)(8676002)(4326008)(5660300002)(71200400001); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: qvRAhUHJuCKm1Rc7QpERNLa0uXOOK0cAMJ+bof8vdazOUD+gcGBu0E6VLxKzA42HHqIZmGFtr61/I8VBIGQowrOIVpfZMWhTjvSPQIIflVwo6wgLcWQDIs1pBciM1wUC8Oc2McXSk2h8MA9RWDGt356HVFz7RC4cYdGjGzMndaWiGnAWLGwlMLHmcbA8y8TYETmx0BB4EbvFAKdZGYPlrvM+/j/74Kxxgwhkcgzdazb2XByYBL+qxMvjlr53CD18zK71oHy/gua7VRdnGgsyXjrY9JPkxTFGfi5KOrutjA7we54iq01vmRLezSDten8FMfdctIV+EZaCFy1pGY5JvsXg+REuwMVepJ3A0u3I2SicfaAFFEXfiHbPIe2ZZ7luvUk7VYUr2IXLtDqBw/n1h1iqZ9sttnxpBjwtHItrGhFLBou+hV7iYUX8z6uF9K72WTdmes5KYGfYJ4Ml65Nyela3BNDgW2Pn7R5bx9Rwjg5yt1IuTAhKgLvkw2lPhm6d0kHj97qX9wbbFq/cJR2lGDlMc3gH5gxcl8t6Ef2gxCAzF6xGvDLeRkMw8Ygn1AhkZ6WxgsD4SbMgBezFfiH4sJbowSnOf6LbEbTMVfY5AwKrVUQ98QvTAZxZEIUwUWiPFTK2K29oAjVbe0S4KLJOrJZsHWZ6ZNrzchiiCI8/s+mX4NwAdmncngbRfmSmW0hOK6GvsTLscV2F1FJ4SHOVn9laL14WkYdIwkQAa05dJqAQe/BP9WspPPFwG5bzxl+epVLMqHRmrsmqCGYvwPhBD2uD3CRV9/v13U1bRDv/fvk=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-ID: <22E2C49DD25BF5469BBD54DC24013C7D@namprd15.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: parc.com
X-MS-Exchange-CrossTenant-Network-Message-Id: eed6f055-febb-4fee-c069-08d7f0868c31
X-MS-Exchange-CrossTenant-originalarrivaltime: 04 May 2020 23:54:56.3080 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 733d6903-c9f1-4a0f-b05b-d75eddb52d0d
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: qqlQNBfNU2QabpBMbJvAbwm1sR0UP0rmESdymuBKqnL5sJWbQdUligUiYADfT8AO
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR15MB2822
Archived-At: <https://mailarchive.ietf.org/arch/msg/icnrg/UfgnQotru_wKqVIvKdDvOSYWbEg>
Subject: Re: [icnrg] recursive key Lookup in CCNX
X-BeenThere: icnrg@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Information-Centric Networking research group discussion list <icnrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/icnrg>, <mailto:icnrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/icnrg/>
List-Post: <mailto:icnrg@irtf.org>
List-Help: <mailto:icnrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/icnrg>, <mailto:icnrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Mon, 04 May 2020 23:55:03 -0000

I wanted to follow-up on list with some discussions Ken and I have had in private.

One of the goals we had in writing 8569 / 8609 is for a given field perform only one job.  It should be clear what a KeyLink is and how to interpret it, just like other fields.  At times in CCNx 0.x, one field would be interpreted one way in one context (often implied by the publisher or based on external data) and interpreted another way in another context.

In the case of recursive key lookup to validate signatures, the processing would go something like this:

1.	Content object O1 has signature S1 with keyid K1 and a KeyLink to name N2.  A verifier without a corresponding public key to K1 would need to fetch N2 to verify the signature S1.
2.	Content object O2 with name N2 has a signature S2 with keyed K1 and a payload of a certificate C1 that wraps public key with keyid K1.  The verifier in step 1 now has the public key that it can verify matches K1 and verifies signature S1.  It is done.  Trust is a separate issue from mechanical verification of the signature.
3.	In CCNx 0.x, content object O2 usually continued with another KeyLink (called KeyLocator back then) to the certificate of the signer of C1 to establish the trust chain.  This second KeyLink in the ValidationAlogrithm section (to use current terms) is not used to verify a ValidationAlogirthm signature, but to establish trust by fetching the next step in the certificate chain of C1.  The retrieved content object would not be used to verify the signature of O2, but a completely different purpose.

If one were to propose a trust mechanism that uses a field in the ValidationAlgorithm section to fetch the next certificate in a chain, one  should make a new field, for example CertificateChainLink, for that purpose.  The KeyLink is to verify a signature, the CertificateChainLink is to fetch an issuer’s certificate.

Another possibility is to use the Issuer Alternative Name to embed a URI in the certificate with a ccnx: schema link rather than use an external field CertificateChainLink.

If one were to develop a CCNx-native certificate, rather than using X.509, based on the ValidationAlgorithm, I think one would likely define additional ValidationDependentData, like CertificateChainLink, to realize that structure -- or even use a more flexible mechanism like SPKI/SDSI or newer mechanisms that can transfer the whole trust chain digests at once.

Marc

On 4/30/20, 6:29 PM, "Ken Calvert" <calvert@netlab.uky.edu> wrote:

    Marc - 

    > It's at the end of Sec 8.4, not 8.1.  

    Right, thanks, sorry.

    I've responded to your points below off-list, but here I'll just say that I remain unconvinced:  RFC 8569 declares trust out of scope, but then proscribes recursive key lookup.  To me, the latter places an undue constraint on how applications can deal with trust.  But I realize I am years late to this party, and I'm not a security expert.

    I did not find any discussion of this issue in the mailing list archives (pointers welcome if I missed it or if it was discussed at any of the meetings).  I note that the explicit prohibition of recursive key lookup first appears in the RFC, and was NOT in any of the internet drafts - although the idea that a content object returned for a KeyLink should contain an X.509 certificate was there from the beginning.

    I am wondering if I'm the only one who cares about this.

    Cheers,
    Ken

    > 
    > Recursive link traversal has several issues.  The main one is loops and another is if there is a maximum length of a chain.  Specifying the validation process for recursive key / certificate lookup is not simple, especially if one does not include publisher public key restrictions.  Given that CCNx does not allow for prefix-matching on names, it is not so simple to create a system of looking up the current certificate for a content object using get-latest-version.  One needs to use expiry dates so the content object expires at or before the certificate expires and re-publish the content object, in which case one can update the KeyLink at the same time.
    > 
    > We do not require the trust chain to be of length 1.  We require the certificate retrieved by the keylink to be self-contained.   The certificate can have as many signers as one desires.  Also, the KeyLink could point to a segmented or manifest-based object, in which case the retrieval is not specifically 1 operation, but it is 1 security indirection step.
    > 
    > 8569 says that trust is out-of-scope for the document.  Thus, we allow, by exclusion, other mechanisms the determine what is a trusted key.  If that mechanism includes network operations, that is ok.  So if you have a key lookup mechanism to fine the trusted keys for a namespace, that's ok.  This process should also specify how one revokes trust too.  If one specifies a trust scheme that needs to update RFC8569, then that's ok.
    > 
    > Also, the spec essentially recommends the process in section 8 as the Consumer behavior (Sec 2.2) by saying the consumer "SHOULD cryptographically verify the signature as per Section 8."  There are some reasons why a consumer should not use section 8.  For example, a manifest that the consumer trusts has a hash pointer to a content object with an untrusted or expired validation section.  The consumer does not need to (and probably should not) apply section 8 to the hash-pointed-to object.
    > 
    > We also recommend that the KeyLink use a content object hash restriction in the link.  In that case, it does not make much sense to have multiple hops as they cannot change.  One could also use the publisher key id restriction for a less-restrictive means, but it is less secure.
    > 
    > Finally, we wanted to have a correct validation process specified in the document that is spelled out in detail.  In Sec 8.4, we specifically limit a KeyLink to point to a Certificate (whereas before it could point to raw public keys too).
    > 
    > See "Trust in Information-Centric Networking: From Theory to Practice" [https://doi.org/10.1109/ICCCN.2016.7568589] for some details on why.
    > 
    > In relation to NDN, my understanding is that their certificate format also does not allow indirection (http://named-data.net/doc/ndn-cxx/current/specs/certificate-format.html).  It is not 100% clear from the NDN spec, but the description of KeyLocator says it is a "name that points to another Data packet containing certificate or public key" (or it's a KeyDigest).  If the certificate is non-recursive, I think you have pretty much the same situation as RFC8569, modulo name prefix matching.  Though it is not clear if that retrieved object could have its own KeyLocator, though I do not know why it would have one.  I am not aware of place where NDN specifies the recursive verification process (or even the non-recursive case) outside of the code, but would I like to know if someone has that pointer.
    > 
    > Marc
    > 
    > On 4/26/20, 4:37 PM, "icnrg on behalf of Ken Calvert" <icnrg-bounces@irtf.org on behalf of calvert@netlab.uky.edu> wrote:
    > 
    >    Why is recursive key lookup prohibited in CCNx 1.0?
    > 
    >    I am really surprised that Section 8.1 of RFC 8569 says "we do not allow for recursive key lookup".
    > 
    >    First, this seems to dictate a single policy for all applications using the CCNx network layer. That seems like a Big Deal, so I would expect to see some reason given in the RFC, but there's no justification.
    > 
    >    I always thought being able to just "turn the crank" and retrieve the key that signed a content object,then the key that signed that, and so on (as long as the names match a trust schema, as described in the Yu et al ICN '15 paper) until you reach a trust anchor was one of the very best things about CCN/NDN.
    >    What am I missing?
    > 
    >    Related question:  What is the essential security difference between an X.509 certificate and a KeyLink?  If there's no difference, why require that trust chains be of length one, and end in X.509 certs (or known keys)?  And if there is a security difference, why define a separate Key object at all?
    > 
    >    Thanks,
    > 
    >    Ken
    >    _______________________________________________
    >    icnrg mailing list
    >    icnrg@irtf.org
    >    https://www.irtf.org/mailman/listinfo/icnrg
    >