Re: [pkix] Validating Certs w/out reliable source of Time

"Dr. Pala" <director@openca.org> Mon, 08 October 2018 14:12 UTC

Return-Path: <director@openca.org>
X-Original-To: pkix@ietfa.amsl.com
Delivered-To: pkix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40B24130DE0 for <pkix@ietfa.amsl.com>; Mon, 8 Oct 2018 07:12:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.88
X-Spam-Level:
X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_HK_NAME_DR=0.01, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no
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 1mKctRDTnnvi for <pkix@ietfa.amsl.com>; Mon, 8 Oct 2018 07:12:47 -0700 (PDT)
Received: from mail.katezarealty.com (mail.katezarealty.com [104.168.158.213]) by ietfa.amsl.com (Postfix) with ESMTP id 1AB23130DCB for <pkix@ietf.org>; Mon, 8 Oct 2018 07:12:47 -0700 (PDT)
Received: from localhost (unknown [127.0.0.1]) by mail.katezarealty.com (Postfix) with ESMTP id EA5613740FE1; Mon, 8 Oct 2018 14:12:46 +0000 (UTC)
X-Virus-Scanned: amavisd-new at katezarealty.com
Received: from mail.katezarealty.com ([127.0.0.1]) by localhost (mail.katezarealty.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id LJWnIX9uViWh; Mon, 8 Oct 2018 10:12:40 -0400 (EDT)
Received: from Maxs-MBP.cablelabs.com (unknown [192.160.73.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.katezarealty.com (Postfix) with ESMTPSA id E278A3740FC1; Mon, 8 Oct 2018 10:12:39 -0400 (EDT)
To: "Panos Kampanakis (pkampana)" <pkampana@cisco.com>, PKIX <pkix@ietf.org>
References: <f1d0a721-96e4-5d1b-4dd3-7b041e3c4379@openca.org> <47b70e1c4d214e9297e29b9ee1450c59@XCH-ALN-010.cisco.com>
From: "Dr. Pala" <director@openca.org>
Organization: OpenCA Labs
Message-ID: <a16d45ac-b48e-6cee-40c1-84b065df2d4c@openca.org>
Date: Mon, 8 Oct 2018 08:12:39 -0600
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <47b70e1c4d214e9297e29b9ee1450c59@XCH-ALN-010.cisco.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms050008060601050104060108"
Archived-At: <https://mailarchive.ietf.org/arch/msg/pkix/ECMJSOrcjWUGbfM0jQ_oqaX1E6w>
Subject: Re: [pkix] Validating Certs w/out reliable source of Time
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: PKIX Working Group <pkix.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pkix>, <mailto:pkix-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pkix/>
List-Post: <mailto:pkix@ietf.org>
List-Help: <mailto:pkix-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pkix>, <mailto:pkix-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 08 Oct 2018 14:12:50 -0000

Hi Panos, all,

thanks for the info. It seems nobody has a good story around it - the 
onboarding provides some obvious paths, but it does not provide really a 
good story around it and it is very prone to implementation errors (it 
seems more like giving up in having a good answer / system when you do 
not trust the network itself - which is the case I am trying to cover).

Although I totally agree with the difficulty around providing a 
solution, I am a bit worried about devices keeping logs/audit traces and 
then follow up on them at a later time - especially without providing 
guidance about what is a trusted source of time... :D I would expect 
many devices not to really check the validity of certificates after they 
have been "used" already.

In my specific use-case (which is not a generic case), I am leaning 
toward building a signed time service w/ a simple challenge-response 
mechanism that can be proxy and verified by the device... since we 
already have domain-specific trust anchors deployed, we might leverage 
those also for this use-case.

Last but not least, it might be useful to define a TLS extension that 
would carry such a record so that time-synchronization becomes less of 
an issue... does such an extension already exists?

Thanks again,

Cheers,
Max

On 10/4/18 10:36 AM, Panos Kampanakis (pkampana) wrote:
>
> Hi Max,
>
> This is an issue that is dealt with in onboarding too. 
> https://tools.ietf.org/html/draft-ietf-anima-bootstrapping-keyinfra-16#section-2.6 
> has some text around it. It states “It is reasonable that the
>
> notBefore date be after the pledge's current working reasonable
>
> date.  It is however, suspicious for the notAfter date to be
>
> before the pledge's current reasonable date.  No action is
>
> recommended, other than an internal audit entry for this.”
>
> IMO, if someone trusted a server cert chain because he didn’t have 
> proper time at the time, he should generate an audit log that can be 
> used to go back to validate when more accurate time available.
>
> There was also a discussion in LAMPS about trusting expired certs in 
> the initial enrollment 
> https://mailarchive.ietf.org/arch/browse/spasm/?q=%22Permissibility+of+expired+cert+renewal%22 
> . Caching revocation info for the chain is important in these cases.
>
> Rgs,
>
> Panos
>
> *From:*pkix <pkix-bounces@ietf.org>; *On Behalf Of *Dr. Pala
> *Sent:* Thursday, October 04, 2018 10:22 AM
> *To:* PKIX <pkix@ietf.org>;
> *Subject:* [pkix] Validating Certs w/out reliable source of Time
>
> Hi all,
>
> I am struggling with one issue that we have been seeing more and more 
> often with the introduction of small IoT devices that connect to 
> clouds and need to validate the other party's certificate chain.
>
> In particular, the problem is that without a reliable (or trusted) 
> source of Time information, devices can not really validate 
> certificates (i.e., is the certificate even valid... ? is it expired ? 
> is the revocation info fresh enough ?) and my question for the list is 
> about best practices in the space.
>
> Do you know if there are indications / best practices from ITU or from 
> IETF (or other organizations) on how to deal with this issue ?
>
> Cheers,
> Max
>
> -- 
>
> Best Regards,
>
> Massimiliano Pala, Ph.D.
> OpenCA Labs Director
>
> OpenCA Logo
>

-- 
Best Regards,
Massimiliano Pala, Ph.D.
OpenCA Labs Director
OpenCA Logo