[Secauth] Perspectives and possibilities

["Hosnieh Rafiee" <[e-mail]>]

Hello,

Sorry for a long pause to get back to group again. 

Recently I tried to categorize all the current security approaches either in
network layer or in upper layers. What I found is that most of the
applications use either TLS (RFC 6176, 5246, etc.) or SSL (RFC 6101, etc.)
as a security mechanisms. Some try to secure the whole communications via
the use of VPN (RFC 4026) or IPsec (RFC 4301, 6071, etc.). There are also
two security approaches in IPv6 to avoid IP spoofing that is CGA (RFC 3972)
and SSAS (http://tools.ietf.org/html/draft-rafiee-6man-ssas ). In IPv4 there
is no way to avoid IP spoofing otherwise one uses a certification that is
verifiable via a third party trusted authority.


So, what I found out is that, the two top popular security approaches are
TLS and SSL. You can see the use of them in SSH or in application layer for
securing domains or a part of IPsec is also the use of these approaches. Now
consider an example scenario using SSH:

Node A wants to connect to Node B over the internet using an IP address: at
the beginning of this communication before the user A start entering his
username and password,  he needs to accept the certification of Node B. If
the node B certificate is authorized by the a trusted authority (TA) that
the name of this TA is listed in the trusted list of Node A, then after Node
A verifies this certificates and check this by asking that TA, it does not
ask for any confirmation from the user. This only happens once. Next time,
the SSH service in Node A stores the information regarding Node B public key
and will not process this process again. 

If Node B has a certification that is not listed in the trusted list of Node
A, then it needs to provide Node A with a list of CAs so that Node B can be
verified by Node A. 

One problem here is that, there are some inexpensive certifications that
many hosting companies sell them. I mostly see their use for domains and not
IP addresses. For buying these certificates, no paper works are required and
the certificates is issued for a certain domain and not bounded completely
to any person or company! What I can see as a weaknesses here is that,
usually the sender node needs to provide the verifier nodes with the list of
CAs (usually one or two). Since these certification are not bound to any IP
addresses or they are more for a certain domain, then IMHO, the attacker can
also play a role in between and provide Node A with a false list that is
related to his own fake CA. If Node A really checks all the list up to root
certificate (or what it really trusts) then the attacker has no chance to
proceed the attack that I am going to explain. But if this doesn't happen
and only Node A checks only the first level certificates (this means Node A
only asks the fake CA to provide the public key and also the list of CAs and
trust this list), or the attacker register domains with no ascii codes
(other codes and other language but look similar to the Node B's domain . In
this case, the attacker can play a MITM attack and these SSL certificates
does not help the node. The reason for such problem.... IP spoofing in
network layer.

If Node B has a self-generated certification, then the user in Node A will
receive a message that asked whether he would like to trust a node with this
certification. This is where the attacker can spoof this message and send
his own public key to the node. When the initiate phase of the SSL is not
secure, then it does not matter whether not  user A proceed with any further
authentication approach.

One possibility to protect the Node A, in my sample scenario, from this
attack is the use of the mechanisms used to avoid IP spoofing in network
layer. For IPv6 as I explained earlier, it is CGA or SSAS. But CGA is not an
ideal solution if one wants to consider all kinds of nodes and consider all
situations. 
I guess, one possibility to start this work while continue this discussion
is  to have a base mechanism for this API and use this base to extend it and
consider all possible problems and improve it until the API become an ideal
one. IMHO, SSAS might be an ideal solution, since it is simple and no extra
efforts while it also provide the node with the prevention of IP spoofing.  

For IPv4 we still needs some thoughts. Is it good to have efforts toward
having a bounding between IPv4 and IPv6 (if the node supports both). In this
case can we come up with an algorithm to provide this bindings? Are we
limited because of the subnet prefixes in IPv4? If anybody has any thought
about any mechanisms for IPv4, please share it.

Any thought about the base of this API? Are we ready to start with the base?

Smile,
Hosnieh