Subject: [Ace] End-to-End Scenarios

From: "Jim Schaad" <[email-masked]>
Date: Sat, 19 Sep 2015 19:51:27 -0700

The previous discussion got sidetracked from where it really needed to go.
So I want to do a restart and focus on a different aspect.  In order to
evaluate a solution, one needs to have as comprehensive list of the unique
scenarios where the solution needs to function.  I want to try and get some
help in building this list.  The list will also need to include some
security constructs that may be included.   I am assuming that there has
been something that created the security context and that the security
context is distributed to the correct entities.  (I understand that one
variation for doing so assumes that the context may be relayed to the server
via the client.)

I think the list starts as follows:

1.  One way command: This covers Put, Delete and so forth.
	C1 sends a command to S1.   S1 can 1) not reply, 2) reply success,
3) reply failure

2.  Query/Response:  This covers Get
	C1 requests R1 from S1.  S1 can 1) reply with data, 2) reply with
failure.

3.  Observation:
	C1 observes R1 on S1.
		S1 can 1) reply with data, 2) reply with failure, 3) reply
success but no data (?)
	C1 cancels observe of R1 on S1 
		S1 can 1) reply with success, 2) reply with failure
	S1 sends data on R1 to C1

4.  Observation with data server:
	C1 observes R1 from S1 on S2
		S2 can 1) reply with data, 2) reply with failure, 3) reply
success but no data
	C1 cancels observing R1
		S2 can 1) reply with success, 2) reply with failure
	S2 send data about R1 to C1
	** S2 may not have access to data about R1
	** Security context to communicate with S1 and S2 from C1 may be
different and not overlap
	** S2 may be required to verify data came from S1, but not be able
to access R1.

5.  Use of a Proxy Server
	All of cases 1 through 4 need to be repeated but with a proxy server
P1 between C1 and the entity it is talking to.

What operations and data flows am I still missing?

Jim

---

From: Olaf Bergmann <[email-masked]>
Date: Mon, 21 Sep 2015 15:29:26 +0200

Jim,

"Jim Schaad" <[email-masked]> writes:

> comprehensive list of the unique scenarios where the solution needs to
> function

Thank you for getting the focus back to the problem that is to be
solved. I think that your list pretty much covers the scenarios that
have been discussed in ACE so far.

> 	C1 sends a command to S1.   S1 can 1) not reply, 2) reply success,

A REST-style protocol does not allow "not reply" per se but it might be
important to keep in mind that an implementation might choose to send no
reply, and for CoAP, the client even may suggest this by sending the
No-Response option. But then, this also holds for the other top-level
list items and observation cancellation (although it does not make sense
for all of them.)

In short: I do not think that we need to list the "not reply" scenario
but keep in mind that S always may decide to send no response.

> 		S1 can 1) reply with data, 2) reply with failure, 3) reply

Yes -- it's in the discretion of S1 to put any data into its response,
i.e. it could be empty as well. This makes 3) a valid subset of 1). (And
it may be useful to list this explicitely as done here.)

> What operations and data flows am I still missing?

Grüße
Olaf

---

From: "Jim Schaad" <[email-masked]>
Date: Mon, 21 Sep 2015 19:53:47 -0700

> -----Original Message-----
> From: Olaf Bergmann [mailto:[email-masked]]
> Sent: Monday, September 21, 2015 6:29 AM
> To: Jim Schaad <[email-masked]>
> Cc: [email-masked]
> Subject: Re: [Ace] End-to-End Scenarios
> 
> Jim,
> 
> Thank you for getting the focus back to the problem that is to be solved. I think
> that your list pretty much covers the scenarios that have been discussed in ACE
> so far.
> 
> A REST-style protocol does not allow "not reply" per se but it might be important
> to keep in mind that an implementation might choose to send no reply, and for
> CoAP, the client even may suggest this by sending the No-Response option. But
> then, this also holds for the other top-level list items and observation
> cancellation (although it does not make sense for all of them.)
> 
> In short: I do not think that we need to list the "not reply" scenario but keep in
> mind that S always may decide to send no response.

I had not been thinking in terms of what S1 chose to do when I wrote that, but in terms of fact that CoAP provides for a confirmable version of operations.    However, the main reason was to be exhaustive.  It may be that we need to think about different implications of S1 replying or not replying in terms of security properties.  I have no idea if this is going to be true however.

> > 		S1 can 1) reply with data, 2) reply with failure, 3) reply success
> > but no data (?)
> 
> Yes -- it's in the discretion of S1 to put any data into its response, i.e. it could be
> empty as well. This makes 3) a valid subset of 1). (And it may be useful to list this
> explicitely as done here.)

Good to know. I wasn't sure if that was the case without the proxy.

