IPsec

IPsec security mechanism is obsoleted in latest Diameter RFC-6733, but it is still maintained for backward compatibility.

Ipsec encrypt and authenticate all traffic at the IP level by a by pre-shared secret key, and uses IKE (Internet Key Exchange) for peer authentication, negotiation of security associations and key management.
 

There are two modes of operation of IPSec 

1) Transport Mode :- In this mode only payload (data to be transfer) of IP packet is encrypted and /or auhenticated.
2) Tunnel Mode:- Entire IP packet is encrypted and/or authenticated.

All Diameter deployment MUST support IPsec in Transport mode (per packet encryption and authentication implicitly in transport mode) and MUST support the Replay Protection mechanisms of IPsec.

IPsec uses the following protocols to perform various functions

1)Authentication Header :- provides INTEGRITY, Authentication and protection against replay attacks.Diagram shows the AH header between the IP header and the TCP header.

Fig:- Packet Format after including AH

Various fields of AH and their purpose are given below.

Fig:- Various fields of AH

1)Payload Len:-The length of this Authentication Header .
2)Reserved:-Reserved for future use (all zeroes until then).
3)Security Parameters Index:-Arbitrary value which is used (together with the source IP address) to identify the security association of the sending party.
4)Sequence Number :-A monotonic strictly increasing sequence number (incremented by 1 for every packet sent) to prevent replay attacks. When replay detection is enabled, sequence numbers are never reused because a new security association must be renegotiated before an attempt to increment the sequence number beyond its maximum value.[5]
5)Integrity Check Value:-Variable length check value. Something similar to check sum.

2)ESP (Encapsulating Security Payload):-provides INTEGRITY, Authentication and protection against replay attacks. And ALSO provide the support for encryption. ESP does not protect the IP packet header. until Tunnel Mode is applied.

Fig:- Packet format after including ESP     -Encryption

ESP and AH can be used together on the same datagram without redundancy. Various fields of ESP and their purpose are given below.
 

Fig:- Various Fields of Esp

1)Security Parameters Index:-Arbitrary value which is used (together with the source IP address) to identify the security association of the sending party.
2)Sequence Number:-A monotonically increasing sequence number (incremented by 1 for every packet sent) to protect against replay attacks. There is a separate counter kept for every security association.
3)Payload data:-The protected contents of the original IP packet, including any data used to protect the contents (e.g. an Initialisation Vector for the cryptographic algorithm). The type of content that was protected is indicated by the Next Header field.
4)Padding:-Padding for encryption, to extend the payload data to a size that fits the encryption's cypher block size, and to align the next field.
5)Pad Length:-Size of the padding in octets.
6)Integrity Check Value :-Variable length check value. Something similar to check sum.
 

Your Comments /Suggestions and Questions are always welcome.I would try to clarify doubts with best of my knowledge. So feel free to put Questions.

Securing Diameter Messages

Diameter is end to end secure protocol.The Diameter Protocol MUST have security mechanism TLS or IPsec. In Diameter deployment Diameter client MUST support IPsec, and MAY support TLS. While Diameter servers MUST support TLS and IPsec. This is mandatory because any client can send request irrespective of whether it support IPsec or TLS,so server must support both.

IPsec security mechanism primarily used for intra-domain traffic i.e. with in the same domain. While TLS is primarily used for inter-domain traffic.

Before we go into details of these security mechanism we will first see what are the threats to diameter message, some basic issues for which security is needed are integrity,confidentiality and replay. Replay is the major issue.

Replay Attack

A replay attack occurs when somebody intercepts (Untrusted proxy or Diameter agent) a series of packets and uses them later either to flood the system for causing a denial-of-service (DoS), or to gain entry to the trusted network.

Solution of Replay

To overcome the problem of Replay it is necessary to identify each packet uniquely so that in some implementation a unique number of given range is allotted to each message and it was ensured that number should not be tempered during transmission. Once a node receive the message with no. which it has already received is rejected immediately.

Now we will see how these security mechanisms works to secure the whole diameter message End-to-End.

