Subject: [Secauth] Summary of the last discussions

From: "Rafiee, Hosnieh" <[email-masked]>
Date: Mon, 16 Dec 2013 19:19:56 +0000

I'd like to summarize the last discussions. Please correct me if I missed anything or I misinterpreted something. We want to decide our next steps so please share your ideas even though you think it doesn't change anything. Maybe it does and maybe it is important but just you don't think it is.

First we need to have a clear policy (Know how to authorize node/user).  Questions
1- Is it different from one system to another? If so, How?

2- To what extend  is it necessary to know "Who" the user is?
Let's back to our real world example, is it enough to check him with his picture? Is it enough to check his passport with the passport of people in that country? is required to check this user with the names of criminals? Is it...

API Needs:
1- mobility (portability)
2- scalability
3- Detect the nodes and then extend it to detect the user. How?
4- calculate energy and CPU consumption (required for small devices)
5- Availability and accessibility
6- Simplicity (to what extend?)

Question:
What are the different ways of detecting a node (computer)? 

What are the different ways of detecting humans/users?

What are differences between these two and why?

Thanks,
Smile,
Hosnieh

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 16 Dec 2013 14:31:35 -0500

I am at bit concerned both with the overall target and this specific 
discussion insofar as there seems to be a tendency to conflate node and 
user.  The two are NOT in my understanding the same.  And from what I 
have seen they do not share identity or authorization.

Yours,
Joel

On 12/16/13 2:19 PM, Rafiee, Hosnieh wrote:
> _______________________________________________
> Secauth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/secauth
>

---

From: Adam Montville <[email-masked]>
Date: Mon, 16 Dec 2013 19:43:21 +0000

> -----Original Message-----
> From: Secauth [mailto:[email-masked]] On Behalf Of Joel M.
> Halpern
> Sent: Monday, December 16, 2013 1:29 PM
> To: Rafiee, Hosnieh; [email-masked]
> Subject: Re: [Secauth] Summary of the last discussions
> 
> I am at bit concerned both with the overall target and this specific discussion
> insofar as there seems to be a tendency to conflate node and user.  The two
> are NOT in my understanding the same.  And from what I have seen they do
> not share identity or authorization.

I've not really been engaged in this discussion, so I feel like I'm dive-bombing a bit - sorry.

I would generally agree with Joel has said here.  There may, however, be circumstances where a particular endpoint can reasonably be considered a proxy for the user or a set of users.  It would be interesting to enumerate the envisioned use cases for this endeavor.   Is this community seeking to generally authenticate "home users" or enterprise users?  Mobile device users?  What are the network configuration constraints, if any, required in order to achieve a reasonable proxy of authentication?  What types of transactions might be "covered" by "reasonable proxy"?

> > I'd like to summarize the last discussions. Please correct me if I missed
> anything or I misinterpreted something. We want to decide our next steps so
> please share your ideas even though you think it doesn't change anything.
> Maybe it does and maybe it is important but just you don't think it is.
> >
> >
> > Let's back to our real world example, is it enough to check him with his
> picture? Is it enough to check his passport with the passport of people in that
> country? is required to check this user with the names of criminals? Is it...
> >
> >
> > API Needs:
> ...

. . .

---

From: Michael Richardson <[email-masked]>
Date: Wed, 18 Dec 2013 10:48:25 -0500

I think that we have:

1) nodes with interfaces to humans ("UIs"), which can ask human for
   "something they know".  These can reasonably be called "user-proxies"
   or "users"

2) nodes without such interfaces, and are limited to "something they have"
   These are things that range from light switches to printers to
   access points and home routers just out of the box(*).

(*)- because, some category-2 nodes, after making sufficient friends with
     a category-1 node, can often gain enough user interface to be able
     to be proxy for users.

There is a recent growth of (mostly IPv4, sadly) home NAS and home monitoring
systems that call home and are then told by HQ who their user is,
and how to trust them.

I don't think that the goal of secauth is to deal with the above devices
in a standard way.  (ACE might do that)

