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

[Christian Amsüss]

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

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

[Carsten Bormann]

(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

[Carsten Bormann]

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

[Jim Schaad]

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

-----Original Message-----
Sent: 01 February 2017 11:23
Subject: Re: OSCOAP: Unauthenticated host name? (was: Re: OSCOAP plug
test)

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

[Christian Amsüss]

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.

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

[Göran Selander]

On 2017-02-01 21:57, "core on behalf of Christian Amsüss"

Post by Christian Amsüss
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.

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.

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

[Christian Amsüss]

[...] 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

[Göran Selander]

Hi Christian,

Inline.

Post by Christian Amsüss

[...] 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.

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

Post by Christian Amsüss
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’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?

Post by Christian Amsüss
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

[Göran Selander]

Post by Christian Amsüss

[...] 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.

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

[Jim Schaad]

-----Original Message-----
Sent: 02 February 2017 01:28
Subject: Re: [core] OSCOAP: Unauthenticated host name? (was: Re: OSCOAP
plug test)

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

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

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

[Jim Schaad]

-----Original Message-----
Sent: 01 February 2017 12:58
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.

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.


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

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