Re: [Danish] Proposed WG Charter

Ash Wilson <ash.wilson@valimail.com> Tue, 15 June 2021 19:54 UTC

Return-Path: <ash.wilson@valimail.com>
X-Original-To: danish@ietfa.amsl.com
Delivered-To: danish@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E74543A3BCE for <danish@ietfa.amsl.com>; Tue, 15 Jun 2021 12:54:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=valimail.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 OElzwAntDKt2 for <danish@ietfa.amsl.com>; Tue, 15 Jun 2021 12:53:55 -0700 (PDT)
Received: from mail-qv1-xf31.google.com (mail-qv1-xf31.google.com [IPv6:2607:f8b0:4864:20::f31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C0A23A3BCB for <danish@ietf.org>; Tue, 15 Jun 2021 12:53:55 -0700 (PDT)
Received: by mail-qv1-xf31.google.com with SMTP id f5so321001qvu.8 for <danish@ietf.org>; Tue, 15 Jun 2021 12:53:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=vEY82GUFf0l+YqAqBFHqqI8KbggVeybp9MZ5nwmWPRc=; b=fpUwjDxtj0fz39jL+HCMON5olIuKxVfpWG9/nM0JK5oEiL5yWQJEIE8cxVcK12XJPY EHDYPbyNn1w+e/uOOfn0iIc0rhLq7ZXsC8KyAjugbwR9xDaWiPVEyTPUuMjcSNqWTXZ2 AqFhQXP3AOR3+mv1JppSMzXQmLGCxw/03Dwt/WEY6MmB9/oKNFnZBc85WjMpgpfL6rmG vEMR+hMFch+OxTLpRFWVFxQKf/Ek4Ed5ehvtRAg9IqkMmidZgtGnX07NoZUWLyFF9k3i 4RXGkmTs6BQ+464E48LpadPBICrtY12wrT0cSU9J3Su8Bvaxs/x+i2OybPvySSD45qdr caBA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=vEY82GUFf0l+YqAqBFHqqI8KbggVeybp9MZ5nwmWPRc=; b=AfN/psB+OyQCn1DCQC54wadVxQ3eM+z1/WfwdauNKuYKgBNL/72mQlcKFLxGTJ1FEJ nJ2g70aI4MocqwqKsz+g81+juM04PZYZMUjWB/XCaCz0O+YRH+JWvt6orUHHzV7qlniN mU/fIJDeWmbBBGTY6axoZTxXL9BrX8SuH9xgzm8PLAJnGVZZSWUY3BCPvxbjZMAwuQn1 r5pbjcIaKIDfL34wwGWzVq9RLuYkZY+J8Qe20W0jERPiv9L6gn8M/vswtpKV8KDZ8T2Q QFddnQXK6X/rEPlOEmKEzC9908zA8mIWIbqQeLef+HlA4wQpcIo4KaLJCvkBtxx+pSqh f7Sw==
X-Gm-Message-State: AOAM5320O7JLP2vTARJJrSBOrEYX8JyREPx5yKnxUozSYfJe39MtvtK0 oLjMZrehPnXRXO83GTCq0WTlFL08d5uRxsJVedRbsVGBNyQ=
X-Google-Smtp-Source: ABdhPJwaN6yRQ24gQbe1NddZwszrIwx7H7jva4dp/HKfhvbGw/K7ALKYr5xARNhzUZuIQfKbLZDI6wHRorre6GChLMg=
X-Received: by 2002:a05:6214:c6b:: with SMTP id t11mr6707060qvj.31.1623786833201; Tue, 15 Jun 2021 12:53:53 -0700 (PDT)
MIME-Version: 1.0
References: <YMZwG/l/pne2tHJF@straasha.imrryr.org> <A7723DDA-3B78-46AD-9449-B6DF7F211706@nohats.ca> <CAEfM=vSd7CuK58W=eX86GYaxKKBfOs8z1mnQQVXnrXf9x-co0g@mail.gmail.com> <d997ea8-9fc8-712-e22-fac64b401ab6@nohats.ca>
In-Reply-To: <d997ea8-9fc8-712-e22-fac64b401ab6@nohats.ca>
From: Ash Wilson <ash.wilson@valimail.com>
Date: Tue, 15 Jun 2021 12:53:42 -0700
Message-ID: <CAEfM=vTkxK_SF5gwb8DzJNUbzbypXK_=uCK_04a9y9Y4hYrZGQ@mail.gmail.com>
To: Paul Wouters <paul@nohats.ca>
Cc: danish@ietf.org
Content-Type: multipart/alternative; boundary="0000000000006261fc05c4d35571"
Archived-At: <https://mailarchive.ietf.org/arch/msg/danish/ox1J8eAl1IFDhs_WrQyZPy-nOkc>
Subject: Re: [Danish] Proposed WG Charter
X-BeenThere: danish@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: DANE AutheNtication for Iot Service Hardening <danish.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/danish>, <mailto:danish-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/danish/>
List-Post: <mailto:danish@ietf.org>
List-Help: <mailto:danish-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/danish>, <mailto:danish-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 15 Jun 2021 19:54:02 -0000

Hi Paul,
Thanks for the feedback, responses/clarification in-line below.

On Tue, Jun 15, 2021 at 12:14 PM Paul Wouters <paul@nohats.ca> wrote:

> On Mon, 14 Jun 2021, Ash Wilson wrote:
>
> > Very often, mobile data used for IoT ends up going into a message broker
> or message queueing system, and the central application subscribes or
> otherwise
> > consumes information from the messaging middleware. Without some sort of
> verifiable sender identity attached to the message itself, the identity of
> the
> > sender and the integrity of the message is assumed based on the
> integrity of all middleware involved in passing messages. If we include the
> sender's DNS
> > name in the message and protect it with a signature, then it may be
> verified by the central application, independent of the transport over
> which it
> > arrives. Then, mobile data network authentication becomes more about
> protecting availability and performance than preventing impersonation in a
> > message-oriented application. Use cases centering around mobile network
> identities are a little more nuanced, and the available mechanisms can vary
> based
> > on the mobile operator's tech stack. That's probably a better
> conversation for 3GPP.
>
> But the price of this method is revealing the DNS FQDN and IP of the IoT
> device. I can't come up with a use case where an IoT device would gain
> more than it loses from announcing to the world who it is and where it is.
>

 The use case where messaging middleware is used to get the message from
the device to the service prevents the establishment of a TLS connection
directly between the producer and consumer of the information. In many
cases, the producer of the information doesn't even have IP connectivity.
The producer (mobile UE, pick your term) sends messages through the
provider network which eventually is presented for consumption by the
provider. A number of message-passing layers may still exist between the
mobile provider and the actual consumer of the messages produced by the
device.  The device has no IP to reveal, and the DNS FQDN is the sender's
identity. .

Some concept of sender identity is required for authentication and
authorization. The application shouldn't trust information that cannot be
attributed. If DNS is used as the public key discovery mechanism, the
authenticity of the payload and the identity of the sender can be verified
by the consuming application, even in the absence of a direct TLS
connection, and for senders which do not even have IP connectivity.


> Traditionally, this is all done using public/private CA's where the
> client conveys it identity securely via TLS client authentication
> using a certificate, or by not authenticating the TLS client and
> forcint the client to do an authentication after the TLS connection
> has estbalishes, eg via Basic Auth at the HTTP level.
>
Correct, for environments where a direct connection between the device and
the core application are possible. Message brokers and other middleware
layers prevent the establishment of a direct TLS connection between
producer and consumer. Without a method for determining message sender
identity, authn/authz from the perspective of the consumer is assumed based
on the assumed integrity of every hop between the producer and consumer.

>
> > Consider that if a messaging middleware platform is trusted by multiple
> sophisticated smart cities applications, and none of those applications
> implement
> > message authentication, the messaging middleware platform itself becomes
> an attractive target for a well-resourced adversary. Simply signing the
> messages
> > passing through the system removes the pressure on the broker to ensure
> integrity, and reduces the value of a compromised broker.
>
> But again, at a price of exposing the identity and the IP address /
> locatin of the client. That makes it vulnerable to DoS attacks, eg
> flood pings to its IP, or more subtle timing attacks - eg I ping it but
> depending on the response time I can infer it is busy or not with its
> actual job.


> Paul
>


-- 

*Ash Wilson* | Technical Director
*e:* ash.wilson@valimail.com

This email and all data transmitted with it contains confidential and/or
proprietary information intended solely for the use of individual(s)
authorized to receive it. If you are not an intended and authorized
recipient you are hereby notified of any use, disclosure, copying or
distribution of the information included in this transmission is prohibited
and may be unlawful. Please immediately notify the sender by replying to
this email and then delete it from your system.