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

[Hannes Tschofenig <[e-mail]>]

Hi Hosnieh,

thanks for the quick response. Remarks inline:


On 09/15/2014 06:23 PM, Hosnieh Rafiee wrote:
> 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.

At the moment we are still at the level of use cases.

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

An IPsec-based solution was developed in the 3GPP but the IETF solution
uses digest authentication (a challenge-response mechanism similar to
the one used in HTTP) combined with TLS between the proxy and the user's
SIP UA.

You can see example call flows here: http://tools.ietf.org/html/rfc3665

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

If you want to change configuration parameters in your home gateway then
you need to log-in using the initially provisioned account credentials.
Whether an IP address change requires you (as a user to actually take
some actions) very much depends on the overall configuration.

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

This is certainly an interesting area of work but not an easy topic for
the IETF since some of the mechanisms are outside the scope of the IETF
itself (since they rely mostly on out-of-band channels with humans doing
some stuff).

You might want to take a brief look at these two documents and follow
the references:
http://tools.ietf.org/html/draft-gilger-smart-object-security-workshop-02
http://tools.ietf.org/html/draft-tschofenig-ace-overview-00

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

The ability for devices to connect to some cloud-based infrastructure is
very common (and has been for a long time). I am not sure how common it
is with washing machines that get connected to an app from a technician
(if I understood it correctly). Maybe you want to clarify the
interaction between the technical service app and the washing machine.


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

Isn't SDN very much a network-operator internal aspect with pre-arranged
trust relationships?

> 
> I hope I could answer your concerns. If not please let me know where
> I did not.
> 
> Thanks, Best, Hosnieh

Ciao
Hannes


> 
> _______________________________________________ Secauth mailing list 
> [e-mail] https://www.ietf.org/mailman/listinfo/secauth
>