1) IPsec (Within same domain)  [Obsoleted]

2) TLS

3)    DTLS 

Now RFC-6733 (Latest) says, TLS to be used when two nodes communicating on TCP transport  connection and DTLS to be used when two nodes communicating of SCTP transport connection. Support for IPSec is no more needed.

Your Comments /Suggestions and Questions are always welcome.I would try to clarify doubts with best of my knowledge. So feel free to put Questions.

|

TLS Transport Layer Security

TLS is predominantly applied between two peer in two different domain.When a node initiates a request to another node on TLS, here originator act as TLS Client and receiver at as TLS Server. In order to ensure a mutual authentication the Diameter server will request a certificate from the TLS client.

Cipher Suite
It is the combined name various activities( such as Authentication, encryption,message authentication code(MAC)etc.) done during the negotiation on security settings for network connection using TLS and SSL. There are many different algorithms which can be used for encrypting data and for computation MAC. Some provide high level security and require large computation, others are less secure and less computation for encryption and decryption.
During connection establishment both client and server (Nodes) exchange the information about the cipher suit they have and select a common cipher suit with highest level of security for communication. If they don't have the common cipher suite, then no secure connection is possible hence connection is closed.

Following cipher suites are available the base diameter
TLS_RSA_WITH_RC4_128_MD5
TLS_RSA_WITH_RC4_128_SHA
TLS_RSA_WITH_3DES_EDE_CBC_SHA DES uses a 56-bit key.
TLS_RSA_WITH_AES_128_CBC_SHA

Here RSA is key Exchange Method
RC4,AES,3DES are encrytion algorithms
MD5,SHA are the hash function used on encryption

Overview of Encryption
1)plaintext: This is what you want to encrypt
2)ciphertext: The encrypted output
3)enciphering or encryption: The process by which plaintext is converted into ciphertext
4)encryption algorithm: The sequence of data processing steps that go into transforming plaintext into ciphertext. Various parameters used by an encryption algorithm are derived from a secret key.
5)secret key: A secret key is used to set some or all of the various parameters used by the encryption algorithm. The important thing to note is that the same secret key is used for
6)encryption and decryption in classical cryptography. It is for this reason that classical cryptography is also referred to as symmetric key cryptography.
7)deciphering or decryption: Recovering plaintext from cipher-text.
8)decryption algorithm: The sequence of data processing steps that go into transforming ciphertext back into plaintext. Various parameters used by a decryption algorithm are derived from the same secret key that was used in the encryption algorithm. In classical cryptography for commercial and other civilian applications, the decryption algorithm is made public.
9)key space: The total number of all possible keys that can be used in a cryptographic system. For example, DES uses a 56-bit key. So the key space is of size 256, which is approximately the same as 7.2 × 1016.

 
Key exchange (also known as "key establishment") is method in cryptography by which cryptographic keys are exchanged between users, allowing use of a cryptographic algorithm. this become important because of large keyspace number of permutations become larger and other party will not able to understand which key is used for encryption and it is not possible to check each and every key to decrypt data.

TLS in General

Fig:- Showing message transfer during Client-authenticated TLS handshake 

TLS (Transport layer security) is successor of SSL(Secure Socket Layer) is a cryptographic protocols that provide communications security over the Transport layer.TLS is based on the handshake procedure, During this handshake the client and server agree on various parameters used to establish connection security.
Client-authenticated TLS handshake

