Subject: Re: [Ace] Possible Proxy use cases for ACE

From: "Hannes Tschofenig" <[email-masked]>
Date: Fri, 7 Feb 2014 09:56:44 +0100 (CET)

Hi Akbar,

when I looked at the use cases again I ran into your mail below.

What I would like to see is a use case description that describes the user experience rather than a description that talks about the solution. Forget the solution for a moment and try to explain the scenario in a Alice and Bob notation style.

For example, Bob may be the building owner and he installed some lights in the building. Once finished he then rented it to Alice for a month and delegated access to Alice for use of the lights for that month or so.

Just making the case up here since I don't really know what use case you have in mind. Have a look at https://datatracker.ietf.org/doc/draft-seitz-core-sec-usecases/ since it does a very good job in the use case descriptions.

Ciao

Hannes

Gesendet: Donnerstag, 23. Januar 2014 um 17:05 Uhr

Von: "Rahman, Akbar" <[email-masked]>

An: "Ludwig Seitz" <[email-masked]>, "Olaf Bergmann" <[email-masked]>

Cc: [email-masked]

Betreff: [Ace] Possible Proxy use cases for ACE

(Note: Changing the subject line to a more descriptive one for the topic)

Hi Ludwig/Olaf,

Thanks for your feedback. It is good that the use case already makes mention of Proxies. What I was interested in was the following use cases (and associated questions). Please tell me if it is already in the scope of the current use case draft or if it should be added.

1) Proxy Unicast Use Case

--------------------------------

A building automation case requires that low cost light fixtures supporting CoAP be purchased off the shelf. Before they are installed, the light fixtures are configured to send all their CoAP requests through a CoAP Forward Proxy located in the building. From experience the building owner sees that the great majority of light fixtures are safe, but that some small percentage occasionally have malware installed on them.

References:

- Forward-Proxies: http://tools.ietf.org/html/draft-ietf-core-coap-18#section-5.7.2

- Security for Proxying: http://tools.ietf.org/html/draft-ietf-core-coap-18#section-11.2

Q1 -Should the Resource Server authentication and access control model require it to know anything about the light fixtures, or should it just consider that all requests as originating from just the Proxy?

Q2 -Can the Proxy enforce authentication and access control model on behalf of the Resource Server?

2) Proxy Multicast Use Case

----------------------------------

As in (1) but with the extra complication that the Proxy may IP multicast (i.e. fan out) the single CoAP request from the light fixture to multiple Resource Servers.

Reference:

- Multicast Proxying: http://tools.ietf.org/html/draft-ietf-core-groupcomm-18#section-2.10

Q1 & Q2 as in (1)

Q3 - Should the multiple Resource Servers have coordinated authentication and access control models to handle the single multicast request?

Best Regards,

Akbar

-----Original Message-----

From: Ace [mailto:[email-masked]] On Behalf Of Ludwig Seitz

Sent: Thursday, January 23, 2014 7:36 AM

To: [email-masked]

Subject: Re: [Ace] New Version of Proposed Charter

On 01/23/2014 01:21 PM, Olaf Bergmann wrote:

> "Rahman, Akbar" <[email-masked]> writes:

>> - Will ACE cover the transfer of authorization info to a CoAP forward

>> proxy to send unicast/multicast DTLS messages on behalf of a Client?

