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

[Hannes Tschofenig <[e-mail]>]

Hi Hosnieh,

a few remarks inline:


On 09/16/2014 05:17 PM, Hosnieh Rafiee wrote:
> 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.


While MD5 is a weak hash function it is actually used in a keyed
version. That makes it better.

The concern raised in Section 26.4.3 of RFC 3261 is not applicable
anymore (due to the introduction of DTLS).

If you think there are still problems with SIP then it might be
worthwhile to reach out to the RAI area. In the meanwhile most of the
guys have moved on to WebRTC (even the telco guys). But it would
nevertheless be worth a try.


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

The work on SIP and IPsec (between the SIP UA and the proxy server) is a
3GPP specific solution and has been standardized there.


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


I think it would be good to describe what the current practices and
design/usage patterns are that you would like to change. While the
currently deployed approach is certainly a solution one can always
phrase the anticipated way of working in form of a user story.

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

In one of the documents I listed there was also a pointer to a working
group (called ENROLL) that was created by Russ Housley a while ago that
tried to solve the enrollment / pairing problem. Unfortunately, the
working group never went anymore because the problem statement was not
precise enough. That can easily happen again.

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

Ok. Got it.

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

I personally do not see how it relates to the other use cases. I would
drop it.

Ciao
Hannes

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