1. Negotiation phase:
-- A client sends a ClientHello message specifying the highest TLS protocol version it supports, a random number, a list of suggested cipher suites and compression methods.
-- The server responds with a ServerHello message, containing the chosen protocol version, a random number, cipher suite and compression method from the choices offered by the client. The server may also send a session id as part of the message to perform a resumed handshake.
-- The server sends its Server-Certificate message (depending on the selected cipher suite, this may be omitted by the server).
-- The server requests a Get-Certificate-Req from the client, so that the connection can be mutually authenticated, using a CertificateRequest message.
(Certificate is used to verify that the node is indeed what it portrays to be.)
-- The client responds with a Client-Certificate message, which contains the client's certificate.
-- The server sends a ServerHelloDone message, indicating it is done with handshake negotiation.
-- The client sends a ClientKeyExchange message, which may contain a PreMasterSecret, public key, or nothing. (Again, this depends on the selected cipher.) This PreMasterSecret is encrypted using the public key of the server certificate.
-- The client sends a CertificateVerify message, which is a signature over the previous handshake messages using the client's certificate's private key. This signature can be verified by using the client's certificate's public key. This lets the server know that the client has access to the private key of the certificate and thus owns the certificate.
-- The client and server then use the random numbers and PreMasterSecret to compute a common secret, called the "master secret". All other key data for this connection is derived from this master secret (and the client- and server-generated random values), which is passed through a carefully designed "pseudorandom function".

2. The client now sends a ChangeCipherSpec record, essentially telling the server, "Everything I tell you from now on will be authenticated (and encrypted if encryption was negotiated)." The ChangeCipherSpec is itself a record-level protocol and has type 20 and not 22.
-- Finally, the client sends an encrypted Finished message, containing a hash and MAC over the previous handshake messages.
-- The server will attempt to decrypt the client's Finished message and verify the hash and MAC. If the decryption or verification fails, the handshake is considered to have failed and the connection should be torn down.

3. Finally, the server sends a ChangeCipherSpec, telling the client, "Everything I tell you from now on will be authenticated (and encrypted if encryption was negotiated)."
-- The server sends its own encrypted Finished message.
-- The client performs the same decryption and verification.
4. Application phase: at this point, the "handshake" is complete and the application protocol is enabled, with content type of 23. Application messages exchanged between client and server will also be encrypted exactly like in their Finished message. The application will never again return TLS encryption information without a type 32 apology.






Your Comments /Suggestions and Questions are always welcome.I would try to clarify doubts with best of my knowledge. So feel free to put Questions.

Introduction to Diameter

Diameter is a Authentication Authorization and Accounting (AAA) protocol. It works on the Application Layer if we consider OSI Layered model. Diameter is a message based protocol, where AAA  nodes exchange messages and receive Positive or Negative acknowledgment for each message exchanged between nodes. For  message exchange  it internally uses the TCP and SCTP which makes diameter reliable. Its technical specifications are given in RFC-6733 Diameter Base Protocol.

Diameter basically a successor of RADIUS (Remote Authentication Dial In User Service) Which is also a AAA protocol based on UDP. UDP does not use implicit hand-shaking mechanism for providing reliability, ordering, or data integrity, Unreliability was the major Flaw in Radius.

Here i have tried to explain various facets of Diameter Base Protocol, Before going to the details of various aspects of the Diameter Base Protocol we will see the improvements of the diameter over RADIUS.
                                                                                                                                                 (NEXT)


Your Comments /Suggestions and Questions are always welcome. I would try to clarify doubts with best of my knowledge. So feel free to put Questions.  

Diameter Peer Discovery

As the name suggests it is the process by which a node finds another node to whom it is going to communicate, dynamically. Earlier in RADIUS we have to manually configure the name or address of the node as well as the secret key for each node. This will lead to large administrative burden. So to overcome this limitation diameter provides the dynamic Diameter agent discovery which is also known as peer discovery which makes simple and more  robust deployment of Diameter Services. The option of manual configuration of diameter node is also available.

Before going to details of HOW the diameter agent discovers the other diameter agent, we will look in to when it is needed to discovery a diameter agent by other diameter agent. There are two cases when it is needed.

1) When Diameter client needs to discovery a first-hop Diameter Agent. i.e. when a client wants to communicate with server or some diameter agent then it is not necessary  that client is directly connected to server/diameter agent. there might be one or more diameter agents(relay,proxy) between the client and server. so the message should pass through them, now which is the first node/hop to which message should be sent is known by peer discovery.

