Subject: [Secauth] Welcome and to do things

From: "Rafiee, Hosnieh" <[email-masked]>
Date: Wed, 11 Dec 2013 19:27:52 +0000

Folks,

Thanks for joining to the group. You can consider this message as both test message and the start of discussion. I guess the first important topic is the discussion regarding the milestones and  "to do things". One of the purpose is to come up with the best implementation solution for authentication (a library or something like that) that can provide security, privacy with acceptable performance and no/less operational barriers.

To have an idea that how folks think about the real issue so that we can see the problems from different points of view, I start with some questions. Feel free to share your experiences or add more questions or answer them.

-       What are the available authentication approaches? (either secure or (might?! Be?!) non-secure)

-       Are the existing solutions are automatic solution or it is manual? do we need to address them as well? If yes, to what extend?

-       What are the main factors that an implementation should consider when dealing with the real world and with the existing technology and devices(operational view)?

-       Are there still systems that uses an IP-based access list?

-       If yes, does/do it/they only in use in network layer?

-       By increasing numbers of proxy servers in all layers (proxy servers that are used for different purposes, one example is SIP proxy, the other example is ND proxy), what are the important factors to be considered so that the nodes know the other communicating nodes?

-       Do we have already security problem for authenticating the nodes to proxy servers and vice versa?

-       ...

Thanks,

Smile,

Hosnieh

---

From: "Moriarty, Kathleen" <[email-masked]>
Date: Wed, 11 Dec 2013 14:41:48 -0500

Hi Hosnieh,

Thanks for the introductory information.  It would be helpful, at least for me, to understand the scope or use cases that you are interested in discussing on this list so we know where to start.  Authentication is a messy space as there are so many options.  The existing options may have each been started with different use cases or to improve upon an existing authentication protocol.  In some cases they overlap.  If the scope of activities are meant to be limited to a specific use case or set of use cases for discussion, it would be helpful to understand that.  If this is a more general effort, it would be great to have some picture of how the existing protocols are complimentary or have overlap.  Everyone that has to research authentication options for an implementation has to do a bunch of research without any way to see what is there already or what the best options are for their use cases.  I may be way off-topic, but think some way of mapping this out would be extremely helpful and valuable to the numerous engineers out there who need to understand how to pick the appropriate solution for their use case and not re-invent the wheel.  Even doing something like that through Wikipedia could be extremely helpful.  This is something I have been thinking about for a while after observing the vast duplication of efforts that folks like those on this list could help to address.

Thanks,
Kathleen

From: Secauth [mailto:[email-masked]] On Behalf Of Rafiee, Hosnieh
Sent: Wednesday, December 11, 2013 2:28 PM
To: [email-masked]
Subject: [Secauth] Welcome and to do things

Folks,

-       ...

Thanks,

Smile,

Hosnieh

---

From: "Rafiee, Hosnieh" <[email-masked]>
Date: Wed, 11 Dec 2013 20:53:32 +0000

Hi Kathleen,

Thanks for your question.

>Thanks for the introductory information.  It would be helpful, at least for me, to understand the scope or use cases that you are interested in discussing on this list so we know where to start. > Authentication is a messy space as there are so >many options.  The existing options may have each been started with different use cases or to improve upon an existing authentication protocol.  In some cases they overlap.  If the scope of activities are meant to be limited to a specific use case >or set of use cases for discussion, it would be helpful to understand that.  If this is a more general effort, it would be great to have some picture of how the existing protocols are complimentary or have overlap.  Everyone that has to research >authentication options for an implementation has to do a bunch of research without any way to see what is there already or what the best options are for their use cases.  I may be way off-topic, but think some way of mapping this out would be >extremely helpful and valuable to the numerous engineers out there who need to understand how to pick the appropriate solution for their use case and not re-invent the wheel.  Even doing something like that through Wikipedia could be> >extremely helpful.  This is something I have been thinking about for a while after observing the vast duplication of efforts that folks like those on this list could help to address.

