Subject: [Secauth] some suggestions - clarification of ACE scope and secauth

From: Hosnieh Rafiee <[email-masked]>
Date: Thu, 9 Oct 2014 10:48:15 +0000

Hi,

In secauth requirement draft, there is two requirements that I suggest to be considered by ACE however, If ACE does not want to work on them,  I will keep it in secauth.

Here is the link to secauth requirement draft.
https://tools.ietf.org/html/draft-rafiee-secauth-usecase-01 

   Scenario 2: Alice's wash machine technically has a problem. Its
   application was configured by the vendors? in a way to report this
   problem automatically to third party technical service (repair
   place). Both the technical service application and wash machine need
   to authenticate each other so that they can trust and exchange
   information. Since the application are usually implemented by the
   third party and there was not much effort to secure the
   communications between the device and the application, the security
   of them is a big concern.

Alice turned on the wash machine at home and then went to work. Alice
   can check the status of this wash machine using an application on her
   Smartphone remotely at company x. Wash machine doesn't support any
   certificates signed by a CA. Alice needs to be authenticated in the
   wash machine and wash machine needs to trust Alice to allow her
   control it remotely. Since the application are usually provided by
   third parties, the security of this communication is important and
   the first point of trust is really important.

Thanks,
Best,
Hosnieh

---

From: Hosnieh Rafiee <[email-masked]>
Date: Thu, 9 Oct 2014 10:50:27 +0000

Follow up:
Requirement -> use cases

---

From: Hosnieh Rafiee <[email-masked]>
Date: Fri, 10 Oct 2014 09:58:31 +0000

Hi Stefanie,

Thanks for your message. My responses inline

> 
> Thank you for your suggestions. I am not sure if I completely
> understand which part of your scenario you want us to integrate into
> the use cases document. Some questions inline.

Just these two use cases that I explicitly included in my message. Because Kathleen reviewed secauth requirement and one of her question about these use cases that it might be covered by ACE. 

> >    information.
> Why does the washing machine contact the repair service and not Alice
> herself? She would have to make an appointment with them anyway if the
> machine is broken.

This is based on an article I read about "talking home devices and privacy and security concerns.  This article was based on researches of one of the owner of new smart wash machines who was concerned about the information sent back and forth by wash machine to x locations. In that article it also explained the ability of a smart wash machine that sends its problems to repair service centers automatically and explains the remaining concerns about the security of such applications since the producers only outsource them without much supervision on their security. 

The scenario which you explained is a bit different (only the end point is different) however, IMO, the security of that can be considered in a same way.  

> >  Since the application are usually implemented by the
> Which authorization problem do you want to solve here? Please have a
> look at section 2.2.1. in [1]. Do you want to address an authorization
> problem that is not already covered here?
> 

I checked ACE use case section 2.2.1. It appears that the use case only considered authorization and not authentication. So it seems that it presumed the authentication of Jane have already done and Jane only needs to authorize Jeffery to access some resources.

I have a question for you. I haven't read the new version of OAuth documents but such authorization scenarios might already considered by Oauth. Maybe it is good to check with them if it wasn't done before. 

Thanks,
Best,
Hosnieh

---

From: Stefanie Gerdes <[email-masked]>
Date: Fri, 10 Oct 2014 10:47:51 +0200

Hi Hosnieh,

Thank you for your suggestions. I am not sure if I completely understand
which part of your scenario you want us to integrate into the use cases
document. Some questions inline.

Thanks,
Steffi

---

From: Stefanie Gerdes <[email-masked]>
Date: Fri, 10 Oct 2014 10:50:51 +0200

[1] https://tools.ietf.org/id/draft-seitz-ace-usecases-01.txt

On 10/10/2014 10:47 AM, Stefanie Gerdes wrote:
> _______________________________________________
> Ace mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ace
> 

-- 
Stefanie Gerdes			Tel: +49 421 218 63906
TZI Universität Bremen		E-Mail: [email-masked]
Bibliothekstr. 1, MZH 5150
28359 Bremen, Germany

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 13 Oct 2014 16:16:10 +0200