2) And in second case, any of the in between diameter agent will search the next agent to which the message to be send so that message reach to destination.

  ______ Case-I  _________ Case-II _________ case-II  ______

 |Client|----->|Dia Agent|----->|Dia Agent|----->|Server|

 |______|      |_________|      |_________|      |______|

           Fig- Showing When Peer discovery is Needed

    

In Diameter peer discovery is done by any of the methods.

1) SRVLOC

2) DNS

Whenever a peer is discovery, it will causes a entry of that peer in PEER-TABLE.

1)SRVLOC (SERVICE LOCATION PROTOCOL)

Here i have tried to explain how SRVLOC works in general and what are its basic features.It is a service discovery protocol that provides a flexible and  scalable way to the computers and other devices to find the information about existence,location and configuration of services in a network dynamically.

Traditionally, user have to find service by knowing the name of a network host (a human readable text string) which is an alias for the network address. But in SLP/SRVLOC user supplies the desired type of service and a set of attributes which describe the service.  Based on that description, the Service Location Protocol resolves the network address of the service for the user.

In SLP/SRVLOC Applications are modeled as clients that need to find servers attached to any of the available networks within an enterprise.For cases where there are many different clients and/or services available, the protocol is adapted to make use of nearby Directory Agents that offer a centralized repository for advertised services.

Terminology for SRVLOC
1)User Agent (UA):-A process working on the user's behalf to establish contact with some service.
2)Service Agent (SA):-A process working on the behalf of one or more services to advertise the services.

3)Directory Agent(DA):-A process which collects service advertisements.There can only be one DA present per given host.

SLP/SRVLOC is message based mechanism of finding the service. These are the messages used in SLP/SRVLOC.

Message Types used in SRVLOC

1)Service Request (SrvRqst)- Generated by User Agent to find the specific service in the network.
2)Service Reply (SrvRply) - It is the Reply in Response of Service Request either by Service Agent or by Director Agent.
3)Service Registration (SrvReg)-It is generated by Service Agent to register their services at Directory Agent.
4)Service Deregister (SrvDeReg)-It is generated by Service Agent to deregister their services from Directory Agent.
5)Service Acknowledge (SrvAck)-It is generated by Directory Agent in response of either SrvReg or SrvDeReg toward ServiceAgent
6)DA Advertisement (DAAdvert)- It is generated by Directory Agent to unsolicitely advertise itself whenever User Agent and Service Agent boots up.
7)SA Advertisement (SAAdvert) -In the absence of Directory Agents, a User agent may request Service Agents in order to discover their scope configuration.  The User Agent may use these scopes in requests.

PROCESS OF DISCOVERY

In the small network SLP allows User Agent to directly issue a command to Service Agent, In this case User Agent BroadCasts/Multicasts the SrvRqst over the network. And in response the Service Agent which has the desired service will send the Unicast SrvRply to the User Agent.

+-----------+ ----Multicast SrvRqst----> +---------------+
|User Agent |                            | Service Agent |
+- ---------+ <----Unicast SrvRply------ +---------------+

In larger networks, one or more Directory Agents are used.  The Directory Agent functions as a cache.  Service Agents send register messages (SrvReg) containing all the services they advertise to Directory Agents and receive acknowledgements in reply (SrvAck). These advertisements must be refreshed with the Directory Agent or they expire.  User Agents unicast requests to Directory Agents instead of Service Agents if any Directory Agents are known.

 +-------+ --Unicast SrvRqst--> +-----------+ <--Unicast SrvReg-- +--------+
 | User  |                      | Directory |                     |Service |
 | Agent |                      |   Agent   |                     | Agent  |
 +-------+ <--Unicast SrvRply-- +-----------+ --Unicast SrvAck--> +--------+
User and Service Agents discover Directory Agents two ways.  First, they issue a multicast Service Request for the'Directory Agent' service when they start up.  Second, the Directory Agent sends an  unsolicited advertisement infrequently, which the User and Service Agents listen for.  In either case the Agents receive a DA Advertisement (DAAdvert).