> > 		S2 can 1) reply with data, 2) reply with failure, 3) reply success
> > but no data
> > 	C1 cancels observing R1
> > 	** S2 may be required to verify data came from S1, but not be able to
> > access R1.
> >
> > 5.  Use of a Proxy Server

---

From: Göran Selander <[email-masked]>
Date: Tue, 22 Sep 2015 04:44:50 +0000

>variation for doing so assumes that the context may be relayed to the

Just to be clear, there are ACE use cases where a client and a server does
not have context with each other, and we need support from COSE to
establish that using a TTP, but I understand if you don’t want to discuss
that in this mail thread.

>	C1 requests R1 from S1.  S1 can 1) reply with data, 2) reply with

I don’t understand the distinction between "command with reply” in 1. and
"Query/Response” in 2.

Do you consider POST be of type 1. or type 2., or doesn’t it matter?

In terms of security constructs, there is a need for a 2-pass PUT
Query/Response (e.g. "Lock a door") , whereas GET Response could be a
1-pass secure message (properly identified and versioned) preceded by an
unprotected GET Request. But maybe this comes later? (There is also a
4-pass “Unlock a door", but I don’t think that should be solved by COSE.)

>	** S2 may be required to verify data came from S1, but not be able

Since you want to be exhaustive, there are operations between Resource
Server (S1) and Data Server (S2).
Mapping between your notation and notation of draft-ietf-ace-actors:

C1 in ACE C; 

S1 in ACE RS; 

S2 in Data Server; 

Alternative data flows:

C2 in Data Server requests with GET (optionally Observe) to S1 in ACE RS;

C3 in ACE RS requests with PUT/POST to S3 (potentially S2) in Data Server;

Göran

>_______________________________________________
>Ace mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/ace

---

From: "Jim Schaad" <[email-masked]>
Date: Mon, 21 Sep 2015 22:37:53 -0700

> From: Göran Selander [mailto:[email-masked]]
> Sent: Monday, September 21, 2015 9:45 PM
> To: Jim Schaad <[email-masked]>; [email-masked]
> >evaluate a solution, one needs to have as comprehensive list of the
> >unique scenarios where the solution needs to function.  I want to try
> >and get some help in building this list.  The list will also need to
> >include some
> >variation for doing so assumes that the context may be relayed to the
> >server via the client.)
> 
> Just to be clear, there are ACE use cases where a client and a server does not
> have context with each other, and we need support from COSE to establish that
> using a TTP, but I understand if you don’t want to discuss that in this mail thread.

I understand that this is needed.  This is going to be true for the multi-cast DTLS as well.  I am assuming that this protocol is going to be written using the REST principles so that this conversation is relevant.  What would still need to be discussed at a later date is the internal message structure.  How much do we believe that the requirements of this are currently documented?

> Do you consider POST be of type 1. or type 2., or doesn’t it matter?

I would think of POST as being of type 1.  The difference for me between type 1 and type 2 is the question  - does this operation require a response or is the response just necessary if the CoAP message is marked confirmable.   The concept of a Get for which there is no response makes no sense.  This is not true for a POST.

> 
> 
> In terms of security constructs, there is a need for a 2-pass PUT Query/Response
> (e.g. "Lock a door") , whereas GET Response could be a 1-pass secure message
> (properly identified and versioned) preceded by an unprotected GET Request.
> But maybe this comes later? (There is also a 4-pass “Unlock a door", but I don’t
> think that should be solved by COSE.)

Please explain.  I don't understand what you are saying.   A couple of flow diagrams may be helpful.

> Since you want to be exhaustive, there are operations between Resource Server
> (S1) and Data Server (S2).

I don't believe that these need to be dealt with separately, but I could be wrong.  Are these not just the same operations with either the Resource Server or the Data Server as the C1 and the other as S1?  Unless there are three parties I don't believe that this introduces any new wrinkles.  Do you have any ones in mind where there might be differences?

> C2 in Data Server requests with GET (optionally Observe) to S1 in ACE RS;

This would be case #2 or #3 above.

> C3 in ACE RS requests with PUT/POST to S3 (potentially S2) in Data Server;

This would be case #1 above.

Jim

---

From: Göran Selander <[email-masked]>
Date: Tue, 22 Sep 2015 07:02:18 +0000

On 2015-09-22 07:37, "Jim Schaad" <[email-masked]> wrote:

>I understand that this is needed.  This is going to be true for the
>multi-cast DTLS as well.  I am assuming that this protocol is going to be
>written using the REST principles so that this conversation is relevant.
>What would still need to be discussed at a later date is the internal
>message structure.  How much do we believe that the requirements of this
>are currently documented?

For example, ACRE (draft-seitz-ace-core-authz-00) contains the basic
cases. And, yes, one of the principles of ACRE is to establish context
using RESTful resources. But there is no list of requirements. In the next
version this will probably be more clear.

