I was trying to understand the difference between Transport security and message security from the below link and came across the following content.
The http://msdn.microsoft.com/en-us/library/ff648863.aspx says that
When using transport security, the user credentials and claims are passed by using the transport layer. In other words, user credentials are transport-dependent, which allows fewer authentication options compared to message security.
Can someone please explain me the meaning of above statement with an example if possible ?
It has mainly two parts which I could not understand :
user credentials are transport-dependent.
allows fewer authentication options compared to message security.
If you read further in those article, you yourself might be able to make out.
If you see TCP/IP or OSI Layers of the Protocol suit you will notice that upto Transport layer communication is mostly dependent on communication mechanism. The protocols of Transport layer are limited (HTTP, TCP, IPC, MSMQ) for transporting of data. They transport all the data in same manner irrespective of the type of data. Here the channel that is transporting is made secure.
On the other hand in message level security, it is message that is secure. You can use any type of mechanism to encrypt / authenticate your message, and in this case Transport level security provides added advantage.
In simple term, A, B and C are three persons. A wants to send a message to C and B is transporter of the message. If A send his message in a simple envelop, then the message is as secure as the transporter that is B. But if A send a message locked in a box and only C has its key, then his message is secure as B plus it has security of the locked box.
Hope this helps.
Further going with the above analogy, if the transporter B is say your postal service, then A has limited options of having security and limited flexibilty to change B's security provision as those are decided by another party (the Postal Department). But in case you are sending a locked box, the locking mechanism is your choice, you have flexibility to choose type of lock of your own choice as long as C agrees and can open it.
Related
I am developing a blockchain for IoT applications, where there are a number of gateways (miners) spread throughout the city and several nodes (sensors) connected to each of them. Each gateway can be added by an end user so this is a untrusted environment. How can I make sure that there isn't fake data being sent to the chain by one of the miners?
I have looked up some consensus protocols by find that none fit this specific problem since there is no value being exchanged.
Every miners sends a ping to a master server and receives from it the list of miners on the network. Then they connect to each other by p2p.
Any ideas of how could I solve this?
Blockchain can be used in both cases permission-less or permissionned, if you want to prevent that anyone can broadcast data, then you have to authenticate the nodes before they can join the network. If even after authenticating the nodes there is a chance that an authenticated node send "fake data" then a trust mechanism must be implemented, nodes verify the trustworthiness of the data's source and decide if the node is trusted and accept the data or not.
In order to prevent spamming or fake data being posted, it has to be added as a consensus rule to the protocol. Otherwise, it requires another layer that validates data based on off-chain data (but doesn't prevent data from being stored in blocks). Blockchain is for achieving distributed consensus, in a permission-less system. Restricting who can participate is not a permission-less system, and would be a centralized system because someone has to determine who is allowed to participate.
The answer to the query lies in Blockchain Oracles.
Oracles to-date are centralized services, meaning any smart contract using such services has a single point of failure, which nullifies any benefits gained from the decentralized nature of smart contracts.
To fill this gap, Chainlink was developed as the first decentralized oracle that can provide external data to smart contracts. As a result, the security and determinism of smart contracts can be combined with the knowledge and breadth of real-world external events. Chainlink will provide a smart contract with access to any external API needed.
As according to chainlink here and here
Blockchains and smart contracts cannot access data from outside of
their network. In order to know what to do, a smart contract often
needs access to information from the outside world that is relevant to
the contractual agreement, in the form of electronic data, also
referred to as oracles. These oracles are services that send and
verify real world occurrences and submit this information to smart
contracts, triggering state changes on the blockchain.
When you read about WCF Message Security and compare it to Transport security, one of the drawbacks that they always mention is that transport security is point-to-point and can't secure a message routed through intermediaries.
What is an example of these intermediaries. When would you use one?
All my experience with services is with point-to-point communication so I'm trying to build a context for when you might encounter a SOAP intermediary or router or proxy.
There are other questions on SO that beat around what I'm getting at but don't directly answer my question. For example, in this question:
Does SSL provide point-to-point security?
the answer says:
intermediate system', I think that quote means a system that must
access the message in the middle (intentionally or not)... not just a
router, but something actually decrypting, viewing and/or modifying
the message.
My question is: What would be an example of a system that need to view/decrypt/modify the message and why would it need to do that?
I just found a partial answer in this document from MS:
http://msdn.microsoft.com/en-us/library/ff647097.aspx
Part of it says:
Message layer security that uses X.509 certificates is flexible enough to provide point-to-point or end-to-end security. This allows messages to be persisted in a secure state for short periods for queue-based processing or for longer periods in an archived state.
So an example would be if a message were queued or stored off to disk. It would stay encrypted through the time it was processed and deleted from disk, presumably.
Edit: Here is a really good article on building a WCF Service Router that explains some of the reasons you might want to use one: http://msdn.microsoft.com/en-us/magazine/cc500646.aspx
See also: http://msdn.microsoft.com/en-us/library/ms731081.aspx
I have 3 simple questions.
What is the Diameter protocol in simple explanation?
Why is it used?
How can one use it?
I have searched the net for a practical explanation but couldn't find one. All there is, is some technical blabber.
Per the ITU, DIAMETER is the successor to RADIUS (twice as good). No, it's not a joke. RADIUS was, and is still used, in many telecommunications networks as the interface to the authorization, authentication and accounting protocol server (typically just called the AAA). The problem with RADIUS is that:
It's built on UDP -- RADIUS packets can just drop off.
It was never designed to handle much more than short, attribute/value pairs.
While it is extendible, it's limited to vendor-specific attributes (VSAs)
Theses were all wonderful back with Livingston incorporated made the Portmaster terminal/modem server. (Ah, back in the day... I can hear the telebit trailblazers now...) But that was when 19.2Kb UUCP was cool.
DIAMETER aims to address these issues for the modern world. First, it's based on TCP. This addresses the drop-out problem. We now know that packets don't get there "half way". We can also encrypt streams. It's also, courtesy of TCP, capable of having much larger attribute sets (we call them AVPs). Thus, it's much easier to convey value sets beyond the simple key/value pair.
As an example, in DIAMETER< you can do a login request, sending far more than a username/password. You can send the course location for example, telling the AAA where the user is at login (maybe there are geo-location rules for access). And, because we have a more robust, richer language to say things in, the AAA can convey, not only the yes/no, but the rules for a given yes, or the reasons for the no.
Does this help?
I found this complete article on Diameter protocol written in IBM website.
Introduction
The Diameter protocol was derived from the RADIUS protocol with a lot
of improvements in different aspects, and is generally believed to be
the next generation Authentication, Authorization, and Accounting
(AAA) protocol. The Diameter protocol was widely used in the IMS
architecture for IMS entities to exchange AAA-related information.
Because the IMS system might be the next big thing in the telecom
industry, we believe a clear understanding of the Diameter protocol is
necessary for understanding the essence of the IMS architecture. This
article offers an overview of Diameter and how it works. For
developers interested in how AAA in IMS works, or who want to
implement Diameter applications, this article is a good starting page.
With the emergence of new technologies and applications such as
wireless networks and mobile IPs, the requirements for authentication
and authorization have greatly increased, and access control
mechanisms are more complex than ever. The existing RADIUS (Remote
Authentication Dial-In User Service) protocol can be insufficient to
cope with these new requirements; what's needed is a new protocol that
is capable of fulfilling new access control features while keeping the
flexibility for further extension. This is where the Diameter protocol
comes into play.
Diameter is a Authentication Authorization and Accounting (AAA) protocol. It works on the Application Layer if we consider OSI Layered model.
Example of AAA protocol:-
Any User trying to access a Network (Ex: Internet Service Provider) has to undergo "AAA" procedure that is being implemented by that Network.
1. Authentication: The network will validate that its an Authenticate User.
2. Authorization: The network will authorize the services requested by the User.
3. Accounting: The network will keep a track of usage made by the User.
While performing the above three steps, the Network may reject the User from using the service at any point and that is how security is maintained and hence the importance of AAA protocol.
So, Diameter basically is a message based protocol, where AAA procedure may occur and the AAA nodes exchange messages and receive Positive/Negative acknowledgment for each message exchanged between nodes.
In addition to IBM’s article “Introduction to Diameter” already mentioned by Hamed in a previous answer, Cisco’s article “Authentication, authorization, and accounting overview” also has some interesting information about Diameter, comparing it to RADIUS.
“Authentication identifies a user; authorization determines what that user can do; and accounting monitors the network usage time for billing purposes.” … “Diameter is the next-generation AAA protocol and overcomes (several) RADIUS deficiencies.”
“The RADIUS protocol carries authentication, authorization and configuration information between a NAS and a RADIUS authentication server.” (In this context, a NAS is a network access server, a gateway providing access to a protected network.) … “Implemented by several vendors of network access servers, RADIUS has gained support among a wide customer base.” RADIUS has codes for a limited number of attributes (including user name and password, service type, login information, etc.), so developers took advantage of its “vendor-specific attribute” (VSA) to exchange custom data, extending (in a proprietary manner) the scope of RADIUS, yet staying within its restrictions (e.g., attribute value no longer than 253 bytes). So, why use Diameter? Diameter offers much greater flexibility (longer data field, expandability, capability negotiation), higher performance (“32-bit alignment”), greater reliability & availability (TCP and STCP support, better acknowledgement mechanism and error messages, failover), increased security (“end-to-end security”), etc.
Just like FreeRADIUS implements a FOSS RADIUS server that you can install on a server so that your other applications and devices (e.g., a Wi-Fi access point or wired switch performing 802.1X authentication) can interact with it, FreeDiameter is a FOSS Diameter framework that you can install on a server. However, while TMCNews’ article “The Role of Diameter in IMS” (2007) mentions that “Diameter has been heavily adopted by the 3GPP in the IMS standards set”, I haven’t seen any consumer- or small-business-grade application or device that makes use of Diameter. On the other hand, Diameter is reportedly “backward compatible with RADIUS to ease migration” (Cisco), through a “translation agent” (IBM). For example, FreeDiameter has an extension, the “RADIUS/Diameter extensible gateway” (app_radgw.fdx), whose “purpose is to allow a RADIUS client to work with a Diameter server”. However, the documentation also warns that the “translation of RADIUS messages to Diameter is quite a complex task. It is likely that the translation plug-ins need some fine-tuning to fit your particular needs.”
I need to implement a very secured Web Service using WCF. I have read a lot of documents about security in WCF concerning authorization, authentication, message encryption. The web service will use https, Windows Authentication for access to the WS, SQL Server Membership/Role Provider for user authentication and authorization on WS operations and finally message encryption.
I read in one of documents that it is good to consider security on each layer indenpendently, i.e. Transport Layer security must be thought without considering Message Layer. Therefore, using SSL through https in combination with message encryption (using public/private key encryption and signature) would be a good practice, since https concerns Transport Layer and message encryption concerns Message Layer.
But a friend told me that [https + message encryption] is too much; https is sufficient.
What do you think?
Thanks.
If you have SSL then you still need to encrypt your messages if you don't really trust the server which stores them (it could have its files stolen), so this is all good practice.
There comes a point where you have a weakest link problem.
What is your weakest link?
Example: I spend $100,000,000 defending an airport from terrorists, so they go after a train station instead. Money and effort both wasted.
Ask yourself what the threat model is and design your security for that. TLS is a bare minimum for any Internet-based communications, but it doesn't matter if somebody can install a keystroke logger.
As you certainly understand, the role of Transport-Level Security is to secure the transmission of the message, whereas Message-Level Security is about securing the message itself.
It all depends on the attack vectors (or more generally the purpose) you're considering.
In both cases, the security models involved can have to purposes: protection against eavesdropping (relying on encryption) and integrity protection (ultimately relying on signatures, since based on public-key cryptography in most cases).
TLS with server-certificate only will provide you with the security of the transport, and the client will know that the communication really comes from the server it expects (if configured properly, of course). In addition, if you use client-certificate, this will also guarantee the server that the communication comes from a client that has the private key for this client certificate.
However, when the data is no longer in transit, you rely on the security of the machine where it's used and stored. You might no longer be able to assert with certainty where the data came from, for example.
Message-level security doesn't rely on how the communication was made. Message-level signature allows you to know where the messages came from at a later date, independently of how they've been transferred. This can be useful for audit purposes. Message-level encryption would also reduce the risks of someone getting hold of the data if it's stored somewhere where some data could be taken (e.g. some intranet storage systems).
Basically, if the private key used to decrypt the messages has the same protection as the private key used for SSL authentication, and if the messages are not stored for longer time than the connection, in that case it is certainly overkill.
OTOH, if you've got different servers, or if the key is stored e.g. using hardware security of sorts, or is only made available by user input, then it is good advice to secure the messages themselves as well. Application level security also makes sense for auditing purposes and against configuration mistakes, although personally I think signing the data (integrity protection) is more important in this respect.
Of course, the question can also become: if you're already using a web-service that uses SOAP/WSDL, why not use XML encrypt/sign? It's not that hard to configure. Note that it does certainly take more processor time and memory. Oh, one warning: don't even try it if the other side does not know what they are doing - you'll spend ages explaining it and even then you run into trouble if you want to change a single parameter later on.
Final hint: use standards and standardized software or you'll certainly run into crap. Spend some time getting getting to know how things work, and make sure you don't accept ill formatted messages when you call verify (e.g. XML signing the wrong node or accepting MD5 and such things).
I have read at several places that transport security is only hop to hop (vs. endpoint to endpoint), and thus has limited use in internet scenarios where there may be several hops in-between your endpoints. First, is this correct? Second, why is transport security only hop to hop? What is preventing the intermediary nodes from simply relaying what they have gotten from their respective receivers?
what they mean when they say that transport security provides only hop-by-hop protection is that at the intermediate steps, the incoming data stream is unencrypted and the intermediary can see the message in plain-text if it so wishes. The intermediary does encrypt the message again before passing it over to next node. So if the intermediary nodes are trusted nodes (your own servers) there is no harm in using transport security, but if the intermediary nodes are not owned by you, these nodes can see the plain message and your data is vulnerable.
This brings me to the question: what are intermediary nodes? Are these the nodes specified in clientVia? So if I don't have any clientVia's (as is mostly the case) can I safely use transport security without the need for message-level security?
References:
http://www.silverlighthack.com/post/2008/12/10/WCF-101-Understanding-Transfer-Security-Visually.aspx. There is a nice diagram here, but per my understanding above, I think part of it is wrong.
http://msdn.microsoft.com/en-us/library/ff647370.aspx