Re: [Ace] End-to-End Scenarios

["Jim Schaad" <[e-mail]>]

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

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