Subject: [Secauth] Review request- secauth - authentication and authorization - first draft

From: Hosnieh Rafiee <[email-masked]>
Date: Mon, 1 Sep 2014 09:26:55 +0000

Folks,

I have received a few comments offlist. I would welcome more comments if any. Please consider reviewing it and share your ideas to know whether or not we considered all your thoughts or we need to work more.

I would prefer to receive comments on the mailinglist rather than offlist. Because other folks might also include something to your comments or there might be supporters or non-supporters of certain idea.

Thanks,
Best,
Hosnieh
http://tools.ietf.org/html/draft-rafiee-secauth-usecase-00

---

From: Hosnieh Rafiee <[email-masked]>
Date: Tue, 2 Sep 2014 11:11:22 +0000

Viktor,

Again thanks a lot for your comments which I really appreciated it. 
> 
> The draft seems to have much text in 3.1 on various flavours of
> authentication mechanisms at the application layer.  It is not clear
> why these are there, if the goal is primarily to explore the
> requirements for an API that exposes network-layer security to the
> application layer.

Yes, as the title of this draft also shows, the purpose is only requirements and use cases and still I don't plan to go through the solution space. However, I have some ideas but I guess it makes sense to go through it after we have an acceptable version of the requirement document.

> It is not clear what the purpose of section 3.2 is.
> 
> Section 3.3 seems to talk about virtual network infrastructure.
> Is this API between the application layer and local network-layer
> security such as IPSEC, ... Or is it an interface to talk to network
> infrastructure?  (Switches, Proxies, ...)

No, this API is inside each node and handles the secure authentication between two devices that there can be user behind one of these device or there can be also another device. 
And the infrastructure can be switches, proxy servers, etc.

Please consider the following cases
Authentication /authorization (for short: Auth2) of a user to a device (this is of course not possible without an application. So to summarize it, it is Auth2 of the application1 to application2 where application 2 is on another node located on different network or the same network)
So for this use case scenario, 

Virtualization falls into the category of Auth2 of device to device. This is , of course, via some applications but the differences is that there is no human or user in between and all the things are done automatically between two devices that can be on a same network or on different networks. 
This is like a policy enforcer protocol wants to setup authentication and authorization

Now about this Auth2 in detail for second scenario that is virtualization (I guess this was the confusing part. right?)

Virtual device (VD) x wants to add a new rule in virtual device y. VD x needs to authenticate VD y and then authorize it before it allows it to add or modify any resources on VD y. VD x uses secauth api and sends authentication request to VD y, based on secauth configuration, it first uses a network layer authentication to create the first level of trust. After VD y uses secauth and authenticates VD x, it authorizes VD x to use some resources or modify a resources on VD y. This step can be handled by other mechanisms (like Oauth) or still can be handled by secauth because the first point of trust was the main purpose of secauth and the other parts can be handled by other protocols or secauth as well. Such as starting a secure channel to encrypt all data, etc.  

Do you think my example is clear? 
Secauth might also use other mechanisms to create this first trust efficiently. 

This is what I tried to explain or expand the virtualization section. 

> Critically, the last paragraph of the introduction:
> seems rather unclear.  Is securing the last mile an API problem?

Not an API problem, but the current problems with current protocols and the purpose is to eliminate this problem or eliminate the gap in first point of trust.

> One example requirement is to expose a channel-binding between the
> network layer encrypted channel, and the application data stream, which
> can be used in combination with higher-layer mechanisms to create an
> authenticated application-layer message stream out of from a network
> layer that provides unauthenticated encryption with integrity
> protection.

Do you mean I need to go to more detail about requirements? Isn't it considered as a use case scenario that how the things need to work? I mean shall I expand the use case section or requirement section?

> Other requirements might include functionality to query the security
> state of the network layer, or control it.
> 
> If I am not misreading the intended scope of the draft, it seems too
> early to review it, because so little is there...

