Re: [Ace] End-to-End Scenarios

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

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

>
>
>> -----Original Message-----
>> From: Göran Selander [mailto:[e-mail]]
>> Sent: Tuesday, September 22, 2015 12:02 AM
>> To: Jim Schaad <[e-mail]>; [e-mail]
>> Subject: Re: [Ace] End-to-End Scenarios
>> 
>> 
>> 
>> 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.
>> 
>
>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
>
>
>> 
>> 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
>> >
>> >
>
>