Re: [Ace] est-coaps clarification on /att and /crts

Michael Richardson <mcr+ietf@sandelman.ca> Tue, 11 December 2018 22:21 UTC

Return-Path: <mcr+ietf@sandelman.ca>
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 17E5212E036; Tue, 11 Dec 2018 14:21:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] 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 GAXmGf4HNrLC; Tue, 11 Dec 2018 14:21:48 -0800 (PST)
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 743B91286E7; Tue, 11 Dec 2018 14:21:48 -0800 (PST)
Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id B01A720089; Tue, 11 Dec 2018 17:21:41 -0500 (EST)
Received: by sandelman.ca (Postfix, from userid 179) id 85E69E1B; Tue, 11 Dec 2018 17:21:47 -0500 (EST)
Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 83DCCE15; Tue, 11 Dec 2018 17:21:47 -0500 (EST)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: "Panos Kampanakis (pkampana)" <pkampana@cisco.com>, "ace@ietf.org" <ace@ietf.org>, "anima@ietf.org" <anima@ietf.org>
CC: Peter van der Stok <stokcons@bbhmail.nl>, "Max Pritikin (pritikin)" <pritikin@cisco.com>
In-Reply-To: <47b9e5cbf7e64fad91a9fc79e83e392c@XCH-ALN-010.cisco.com>
References: <c07a0c0ecb5d48c4aed2595ab8cbef5c@XCH-ALN-010.cisco.com> <3831.1544545763@localhost> <47b9e5cbf7e64fad91a9fc79e83e392c@XCH-ALN-010.cisco.com>
X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.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-sha256"; protocol="application/pgp-signature"
Date: Tue, 11 Dec 2018 17:21:47 -0500
Message-ID: <27594.1544566907@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/bM4Md_SFtGq3syVjWFJ0nyvvGOc>
Subject: Re: [Ace] est-coaps clarification on /att and /crts
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: Tue, 11 Dec 2018 22:21:51 -0000

Panos Kampanakis (pkampana) <pkampana@cisco.com> wrote:
> I thought about this for the EST-coaps draft. EST allowed for
> unauthenticated /cacerts and /csrattrs (/crt and /att in EST-coaps) as you
> are suggesting.

Exactly.

> It is not as simple in EST-coaps. Two reasons:

> 1) There are constrained networks where an easy amplification attack could
> take place. For example the /crt request is very small and the response can
> be big (a few KBs in the context of a constrained network is big). If
> unauthenticated, then /crts could be an easy amplification attack to
> saturate a constrained network. We don't want that to happen. We want all
> our clients to be authenticated by DTLS before they start loading up our RF
> network.

I'm not suggesting that the DTLS be skipped, I'm suggesting that the client
certificate presented might be meaningless to the EST server.
As for amplication attacks, they usually depend upon forged source addresses,
and in that case the DTLS wouldn't have completed.

> 2) Additionally, there is a practical challenge of COAPS. When the DTLS
> handshake is taking place the server does not know what the request will
> be. In EST the server would send an HTTP WWW-Authenticate header to ask the
> client to authenticate. Such a mechanism does not exist in COAP, so it
> would not be straightforward unless we introduced a bunch of new things
> into COAP.

AFAIK, we don't support HTTP-level authentication in COAPS, only DTLS level
authentication is specified in EST-COAPS.

> I think it is still right to authenticate clients even for /crt and /att in
> the EST-coaps context. Maybe that is something to be revisited in
> Constrained-BRSKI/voucher, but not taken lightly.

So I think that we need to say something in EST-COAPS to explain that we do
not see a use case for replying to /crts and /att for clients which are not
recognized.  Is 401 (4.01) or 403 (4.03) more appropriate do you think?

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



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