Subject: [core] Mail regarding draft-ietf-core-coap

From: Kawai Wong <[email-masked]>
Date: Wed, 15 Jul 2020 02:34:34 +0000

Hi,
Our organisation is using CoAP and we have require a special use case to provide authorization for CoAP requests, much like how there’s an Authorization header for HTTP.

At the moment RFC7252 does not have any mechanism in place for this.

We are wondering if we can get an Option number included for this purpose as part of the standard? e.g.

  *   Bearer Option with opaque option format for bearer tokens; Or
  *   Authorization Option also an opaque option format

Please do let me know what your thoughts are and the considerations taken into account for registering a new option number to be included as part of the standard.

Thanks,
Kawai Wong | Solutions Developer - Informatics

Ext: 7868
Email: [email-masked]<mailto:[email-masked]>
www.fphcare.com<http://www.fphcare.com/>

[signature_1152559984]

---

From: Michael Richardson <[email-masked]>
Date: Tue, 21 Jul 2020 09:00:18 -0400

Kawai Wong <[email-masked]> wrote:
    > Our organisation is using CoAP and we have require a special use case
    > to provide authorization for CoAP requests, much like how there’s an
    > Authorization header for HTTP.

CoAP or coaps?
OSCORE?

    > *   Authorization Option also an opaque option format

Thank you for thinking about this as a bearer token, rather than a password :-)

    > Please do let me know what your thoughts are and the considerations
    > taken into account for registering a new option number to be included
    > as part of the standard.

I can't help but think that if the bearer token is something both parties
already have, that you are better off using OSCORE with PSK authentication.

If the bearer token is something the client has and the server can
evaluate for correctness (it has structure meaningful to the server), then a
different consideration would be in order.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Jim Schaad <[email-masked]>
Date: Tue, 21 Jul 2020 07:25:01 -0700

> -----Original Message-----
> From: core <[email-masked]> On Behalf Of Michael Richardson
> Sent: Tuesday, July 21, 2020 6:00 AM
> To: Kawai Wong <[email-masked]>
> Cc: [email-masked]; [email-masked]
> Subject: Re: [core] Mail regarding draft-ietf-core-coap
> 
> 
ACE?

> Thank you for thinking about this as a bearer token, rather than a password :-)'

One of the things that should be taken into account is the size of the options.  Large options are better carried as part of the payload since all options are resent as part of every block-wise transfer message.  Additionally, you can have issues with fragmentation based on large options.

> I can't help but think that if the bearer token is something both parties already
> have, that you are better off using OSCORE with PSK authentication.
> 
> If the bearer token is something the client has and the server can evaluate for
> correctness (it has structure meaningful to the server), then a different
> consideration would be in order.

I worry somewhat about the use of bearer tokens if you are not including an additional security layer such as OSCORE or DTLS (which is not end-to-end) as bearer tokens can be stolen and potentially used by attackers.

Jim

> 
> --
> Michael Richardson <[email-masked]>, Sandelman Software Works  -
> = IPv6 IoT consulting =-
> 
>

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 22 Jul 2020 06:49:54 +0200

Hi Kawai,

I’m not sure your actual question has been answered yet.  Let me try.

> On 2020-07-15, at 04:34, Kawai Wong <[email-masked]> wrote:
> 
> Hi,

First, a matter of terminology.  The header field that HTTP calls “Authorization” actually is about authentication.  RFC 7235 says (section 4.2):

   The "Authorization" header field allows a user agent to authenticate
   itself with an origin server […]

(The authentication could then be used to derive some authorization locally in the server, but that is not further specified here.)
 
> 	• Bearer Option with opaque option format for bearer tokens; Or
> 	• Authorization Option also an opaque option format

Yes, you can register such an option.
The registration procedure is described in Section 12.2 of RFC 7252 and involves a “Designated Expert” to ensure that the option number encodes the right bits (Critical/Elective etc.; see Section 5.4.6 of RFC 7252).

So this registry has been open for seven years now.  Curiously, in all this time, nobody has registered a bearer token option.  Why might that be?

As others have hinted, a bearer token is very insecure unless it is protected by some channel or object security.  I’ll assume DTLS here, because that has been part of the CoAP security solutions from the start, but similar approaches are possible with OSCORE (RFC 8613).

So you’ll want to set up a DTLS connection to protect that bearer token.
But in that connection setup, you can already provide authentication for both client and server.  Then there is no need to tediously send a bearer token with every request, which for CoAP might more than double its size.

Why isn’t HTTP doing that?  Probably for the same reason the Authorization header isn’t really used that much in HTTP:  For the browser web, the browser wants to obtain HTML with a user interface for setting up the authentication (password entry), so it needs to have the TLS connection set up already first.  This means that in HTTP, usually only the server authenticates (you can find grueling details about what needs to be done to do client authentication in a browser with HTTPS); instead Cookies are used to eventually convert client authentication into a more or less ephemeral bearer token.

The whole bearer token concept doesn’t work that great in the IoT.
In the browser web, you have a single server (think Facebook.com — even though that is replicated a lot, it appears as a single server to the client) for which you would use the bearer token.  In the IoT, you are talking to dozens or hundreds of little servers, which have no good way to synchronize their bearer tokens (and, if they did, that would be a massive security hole with the ease with with IoT devices can be stolen).  Instead, you would negotiate one bearer token with each of them.  But if you do that, you essentially have a one-on-one shared secret that instead can be used for setting up secure DTLS connections.  You can get these secrets from protocols such as ACE-OAuth before even talking to the server.  ACE-OAuth also provides a way to provision the actual authorization information that applies to the authenticated client (e.g., using draft-bormann-core-ace-aif to build a  token that is then securely forwarded to the server).

I hope this little rationale helps, and we can stay with the situation we have since 2013: we don’t have (because we don’t need) a bearer token option registered for CoAP.

Grüße, Carsten