I'm actually unclear what secauth is doing.
I think it has something to do with connecting credentials (for some
as yet unknown definition) with layer-3 addresses.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting for hire =-

---

From: "Rafiee, Hosnieh" <[email-masked]>
Date: Fri, 20 Dec 2013 15:37:59 +0000

> > discussion insofar as there seems to be a tendency to conflate node
> > and user.  The two are NOT in my understanding the same.  And from
> > what I have seen they do not share identity or authorization.

I agree that identifying users is hard and we can never have an absolute promise that we can definitely do this. But, what we can do is that to find the best possible way for this identifications. In other words, we cannot say 100% that this is user A who authenticated with the system but our goal is to some extend ensure that we are still communicating with the same user.  
You're right that authorization and authentication can be in different scope. But, IMHO, in most cases one is required for the other one. In other words, one can lead to other one. 

> I would generally agree with Joel has said here.  There may, however, be
> circumstances where a particular endpoint can reasonably be considered a
> proxy for the user or a set of users.  It would be interesting to enumerate the
> envisioned use cases for this endeavor.   Is this community seeking to
> generally authenticate "home users" or enterprise users?  Mobile device
> users?  What are the network configuration constraints, if any, required in
> order to achieve a reasonable proxy of authentication?  What types of
> transactions might be "covered" by "reasonable proxy"?

I guess proxy servers or any devices that play a role of intermediate in the networks can be a problem for authentications and this is where the API can be in use.

Thanks,
Merry Christmas and Happy new year..
Smile,
Hosnieh

---

From: "Hosnieh Rafiee" <[email-masked]>
Date: Mon, 30 Dec 2013 21:39:58 +0100

Follow up,
I am sorry, I guess I missed some parts of your questions

>>   Is this community seeking to
> > generally authenticate "home users" or enterprise users?  Mobile
> > device users?  

The focus here is first, enterprise users then we will move slightly to home
users. This is because usually home users are considered as a part of ISP
organization. Maybe I am wrong but I guess one can see the part of ISPs
network that support home users as a big non-stable enterprise. IMHO, mobile
devices must be considered. This is because with new technological devices,
we have to expect more movements inside the networks than before.

>> What are the network configuration constraints, if any,
> > required in order to achieve a reasonable proxy of authentication?

I think the most important thing is that one need to consider to have cross
framework ability for the API so that it supports all devices with different
vendors (vendors cooperation is needed)

I guess all nodes in the network needs to support such network layer
authentication so that it can be usable for other layers. However, it does
not necessarily mean that one need to change border devices to understand
this authentication.  
How?
1- Only use the data used to identify a node in the network layer (repeating
authentication for other layers) ; the API makes this data available to any
other applications - I guess it won't be much operational barriers. Right?
Constraints: How to implement such API to support all devices and play a
role of intermediate.

But
2- if we want the authentication to be done in network layer all its way
from one proxy server to another, I guess we need to consider the
configurations of firewalls and other intermediate devices on the way of
this authentication. The one that disallow any unknown connections to other
devices. 

My first thought was number 1. But if people think, number 2 makes sense
then we go for it.

Smile,
Hosnieh

---

From: Jerome Athias <[email-masked]>
Date: Tue, 31 Dec 2013 12:23:15 +0400

Hi,

in case this could be useful, you could look at the work of the FIDO alliance
http://fidoalliance.org/about.html

Cheers
Happy Safe New Year

---

From: "Hosnieh Rafiee" <[email-masked]>
Date: Tue, 31 Dec 2013 11:50:23 +0100

Hi,

As far as I understood from the explanation of the website, they use
biocrypto as a part of authentication in client side. So, a part of the
authentication in that website is similar to what we want to use, but there
are some issues:
- I already discussed here that using the biocrypto mechanisms are just like
changing the security problems to other forms and even worse than before.
One can change a password, but one cannot change the bio identity otherwise
one does a surgery.
- Users need to involve in their key generation and other stuff while the
network layer authentication can provide them with this stuff and the API
provide them this information

 I see the first issue as a really scary and big issue that I explained it
before in other message.

