Subject: [core] OSCOAP: Unauthenticated host name? (was: Re: OSCOAP plug test)

From: Christian Amsüss <[email-masked]>
Date: Wed, 1 Feb 2017 10:16:33 +0100

On Wed, Feb 01, 2017 at 08:32:24AM +0100, Carsten Bormann wrote:
> Maybe we should move this discussion on-list.

Now CC'd.

(Context from the previous thread: What about plain IP addresses? What
if a host has no name? What if a proxy needs to switch schemes inbetween
due to modified transports?)

> On 1 Feb 2017, at 08:08, Jim Schaad <[email-masked]> wrote:
> > 
> > URL of the server
> 
> Well, we need to authenticate the Uri-Path/Uri-Query part, as that may be the essence of the request.
> 
> But you are right that the authority part of the URL is more volatile
> in CoAP than in HTTP, as may be the scheme.  So maybe authenticating
> the origin (scheme + authority) can be substituted by some data
> destination authentication.  Is that something we always want to do?

If we switched to merely using the security context when facing the
application (ie. the part that trusts OSCOAP with its unprotected
messages), I'm uncertain about what addresses the application would use,
and what that would mean for being part of the linkable web.

To me, using crypto parts (be it the CID or some derivative of the key)
reminds me of the .onion naming scheme (and the troubles it causes).
Would an application that uses OSCOAP really want to substitute linking
to `coap://host.domain/path` with `coap+oscoap://hex-key/path`? (Because
if that's what we're protecting, that's what the application gets as
trustworthy data).

Is there a middle ground, where applications can still use name
resolution and rely on the OSCOAP layer to figure out which keys are
trusted to sign off the given host name?

> Is the security association for data destination authentication always
> identical to that we use for the authentication in general?

Do you mean situations in which the individual device can vouch for its
data but is ignorant of its own name, and a device inbetween (like a bus
arbiter) would add a secured name to the data?

Best regards
Christian

-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 1 Feb 2017 10:34:10 +0100

(When you reply to the referenced message, please trim the recipient list — with a very long CC list, the chairs have to moderate every single message.)

Grüße, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 1 Feb 2017 20:23:27 +0100

> On 1 Feb 2017, at 20:15, Jim Schaad <[email-masked]> wrote:
> 
> URL of the server

That would be the origin part of the URI (scheme, authority, port) — the rest of the URI of course still needs to be authenticated.

(RFC 6454 defines the concept of origin, and explains why it is so important in the HTTP Web — may be less so in the CoAP Web.)

Grüße, Carsten

---

From: Jim Schaad <[email-masked]>
Date: Wed, 1 Feb 2017 11:15:09 -0800

I have apparently done a bad job of explaining what I was talking about in
my original message.  Some of the original context appears to have been
lost.

1.  The key that is going to be used is still identified by a key identifier
in the message.  That does not change from today.

2.  Currently the URL of the server is included in a request as part of the
externally authenticated information.  Thus, for example the string
"coap:/[::1]" might be included in the authenticated information if I was
sending a message back to a server on the same machine.

3.  It is my belief that having the text string URL for the server as part
of the authenticated information is both extraneous, the fact that the
message can be decrypted is essentially equivalent, and potentially a
problem if there are NATs or multiple proxies involved in the system.

My suggestion has nothing to do with how messages are routed or how keys are
identified.

Jim