+---------------+ -----Multicast SrvRqst ----> +-----------+
|    User or    | <----Unicast DAAdvert------  | Directory |
| Service Agent |                              |   Agent   |
+---------------+ <----Multicast DAAdvert----  +-----------+

This is how the peer discovery take place by SRVLOC. Same phenomenon is used in Base Diameter Protocol for Peer Discovery.

2)DNS Service Protocol

It is the way of finding the services on the network by using standard DNS programming interface. DNS provides various API's for the purpose of service discovery.The DNS Service Discovery API helps you to perform three main tasks:
-->Registering a service (DNSServiceRegister)
-->Browsing for services (DNSServiceBrowse)
-->Resolving service names to host names (DNSServiceResolve)
In support of these main tasks, this API can directly assist you in performing two subsidiary tasks:
-->Enumerating domains (finding recommended service domains)      (DNSServiceEnumerateDomains)
-->Updating registrations(changing your DNS registration data dynamically)

Similar type of  builtin  API's will be used by Base Diameter Protocol implicitly for peer discovery.

Improvements of Diameter over RADIUS

Failover Mechanism 

RADIUS does not have any kind of failover mechanism, even it can't have failover mechanism because it is UDP based and UDP does not have implicit handshaking procedures. Therefore once packet has sent on RADIUS it is probably assumed that it will reached to the destination in proper order. While diameter defines the Application layer acknowledgements and failover methods which we will define later.

Transmission Layer Security

RADIUS does not provide per packet confidentiality. RFC-3162 provide IPsec but it is not mandatory, while in diameter it is mandatory to apply per packet confidentiality with the help of IPSec (IP Security) and TLS (Transport Layer Security).

Reliable Transport

RADIUS is based on UDP which makes it unreliable implicitly while the diameter runs over reliable transport medium TCP or SCTP.

Agent Support

RADIUS does not provide for explicit support for agents,including Proxies, Redirects and Relays i.e. Radius does not define the functionality of agents, means which part of the radius message is altered by which agent,While Diameter defines agent behavior explicitly i.e. which agent will alter which part of Diameter message. For example Redirect agent will not alter any part of diameter message/ packet. Each agents behviour is defined later.

Server-initiated messages

Server-initiated messages implies; the messages that server initiates him self for the client. For instance the established connection or session  between server and client  is disconnected  due to some undesirable event, Now server sends a message to client for reconnect or reauthenticate himself.   In RADIUS server-initiated messages are defined in [DYNAUTH] (Dynamic Authentication),support is optional. This makes it difficult to implement features such as unsolicited disconnect or reauthentication/reauthorization on demand across a heterogeneous deployment. Support for server-initiated messages is mandatory in Diameter.

Auditability 

Auditability is the property that allows the system to detect whether the untrusted proxies have altered the message attributes (even packet header) or not. RADIUS does not define data-object security mechanisms, and as a result, untrusted proxies may modify attributes or even packet headers without being detected. Combined with lack of support for capabilities negotiation, this makes it very difficult to determine what occurred in the event of a dispute. While implementation of data object security is not mandatory but support within Diameter. 

Transition support

Initially, it is expected that Diameter will be deployed within new network devices, ans gateways will enable communication between legacy RADIUS devices and Diameter agents.

While Diameter does not share a common protocol data unit (PDU) with RADIUS,considerable effort has been expended in enabling backward compatibility with RADIUS, so that the two protocols may be deployed in the same network. 

Capability negotiation 

RADIUS does not support error messages, capability negotiation, or a mandatory/non-mandatory flag for attributes. Since RADIUS clients and servers are not aware of each other's capabilities,they may not be able to successfully negotiate a mutually acceptable service, or in some cases, even be aware of what service has been implemented. While this is supported in Diameter. It is later defined in detail.

Peer discovery and Configuration

RADIUS deployment requires that the name or address of servers or clients be manually configured, along with the corresponding shared secrets. This results in a large administrative burden, and creates the temptation to reuse the RADIUS shared secret, which can result in major security issue if the Request Authenticator is not globally and temporally unique as required in . Through DNS, Diameter enables dynamic discovery of peers. Dynamic peer discovery is defined later in detail.