Thanks,
Smile,
Hosnieh

> From: Jerome Athias [mailto:[email-masked]]
> Sent: Tuesday, December 31, 2013 9:23 AM
> To: Hosnieh Rafiee
> Cc: Adam Montville; [email-masked]
> > The focus here is first, enterprise users then we will move slightly
> > to home users. This is because usually home users are considered as a
> > part of ISP organization. Maybe I am wrong but I guess one can see the
> > part of ISPs network that support home users as a big non-stable
> > enterprise. IMHO, mobile devices must be considered. This is because
> > with new technological devices, we have to expect more movements inside
> the networks than before.
> >
> > I think the most important thing is that one need to consider to have
> > cross framework ability for the API so that it supports all devices
> > with different vendors (vendors cooperation is needed)
> >
> > authentication so that it can be usable for other layers. However, it
> > does not necessarily mean that one need to change border devices to
> > understand this authentication.
> > How?
> > 1- Only use the data used to identify a node in the network layer
> > (repeating authentication for other layers) ; the API makes this data
> > available to any other applications - I guess it won't be much
operational
> barriers. Right?
> > Constraints: How to implement such API to support all devices and play
> > a role of intermediate.
> >
> > But
> > 2- if we want the authentication to be done in network layer all its
> > way from one proxy server to another, I guess we need to consider the
> > configurations of firewalls and other intermediate devices on the way
> > of this authentication. The one that disallow any unknown connections
> > to other devices.
> >
> > My first thought was number 1. But if people think, number 2 makes
> > sense then we go for it.
> >
> > Smile,
> > Hosnieh
> >

---

From: "Hosnieh Rafiee" <[email-masked]>
Date: Tue, 31 Dec 2013 11:54:49 +0100

Follow up,

They also only considered a case where one side of the authentication is a
user and not a proxy server is in between. So, again it is an issue.
Finally, consider the costs of such scanners and how users want to carry
them everywhere and many other spoofing and security flaws happen in between
which makes the situation really worse. IMHO, I never recommend to go
through the biocrypto solutions. 
These are the problems that we will address in the proposed API in this
group.

Smile,
Hosnieh

> From: Secauth [mailto:[email-masked]] On Behalf Of Hosnieh
> Rafiee
> Sent: Tuesday, December 31, 2013 11:50 AM
> To: 'Jerome Athias'
> Cc: [email-masked]; 'Adam Montville'
biocrypto
> as a part of authentication in client side. So, a part of the
authentication in that
> website is similar to what we want to use, but there are some issues:
> One can change a password, but one cannot change the bio identity
> otherwise one does a surgery.
before in
> other message.
> > > to home users. This is because usually home users are considered as
> > > a part of ISP organization. Maybe I am wrong but I guess one can see
> > > the part of ISPs network that support home users as a big non-stable
> > > I think the most important thing is that one need to consider to
> > > have cross framework ability for the API so that it supports all
> > > devices with different vendors (vendors cooperation is needed)
> > >
> > > authentication so that it can be usable for other layers. However,
> > > it does not necessarily mean that one need to change border devices
> > > to understand this authentication.
> > > How?
> > > (repeating authentication for other layers) ; the API makes this
> > > data available to any other applications - I guess it won't be much
> operational
> > barriers. Right?
> > > Constraints: How to implement such API to support all devices and
> > > play a role of intermediate.
> > >
> > > But
> > > way from one proxy server to another, I guess we need to consider
> > > the configurations of firewalls and other intermediate devices on
> > > the way of this authentication. The one that disallow any unknown
> > > connections to other devices.
> > >

---

From: Jerome Athias <[email-masked]>
Date: Tue, 31 Dec 2013 20:24:27 +0400

Ok,

well, so, sorry to be off-topic...
If it is assumed that no other works/approaches* are covering these
problems (difficult to judge without use cases), so defining the
requirements could help to start.

*
http://csrc.nist.gov/projects/abac/index.html
https://downloads.cloudsecurityalliance.org/initiatives/sdp/Software_Defined_Perimeter.pdf

My 2bc