>I would think of POST as being of type 1.  The difference for me between
>type 1 and type 2 is the question  - does this operation require a
>response or is the response just necessary if the CoAP message is marked
>confirmable.   The concept of a Get for which there is no response makes
>no sense.  This is not true for a POST.
>
>> 
>> 
>>Query/Response

Publish-subscribe is one example of 1-pass GET Response (between S1 and S2
in 4. below).

For 2-pass PUT (should probably be POST) Query/Response “lock a door”
think e.g. about:

http://www.theguardian.com/technology/2015/may/26/high-tech-thieves-jamming
-technology-steal-car

The current protocol is based on the user watching the blinking lights of
the car confirming it being locked. Better if the key device verified that
the lock request was received, and if not alerted the user.

For "Unlock a door” think of the same scenario where the PUT/POST unlock
request from the key device is recorded by the adversary. Then it waits
for the user to give up and leave. Then it plays back the recorded request
(note, this is not a replay). This can be mitigated by more round trips,
actually 3-pass is sufficient. But again, this should probably be in the
application of COSE.

Sorry no flow charts, but perhaps possible to understand anyway?

>I don't believe that these need to be dealt with separately, but I could
>be wrong.  Are these not just the same operations with either the
>Resource Server or the Data Server as the C1 and the other as S1?  Unless
>there are three parties I don't believe that this introduces any new
>wrinkles.  Do you have any ones in mind where there might be differences?
>

Agree, just wanted to be explicit.

Göran

---

From: Olaf Bergmann <[email-masked]>
Date: Tue, 22 Sep 2015 13:55:21 +0200

>> From: Olaf Bergmann [mailto:[email-masked]]
[...]
> I had not been thinking in terms of what S1 chose to do when I wrote
> that, but in terms of fact that CoAP provides for a confirmable
> version of operations.

Okay. So, CoAP requires an acknowledgement on the message layer to be
sent for confirmable messages which then stops retransmission. A correct
server will send that. On the request/response layer (where the response
may be separate from the acknowledgement message), the server could
defer the response to a request indefinitely, if it sees reason to do so.

Thus I completely agree with your split between GET and PUT/DELETE/PATCH
in that a GET request without a response usually does not make much
sense. POST is somewhat special in that one possible effect of POST is
to create a new resource whose URI is returned in the response.

> However, the main reason was to be exhaustive.  It may be that we need
> to think about different implications of S1 replying or not replying
> in terms of security properties.  I have no idea if this is going to
> be true however.

Same here.

It just came to my mind that for scenario 3, there is an additional
cancellation mechanism: S1 can send a notification, C can respond with a
reset message to remove the observation relationship at the
server. Usually, this happens when C lost state but nothing stops C from
using that same mechanism to tell S1 that it should stop sending
notifications.

Grüße
Olaf

---

From: "Jim Schaad" <[email-masked]>
Date: Tue, 22 Sep 2015 22:43:21 -0700

> Sent: Tuesday, September 22, 2015 12:02 AM
> >> >The previous discussion got sidetracked from where it really needed
> >> >to
> >>go.
> >> >So I want to do a restart and focus on a different aspect.  In order
> >> >to evaluate a solution, one needs to have as comprehensive list of
> >> >the unique scenarios where the solution needs to function.  I want
> >> >to try and get some help in building this list.  The list will also
> >> >need to include some
> >> >been something that created the security context and that the
> >> >security context is distributed to the correct entities.  (I
> >> >understand that one variation for doing so assumes that the context
> >> >may be relayed to the server via the client.)
> >>
> >> Just to be clear, there are ACE use cases where a client and a server
> >>does not  have context with each other, and we need support from COSE
> >>to establish that  using a TTP, but I understand if you don’t want to
> >>discuss that in this mail thread.
> >
> >multi-cast DTLS as well.  I am assuming that this protocol is going to
> >be written using the REST principles so that this conversation is relevant.
> >message structure.  How much do we believe that the requirements of
> >this are currently documented?
> 
> For example, ACRE (draft-seitz-ace-core-authz-00) contains the basic cases.
> And, yes, one of the principles of ACRE is to establish context using RESTful
> resources. But there is no list of requirements. In the next version this will
> probably be more clear.
> 
> >
> >>
> >> >
> >I would think of POST as being of type 1.  The difference for me
> >between type 1 and type 2 is the question  - does this operation
> >require a response or is the response just necessary if the CoAP message is
> marked
> >>1-pass secure message  (properly identified and versioned) preceded by
> >>an unprotected GET Request.
> >> But maybe this comes later? (There is also a 4-pass “Unlock a door",
> >>but I don’t  think that should be solved by COSE.)
> >
> Publish-subscribe is one example of 1-pass GET Response (between S1 and S2 in
> 4. below).
> 
> 
> The current protocol is based on the user watching the blinking lights of the car
> confirming it being locked. Better if the key device verified that the lock request
> was received, and if not alerted the user.
> 
> request from the key device is recorded by the adversary. Then it waits for the
> user to give up and leave. Then it plays back the recorded request (note, this is
> not a replay). This can be mitigated by more round trips, actually 3-pass is
> sufficient. But again, this should probably be in the application of COSE.
> 

