Subject: [Secauth] initual attempt for auth categorization

From: "Rafiee, Hosnieh" <[email-masked]>
Date: Sat, 14 Dec 2013 11:14:55 +0000

Folks,

I'd consider two categories. If you think there are more, feel free to add.
(two versions, picture and text )

                                           Trusted authority for securing it
                                           ^
                                           +
                                      xxxxx x xxx
                              xxxxxxxxx          xxxx
                            xxx                     xxx
                          xx                          xx
                               +--------------------+
                               |  IP based access   |
                               |     Lists          |
                      +------->+--------------------+
                      +                                        +----------------------+
  Authentications+----+                              +-------->|  Session ID          |
                      |        +--------------------+|         |     based            |
                      +------->| unique identity    |+         +----------------------+
                               |     based          |+
                               +--------------------+|         +----------------------+
                                                     +-------->|  Username/Password   |
                                                               |      based           |   x
                                                               +----------------------+
                                                       xxx                             xx
                                                         xxxx                      xxxx
                                                             xxxxx    xxxx xxxxxxxx
                                                                   xxx    x
                                                                         xxx
                                                                          x

                                                                      SSL or TLS might be in use
                                                                      for security

Question:
-How many percentage of authentication is IP based?
Problems:
Security costs -> register in CAs
-How many are mixed (IP based and any of the approaches in second category?

Smile,
Hosnieh
P.S. maybe we can also have a nice wiki at the end by gathering all existing approaches and their purposes. Right?

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Sat, 14 Dec 2013 20:51:44 +0000

My sense, which I am willing to be disabused of, is that IP-based authentication can be useful to deny a party access if, based on location, they are simply wrong (for example, a given resource is only supposed to be used from inside a company, and it is being accessed from outside), or can identify a case in which more stringent rules may need to be applied. IP addresses don't correlate directly either with people or applications, both because addresses change and people change addresses; hence it is almost never valid to say "the access came from address foo and therefore is authorized".

Given that belief, I feel like you're starting in the middle of the conversation. The appropriate starting question is not the state of security, which as exemplified by your question is pretty disconnected from reality. The appropriate starting point has something to do with what is being secured and what assumptions about authentication and authorization are valid in the use case.

---

From: "Rafiee, Hosnieh" <[email-masked]>
Date: Sat, 14 Dec 2013 22:23:54 +0000

Hi Fred,

> 
> My sense, which I am willing to be disabused of, is that IP-based authentication
> can be useful to deny a party access if, based on location, they are simply
> wrong (for example, a given resource is only supposed to be used from inside
> a company, and it is being accessed from outside), or can identify a case in
> which more stringent rules may need to be applied. IP addresses don't
> correlate directly either with people or applications, both because addresses
> change and people change addresses; hence it is almost never valid to say
> "the access came from address foo and therefore is authorized".

That is true. The IP address cannot identify the human but it can help to some extend if it combined with CAs or other security approaches.

> Given that belief, I feel like you're starting in the middle of the conversation.
> The appropriate starting question is not the state of security, which as
> exemplified by your question is pretty disconnected from reality. The
> appropriate starting point has something to do with what is being secured and
> what assumptions about authentication and authorization are valid in the use
> case.

Thanks for your suggestion. I agree and I found your point really reasonable.  Do you think it is good to start with the meaning of authentication and authorization? In other word, what are the other terms come with authentication and what with authorization?
Then maybe the next step is what are authorization approaches, What are authentication approaches?
Am I right or I'm again jumping to the middle?

Thank you,
Smile,
Hosnieh

---

From: "Rafiee, Hosnieh" <[email-masked]>
Date: Sat, 14 Dec 2013 23:32:22 +0000

I start with these definitions:

Authentication:

-------------------------

1- Definition

The process of  identifying an entity. In other words, answering this question that who is this user?

2- Real world example

The airport security authenticate a person based on his travel documents, i.e., his passport.

3- Scope & use cases

- Application layer

User authentication examples: To access a website, To check an email, To check your bank account

Computer authentication examples: Update a software automatically,

- Network layer

- Computer authentication example: two computers' communications

Authorization:

-------------------------

1- Definition

The process of giving an entity a possibility to access some resources or authorize it to do something either on a single node or for the whole network. It is more to do with policies than other scopes.

Important: the entity needs first to be authenticated then one can define a policy for this entity based on its unique identifier (whetever used to access other entity on the network)

2- Real world example

A guard of a building can enter to the building and go to all corridors but only can go to room A and B but not room C. He does not have a key for that room.

3- Scope & use cases

- Application layer

User authorization examples: a normal user can only access to his own home directory in Linux but root users is the user who define the policies for other users and has full access to some resources.

Computer authorization examples: An automatic updater can only install updates if the user before authorize it to do so.

-Network layer

- Computer authorization example: Routers are only authorized by a trusted authority to advertise certain router prefixes

Any thoughts?

Smile,

Hosnieh

---

From: Hector Santos <[email-masked]>
Date: Sun, 15 Dec 2013 10:58:59 -0500

> I start with these definitions:

Is "WHO" is as important as being confident that authentication yields 
a consistent and persistent result?   I think this introduces the idea 
of Authentication Portability, for example....

> documents, i.e., his passport.

Can the authentication entity, in this case, a passport, be portable? 
  If not, what prevents it from being portable?  The Photo?

> To check your bank account

We switched the authentication entity example.  An login id, email 
address are portable authentication entities.

> The process of giving an entity a possibility to access some resources
> or authorize it to do something either on a single node or for the
> whole network. It is more to do with policies than other scopes.
>
> Important: the entity needs first to be authenticated then one can
> define a policy for this entity based on its unique identifier
> (whetever used to access other entity on the network)
>
> 2- Real world example
>
> A guard of a building can enter to the building and go to all
> corridors but only can go to room A and B but not room C. He does not
> have a key for that room.
>
> 3- Scope & use cases
>
> - Application layer
>
> User authorization examples: a normal user can only access to his own
> home directory in Linux but root users is the user who define the
> policies for other users and has full access to some resources.
>
> Computer authorization examples: An automatic updater can only install
> updates if the user before authorize it to do so.
>
> -Network layer
>
> - Computer authorization example: Routers are only authorized by a
> trusted authority to advertise certain router prefixes
>
> Any thoughts?

I think Authorization is easier to define, obtain, achieve, comprehend 
and probably have too much trust in its proper mode of operation than 
authentication.  Of course, the classic security problem example are 
"Compromised Users."

Pattern recognition should/can/is been part the process, i.e., 
recognizing unauthorized usage or major changes in usages can trigger 
red flags.  A good example is average monthly credit card purchases 
suddenly changing.

Btw, What are the goals of this WG?   You stated an API, a "library" 
of sort.

Overall, I think much of this leads to the idea of having an 
universal, persistent, consistent id that can applied across many use 
cases.  This can help with the authorization process.  It is managed 
by a centralized system.  But there is still much resistance to this 
single source centralization.

But, is it useful to discuss existing public domain "APIs" to ask why 
they don't work or can't work?  It seems much of your excellent 
outlining appears to be duplicate or already thought out issues, all 
with the same basic real world and insecurity issues.   To me, no 
matter how great the "API" and its coverage of functionality is, the 
"Compromised User" problem seems to be the same basic problem with all 
methodologies.   This is probably why, ideas like physical 
identification methods are increasing (Fingerprint, Eye scanning, etc).

-- 
HLS

---

From: Michael Hammer <[email-masked]>
Date: Sun, 15 Dec 2013 20:23:51 +0000

Ummm..  Wikipedia?  J

From: Secauth [mailto:[email-masked]] On Behalf Of Rafiee, Hosnieh
Sent: Saturday, December 14, 2013 6:15 AM
To: [email-masked]
Subject: [Secauth] initual attempt for auth categorization

Folks,

 

                                           ^

                                           +

                                      xxxxx x xxx

                              xxxxxxxxx          xxxx

                            xxx                     xxx

                          xx                          xx

                               +--------------------+

                               |  IP based access   |

                               |     Lists          |

                      +
+----------------------+

  Authentications+----+                              +-------->|  Session ID
|

                      |        +--------------------+|         |     based
|

                      +------->| unique identity    |+
+----------------------+

                               |     based          |+

                               +--------------------+|
+----------------------+

                                                     +-------->|
Username/Password   |

                                                               |      based
|   x

+----------------------+

                                                       xxx
xx

                                                         xxxx
xxxx

                                                             xxxxx    xxxx
xxxxxxxx

                                                                   xxx    x

                                                                         xxx

                                                                          x

                                                                      SSL or
TLS might be in use

                                                                      for
security

 

Question:

Problems:

Smile,

Hosnieh

P.S. maybe we can also have a nice wiki at the end by gathering all existing
approaches and their purposes. Right?

---

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

Hi Hector, 

> a consistent and persistent result?  

In my opinion, yes, otherwise authentication does not make sense.

> I think this introduces the idea

Sounds interesting. I guess we're already do it for some services but probably not put them in a certain category.

> Can the authentication entity, in this case, a passport, be portable?

It is actually portable. At least, for application layer, in most cases this is true since the users want to access their resources from anywhere. Two  important factors that can be considered here are "accessibility" and "availability".

>   If not, what prevents it from being portable?  The Photo?

It is a good question... The reasons might be as follows but you might add more:
- size (if it is too large it is not easy to carry it)
- weight . If it is made of iron or other heavy materials, I guess there were less motivation to carry it.
- Issuance authority (authorization problem). It is from a country that is not on the map/ It does not look similar to the passport of the same people in the same country! So no way to authenticate it since it does not follow the policy
-  not readable (not clean document that is easy to read and easy to authenticate the person)
- Photo (the photo Is not similar to the owner)
- Validity . The passport expired some time ago.
-...

> We switched the authentication entity example.  An login id, email address
> are portable authentication entities.

In my opinion, they are portable 90%. Otherwise the policy changes this rule. For example, user x can only login to computer y if he has a IP address from network z. This means if user x goes to network u, he can no longer access and login to computer y.

> I think Authorization is easier to define, obtain, achieve, comprehend and
> probably have too much trust in its proper mode of operation than

So, what folks think about the current mechanisms to mitigate the "compromised users"?

> Pattern recognition should/can/is been part the process, i.e., recognizing
> unauthorized usage or major changes in usages can trigger red flags.  A good
> example is average monthly credit card purchases suddenly changing.

But IMHO, this does do nothing with authorization. Since the user did not pass the limit or cannot pass the purchase limit. Say.. our limit is $ 5000 per month and he can either use this limit or not. The bank was not hacked that we see the changes in the limit of 5000 $. So, our target user only decided to travel and uses his credit card more often than other times. But it does not mean that his account is compromised otherwise he, himself, notify the bank. The bank system cannot turn on red flag for every transaction activities that seems to be strange but only can send an email or notify the user. So, my conclusion here is that this part needs human intervention otherwise system, alone, cannot handle such complicated process. I also think that our improvement cannot help this scope since in first step, one need human intervention and then based on the result one can go through the decision making process to react based on the situation. 
IMHO, we can work and try to change the processes that we have a clear general policies. For example, if the bank database was hacked then this is what one can look for reasons but if only a user's account was compromised, before any reaction, there should be another permission from the user side to notify you and let you to investigate the problem. 
Of course, there is still a few things that we can improve. For example, 

Any Thought?

> Btw, What are the goals of this WG?   You stated an API, a "library"

At the moment is actually non-WG and as you said the purpose is the universal API to be available for the means of authentication. So, what we plan to do is to analyze the current authentication and authorization mechanisms and find out the best way to improve them by considering some factors such as
- delay reduction
- possibility for all devices
- deploy ability
-  Security and privacy assurance (as much as possible)
-  transparency for all layers 
-  simplicity
Did I miss any factors?! Hum...

> Overall, I think much of this leads to the idea of having an universal,
> persistent, consistent id that can applied across many use cases.  This can help
> with the authorization process.  It is managed by a centralized system.  But
> there is still much resistance to this single source centralization.

Yes, I understand. This is why I opened this discussion list to talk in IETF and not just a discussion list somewhere. My main reasons are as follows:
You are all experts in one or more areas and also most of you work for companies that lead the internet either by their hardware or software. So, such big ideas that needs the cooperation and thoughts from big companies is really apply here since this cooperation can facilitate the deploy ability and implementations. 

> But, is it useful to discuss existing public domain "APIs" to ask why they don't
> work or can't work?  It seems much of your excellent outlining appears to be
> duplicate or already thought out issues, all

To be honest, IMHO, physical identifications can be compromised easier than other types of authentication.  You might get surprised but I just make some examples: 
For finger print: you everyday touch so many stuff. If you use public transportations, if you go to a restaurant, etc. If I want your finger print I just follow you, when you touch something I will just grap it and have your finger print and make a sample for my own. Isn't it easy? 
The other possible attack, if your scanner hash the value and sent it to the server for authentication. Your finger print (in computer will be just a bunch of random numbers) always generate the same value. Only the attacker needs once to have a sample of that on the network (eavesdropping) and then use it for other purposes. For people who think these kinds of physical identification can help, I am again opposite to this otherwise you try to come up with combination of several approaches. Then I guess the problem will be deploy ability and expenses. Can all people access to finger print scanner? Can people carry them? 
By using those approach, IMHO, you only change the problems to other types but you do not actually solve the problem. 
By the way, please also think about the scary scenario that the server which keeps the sample of your finger print or eye scan just hacked... can you change your eye scan or finger print like how you do with your passwords?
So, what I want to conclude here is that I just know that by using those fancy stuff the problem will not be addressed but just turn to new problems and maybe new unknown problems and I think it is also easier to hack those stuff rather than our current system.

For eye scanning, can you carry your eye scanner everywhere? Do you have enough money to buy such expensive scanners? And at the end the same problem with finger print can happen for eye samples... 

The other problems with the above approaches is privacy. You use the same identification everywhere so you're vulnerable to tracking attacks.

This is why I said, we're living in a scary world... 

About APIs, just share the names. We can discuss and learn from their problems .

Thanks,
Smile, 
Hosnieh

---

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

>Ummm....  Wikipedia?  :)

Yes, why not :-) .  You can find some discrete information regarding authentication and authorization but actually we can improve it and add more page and make these relationships.
Are you in?

Smile,
Hosnieh