Hi Hosnieh,

the scenarios fall into the scope of ACE if at least the resource server
is constrained.

If the washing machine just talks to some cloud-based infrastructure
then that's not really of interest to ACE. If there is, however, a
technician standing next to the washing machine and wants to retrieve
information from the washing machine using his mobile phone or tablet
directly then the washing machine becomes the resource server.

To me it appears (from our earlier discussion about the scenarios) that
you envision some interaction with a server-side infrastructure. If
that's the case then you should be able to solve these use cases with
the already existing standards we have developed.

Ciao
Hannes

---

From: Hosnieh Rafiee <[email-masked]>
Date: Mon, 13 Oct 2014 15:17:13 +0000

Hi Hannes,

Thanks for your response. My responses inline...
> 
> the scenarios fall into the scope of ACE if at least the resource
> server is constrained.

I presumed that something like wash machine have constrained resources.

> directly then the washing machine becomes the resource server.

Ok, So, if I understand you correctly, if one end point is constrained devices and the other point is cloud infrastructure, this is not what ACE will work on and I can put it in secauth. 

> the already existing standards we have developed.

Yes true. But it appears that I have to revise the scope based on your comments and other offlist discussion.

Thanks, 
Best,
Hosnieh

---

From: Hosnieh Rafiee <[email-masked]>
Date: Mon, 13 Oct 2014 16:16:49 +0000

Hi Carsten,

Thanks for your message. Please see my responses inline...

> > Ok, So, if I understand you correctly, if one end point is
> constrained devices and the other point is cloud infrastructure, this
> is not what ACE will work on
> 
> If this is just about a secure connection between the constrained
> device and a less-constrained device, that is already covered by DTLS,
> so there is nothing to work on.

To some extend true. Thanks for clarification. I will check DTLS again to see what they have and how they want to provide the authentication and authorization in virtualization environment, share the result with the mailinglist.

Besides the above mentioned scenarios, secauth plans to work on first point of trust for different use cases. Does ACE also work on this first point of trust? If so I will remove all use cases regarding constrained devices, if not I only change these particular use cases to only focus on providing first point of trust.

> If the point is to have the less-constrained device become authorized
> to access resources on the constrained device, then we need something
> like ACE.
> 
> A more detailed introduction of what ACE is about is in draft-gerdes-
> ace-actors-01.txt

Thanks, will take a look.

Best,
Hosnieh

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 13 Oct 2014 18:03:31 +0200

On 13 Oct 2014, at 17:17, Hosnieh Rafiee <[email-masked]> wrote:

> Ok, So, if I understand you correctly, if one end point is constrained devices and the other point is cloud infrastructure, this is not what ACE will work on

If this is just about a secure connection between the constrained device and a less-constrained device, that is already covered by DTLS, so there is nothing to work on.

If the point is to have the less-constrained device become authorized to access resources on the constrained device, then we need something like ACE.

A more detailed introduction of what ACE is about is in draft-gerdes-ace-actors-01.txt

Grüße, Carsten

---

From: Hosnieh Rafiee <[email-masked]>
Date: Tue, 14 Oct 2014 15:27:30 +0000

Hi Carsten,

I just followed your suggestion and reviewed DTLS document again (to recall its exact application). What I understood from DTLS is that it is similar to TLS but it only includes the possibility for handling the untruthful communication over UDP. But there is nothing about how to handle the communication between two nodes in virtual environment (automatically) or how to handle the first point of trust. This is especially important to avoid the use of CAs (because of reasons explained in the secauth use cases and requirements).

My conclusion from that document is that still secauth can keep its scope on the followings:
- Provides the first point of trust (as specified in revised version of secauth charter)
- Provides an authentication and authorization language (protocol) for virtual environment (device to device, user to device)

Any other thoughts?
Thanks,
Best,
Hosnieh