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

"Panos Kampanakis (pkampana)" <pkampana@cisco.com> Wed, 12 December 2018 02:59 UTC

Return-Path: <pkampana@cisco.com>
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 B07B4131007; Tue, 11 Dec 2018 18:59:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.96
X-Spam-Level:
X-Spam-Status: No, score=-15.96 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.46, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 StiwEyB2_lz0; Tue, 11 Dec 2018 18:59:14 -0800 (PST)
Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8741C1277D2; Tue, 11 Dec 2018 18:59:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4599; q=dns/txt; s=iport; t=1544583554; x=1545793154; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=LFwOWljz6mrzN4BjrEIickIClcAr5V5xVKDbPkK7o8U=; b=MolTP/HYlUqhAaJ7f+GIYgUYqWArU4LLPbHLByEkt+ybbQzuTn834Eq3 rq0lfH59azmB6xrNxuQwzo46vABI6oEXe6EaJiotdN6oq/DpJLLTl1TdS +cCA2QReLdkZNJub+VpBGYztgisU9bgNwhQWwWyfhtec7H7IjX7RD3I14 k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ADAACkeBBc/5JdJa1lGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBUQQBAQEBAQsBggNmgQInCowKjh+XUoF6CwEBH4FYgnU?= =?us-ascii?q?CgmwiNAkNAQMBAQIBAQJtHAyFPAEBAQECATo/BQcEAgEIEQQBAQEeEDIdCAI?= =?us-ascii?q?EAQ0FCIMagXkIpx+KMIlzgkgXgUA/gRGDEoRrhXEClXaKMFUJApFJIJFCiSO?= =?us-ascii?q?PagIRFIEnHziBVnAVgycJhSuLJ0ExiziBHwEB?=
X-IronPort-AV: E=Sophos;i="5.56,343,1539648000"; d="scan'208";a="211803218"
Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Dec 2018 02:59:13 +0000
Received: from XCH-RCD-014.cisco.com (xch-rcd-014.cisco.com [173.37.102.24]) by rcdn-core-10.cisco.com (8.15.2/8.15.2) with ESMTPS id wBC2xDov001154 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 12 Dec 2018 02:59:13 GMT
Received: from xch-aln-010.cisco.com (173.36.7.20) by XCH-RCD-014.cisco.com (173.37.102.24) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 11 Dec 2018 20:59:12 -0600
Received: from xch-aln-010.cisco.com ([173.36.7.20]) by XCH-ALN-010.cisco.com ([173.36.7.20]) with mapi id 15.00.1395.000; Tue, 11 Dec 2018 20:59:12 -0600
From: "Panos Kampanakis (pkampana)" <pkampana@cisco.com>
To: Michael Richardson <mcr+ietf@sandelman.ca>, "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>
Thread-Topic: est-coaps clarification on /att and /crts
Thread-Index: AQHUkW6xEQf9wDn5PkCg7PZRmoPArKV5u4KggADGBID//+UPkA==
Date: Wed, 12 Dec 2018 02:59:12 +0000
Message-ID: <e5c042393be24304b0275ed07ea6ba2b@XCH-ALN-010.cisco.com>
References: <c07a0c0ecb5d48c4aed2595ab8cbef5c@XCH-ALN-010.cisco.com> <3831.1544545763@localhost> <47b9e5cbf7e64fad91a9fc79e83e392c@XCH-ALN-010.cisco.com> <27594.1544566907@localhost>
In-Reply-To: <27594.1544566907@localhost>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.82.174.56]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Outbound-SMTP-Client: 173.37.102.24, xch-rcd-014.cisco.com
X-Outbound-Node: rcdn-core-10.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/XagkauyRBTe9JezBOkUUtZdNCeE>
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: Wed, 12 Dec 2018 02:59:17 -0000

Gotcha, so you are describing a provisional DTLS connection at the server. 

Just to give a bit more color, in a usecase we are working on right now the mesh network link rate <100Kbps. That network gets oversubscribed with legit cacert responses. I can only imagine how worse it would be if bad guys were allowed to send small /crt requests and trigger big cert responses. 

Just a 4.01 would not tell the client that he needs to send client certs for auth. In plain EST it would take an HTTP 401 with an 
WWW-Authenticate  = "WWW-Authenticate" ":" 1#challenge
header in the response. Unless we replicate that a generic 4.01 would not be enough for the client to know what to do. 

Another issue is EST-coaps request pipelining. A cacerts could precede an enrollment in the same DTLS connection (for really constrained devices that don't want to establish two connections). This could be opening room for unauthenticated enrollments when pipelining is used. 

I think it is a good idea to not repeat the EST behavior in regards to /crt and /att. Provisional TLS at the server could have value in Constrianed-BRSKI/voucher though, for some situations though. 

> 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? 

Currently we say that clients need to be authenticated in a DTLS connection before an EST-coaps request. Do you want to make it more explicit to say that even though EST allowed for it, EST-coaps does not allow unauthenticated /crt and /att? We can certainly add that. 

Rgs,
Panos


-----Original Message-----
From: Michael Richardson <mcr+ietf@sandelman.ca> 
Sent: Tuesday, December 11, 2018 5:22 PM
To: Panos Kampanakis (pkampana) <pkampana@cisco.com>om>; ace@ietf.org; anima@ietf.org
Cc: Peter van der Stok <stokcons@bbhmail.nl>nl>; Max Pritikin (pritikin) <pritikin@cisco.com>
Subject: Re: est-coaps clarification on /att and /crts

* PGP Signed by an unknown key


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>ca>, Sandelman Software Works  -= IPv6 IoT consulting =-




* Unknown Key
* 0xDDD0DD65