Roaming Support 

To improve scalability, the concept of proxy chaining is used  via an intermediate server, facilitating roaming between providers. However, since RADIUS does not provide explicit support for proxies, and lacks auditability and transmission-level security features as explained above, hence RADIUS- based roaming is open to attack from external parties as well as susceptible to fraud perpetrated by the roaming partners themselves. Thus, it is not suitable for wide-scale deployment on the Internet using proxy chaining . Diameter deals with this problem by providing secure and scalable roaming.

(PREVIOUS)                                                     (NEXT)
Your Comments /Suggestions and Questions are always welcome. We would try to clarify doubts with best of our knowledge. So feel free to put Questions.

Capability Negotiation

The basic motive of this process is to KNOW about the other node to which a node intended to communicate before establishing the connection, ie. whether other node contains the applications for which node wants to communicate. 

Technically speaking, It is the process where two diameter peer exchange their identity and its capabilities (such as protocol version number, supported diameter applications, security mechanism etc.). Peer share their capabilities by CER/CEA Message (Capability-Exchange-Request/Capability-Exchange-Answer).

If one peer sends a CER message to another Peer and receiver does not have support for 

 
1) any common application then it must return the CEA with Result-Code Avp set to DIAMETER_NO_COMMON_APPLICATION and should disconnect the transport layer connection.

2)no common security mechanism then it must return the CEA with Result-Code Avp set to DIAMETER_NO_COMMON_SECURITY and should disconnect the transport layer connection. (Only maintained to have backward compatibility Because in latest release Transport Level security is establish before diameter connection so CER/CEA message is also comes under TLS/DTLS for more Info Click Here)

3)If CER is received from any unknown peer then receiver should discard the message, or send the CEA with the Result-Code Avp set to DIAMETER_UNKNOWN_PEER.
 

If the local implementation policy permits to receive CER from unknown hosts,a successful CEA MAY be returned, and the life time of the peer entry in PEER-Table is equal to the lifetime of the transport connection. If in any case transport connection fails then all the pending transactions destined to the unknown peer can be discarded.

The CER and CEA messages MUST NOT be proxied, redirected or relayed. Since CER/CEA messages can not be proxied, but still it is possible that proxy will receive a CER message and proxy does not have any peer to handle the application requested in CER, in this case proxy set the E bit in CEA and set the Result-Code Avp to DIAMETER_UNABLE_TO_DELIVER, sends back to CER generator peer.

For Example:- consider two nodes A and B and Node-A contains three applications X,Y,Z and two security mechanism s1 and s2 while Node-B contains two applications A,X and s1 security mechanism. Now Node-A will send CER to Node-B. Node -B will process the request and will create and send the CEA showing success and the common application i.e. X and s1 security mechanism. Now Node-A become aware of the fact that it can communicate for X application and s1 security mechanism.

Probable CER And CEA would be:-

      ________          CER                     ________

     | Node-A | ------------------------------>| Node-B |

     |________| <------------------------------|________|

                                          CEA 

               

<CER> ::= < Diameter Header: 257, REQ >                          <CEA> ::= < Diameter Header: 257 >
    { Origin-Host }                                               { Result-Code =SUCCESS}
    { Origin-Realm }                                              { Origin-Host }

    { Host-IP-Address }                                           { Origin-Realm }
    { Vendor-Id }                                                 { Host-IP-Address }  
    { Product-Name }                                              { Vendor-Id } 
    [ Inband-Security-Id =s1 ]                                    { Product-Name } 
    [ Inband-Security-Id =s2]                                     [ Inband-Security-Id =s1 ]   

    [ Vendor-Specific-Application-Id =X]                          [ Vendor-Specific-Application-Id =X]
    [ Vendor-Specific-Application-Id =Y] 
    [ Vendor-Specific-Application-Id =Z]  
 

                 CER/CEA Message Exchange

  
Your Comments /Suggestions and Questions are always welcome.I would try to clarify doubts with best of my knowledge. So feel free to put Questions.