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

[Carsten Bormann <[e-mail]>]

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 <[e-mail]> wrote:
> 
> 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.

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.)
 
> 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

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