Re: [Ace] AD review of draft-ietf-ace-coap-est-12

Peter van der Stok <stokcons@bbhmail.nl> Fri, 30 August 2019 11:12 UTC

Return-Path: <stokcons@bbhmail.nl>
X-Original-To: ace@ietfa.amsl.com
Delivered-To: ace@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14D29120814; Fri, 30 Aug 2019 04:12:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.996
X-Spam-Level:
X-Spam-Status: No, score=-1.996 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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=bbhmail.nl
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 U86QF7O4CTeB; Fri, 30 Aug 2019 04:12:49 -0700 (PDT)
Received: from smtprelay.hostedemail.com (smtprelay0033.hostedemail.com [216.40.44.33]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8E4A120018; Fri, 30 Aug 2019 04:12:48 -0700 (PDT)
Received: from filter.hostedemail.com (clb03-v110.bra.tucows.net [216.40.38.60]) by smtprelay08.hostedemail.com (Postfix) with ESMTP id 83FB9182CF665; Fri, 30 Aug 2019 11:12:47 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bbhmail.nl; h= mime-version:content-type:date:from:to:cc:subject:reply-to :in-reply-to:references:message-id; s=key; bh=hUs+LgUZDCAQXsoI3m rfA86v0MVglzAvrBM4MuLa6lE=; b=C4auUkM6HikmZbkv2YVFS/41rA2DYDh8tK fXVBpbJIeGDDExbGNLnOcBJYhY33cxsXTyXWp11LOegJrm6uPXHwYOXIObUcEaaW PmZs+n6CiG1fjM7Zj7PRXyqCw873tKVSiAmpgUsDhH+eM0Nd4t1Z+hrvLZnah1Bo WTQfyntQs=
X-Session-Marker: 73746F6B636F6E73406262686D61696C2E6E6C
X-Spam-Summary: 2, -10, 0, , d41d8cd98f00b204, stokcons@bbhmail.nl, :::::::, RULES_HIT:41:72:152:327:355:379:582:599:800:960:962:967:968:973:983:988:989:1152:1189:1208:1212:1221:1260:1313:1314:1345:1359:1431:1436:1437:1516:1517:1518:1575:1588:1589:1592:1594:1605:1617:1712:1730:1776:1792:2068:2069:2197:2198:2199:2200:2525:2527:2528:2551:2553:2559:2564:2638:2682:2685:2689:2691:2693:2731:2859:2892:2895:2897:2898:2901:2906:2909:2910:2911:2922:2923:2924:2925:2926:2933:2937:2939:2942:2945:2947:2951:2954:3022:3138:3139:3140:3141:3142:3622:3865:3866:3867:3868:3870:3871:3872:3873:3874:3934:3936:3938:3941:3944:3947:3950:3953:3956:3959:4250:4321:4425:4860:5007:6117:6119:6261:6657:6659:6678:7576:7774:7875:7903:7974:8545:8557:8568:8603:9010:9025:9040:9177:9545:10004:10848:11026:11232:11473:11657:11658:11854:11914:12043:12050:12109:12114:12291:12295:12379:12438:12663:12679:12683:12740:12895:13139:13141:13161:13180:13200:13229:13230:13439:13846:13972:14095:14110:14799:21060:21080:21324:21433:21450:21451:2
X-HE-Tag: shake01_527f7a10a1824
X-Filterd-Recvd-Size: 23548
Received: from mail.bbhmail.nl (imap-ext [216.40.42.5]) (Authenticated sender: webmail@stokcons@bbhmail.nl) by omf01.hostedemail.com (Postfix) with ESMTPA; Fri, 30 Aug 2019 11:12:46 +0000 (UTC)
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_fa2fcbc5f8adccdd6342e33e0fe12a62"
Date: Fri, 30 Aug 2019 13:12:46 +0200
From: Peter van der Stok <stokcons@bbhmail.nl>
To: Jim Schaad <ietf@augustcellars.com>
Cc: 'Benjamin Kaduk' <kaduk@mit.edu>, draft-ietf-ace-coap-est.all@ietf.org, ace@ietf.org
Organization: vanderstok consultancy
Reply-To: consultancy@vanderstok.org
Mail-Reply-To: consultancy@vanderstok.org
In-Reply-To: <027701d55ebf$994184b0$cbc48e10$@augustcellars.com>
References: <20190828233639.GI84368@kduck.mit.edu> <027701d55ebf$994184b0$cbc48e10$@augustcellars.com>
Message-ID: <edcbc2a243cc7118e35aec77b2e1599c@bbhmail.nl>
X-Sender: stokcons@bbhmail.nl
User-Agent: Roundcube Webmail/1.2.7
X-Originating-IP: [5.206.216.229]
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/cknDwrdys6ULqlZes_qhFG84O2c>
Subject: Re: [Ace] AD review of draft-ietf-ace-coap-est-12
X-BeenThere: ace@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" <ace.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ace>, <mailto:ace-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ace/>
List-Post: <mailto:ace@ietf.org>
List-Help: <mailto:ace-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ace>, <mailto:ace-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 30 Aug 2019 11:12:53 -0000

HI Jim and Ben,

Ben, many thanks for a nice and elaborate  review of the draft.

beginning next week I will provide partial answers to the review.
Some small remarks below to the much appreciated explanations by Jim.

An initial answer to the first point precedes the answers by Jim.

cheerio,

Peter
_____________________________________________________________

Section 2

   This document also profiles the use of EST to only support
   certificate-based client authentication.  HTTP Basic or Digest
   authentication (as described in Section 3.2.3 of [RFC7030]) are not
   supported.

Is the intent just to exclude HTTP-layer authentication, or to
specifically prefer client certificate authentication?  7030 does allow
for non-certificate TLS-layer authentication (e.g., TLS-SRP), which
would be compatible with DTLS just fine.  There's also recurrent talk of
getting modern PAKE(s) integrated with TLS, which might also be an
option in the constrained space.
[There are subsequent parts of the document that continue to assume
only-certificates, so I'm mostly assuming that the intent is
specifically to prefer client certificates, and have not made specific
notes at those other places in the document.]

<pvds>
client certificate authentication is preferred based on the following
history:
est_coaps was initially written as extension to anima BRSKI for small
devices.
In that context the only reasonable use case is client certificate
authentication.
In a later stage a wider audience of the document was identified beyond
BRSKI also with a certificate authentication use case.
The draft is limited to the certificate authentication, other
authentications are not considered.
I am not sure if this falls under preference of certificate
authentication or exclusion of http layer authentication.
If http layer authentication is wanted, my suggestion is that another
document specifies this. This draft does not forbid the use of http
layer authentication.
Did I interpret your remark as you intended?
</pvds>

Jim Schaad schreef op 2019-08-30 01:15:

> A couple of answers from my own perspective
> 
> -----Original Message-----
> From: Ace <ace-bounces@ietf.org>; On Behalf Of Benjamin Kaduk
> Sent: Wednesday, August 28, 2019 4:37 PM
> To: draft-ietf-ace-coap-est.all@ietf.org
> Cc: ace@ietf.org
> Subject: [Ace] AD review of draft-ietf-ace-coap-est-12
> 
> Hi all,
> 
> A good number of comments here, though many are just nits.  We may need some
> more in-depth discussion about only using certificates for client
> authentication (immediately below) and how we discuss server-keygen.
> 
> Thanks,
> 
> Ben
> 
> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
> 
> When proof-of-possession is desired, a set of actions are required
> regarding the use of tls-unique, described in Section 3.5 in
> [RFC7030].  The tls-unique information consists of the contents of
> 
> I see the note in the shepherd writeup about converting EST to use TLS
> exporters rather than tls-unique in a separate update document.  Where is
> that work happening?  The discussion in Section 10.1 is helpful (and we
> could do well to reference it from here) but does not inspire great
> confidence in the reader that such work will come to fruition.
> I think we also need to at least mandate extended-master-secret to be used
> on the underlying DTLS connection.  (That is, assuming that we don't want to
> lock down to specific, non-vulnerable, ciphersuites -- RFC 7925 only has
> TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 as MTI, not MTU.)
> 
> [JLS]  If this work is going to happen it needs to be done as an update to
> the EST RFC.  I don't know if it would be better to do that in LAMPS rather
> than here.  Currently I do not know of anybody who is going to do this.
> This is my issue and I am willing to let it slide for the time being.
> 
> <pvds> I am happy with an update to LAMPS </pvds>
> 
> In the context of CoAP, the presence and location of (path to) the
> EST resources are discovered by sending a GET request to "/.well-
> known/core" including a resource type (RT) parameter with the value
> "ace.est*" [RFC6690].  The example below shows the discovery over
> 
> Is that a literal asterisk, for ace dot est star?
> (1) Why?
> (2) It probably merits a mention in the text to confirm it for the reader.
> 
> [JLS] This is standard CoAP searching with the "rt" parameter.  The start is
> a) literal and b) means a wild chard with the expected meaning.  I don't
> think that this needs any additional text.
> <pvds> agree; new text will look much like repetition of text in other documents </pvds>
> 
> It's a little unfortunate that we can only indicate ct=62 for the last two,
> and there's no way to indicate what content types we expect within that
> container.
> 
> [JLS] This was a big topic of discussion both in ace and more importantly in
> core for the multipart content type.  If this is solved it should be solved
> in CoRE and not here.  (I recognize from the text that you don't expect it
> to be solved in this document.)
> <pvds> finding the other ct's means parsing the CBOR content</pvds>
> 
> I can (grudgingly) accept that people are going to do server-side key
> generation, so I do not propose to remove it from the document.  The policy
> case is a clear example of why the feature needs to be available, but I'm
> not 100% sure that I believe that server-keygen could be "more secure" given
> that the client needs to be able to produce secure random numbers for DTLS
> (though I do accept that some people will believe it to be so!).  It seems
> likely to only be possible in some intermediate situation where the
> client-generated random numbers could be attacked but at substantial
> expense, such that paying that expense for a single handshake is "too much"
> for the attacker to bear, but doing it for the key generation that would
> give the attacker all transactions would make the expense worthwhile; this
> intermediate situation seems to also be transitory, since attacks only get
> better/cheaper.
> For the other case, if we were doing RSA keygen, then going from random
> numbers to prime generation could be enough incremental expense that
> offloading to the server would make sense, but I didn't think the elliptic
> curve stuff had the same kind of issues, so I'd like to hear more about the
> resource-consumption aspect as well.
> 
> [JLS] I would disagree that there is any requirement for a client using
> DTLS to have any type of secure random numbers to still get a secure
> channel.  If you do PSK authentication, then it is not required.  The
> "random numbers" in the protocol are not really random, this is really true
> because they are public numbers, you would like them to be non-predictable
> but I do not know that this is even a requirement.  The only question is how
> much you want to avoid some type of static-ephemeral key agreement state
> which looses the PFS but is still potentially not horrid to have.
> <pvds> I would prefer my co-authors to react to this aspect </pvds>
> 
> with other requests in the same DTLS connection SHOULD revalidate the
> server certificate chain against the updated Explicit TA from the
> /crts response before proceeding with the subsequent requests.  If
> the server certificate chain does not authenticate against the
> database, the client SHOULD close the connection without completing
> the rest of the requests.  The updated Explicit TA MUST continue to
> be used in new DTLS connections.
> 
> I'm not going to say you shouldn't do this check, but it seems pretty easy
> for an attacker that knows it's servicing a /crts request to supply a
> response that includes a (potentially bogus) trust anchor that can certify
> the certificate it used for the current connection.  So it's not clear how
> much protection this really provides.
> 
> [JLS] Right, of course the attacker that is going to do this needs to have
> gotten a trusted channel set up initially to provide that (potentially
> bogus) trust anchor over.  If you can do that then there is no longer any
> trust in the system at all.
> 
> As described in CMC, Section 6.7 of [RFC5272], "For keys that can be
> used as signature keys, signing the certification request with the
> private key serves as a POP on that key pair".  The inclusion of tls-
> unique in the certificate request links the proof-of-possession to
> the TLS proof-of-identity.  This implies but does not prove that only
> the authenticated client currently has access to the private key.
> 
> Do we want to further clarify that this means the PoP is weaker than it
> could be?  ("no" is a fine answer, as always.)
> 
> [JLS] My response would be no.  I have spent hours describing the issues
> that arise here without it always being clear that I have succeeded.  Trying
> to do this in text and get the corner cases well described is extremely
> difficult.
> 
> It also assumes the Registrar has a trust relationship with the
> upstream EST server in order to act on behalf of the clients.  When a
> client uses the Implicit TA database for certificate validation, she
> SHOULD confirm if the server is acting as an RA by the presence of
> the id-kp-cmcRA EKU [RFC6402] in the server certificate.
> 
> Why is this only a SHOULD?
> 
> [JLS] Because it could be done by a different method.
> 
> Jim
> 
> _______________________________________________
> Ace mailing list
> Ace@ietf.org
> https://www.ietf.org/mailman/listinfo/ace