Thanks again,
Best,
Hosnieh

---

From: "Hosnieh Rafiee" <[email-masked]>
Date: Wed, 3 Sep 2014 13:17:48 +0200

Hi Paul,

Thanks a lot for your comments and suggestions. I will consider them all in
next version. Please see my responses inline...

> I find the abstract and purpose of the document confusing.
> It's hard to tell purpose of the requirements.

I kept the abstract so short. But if it is needed I would expand it.

> "... use cases and requirements for secure
>    authentication in other layers above the network layer ..."
> Not sure why layers matter in the abstract for AuthN/AuthZ services.
> 
> "... and the use of network layer security approaches
>    for this purpose. ..."
> 
> The first part excludes network layer and now you include network layer.

You are right. I guess it is wording problem. The purpose is to use Network
layer approaches as means of authentication in other layers. This network
layer approaches also can combine with other available approaches. For
instance for the start, the authentication is network layer and after the
establishment of this trust, it  can be application layer or user based
password authentication or token based to authorize this user to access to
certain resources. Like two level authentication and authorization.

> " 3.1. Authentication/Authorization of a User to a Device"
> Not sure why this would be in scope since the user is not an
'application'.
> This is also not a well formed use case
> (e.g. a banking application that needed
> to validate that a user had direct control over a application might be a
viable
> use case)
> 
> 
> 
> " 3.1.1.  Biometric Authentication"
> This is not a use case, it's a mechanism.
> 
> " 3.1.5. NAT Scenario"
> Useful use case for network layer ...
> Not clearly articulated why it's interesting.
> Not so important above layer three.
> Not clear about scope of this document.

I would like to remove the requirements for CA for each single node. CA
might be useful for many cases but not when we supposed to use it for each
single user and single node. So the purpose is to remove CAs and also
automation when we plan not to use CA. because by removing CA, the problem
would be the establishment of trust. So, now the purpose is to provide this
trust with less efforts. Since most spoofing attacks happens in network
layer, we aim to prevent this attack in this layer. 

Please consider that the aim is not only the authentication and
authorization of a user to access some resources but also a node to update,
or modify something on another node. This is why the cases like proxy
servers are important.
Since we are talking about network layer approaches to easily avoid IP
spoofing and other kinds of spoofing problems, then NAT MIGHT cause a
problem and that was a reason that I considered a scenario where one of our
nodes are behind NAT.

Do you think it is clear now? 

> " 3.1.6. Valid IP address"
> Does not make sense in section 3.1
> Not really the right term for the scenario.

> Not really a use case, but one possible addressing Situation.

Ok, then change it to something else.

> Use cases might beter include users:
>  - home user behind firewall
>  - home gateway with static IP address (valid)
>  - home IoT widget with IPv6 based on device MAC address (privacy issues)
>  - home IoT widget with IPv6 based on Ephemeral MAC address
>  - etc

Thanks for the suggestion. Ok, I will consider them.

> 
> " 3.3. Authentication and Authorization of Virtual Devices"
> Not clear if this is in scope for IETF work. Internal security of
Virtualized
> services is not apparent over-the-wire. A virtual server is typically
> indistinguishable from a non-virtual server.
> 
> 
> 
> Draft is a bit rough at the moment.  Clarity in abstract and purpose would
be a
> good starting point.

Ok I will try to address them and will prepare next version.
Best,
Hosnieh

---

From: Hosnieh Rafiee <[email-masked]>
Date: Mon, 15 Sep 2014 15:22:32 +0000

Hello,

I have revised the secauth requirement and use case draft. I would appreciate your inputs on this new version.

I am going to upload after receiving more feedback
The current pre-upload version can be found here:

< http://editor.rozanak.com/show.aspx?u=AZ6AA4BFD809BB71B2544CTAM >

@Paul, Viktor: would you please check to see whether the document is clear and satisfy the changes you have asked.

