Re: [Ace] End-to-End Scenarios

[Göran Selander <[e-mail]>]

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

>
>
>> -----Original Message-----
>> From: Göran Selander [mailto:[e-mail]]
>> Sent: Monday, September 21, 2015 9:45 PM
>> To: Jim Schaad <[e-mail]>; [e-mail]
>> Subject: Re: [Ace] End-to-End Scenarios
>> 
>> 
>> 
>> On 2015-09-20 04:51, "Jim Schaad" <[e-mail]> wrote:
>> 
>> >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.)
>> 
>> 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?

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


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?

>
>> 
>> 
>> >
>> >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.
>> 
>> 
>> 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?
>
>> 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;
>
>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.


Agree, just wanted to be explicit.

Göran


>
>Jim
>
>> 
>> 
>> 
>> Göran
>> 
>> 
>> 
>> >
>> >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
>> >
>> >
>> >_______________________________________________
>> >Ace mailing list
>> >[e-mail]
>> >https://www.ietf.org/mailman/listinfo/ace
>
>