Re: [Secauth] Review request- secauth - authentication and authorization - second draft

[Hosnieh Rafiee <[e-mail]>]

Hi Hannes,

Thanks a lot for your comment that I really appreciated. Please find my responses inline.

> 
> [hannes] Take a look at the ACE use case document. This use case sounds
> very similar to what we are trying to address. Here is the pointer to
> the use case document:
> http://tools.ietf.org/html/draft-seitz-ace-usecases-01

The scope of them are not the same. secauth covers greater scope than ACE.  As far as I can remember (if my memory helps) both group was initiated almost at the first time but ACE focused on constrained devices and the main focus of secauth is the use of network layer security for first point of trust in different use cases. In other words, you can combine it with other approaches if it is necessary -- OAuth, ACE, etc.

I think ACE is a protocol and secauth is at the moment an API.


> 
> [hannes] Hasn't this been solved already with the work on SIP?

As far as I know there was a draft that aimed to use IPsec and I explained in the draft about the use of IPsec. I haven't seen other works. Probably I missed them. If there are please share the links and I would review and compare with secauth. Secauth wants to be simple and easy because automation is also the purpose.


> [hannes] Today this issue is solved by either connecting to the device
> in a special way (when you install it) and then provision your
> username/password or you use some other pairing procedure (such as
> entering info that is printed on the bottom of the device).

The use of secauth doesn't necessarily reduce the need of passwords. You can use two level authentication and authorization. The other case is that what if you need to change your IP or other parameters? Do you need to reconfigure manually? This is again what I plan to address.

> These pairing procedures are interesting but they often relate to the
> radio technology that is being used (compare Bluetooth vs. WiFi) and
> then there are various technologies that have been explored (and
> standardized already).

True. But I also considered them in the introduction and problem statement. The various security approaches that are used and as far as I know the first point of trust is already the main problem. It is difficult to close that gap completely but we can eliminate this gap by the use of secauth.


> 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 a 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.
> 
> [hannes] This is not a common use today but what is common is that
> devices get provisioned with long-term keys during the manufacturing /
> provisioning process and then they talk to the websites of the
> manufacturer. In fact, this is the most common deployment model of IoT
> appliances today.

I read an article two days ago that there are already some vendors that have smart home devices that send information to the technical site. So, this is already in use but with... unsure level of security. This was the case I also considered it as one of the important use cases. 

> 3.4.  Verification of an App. to an App. Over the Network
> 
> [hannes] I don't know a lot about these use cases since I did not
> follow the OpenFlow work. So, I will skip those.
> 

SDN/NFV are quite new and there are still working on progress for their security. So secauth can be an answer to the authentication and authorization. 

I hope I could answer your concerns. If not please let me know where I did not.

Thanks,
Best,
Hosnieh