@folks: I welcome more comments before uploading new version. Please share your inputs on editorial, document organization or technical.

Thanks,
Best,
Hosnieh

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 15 Sep 2014 17:47:12 +0200

Hi Hosnieh,

I just took a quick look at the scenarios. Comments are inline:

----

3.  Use cases

   The following subsections explain different use case scenarios.

3.1.  Verification of a User to an Application Over the Network

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.

[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

3.2.  Home User Behind Firewall or a Proxy Server

Alice?s device is behind a firewall or a proxy server. Alice wants to
use an application that uses SIP protocol to contact Bob. Bob rejects
any unknown calls to avoid advertisements/spam. Proxy server needs to
verify Alice and send the information to Bob?s device

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

3.3.  Home Gateway/Device with an Static IP Address (Valid IP)

Scenario 1: Alice needs to control its home gateway and add new rules
so that she can access a device inside her home network. Alice
remotely connects to this device. This device doesn?t support any
valid CA. The device needs to authenticate Alice before lets it
control this device and add/modify any new rule to this device.

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

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

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.

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.

----

Ciao
Hannes

On 09/15/2014 05:22 PM, Hosnieh Rafiee wrote:
> _______________________________________________
> Secauth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/secauth
>

---

From: Hosnieh Rafiee <[email-masked]>
Date: Mon, 15 Sep 2014 16:23:48 +0000

Hi Hannes,

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

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

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

> then there are various technologies that have been explored (and

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.

> manufacturer. In fact, this is the most common deployment model of IoT

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. 

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

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 16 Sep 2014 08:38:51 +0200

Hi Hosnieh,

thanks for the quick response. Remarks inline:

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

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

> 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

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

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

> Thanks, Best, Hosnieh

Ciao
Hannes

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

---

From: Hosnieh Rafiee <[email-masked]>
Date: Tue, 16 Sep 2014 15:17:00 +0000

Hi Hannes,

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

> the one used in HTTP) combined with TLS between the proxy and the
> user's SIP UA.
> 

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

> your
> case
> > is that what if you need to change your IP or other parameters?
> If you want to change configuration parameters in your home gateway
> then you need to log-in using the initially provisioned account
> credentials.

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)

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

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

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

---

From: Hosnieh Rafiee <[email-masked]>
Date: Wed, 17 Sep 2014 11:43:44 +0000

Hannes, Folks,

Is there any other comments that I can address before uploading new version today?

Do you think it is good to have a online meeting to discuss this more? If yes please suggest the date.

Thanks,
Best,
Hosnieh

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 17 Sep 2014 14:04:43 +0200

Hi Hosnieh,

a few remarks inline:

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

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.

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

---

From: Hosnieh Rafiee <[email-masked]>
Date: Wed, 17 Sep 2014 15:33:36 +0000

Hi Hannes,

Thanks again for your remarks.  

> nevertheless be worth a try.

Yes, I still think that there is a concern. I will solicit a message to WebRTC and ask them to join to this group and share their inputs.

> 3GPP specific solution and has been standardized there.

Ok, got it :-). No argue :-)

> phrase the anticipated way of working in form of a user story.

Just to clarify this, do you mean I have also to explain the design of solution space? If not, would you please give me an example so that I can understand what I expect to do.

> precise enough. That can easily happen again.

I understand but technology changed, requirements changed and we can look ahead and widen our scope and our way of thinking accordingly. Maybe the things that 2 years ago wasn't possible is now possible due to the new technology. In other word, people were not ready for that because of unavailability of technology but I think now it is the time. As I said I first started with solution but then guys said that I need to clarify the problem first before I jump to the solution. (I guess I usually jump!... then I try to return to the problem).

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

The only reason that I added that is that this solution is not only for user to application, but can be used  also for device to device either it is virtual or it is physical.

In other word, just specifying its scope that is not limited to certain applications.

Do you still think it does not help and not related to have it here?

Thanks,
Best,
Hosnieh