At first, I had an idea to only focus on SSAS (the one that I am working and improving it) and uses it as a means of authentication in other layers. But I think it might be useful to widen the focus so that we can see and cover more scope and come up with the best, most appropriate solution. It might be also something around SSAS but also it might be something beyond it. The most important thing is that we consider the realization of it. I am ready to implement but it is also good to see the cooperation of large incorporations in this implementation. So, what we come up with can be available for all current devices either small (like a mobile phone) or big one. This solution , then, can be accessible for all applications, services in all upper layers. In other word, an efficient framework. This can be a default solution for many places that are looking for secure, privacy enabled authentication. I guess everybody in this list is expert in one or more areas and it is good to see opinions of non-security experts and security experts. This really gives us the chance to better touch the problem.

Thanks again for asking,
Smile,
Hosnieh

---

From: Michael Hammer <[email-masked]>
Date: Thu, 12 Dec 2013 01:28:13 +0000

Hi.

There may be some history here that many that joined are not aware of.
You are talking solutions, but what exactly is the problem being solved?

A Use Case or two could demonstrate what is not working as Kathleen noted.
Otherwise, this seems like a research project.

Mike

-----Original Message-----
From: Secauth [mailto:[email-masked]] On Behalf Of Rafiee, Hosnieh
Sent: Wednesday, December 11, 2013 3:54 PM
To: Moriarty, Kathleen; [email-masked]
Subject: Re: [Secauth] Welcome and to do things

Hi Kathleen,

>Thanks for the introductory information.  It would be helpful, at least for
me, to understand the scope or use cases that you are interested in
discussing on this list so we know where to start. > Authentication is a
messy space as there are so >many options.  The existing options may have
each been started with different use cases or to improve upon an existing
authentication protocol.  In some cases they overlap.  If the scope of
activities are meant to be limited to a specific use case >or set of use
cases for discussion, it would be helpful to understand that.  If this is a
more general effort, it would be great to have some picture of how the
existing protocols are complimentary or have overlap.  Everyone that has to
research >authentication options for an implementation has to do a bunch of
research without any way to see what is there already or what the best
options are for their use cases.  I may be way off-topic, but think some way
of mapping this out would be >extremely helpful and valuable to the numerous
engineers out there who need to understand how to pick the appropriate
solution for their use case and not re-invent the wheel.  Even doing
something like that through Wikipedia could be> >extremely helpful.  This is
something I have been thinking about for a while after observing the vast
duplication of efforts that folks like those on this list could help to
address.

At first, I had an idea to only focus on SSAS (the one that I am working and
improving it) and uses it as a means of authentication in other layers. But
I think it might be useful to widen the focus so that we can see and cover
more scope and come up with the best, most appropriate solution. It might be
also something around SSAS but also it might be something beyond it. The
most important thing is that we consider the realization of it. I am ready
to implement but it is also good to see the cooperation of large
incorporations in this implementation. So, what we come up with can be
available for all current devices either small (like a mobile phone) or big
one. This solution , then, can be accessible for all applications, services
in all upper layers. In other word, an efficient framework. This can be a
default solution for many places that are looking for secure, privacy
enabled authentication. I guess everybody in this list is expert in one or
more areas and it is good to see opinions of non-security experts and
security experts. This really gives us the chance to better touch the
problem.

Thanks again for asking,
Smile,
Hosnieh

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

---

From: "Rafiee, Hosnieh" <[email-masked]>
Date: Thu, 12 Dec 2013 12:28:47 +0000

Hi Michael

> You are talking solutions, but what exactly is the problem being solved?

No, I am not going to jump in to the conclusion. There are still a long road to decide on the solution. 

> A Use Case or two could demonstrate what is not working as Kathleen noted.