So if I understand correctly, you are talking about the fact that there might be some special circumstances  that might be applied to a series of related messages where each message will have different content and might be different operations (i.e. a Put followed by a Get).

Side note:  I have always called that a replay attack since the message was intercepted and replayed, it is just a specialized version of one where the message is prevented from arriving at the destination.  These show up all of the time in terms of resets or out of order replays that need to be looked at.

Jim

> >I don't believe that these need to be dealt with separately, but I
> >could be wrong.  Are these not just the same operations with either the
> >Resource Server or the Data Server as the C1 and the other as S1?
> >Unless there are three parties I don't believe that this introduces any
> >new wrinkles.  Do you have any ones in mind where there might be
> differences?
> >

---

From: Göran Selander <[email-masked]>
Date: Wed, 23 Sep 2015 06:12:11 +0000

On 2015-09-23 07:43, "Jim Schaad" <[email-masked]> wrote:

>>cases.
>>for the
>So if I understand correctly, you are talking about the fact that there
>might be some special circumstances  that might be applied to a series of
>related messages where each message will have different content and might
>be different operations (i.e. a Put followed by a Get).

This is a very general statement but what I had in mind fits into the
description.  We will probably have a specific proposal for how to handle
this type of problems.

Göran

>
>Side note:  I have always called that a replay attack since the message
>was intercepted and replayed, it is just a specialized version of one
>where the message is prevented from arriving at the destination.  These
>show up all of the time in terms of resets or out of order replays that
>need to be looked at.
>
>Jim
>
>
>>

---

From: "Jim Schaad" <[email-masked]>
Date: Wed, 23 Sep 2015 13:29:52 -0700

> Sent: Tuesday, September 22, 2015 11:12 PM
> >> >>Query/Response  (e.g. "Lock a door") , whereas GET Response could
> >> >>be a 1-pass secure message  (properly identified and versioned)
> >> >>preceded by an unprotected GET Request.
> >> >> But maybe this comes later? (There is also a 4-pass “Unlock a
> >> >>door", but I don’t  think that should be solved by COSE.)
> >> >
> >> Publish-subscribe is one example of 1-pass GET Response (between S1
> >>and
> >>S2 in
> >> 4. below).
> >>
> >>
> >> The current protocol is based on the user watching the blinking
> >>lights of the car  confirming it being locked. Better if the key
> >>device verified that the lock request  was received, and if not
> >>alerted the user.
> >>
> >> For "Unlock a door” think of the same scenario where the PUT/POST
> >>unlock  request from the key device is recorded by the adversary. Then
> >>it waits for the  user to give up and leave. Then it plays back the
> >>recorded request (note, this is  not a replay). This can be mitigated
> >>by more round trips, actually 3-pass is  sufficient. But again, this
> >>should probably be in the application of COSE.
> >>
> >
> >might be some special circumstances  that might be applied to a series
> >of related messages where each message will have different content and
> >might be different operations (i.e. a Put followed by a Get).
> 
> This is a very general statement but what I had in mind fits into the description.
> We will probably have a specific proposal for how to handle this type of
> problems.

Would you characterize all of these n-pass situations as being part of a single "transaction" or do you not believe that to be the case?

Jim

---

From: Göran Selander <[email-masked]>
Date: Thu, 24 Sep 2015 04:31:57 +0000

On 2015-09-23 22:29, "Jim Schaad" <[email-masked]> wrote:

>> >> >Please explain.  I don't understand what you are saying.   A couple
>>of
>> >> >flow diagrams may be helpful.
>> >>
>> >>
>>description.
>Would you characterize all of these n-pass situations as being part of a
>single "transaction" or do you not believe that to be the case?

The two more-than-1-pass “situations” mentioned here are about protecting
actuations of the kind “turn on” / "turn off” from certain threats of DoS
and/or replay. If you consider “turn on” and “turn off” to be "single
transactions” then yes.

I can’t say how this would look in general, but I would think there is
only a few variants depending on which party/parties require freshness and
which party initiates or requires confirmation that the transaction is
finished.

Note that the issue is not object security related, the attack applies
equally well to TLS record layer. So it should not be should not be solved
in COSE or OSCOAP.

Göran