>> (Reference:

>> http://tools.ietf.org/html/draft-ietf-core-coap-18#section-11.2 )

> The current discussions did not address this issue, and I think that

> this will not be a hot topic in the starting phase of a to-be-WG.

> But I agree that this kind of authorization transfer should be taken

> into consideration for solution design in the current drafts. Do you

> have a description of a usage scenario that could be incorporated with

> the use cases draft?

Proxies are already mentioned in the use cases draft (section 2.5.1 and requirement U5.3). Rahman, do you think that should be more specific?

If so I'm happy to hear your suggestions.

/Ludwig

--

Ludwig Seitz, PhD

SICS Swedish ICT AB

Ideon Science Park

Building Beta 2

Scheelevägen 17

SE-223 70 Lund

Phone +46(0)70-349 92 51

http://www.sics.se

_______________________________________________

Ace mailing list

[email-masked]

https://www.ietf.org/mailman/listinfo/ace

---

From: "Rahman, Akbar" <[email-masked]>
Date: Fri, 7 Feb 2014 07:32:19 -0500

Hi Hannes,

Okay.  Good suggestion.  Let me try to sketch something out over the weekend and then I will send it out for all your feedback.

Best Regards,

Akbar

From: Hannes Tschofenig [mailto:[email-masked]] 
Sent: Friday, February 07, 2014 3:57 AM
To: Rahman, Akbar
Cc: Ludwig Seitz; Olaf Bergmann; [email-masked]
Subject: Aw: [Ace] Possible Proxy use cases for ACE

Hi Akbar, 

Ciao
Hannes

Hi Ludwig/Olaf,

References:

Reference:

Q1 & Q2 as in (1)

Best Regards,

Akbar

-----Original Message-----
From: Ace [mailto:[email-masked]] On Behalf Of Ludwig Seitz
Sent: Thursday, January 23, 2014 7:36 AM
To: [email-masked]
Subject: Re: [Ace] New Version of Proposed Charter

/Ludwig

--
Ludwig Seitz, PhD
SICS Swedish ICT AB
Ideon Science Park
Building Beta 2
Scheelevägen 17
SE-223 70 Lund

Phone +46(0)70-349 92 51
http://www.sics.se

---

From: "Rahman, Akbar" <[email-masked]>
Date: Tue, 11 Feb 2014 01:56:30 -0500

Hi Hannes/Oalf/Ludwig,

I came up with the following use case regarding Proxy usage.  Any feedback would be much appreciated:

Bob and the  Bank lights

------------------------------

A bank headquarters is housed in a multi-story building with the latest energy saving devices.  Foremost among these are the building fluorescent lights.  These light fixtures are all modular units with short range wireless links which connect to the closest relay (proxy) when they are installed so that they can be centrally controlled and monitored. 

Bob is the office manager of the bank headquarters.  He is always under budget pressure to keep operating costs down.  He finds a local light supplier with very low unit costs.  So he decides to test the quality of these units and purchases a few lights and places them each in different floors of the building.  Unfortunately, these lights have malware previously installed in on them by Alice who was the delivery person who brought the lights to Bob.  At a specific time after Bob installs the rogue lights, the lights attempt to flood the light control network with traffic  in an attempt to bring the network down and black out the building.  Fortunately, Bob narrowly averts the disaster because he has configured the relays (proxies) to shut down at signs of excess traffic (i.e. why should lights need to be so chatty?).  Though this does result in the local areas lighted by the rogue lights to go dark.  Bob is just happy that he did not happen to test to many of these rogue lights at once or else the building would have been blacked out due to his counter measures (rather than from the direct attack).

---------------------------------------

After writing the use case, I was happy to see that some combination of the requirements from section 2.4.1 and 2.4.2 of draft-seitz applies to this use case.  So I am not sure if any new requirements have to be added.  But maybe the use case is worthwhile to record as an interesting scenario.

Best Regards,

Akbar

From: Ace [mailto:[email-masked]] On Behalf Of Rahman, Akbar
Sent: Friday, February 07, 2014 7:32 AM
To: Hannes Tschofenig
Cc: Olaf Bergmann; Ludwig Seitz; [email-masked]
Subject: Re: [Ace] Possible Proxy use cases for ACE

Hi Hannes,

 

Best Regards,

Akbar

Hi Akbar, 

Ciao
Hannes

Hi Ludwig/Olaf,

References:

Reference:

Q1 & Q2 as in (1)

Best Regards,

Akbar

-----Original Message-----
From: Ace [mailto:[email-masked]] On Behalf Of Ludwig Seitz
Sent: Thursday, January 23, 2014 7:36 AM
To: [email-masked]
Subject: Re: [Ace] New Version of Proposed Charter

/Ludwig

--
Ludwig Seitz, PhD
SICS Swedish ICT AB
Ideon Science Park
Building Beta 2
Scheelevägen 17
SE-223 70 Lund

Phone +46(0)70-349 92 51
http://www.sics.se

---

From: Olaf Bergmann <[email-masked]>
Date: Tue, 11 Feb 2014 10:32:33 +0100

Hi Akbar,

> Bob and the  Bank lights

Thanks for writing this up. Indeed, there are some commonalities with
the contents of the use-case document. What makes your use-case
different is that you describe access control on the network level (the
router/switch rejects forwarding of excess traffic). Usually, this would
be part of the forwarding node's filtering policy. Is this something
that could be handled by the "ACE framework" as well?

Gruesse
Olaf

---

From: "Rahman, Akbar" <[email-masked]>
Date: Tue, 11 Feb 2014 07:32:50 -0500

Hi Olaf,

Yes, this is exactly the issue that I wanted to raise.  I imagine that a network element which I term the Proxy (but which can be called relay/router/etc) will have to be part of the authorization framework and in some cases this Proxy will have to be the one rejecting traffic.  The reason that I bring this up in the ACE framework is because of my previous references to key parts of the existing CoAP specs:

References:

Reference:

Q1 & Q2 as in (1)

Best Regards,

Akbar

-----Original Message-----
From: Olaf Bergmann [mailto:[email-masked]] 
Sent: Tuesday, February 11, 2014 4:33 AM
To: Rahman, Akbar
Cc: Ludwig Seitz; Hannes Tschofenig; [email-masked]
Subject: Re: [Ace] Possible Proxy use cases for ACE

Hi Akbar,

> Bob and the  Bank lights

Thanks for writing this up. Indeed, there are some commonalities with the contents of the use-case document. What makes your use-case different is that you describe access control on the network level (the router/switch rejects forwarding of excess traffic). Usually, this would be part of the forwarding node's filtering policy. Is this something that could be handled by the "ACE framework" as well?

Gruesse
Olaf