Re: [Danish] Proposed WG Charter

[Ash Wilson <[e-mail]>]

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

On Tue, Jun 15, 2021 at 12:14 PM Paul Wouters <[e-mail]> 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:* [e-mail]

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.