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

[Hosnieh Rafiee <[e-mail]>]

Hi Hannes,

Thanks again for sharing your inputs. Please find my responses inline..

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

I checked the RFC reference you have provided including RFC 3261 and RFC 2617 that discussed about HTTP digest. There are some problems:
1- MD5 is a weak hash function and no longer is recommended
2- section 26.4.3 RFC 3261 already discussed the problem with TLS
Another problem with TLS was already discussed in secauth requirement draft.

So it appears that this problem wasn't solved and still there. 

Some time ago I saw a draft but cannot find it... it was about SIP and IPsec... I guess (maybe I am confused with other work...)


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

As I explained before, secauth does not necessarily remove the requirement for the use of password but only aims to ensure that the user enters its password in a so called correct server/device. However, if user doesn't like to use password, then it can handle the communication in other ways that I do not want to jump to solution space. (however I have some solutions in my mind)


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

I am not quite agree with your sentence where you said it is out of scope of the IETF. This is because as long as we can use or offer something that reduce this human interaction with new or current available standards, then this is not something not achievable at IETF. Although, this is true that nobody can claim that we can completely remove the human interaction for the configurations. But there is a difference between having easy configuration than having complex configuration. In other word, to what level the human needs to interact. 


> 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

Thanks I will do it.

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

That article was more focused in someone remotely control home devices like a wash machine and also the information that a wash machine sent to the technical service to inform about its health. 
I imagine that when this is already implemented for a wash machine might exist for other devices as well and the main focus of that article was the privacy and security concerns.

>Maybe you want to clarify
> the interaction between the technical service app and the washing
> machine.

Ok, will do it. 

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

Not completely since the environment is more dynamic and needs more flexibility that wasn't require in the current infrastructure.