Issues and thoughts
-  Problem with spoofed identification
- Problem with performance
- Problem with unique means of authentication -> barriers on device supports
- problem with having secure approach in upper layer but ignoring the attacks on lower layers
- Problem with deploy ability of the existing approaches (operational barriers)
- Is it better to do authentication in lower layers such as network layer? (link layer is only valid in local link so it might not be useful to go through that since not accessible in other networks) 
- Any alternative means of authentication except using only SSL or other protocols to secure the process?

1- Define a means of identifying other communicating nodes
This use case allows the nodes to identify each other. This is especially helpful if the nodes are authenticated based on a unique identifier. Does this use case make problem for user's privacy and allows tracking?
Is IP address enough?
Is session ID enough?
How about privacy?
How about security?
One example, SIP proxy servers.
If the applications securely started any communication, are there still vulnerable from lower layers? What if the attacker is inside the network? 
2- Decrease the delay issues causes by lower layers (especially network layer)
This use case allows to find the delay problems. The focus can be either real-time services or both real-time and non-real-time services (user's delay tolerance).
- Decrease Packet size -> delivery of large packets are not as fast as delivery of small packets. Large packets -> because of using security approaches (carrying long key sizes, etc)
- Decrease verification time 
- Energy and resources usage -> using security approaches needs extra resources for generation and verification -> What about battery barriers-> What about memory sizes? -> 
3- Automate the whole/most authentication process
- Decrease the administrations' tasks

4- Unified the authentication mechanisms and have transparency
....

This is only a few use cases that might be good for the start of discussion. Any thought? Anything else?

Thanks,
Smile,
Hosnieh

---

From: Michael Hammer <[email-masked]>
Date: Thu, 12 Dec 2013 15:45:26 +0000

Inline...

-----Original Message-----
From: Rafiee, Hosnieh [mailto:[email-masked]] 
Sent: Thursday, December 12, 2013 7:29 AM
To: Michael Hammer
Cc: [email-masked]; [email-masked]
Subject: RE: Welcome and to do things

Hi Michael

> You are talking solutions, but what exactly is the problem being solved?

No, I am not going to jump in to the conclusion. There are still a long road
to decide on the solution. 

Issues and thoughts
>> What identity?  Who is spoofing?  Why are they spoofing?  More specifics
please.

>> Performance of what?

>> What means of authentication?  What device?

- problem with having secure approach in upper layer but ignoring the
attacks on lower layers
>> Sounds like a lower layer problem.  Architecture keeps layers separate
for a reason.
>> You don't want to create cross-layer dependencies that then cause Apps to
fail when lower layers are modified.

- Problem with deploy ability of the existing approaches (operational
barriers)
>> Seems like consideration rather than core issue.

- Is it better to do authentication in lower layers such as network layer?
(link layer is only valid in local link so it might not be useful to go
through that since not accessible in other networks) 
>> Same can be said for network level.  Do you want to authenticate every
packet?
>> Are you trying to make something connectionless connection-oriented?

- Any alternative means of authentication except using only SSL or other
protocols to secure the process?

1- Define a means of identifying other communicating nodes
This use case allows the nodes to identify each other. This is especially
helpful if the nodes are authenticated based on a unique identifier. Does
this use case make problem for user's privacy and allows tracking?
Is IP address enough?
Is session ID enough?
How about privacy?
How about security?
One example, SIP proxy servers.
If the applications securely started any communication, are there still
vulnerable from lower layers? What if the attacker is inside the network? 
>> Are you suggesting that an attacker can decrypt a TLS encrypted SIP
packet?

2- Decrease the delay issues causes by lower layers (especially network
layer)
This use case allows to find the delay problems. The focus can be either
real-time services or both real-time and non-real-time services (user's
delay tolerance).
- Decrease Packet size -> delivery of large packets are not as fast as
delivery of small packets. Large packets -> because of using security
approaches (carrying long key sizes, etc)
- Decrease verification time 
- Energy and resources usage -> using security approaches needs extra
resources for generation and verification -> What about battery barriers->
What about memory sizes? -> 
>> These have been around a long time and studied by many.  What is new
here?

>> Last two are considerations of a solution, not a core issue.

This is only a few use cases that might be good for the start of discussion.
Any thought? Anything else?

Thanks,
Smile,
Hosnieh

---

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

Hi Mike,

To be clear here, to have a good local security within the networks, one would need to apply one of the current security approaches. There are a few approaches available for this means in network layer (and in specific in IP layer) such as SeND or some other non-secure approaches that at the moment is in use for this purpose. If one can spoof the IP, it might be easier for him to play the MITM attack since upper layer don't have much information about the owner of this iP. 

Moreover, In a network with hundreds of nodes, you're not going to preload every single node with the self-generated certification of each other. IMHO, It is too much work.  So, what the nodes really would do is to exchange their public keys to each other by starting the communication based on their IP address. If there is no attacker during this start. Everything seems to be fine but what if the attacker now listen to this communication and spoof the IP address of the other nodes and send the public key of himself to the real node. This is just a thought, correct me if I am wrong and tell me why you think it is NOT possible. We all here to discuss about possibility usability of the opinions here and share and decide on the best one. 

We can come up with the implementation or a library of what is integrated with the current TLS, etc secure approaches. It is also possible that we can come up with the alternative one.  BTW, please do not misinterpret my sentence about integration of authentication in all layers. I do not mean to physically integrate all OSI layers but what I meant is to make the parameters that is used in network layer for authentication available in upper layers so that if any applications or services would like to use them for a secure authentication, it can do it by calling this library without going through the understanding of network layer or security in that layer.

The most important thing on which we want to focus is that we have thousands of devices (mobile phone, cars, laptops, PCs, ipad,tablets, etc) that are increasing every minutes. All what are going to use IP as a means of communications. I only imagine a world full of IP based devices. Companies also would like to offer the best services to their customers by fancy ideas such as controlling all your devices via public networks, i.e., Internet and access them wherever you are!. For me, it is really a scary scenario and I guess with fast growing technologies, you have to expect this in next few years. (some companies already offer some services such as controlling your home from your work, etc). Since they are IP based, any flaws in network layers can have a direct effect the privacy and security of the user. 

One might say, the attacker cannot be inside the network. I am really opposite of this sentence. If one only read the security news, recently millions of facebook and yahoo password hacked. Both company claimed that it wasn't any flaws in their system but they can do nothing about the malwares on users' system.

These are only a few reasons that why we need network security and when we go through the implementation of that to decrease the delay, why not to use the same authentication approach in other layers?

> >> What identity?  Who is spoofing?  Why are they spoofing?  More specifics

The identity can be a session ID or it can be your computer's IP address.

> - Problem with performance

When you use any security approaches, verification needs time. Generation needs time. For some applications and services, this time might not be acceptable. One example is using VoIP. It is real time application and there is a maximum delay threshold. 
The other important factor is CPU and battery usage. This is especially important for devices that has limited computational resources and using an approach that might busy the whole CPU for some time for generation/verification is not ideal as the device lose its functionality

So, If I want to summarize here, the factors are delay tolerance, CPU usage, Battery usage. 

> >> What means of authentication?  What device?

I have already explained this that what is in my mind is a cross framework implementation that is possible to use in all devices (car, mobile phone, laptop, pcs. Servers, etc)

> >> Sounds like a lower layer problem.  Architecture keeps layers separate

Nope, If there is a security problem in lower layers, the chance of harming the target system is more than 50%, although, one secured your upper layers. 

> fail when lower layers are modified.

Again it is not cross layer dependencies. The purpose is not to integrate layers but only use or integrate the authentication of one layer for other layers. Because, for providing such library the main layer, i.e., network layer needs to have this implementation, the upper layers only benefit from it but not dependent to it.

> >> Seems like consideration rather than core issue.

There are a lot of standards in IETF that really cannot be implemented or only disabled since there wasn't any consideration from operational view. So, IMHO, it is really important to consider this fact and I see it as one of the main issue with many existing approaches

> >> Are you trying to make something connectionless connection-oriented?

Not exactly. Since, I do not think like TLS you need to have a handshake otherwise we come up with something that merge to SSL or TLS. 

> protocols to secure the process?

Other security protocols as well. It was only an example.

> >> Are you suggesting that an attacker can decrypt a TLS encrypted SIP

If the certification of both communication nodes are not preloaded or no CA is used, then, IMHO, the attacker has a chance to do this in a start of the communication.  
However, my main focus was on proxy servers. Since the communication in this case is not between two original end nodes but the proxy server is in between and this causes many security issues. The questions such as how the proxy server can identifies the both ending nodes and facilitate this connections. 

> >> These have been around a long time and studied by many.  What is new

The problem wasn't solved and still there :-) but might be improved. The most studies also in case there is no security approaches running there and they only focused on the protocol itself.

> >> Last two are considerations of a solution, not a core issue.

Many protocols are not implemented or have deploy ability problems because of automation problem. One big example is DNSSEC. There are many people working on this issue. So, IMHO, it is a big issue and not just a small consideration. I might be wrong but this is based on my observation.

Smile,
Hosnieh (Sara)

P.S. Sorry for the delay to answer you. I had a nice?!! Christmas gift from my webhosting company, I.e., their system automatically deleted the DNS records and all mailbox related to one of my main domain that I use for ietf and other private stuff without any notification (I usually don't use this email for ietf).... they are really a good entrepreneurs since they made me busy with many tasks and still continues... They THOUGHT that when I transferred the domain to other registrar, I also want to delete it! I hope next time before they use their thoughts, they ask me before...

---

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

"what I meant is to make the parameters that is used in network layer for
authentication available in upper layers 
so that if any applications or services would like to use them for a secure
authentication, 
it can do it by calling this library without going through the understanding
of network layer or security in that layer."

That is a self-contradiction.  You either understand the lower layer or you
don't.
You can't have your cake and eat it too.

You don't have to integrate layers to create unhealthy dependencies between
layers.
What happens to your security if I replace the IP layer and 
it may be based upon with some other network or internetwork protocol?
It breaks.

Also, if something unexpected happens in the IP layer, again, your
application breaks.  
We experienced that with SIP.

Despite protestations, you are coupling layers together.  That is bad.  Not
good architecture.

The whole point of PKI is to not have to pre-share keys, which is the core
problem you cite.
The mechanisms exist, but the will to do the implementation is lacking.
That does not mean the technology is bad, just that the implementation is
bad.

Because of mobility, you can't always know what the IP address is going to
be in advance.
Does your solution need to be resilient to mobility?

Your delay and battery usage is going to increase the more layers you
replicate security in.
As far as an application is concerned, if the PKI is done properly and TLS
works properly, 
what more are you lacking?

Mike

-----Original Message-----
From: Rafiee, Hosnieh [mailto:[email-masked]] 
Sent: Saturday, December 14, 2013 4:25 AM
To: Michael Hammer
Cc: [email-masked]; [email-masked]
Subject: RE: Welcome and to do things

Hi Mike,

To be clear here, to have a good local security within the networks, one
would need to apply one of the current security approaches. There are a few
approaches available for this means in network layer (and in specific in IP
layer) such as SeND or some other non-secure approaches that at the moment
is in use for this purpose. If one can spoof the IP, it might be easier for
him to play the MITM attack since upper layer don't have much information
about the owner of this iP. 

Moreover, In a network with hundreds of nodes, you're not going to preload
every single node with the self-generated certification of each other. IMHO,
It is too much work.  So, what the nodes really would do is to exchange
their public keys to each other by starting the communication based on their
IP address. If there is no attacker during this start. Everything seems to
be fine but what if the attacker now listen to this communication and spoof
the IP address of the other nodes and send the public key of himself to the
real node. This is just a thought, correct me if I am wrong and tell me why
you think it is NOT possible. We all here to discuss about possibility
usability of the opinions here and share and decide on the best one. 

We can come up with the implementation or a library of what is integrated
with the current TLS, etc secure approaches. It is also possible that we can
come up with the alternative one.  BTW, please do not misinterpret my
sentence about integration of authentication in all layers. I do not mean to
physically integrate all OSI layers but what I meant is to make the
parameters that is used in network layer for authentication available in
upper layers so that if any applications or services would like to use them
for a secure authentication, it can do it by calling this library without
going through the understanding of network layer or security in that layer.

The most important thing on which we want to focus is that we have thousands
of devices (mobile phone, cars, laptops, PCs, ipad,tablets, etc) that are
increasing every minutes. All what are going to use IP as a means of
communications. I only imagine a world full of IP based devices. Companies
also would like to offer the best services to their customers by fancy ideas
such as controlling all your devices via public networks, i.e., Internet and
access them wherever you are!. For me, it is really a scary scenario and I
guess with fast growing technologies, you have to expect this in next few
years. (some companies already offer some services such as controlling your
home from your work, etc). Since they are IP based, any flaws in network
layers can have a direct effect the privacy and security of the user. 

One might say, the attacker cannot be inside the network. I am really
opposite of this sentence. If one only read the security news, recently
millions of facebook and yahoo password hacked. Both company claimed that it
wasn't any flaws in their system but they can do nothing about the malwares
on users' system.

These are only a few reasons that why we need network security and when we
go through the implementation of that to decrease the delay, why not to use
the same authentication approach in other layers?

> - Problem with performance

When you use any security approaches, verification needs time. Generation
needs time. For some applications and services, this time might not be
acceptable. One example is using VoIP. It is real time application and there
is a maximum delay threshold. 
The other important factor is CPU and battery usage. This is especially
important for devices that has limited computational resources and using an
approach that might busy the whole CPU for some time for
generation/verification is not ideal as the device lose its functionality

So, If I want to summarize here, the factors are delay tolerance, CPU usage,
Battery usage. 

> >> What means of authentication?  What device?

I have already explained this that what is in my mind is a cross framework
implementation that is possible to use in all devices (car, mobile phone,
laptop, pcs. Servers, etc)

> >> Sounds like a lower layer problem.  Architecture keeps layers 

Nope, If there is a security problem in lower layers, the chance of harming
the target system is more than 50%, although, one secured your upper layers.

> fail when lower layers are modified.

Again it is not cross layer dependencies. The purpose is not to integrate
layers but only use or integrate the authentication of one layer for other
layers. Because, for providing such library the main layer, i.e., network
layer needs to have this implementation, the upper layers only benefit from
it but not dependent to it.

> >> Seems like consideration rather than core issue.

There are a lot of standards in IETF that really cannot be implemented or
only disabled since there wasn't any consideration from operational view.
So, IMHO, it is really important to consider this fact and I see it as one
of the main issue with many existing approaches

> (link layer is only valid in local link so it might not be useful to 
> go through that since not accessible in other networks)

Not exactly. Since, I do not think like TLS you need to have a handshake
otherwise we come up with something that merge to SSL or TLS. 

> >> Are you suggesting that an attacker can decrypt a TLS encrypted SIP

If the certification of both communication nodes are not preloaded or no CA
is used, then, IMHO, the attacker has a chance to do this in a start of the
communication.  
However, my main focus was on proxy servers. Since the communication in this
case is not between two original end nodes but the proxy server is in
between and this causes many security issues. The questions such as how the
proxy server can identifies the both ending nodes and facilitate this
connections. 

> >> These have been around a long time and studied by many.  What is 

The problem wasn't solved and still there :-) but might be improved. The
most studies also in case there is no security approaches running there and
they only focused on the protocol itself.

> >> Last two are considerations of a solution, not a core issue.

Many protocols are not implemented or have deploy ability problems because
of automation problem. One big example is DNSSEC. There are many people
working on this issue. So, IMHO, it is a big issue and not just a small
consideration. I might be wrong but this is based on my observation.

Smile,
Hosnieh (Sara)

P.S. Sorry for the delay to answer you. I had a nice?!! Christmas gift from
my webhosting company, I.e., their system automatically deleted the DNS
records and all mailbox related to one of my main domain that I use for ietf
and other private stuff without any notification (I usually don't use this
email for ietf).... they are really a good entrepreneurs since they made me
busy with many tasks and still continues... They THOUGHT that when I
transferred the domain to other registrar, I also want to delete it! I hope
next time before they use their thoughts, they ask me before...

---

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

>That is a self-contradiction.  You either understand the lower layer or you

Not necessarily. One big example is the use of Microsoft windows (close source example) or recent desktop versions of Ubuntu (open source example). The users only use it and the system works for them. They can also deploy their own programs in those OS without the need to have a good knowledge of kernel. They only need to know what libraries they need to trigger to run their programs. This is the same case in the proposed API. We want it to be transparent for users in other layers. They only call it but not necessarily need to understand the complexity in network layer or how it handles the packets. If they are curious to know, that is the other case and does not mean that they need to know.

>You can't have your cake and eat it too.

One can let his/her mommy to bake a cake ;-) . So what I want to say here is that you can have your cake without having a knowledge of how to bake it. It is ready for you just go for it and eat it... (I feel hungry now...)

>it may be based upon with some other network or internetwork protocol?

I call them the conditions to be considered in the API. So, as you know, you can never find any software that can handle all conditions otherwise we also considered it. If the API is scalable, then later it is possible to scale it with new protocols. So I do not see it something which is impossible but considerations.

>We experienced that with SIP.

If IP layer doesn't work, how you want to have your communications? At least with the current infrastructure of the internet. If SIP protocol fails in some special conditions, it is not necessarily the problem of IP layer. You have to see what SIP expects from IP layer and what condition they did not considered. This is again I call it consideration. For any API there is a need for black box and white box testing for this purpose to consider and solve the most unexpected behavior of system.

>Despite protestations, you are coupling layers together.  That is bad.  Not

Again I say no. Even though, we say it is true, some other protocols do the same. One big example is ssh. It uses many different layers. Do you say it integrated the layers? I say no. It only uses different layers for different purposes. The other important thing is that your system is free to use this approach/API. We only consider the best possibilities and best possible implementations. Our goal is to handle the current problems and simplifies the authentication and of course, our goal is to make this API available for all devices. You either like to use it or not. 

>That does not mean the technology is bad, just that the implementation is

The problem is that, the technology didn't consider the deploy ability. This is bad and now one cannot solve that problem. one can use many patches to fix the holes but nothing would fit exactly to this issue.
So what I see as a big issue with PKI is that scalability and costs. Are you going to buy certificates for each single nodes of your network. Maybe yes, if you have only a few nodes. Maybe no, if you have thousands of nodes. 
The other thing is that you can use active directory but you're going to have your main server as a windows servers or be dependent to Microsoft technologies. Maybe some accepts it but for others maybe it is too much costs.

>Does your solution need to be resilient to mobility?

Since I discussed about small nodes as well and also cars and every devices, I also considered mobility as one of the main requirements. It is possible to handle that so that the node who changes the IP address is the same node by using his old public key and new public key. 

>Your delay and battery usage is going to increase the more layers you

We handle delay in network layer and calculate the energy consumptions and make it as minimum as possible. Then the API makes this information available for any services or apps that want to use it and care about these values. 

>what more are you lacking?

As far as I know, it is like a dream because of the reasons I mentioned before (costs, etc). PKI was first proposed in 1999 and still it is on progress. So, I would see it as a good way for authorizing probably routers but not every single nodes or every single users in the world or probably in near future we have to consider the other planets as well  :-)

Thanks,
Smile,
Hosnieh