> -----Original Message-----
> From: Christian Amsüss [mailto:[email-masked]]
> Sent: 01 February 2017 01:17
> To: Carsten Bormann <[email-masked]>
> Cc: core <[email-masked]>; Jim Schaad <[email-masked]>; Francesca
> Palombini <[email-masked]>; Göran Selander
> <[email-masked]>; Martin Gunnarsson
> <[email-masked]>; John Mattsson
> <[email-masked]>; Jaime Jiménez
> <[email-masked]>; Mališa Vučinić <[email-masked]>;
> Ludwig Seitz <[email-masked]>
> Subject: OSCOAP: Unauthenticated host name? (was: Re: OSCOAP plug test)
> 
> (Context from the previous thread: What about plain IP addresses? What if
a
> host has no name? What if a proxy needs to switch schemes inbetween due
> to modified transports?)
> 
> > Well, we need to authenticate the Uri-Path/Uri-Query part, as that may
be
> the essence of the request.
> >
messages),
> I'm uncertain about what addresses the application would use, and what
that
> would mean for being part of the linkable web.
> 
> Would an application that uses OSCOAP really want to substitute linking to
> `coap://host.domain/path` with `coap+oscoap://hex-key/path`? (Because if
> that's what we're protecting, that's what the application gets as
trustworthy
> data).
> 
> Is there a middle ground, where applications can still use name resolution
> and rely on the OSCOAP layer to figure out which keys are trusted to sign
off
> the given host name?
data
> but is ignorant of its own name, and a device inbetween (like a bus

---

From: Christian Amsüss <[email-masked]>
Date: Wed, 1 Feb 2017 21:57:47 +0100

Hello Jim,

> My suggestion has nothing to do with how messages are routed or how keys are

thank you, that does make the topic of this thread clearer to me.

Relying plainly on the CID or similar would interact badly with
scenarios where virtual hosting is employed, or where a forward proxy is
the termination point of OSCOAP: Say a CoAP gateway to a proprietary (or
otherwise non-CoAP-capable) network is using virtual hosts to present
devices behind it. In such a situation, if the host name were left out
of the AAD, the Uri-Host could be switched out by a MITM, and the
gateway would forward the request to the wrong device without that
triggering security measures.

We could move Uri-Host inside OSCOAP in such situations (however they're
identified), but when proxying is involved, the information would still
be needed outside, which I think led to the "A" category of options in
OSCOAP.

Best regards
Christian

---

From: Jim Schaad <[email-masked]>
Date: Wed, 1 Feb 2017 13:26:23 -0800

Right, but given that CoAP is using different security primitives I think that the analysis is going to be completely different.

In HTTP we are using public key cryptography.  This means that we need to match the origin as testified by the certificate with the origin that we expected.  We need to verify that we are not getting an answer back from somebody else.

In the CoAP web, we are using mutual authentication from shared secrets.  This means that we have the origin testified by the shared secret rather than from the public key.  The secret itself is the authentication proof.

Jim

> From: Carsten Bormann [mailto:[email-masked]]
> Sent: 01 February 2017 11:23
> To: Jim Schaad <[email-masked]>; core <[email-masked]>
> Subject: Re: OSCOAP: Unauthenticated host name? (was: Re: OSCOAP plug
> test)
> 
> 
> That would be the origin part of the URI (scheme, authority, port) — the rest
> of the URI of course still needs to be authenticated.
> 
> (RFC 6454 defines the concept of origin, and explains why it is so important in
> the HTTP Web — may be less so in the CoAP Web.)
> 
> Grüße, Carsten

---

From: Göran Selander <[email-masked]>
Date: Thu, 2 Feb 2017 07:14:16 +0000

>be needed outside, which I think led to the "A" category of options in

Indeed. In the forward proxy setting targeted by OSCOAP the client knows
the URI of the origin server and is protecting the message for this origin
server, such that the origin server is able to verify that the message
received from the forward proxy had the intended URI.

If we want to support a more general setting where the uri-host/path could
be replaced/removed (still maintaining the uri-path/query as Carsten
pointed out) we could remove the unencrypted-uri in the external_aad.

If unencrypted-uri is not used, it does not lead to the wrong server
believing it is the target for the request. As Jim pointed out, the key
used to protect the message would be different and so the integrity
verification would fail in this case.

Note that independently of unencrypted-uri, the proxy is anyway not able
to verify if a MITM has switched the uri-host/port. To the proxy, the
uri-host/port is needed to handle the message, including the case of the
proxy itself or a virtual host, but security-wise it is just a “hint”,
analogously to the kid being a hint to which key is used. This is assuming
different virtual hosts etc. have different keys, which anyway should be
the security practise.

The current format enables the server to verify both that it is the target
and that the right URI has been used, maybe the latter is too ambitious?

Göran

---

From: Jim Schaad <[email-masked]>
Date: Wed, 1 Feb 2017 23:16:04 -0800

> Sent: 01 February 2017 12:58
> To: Jim Schaad <[email-masked]>
> Cc: 'Carsten Bormann' <[email-masked]>; 'Mališa Vučinić'
> <[email-masked]>; 'core' <[email-masked]>; 'Martin Gunnarsson'
> <[email-masked]>
> Subject: Re: [core] OSCOAP: Unauthenticated host name? (was: Re: OSCOAP
> plug test)
> 
> Hello Jim,
> 
> > 3.  It is my belief that having the text string URL for the server as
> > part of the authenticated information is both extraneous, the fact
> > that the message can be decrypted is essentially equivalent, and
> > potentially a problem if there are NATs or multiple proxies involved in
the
> system.
> >
> > My suggestion has nothing to do with how messages are routed or how
> > keys are identified.
> 
> Relying plainly on the CID or similar would interact badly with scenarios
> where virtual hosting is employed, or where a forward proxy is the
> termination point of OSCOAP: Say a CoAP gateway to a proprietary (or
> devices behind it. In such a situation, if the host name were left out of
the
> AAD, the Uri-Host could be switched out by a MITM, and the gateway would
> forward the request to the wrong device without that triggering security
> measures.
> 
> identified), but when proxying is involved, the information would still be
> needed outside, which I think led to the "A" category of options in
OSCOAP.

If all we need is to have Uri-Host there is another alternative.  Iff a
Uri-Host field exists then authenticate JUST that field.

I find the above case interesting as it demonstrates a need for this
specific field in a way that is useful.  I keep having this problem that I
am not sure what the setups are that CoAP is using.  In this case do you see
a need for being able to have the scheme and port protected as well?  It
might make sense to do the same that as above, that is only authenticate the
fields if they are present and not try to infer what the content might be.
I still worry about having schemas change as you go through proxies however.

Jim

---

From: Christian Amsüss <[email-masked]>
Date: Thu, 2 Feb 2017 10:27:32 +0100

On Thu, Feb 02, 2017 at 07:14:16AM +0000, Göran Selander wrote:
> [...] This is assuming different virtual hosts etc. have different
> keys, which anyway should be the security practise.

I think this is key here. If we state that a context is bound to a host
name, we don't need to verify the host name.

This would, however, open up another question:

How does this interact with role interchange (3.2, "endpoints MAY
interchange [...] roles while maintaining the same security context")?
Could a host name be bound to each of the sender/recipient IDs, and role
reversal would not be possible if the possible if the client didn't have
a hostname assigned for the context?

Note that this topic *is* tricky already now, for the server asking back
a client might not know what to put in the outer Uri-Host field, but it
can at least work around it by picking something like
`123456.client.my-hostname.my-domaincom` and send it for the client to
ignore but verify.

I hope I'm not overly nitpicking here (please tell me if I am).

Christian

---

From: Göran Selander <[email-masked]>
Date: Thu, 2 Feb 2017 10:43:00 +0000

Hi Christian,

Inline.

>name, we don't need to verify the host name.

Good, then we may have a resolution to Jim’s issue.

>`123456.client.my-hostname.my-domaincom` and send it for the client to

I’m not sure I understand your proposal exactly, but I think you may have
a point. 

OSCOAP assumes that the client can retrieve the security context for a
target host/resource, and how this is established is out of scope (e.g.
using a trusted third party like an authorisation server or some discovery
procedure). The same also applies to the role interchange and how the new
client/former server associates a host/resource of the new server/former
client to an existing security context.

However, to support that case we may want to give an example for how a
client can securely provide information about what host name to use when
accessing resources on its host protected with the current security
context. E.g. the client could make a POST to a certain resource on the
server (to-be client) containing such information. Would something like
that be useful?

>I hope I'm not overly nitpicking here (please tell me if I am).

Thanks for asking good questions, you are in no (bad) way nitpicking here!

Göran

---

From: Göran Selander <[email-masked]>
Date: Thu, 2 Feb 2017 11:07:01 +0000

Just one clarification:

>name, we don't need to verify the host name.

There may still be different security contexts for different resources, or
multiple security contexts for a given resource, on a given server. The
important things here are:

- the server can resolve a received context identifier to a security
context

- the same security context is not used on different servers (so the
context/key + resource identifier uniquely identifies the resource).

Göran

---

From: Jim Schaad <[email-masked]>
Date: Thu, 2 Feb 2017 12:46:51 -0800

> Sent: 02 February 2017 01:28
> To: Göran Selander <[email-masked]>
> Cc: Jim Schaad <[email-masked]>; 'core' <[email-masked]>
name, we
> don't need to verify the host name.
> 
> reversal would not be possible if the possible if the client didn't have a
> hostname assigned for the context?
> 
> Note that this topic *is* tricky already now, for the server asking back a
client
> might not know what to put in the outer Uri-Host field, but it can at
least
> work around it by picking something like `123456.client.my-hostname.my-
> domaincom` and send it for the client to ignore but verify.
> 
> 

I think you might be overly nitpicking - however that is where I find most
of the problems in the world is when I do that.  So don't stop on my
account.

The server name would be tied to the "recipient" name in side of the
context.  When you distribute, you could actually use the server name as the
recipient id in some cases - or in addition to it.

Thus I would distribute:

Context ID: abcd
Master Secret: 12345
<Recipient #1 - YOU>
   Recipient ID:
   Server Name
</end>
<Recipient #2 - Them>
   Recipient ID:
  Server Name
</end>

This could then be repeated for the multicast case.  If the concept of a
server name for an entity does not make sense, then the field could be
omitted and you can continue per normal.

You are going to have a server name tied to each end of the context, not a
single name for the context.

Jim