|
|
The Managed IP Network is a core IP network whose responsibilities include: interconnection for the components required for signaling, media, and quality of service establishment. Also provides the connectivity between other Managed IP Networks and HFC DOCSIS networks. The functional components are Call Management Server (CMS), Announcement Server (ANS), OSS back-office server, Signaling Gateway (SG), Media gateway (MG) and Media Gateway Controller (MGC).
Packet Cable Zone consists of the set of MTAs in one or more DOCSIS HFC networks that are MANAGED BY A SINGLE CMS. It can be also defined a packet cable domain that consist of one or more Zones.
Asymmetric or Public Keys Algorithms make use of two different keys: a public key and a private key. The encryption is done with one key while the decryption is done with the other key, and viceversa. It is not possible to encrypt and decrypt with the same key. This eliminates the drawback of symmetric algorithms of requiring a secure key exchange channel. One important property of these algorithms is that they can provide authentication. The encryption with private keys is used in digital signatures. Two different public key algorithms are RSA and Diffie Hellman. The Diffie-Hellman algorithm is a key exchange algorithm that is used for securely establishing a shared secret (symmetric key) over an insecure channel. The communicating parties exchange public information from which they derive a key. An outsider can not reconstruct the key from the information passed through the insecure channel. After the shared secret (key) has been established, it can then be used to derive keys for use with symmetric key algorithms such as DES. An advantage of this algorithm is the possibility to derive a shared secret key (for symmetrical algorithm use)
Hash functions. These are functions that take a variable input data and produce fixed length output data (the hash value). If two messages match, it is highly sure that the messages are the same. If a hash function takes a key as a second input parameter and the output depends on both the message and the key is called a Message Authentication Code (MAC). A MAC is used for digital signatures. The encryption of a hash with the private key is called a digital signiture. Examples of hash functions are MD5 and SHA-1.
Note that the encryption algorithms will be used by the security mechanism (IPSec, IKE, Kerberos).
IP security framework has three main components Authentication Header (AH), Encapsulating Security Payload (ESP) and Internet Key Exchange (IKE). IPSec is independent of the current cryptographic algorithms. It uses them, but it is free to choose any of them. The specific implementation of an algorithm for use by an IPSec protocol is often called a transform. For example, the DES algorithm used in ESP is called ESP DES-CBC transform. An important concept for the IPSec is the Security Association. A Security Association is a unidirectional (simplex) logical connection between two IPSec systems, uniquely identified by the following triple: <Security Parameter Index, IP Destination Address, Security protocol>;
SPI -Security Parameter Index (SPI) is used to identify different SAs with the same destination address and security protocol. The SPI is carried in the header of the security protocol (AH or ESP).
Authentication Header Protocol AH is used to provide integrity and authentication IP datagrams. AH authenticates fields in the IP header as possible. The mutable fields (those fields that are modified on the route can not be protected with AH. If it is required protection also for those fields, then tunneling the datagram is required (encapsulate the datagram into a new IP packet- prepends a new IP header and a AH header. In the transport mode the AH header comes between IP header and the payload. Although it has the advantage of less processing overhead, it has the drawback of no authenticating the mutable fields. In the tunnel mode the datagram is encapsulated in a new IP packet with AH. Now we have integrity and authentication for the whole datagram including the mutable fields, but the computation time is increased.
Encapsulating Security Payload (ESP)
ESP is used to provide integrity check, authentication and encryption to IP datagrams. ESP processing is applied only to non-fragmented packets. The payload is located (encapsulated) between the trailer and the header. Some important aspects that should be mentioned.
IKE (Internet Key Exchange protocol)
The Internet Key exchange protocol provides management of keys and SAs for IPSec AH and ESP protocol. This is a peer to peer authentication and keying mechanism. One of the drawbacks of the peer to peer protocol is that is that each peer must know and implement a site's security policy which in practice can be quite complex. But it has the advantage of the ability for two peers to mutually authenticate and exchange keys without the need for an actively participating third party. Mainly the protocol consists of two phases.
In Phase 1 a set of negotiations establishes a master secret key
In the most general case public key cryptography is used to establish the ISAKMP SAs between the systems(! ISAKMP SAs != IPSec SAs), and to establish the keys that will be used to protect the messages that will follow in the phase 2 negotiation. Phase 1 is concerned with establishing the protection for IKE message itself, but does not establish any SAs or keys for protecting user data (but it generates ISAKMP SAs and keys). A Diffie Hellman algorithm is used to establish the first phase shared secret key. The drawback of the algorithm is the computationally expensiveness and prone to denial of service attacks. A short summary of the six ISAKMP exchanged messages for setting up ISAKMP SAs at this phase is:
Phase 2 - Setting Up the Protocol SAs(note that the protocol is not ISAKMP and can be IPSec for example): After having completed the Phase 1 negotiation process to set up the ISAKMP SAs, Host's next step is to initiate the Phase 2 message exchanges to define the security associations and keys that will be used to protect IP datagrams exchanged between the pair of users (these are referred to somewhat obtusely as "non-ISAKMP SAs"). Because the purpose of the Phase 1 negotiations was to agree on how to protect ISAKMP messages, all ISAKMP Phase 2 payloads, but not the ISAKMP header itself, must be encrypted using the algorithm agreed to by the Phase 1 negotiations. Messages are protected by the security associations generated at phase 1. Usually during the second phase the refresh of the cryptographic keys takes place at a very short interval (a couple of minutes).
A number of three messages is exchanged in the second phase.
In addition, the IKE methods have been designed with the explicit goals of providing protection against several well-known exposures:
Denial-of-Service: The messages are constructed with unique cookies that can be used to quickly identify and reject invalid messages without the need to execute processor-intensive cryptographic operations.
Man-in-the-Middle: Protection is provided against the common attacks such as deletion of messages, modification of messages, reflecting messages back to the sender, replaying of old messages, and redirection of messages to unintended recipients.
Perfect Forward Secrecy (PFS): Compromise of past keys provides no useful clues for breaking any other key, whether it occurred before or after the compromised key. That is, each refreshed key will be derived without any dependence on predecessor keys.
The following authentication methods are defined for IKE at he first phase:
1. Pre-shared key
2. Digital signatures (DSS and RSA)
3. Public key encryption (RSA and revised RSA)
Kerberos and other authentication systems
This is a system that requires the existence of a third party element, that both communicating parties (client and server) trust. In this way it is eliminated the difficult key management from IKE and its computational effort. In case the systems allow the possibility of existence of the third party server, this is a better solution. If the existence of the third party is not feasible, then IKE is a better solution, since IKE does not require third party. In the Kerberos system [6], a client that wants to connect to a server for its service, first has to ask a ticket for the server from a trusted third party. This party that issues the ticket to the client is the Kerberos Authentication Server. The client is known to the KAS as a principal name (c). The private key (Kc) is the authentication key known only to the user and the KAS. It is a symmetric key between KAS and the client.
1. Client -> KAS The client sends a message c, tgs, n, to the KAS, containing its identity (c), a nonce (a mean to identify this request), and requests for a ticket for use with the ticket-granting server (TGS).
2. KAS -> Client The authentication server looks up the client name (c) and the service name (the ticket-granting server, tgs) in the Kerberos database, and obtains an encryption key for both client and TGS (Kc and Ktgs). The KAS then forms a response to send back to the client. This response contains an initial ticket Tc,tgs , which grants the client access to the requested server (the ticket-granting server). The ticket Tc,tgs contains Kc,tgs , c, tgs, nonce, and some other info. The KAS also generates a random encryption key Kc,tgs , called the session key. It then encrypts this ticket using the encryption key of the ticket-granting server (Ktgs ). This produces what is called a seal ticket Tc,tgs Ktgs . A message is then formed consisting of the sealed ticket and the TGS session key Kc,tgs .
3. Client -> TGS Upon receiving the message, the client decrypts it using its symmetric secret key Kc, which is only known to it and the KAS. It checks to see if the nonce (n) matches the specific request, and then caches the session key Kc,tgs for future communications with the TGS. The client then sends a message to the TGS. This message contains the initial ticket Tc,tgs Ktgs , the server name (s), a nonce, and a new authenticator Ac containing a timestamp. Ac is c, nonce. The message is: AcKc,tgs , Tc,tgsKtgs , s, n
4. TGS -> Client The (TGS) receives the above message from the client (c), and first deciphers the sealed ticket using its TGS encryption key. This ticket was originally sealed by the Kerberos authentication server in step 2 using the same key. From the deciphered ticket, the TGS obtains the TGS-session-key. It uses this TGS session key to decipher the sealed authenticator. The TGS now looks up the server name from the message in the Kerberos database, and obtains the symmetric encryption key (Ks) for the specified service. The TGS forms a new random session key Kc,s for the benefit of the client (c) and the server (s), and then creates a new ticket Tc,s containing: Kc,s , n, nonce, lifetime, etc. It then assembles and sends a message to the client.
5. Client -> Server The client receives this message and deciphers it using the TGS session key that only it and the TGS share. From this message it obtains a new session key Kc,s that it shares with the server(s) and a sealed ticket that it cannot decipher because it is enciphered using the server's secret key K s . The client builds an authenticator and seals it using the new symmetric session key Kc,s . At last, it sends a message containing the sealed ticket and the authenticator to the server (s) to request its service. The server (s) receives this message and first deciphers the sealed ticket using its encryption key, which only it and KAS know. It then uses the new session key contained in the ticket to decipher the authenticator and does the same validation process that was described in step 4. Once the server has validated a client, an option exists for the client to validate the server to prevent an intruder from impersonating the server. The client requires then that the server sends back a message containing a timestamp. This message is enciphered using the session key that was passed from the client to the server.
Let us summarize some of the central points in this scheme:
In order for the workstation to use any end server, a ticket is required. All tickets, other than the first ticket (also called the initial ticket) are obtained from the TGS. The first ticket is special; it is a ticket for the TGS itself and is obtained from the Kerberos authentication server. Every ticket is associated with a session key that is assigned every time a ticket is allocated
Important Note: All the keys referred above in Kerberos discussion are symmetric keys. As we will see later, asymmetric keys can be used for Kerberos for first two messages encryption, method referred as Kerberos/PKINIT. But the Kerberos idea remains the same.
The common general attacks against security can be:
A detailed description of the threats on each interface and solution encountered will be presented in chapter 5.1 Now it is briefly presented attack that are particular to Packet Cable Network interfaces.
Below is a summary of general threats and the corresponding attacks from Packet Cable perspective that are relevant in the context of IP voice communications.
Theft of Service
The theft of services can be treated according to two criterions: Theft of network Services and Theft of services Provided by MTA.
Theft of Network Services
Attacks
MTA Clones
One or more MTAs can masquerade as another MTA by duplicating its permanent identity and keys. The secret cryptographic keys may be obtained by either breaking the physical security of the MTA or by employing cryptoanalysis. In addition to cloning of the permanent cryptographic keys, temporary (usually symmetric) keys may also be cloned. Such an attack is more complex, since the temporary keys expire more often and have to be frequently redistributed.
Subscription Fraud is when a customer sets up an account under false information
Protocol Attacks against an MTA is when a weakness in the protocol can be manipulated to allow an MTA to authenticate to a network server with a false identity or hijack an existing voice communication. This includes replay and man-in-the-middle attacks. This is one of the most important attack, because even if we have a very good encryption systems, if the protocol is weak, the thief does not need to decript any message, he will use the protocol weaknesses to get the needed information (by actively using the protocol);
Theft of Services provided by MTA
Attacks
MTA code to support these services may be downloaded illegally by an MTA clone, in which case the clone has to interact with the network to get the download. In that case, this threat is no different from the network service theft described in the previous section.
Signaling Channel Information Threats Signaling information, such as the caller identity and the services to which each customer subscribes may be collected for marketing purposes. The caller identity may also be used illegally to locate a customer that wishes to keep his or her location private.
Repudiation In a network where masquerade (using the above mentioned cloning and protocol manipulation techniques) is common or is easily achievable, a customer may repudiate a particular communication (and, e.g., deny responsibility for paying for it) on that basis.
In addition, unless public key-based digital signatures are employed on each message, the source of each message cannot be absolutely proven. If a signature over a message that originated at an MTA is based on a symmetric key that is shared between that MTA and a network server (e.g. the CMS), it is unclear if the owner of the MTA can claim that the Service Provider somehow falsified the message. Public key based digital signatures can be a solution.
In this chapter we will take a closer look on some of the most important interfaces between cable modem elements. The following figure summarizes all packet cable security interfaces, including the key management.
In the diagram before, the significance of each interface label looks like this [1]:
<label>:<protocol> <security protocol> / <key management protocol>
If the key management protocol is missing, it means there is no need for key management for that interface.
A briefly description of the security interfaces are presented in the following table [1].
In previous chapter we analyzed the general mechanism of security widely used. In this chapter we will particularize the algorithms to meet the specific requirements for cable networks. So we will present the particular properties of IPSec and IKE, Kerberos with its extension PKINIT (asymmetric key encryption for the kerberos methods). Also the End-to-End Security for RTP, BPI+ will be presented in the paper.
Because within PacketCable, IPSEC is used on a number of different interfaces with different security and performance requirements, several different key management protocols have been chosen for different PacketCable interfaces. On some interfaces it is IKE, on other interfaces it is Kerberos/PKINIT, and in some cases IPSEC keys are distributed over protected signaling interfaces.
In addition, some network elements are required to run multiple key management protocols. In particular, the CMS and the MTA MUST support multiple key management protocols. The MTA has to support Kerberos/PKINIT on the MTA-CMS signaling interface, in addition to IKE on the CMS-CMTS and CMS-RKS interfaces. The MTA has to support Kerberos/PKINIT on the MTA-CMS signaling interface, as well get its IPSEC keys for RTCP packets from NCS signaling messages [1].
In the 2nd phase it is negotiated another secret than 1st phase used to derive keys for the IPSec ESP transforms. As in the 1st phase authentication is important to avoid man in the middle attacks, we must use it for the message exchange. There are a couple of modes for defining the authentication. In packet cable IKE Authentication with Signatures and Authentication with Pre-Shared Keys are used. In the 2nd phase, an IPSec ESP SA is established , including the IPSec ESP keys and ciphers. First a second phase secret is established, and then all the IPSec keying material is derived from that new secret using a one way function. Symmetric encryption Algorithms for IKE Exchanges are used in both phases. The encryption algorithms that can be negotiated are: 3-DES in CBC mode, RC5 in CBC mode, IDEA in CBC mode, etc (all are symmetrical key algorithms). [1], [3]
The basic mechanism is as follows [1]:
The client(MTA) sends an AS-REQ message (client request - 1st message) to the KDC as before, except that, the client use public key cryptography in the initial authentication step, his certificate and a signature accompany the initial request in the preauthentication fields. Upon receipt of the client's request, the KDC verifies the certificate and issues a ticket granting ticket (TGT) as before, except that, the encryption part from the AS-REP message (TGS response - 2nd message) carrying the TGT is now encrypted utilizing either a Diffie-Hellman derived key or the client's public key. This message is authenticated utilizing the public key signature of the KDC.
The protocol is based on kerberos tickets, which are cookies, encrypted with the particular server's key. A kerberos ticket is used to both authenticate a client to a server and to establish a session key, which is contained in the ticket. Two way authentication with public key certificates (with PKINIT) is used by MTA (client in kerberos terminoly) to obtain a CMS (server in Kerberberos terminology) ticket from the TGS (the trusted third party). The authentication in each direction is accomplished with a digital signature over some known information and with a public key certificate chain. The digital signature is a proof that each party posses its private key, while the certificate chain authenticates the corresponding public key and associates it with a known identity.
The corresponding session key is delivered to the MTA sealed with either the MTA's RSA public key or with a secret key derived from a Diffie Hellman key exchange algorithm.
The CMS ticket contains a symmetric session key, which in turn is used to establish a set of keys for use with the IPSec ESP mode.
The diagram below illustrates how the MTA uses PKINIT to obtain a kerberos ticket for the CMS (first two messages). The kerberos ticket is later used by the MTA to set up a security association with the CMS. Note, that for the rest of the messages (the last three) there is no requirement for public key usage.
For the remaining three Kerberos messages (Kerberos AP Request/AP Replay Exchange) we can summarize in the figure below:
Keys for the encryption and MAC calculation are derived from the End-End secret, which is exchanged between sending and receiving MTA as part of the call signaling. Thus, the key exchanges for media stream security are secured themselves by the call signaling security.
Key management for RTP requires that both the (encryption) Transform ID and the Authentication are specified. RTP uses RTP-RC4 as transform (encryption cipher). This is a RC4 stream cipher. It a very efficient symmetric cipher about 10 times faster than DES. As authentication algorithms RTP-MMH-2 and RTP-MMH-4 must be supported.
At the device provisioning the MTA device verifies the authenticity of the configuration file downloaded from the boot server. Privacy of the configuration data is also provided. The configuration data will be "signed and sealed" by packaging it into a PKCS 7 sealed object.
DNS has its own security mechanism incorporated called DNSSEC.
The most important element that must support multiple interfaces is the MTA.
The SNMP3 keys are downloaded with the MTA configuration file.
Security Services
Key Management SNMPv3 security specification defines key change messages which are protected with the old value of the key. During device provisioning the MTA receives its authentication and privacy keys in an encrypted configuration file.
This interface is used by the message exchange between MTA (client)
and the TGS (server) for obtaining tickets for CMS (server). As this interface
covers only a part of the Kerberos/PKINIT message exchange, (already discussed
previously) it will not be detailed. And, we can not talk about services
on this interface. The services are treated globally for Kerberos/PKINIT
protocol.
The protocol will be described below in the CMS protocol presentation.
CMS is the other end of the same interface.
Services
Key Management Key Distribution via the CMS, a trusted third party, assures the MTA that the communication was established through valid signaling procedures, and with a valid subscriber. Each MTA (or MG) is also assured that the key it receives is not shared by anyone else besides the MTA (or MG) on the other side of a legitimately established connection.
Since BPI+ key management and privacy runs between CM and CMTS,
it does not help in authenticating the identity of the MTA. So, all protocols
between MTA and CMTS have additional security requirements not met by BPI+.
RSVP protocol is used between CMTS and MTA.
CMTS is another network element that must implement multiple interface protocols.:
CMS functional element must also implement multiple interfaces:
Security Services (The same set of requirements applies to
both CMS-MTA and CMS-CMS signaling interfaces)
Key Management Kerberos with PKINIT MUST be used as the key distribution mechanism on the pkt-s10 interface. The MTA will obtain the Kerberos ticket from the TGS when started and will refresh it based on the timeout parameter. The MTA will also obtain sub-key (and thus IPSEC ESP keys) based on timeout parameters. The MTA will also obtain the IPSEC ESP keys when they are timed out and the MTA needs to transmit data to the CMS. Usage of Kerberos/PKINIT on this interface is allowed due to the feasibility to have a trusted third party without big expense.
All signaling traffic, which includes QoS signaling, call signaling, and signaling with the PSTN Gateway Interface, will be secured via IPSec. IPSec security association management will be done through the use of two key management protocols:Kerberos/PKINIT and IKE. Kerberos/PKINIT will be used to exchange keys between MTA clients and their CMS server; IKE will be used to manage all other signaling IPSec SAs.
KINK is used to create a protocol for centralized key management for Security Associations (SA) as an alternative to IKE. It uses the Kerberos architecture for key management. The idea is to obtain a system functioning without requiring public key usage. It is intended not to require any modifications to IPSec or Kerberos. In fact, the new protocol integrates much of the Kerberos functionality. The idea is the usage of centralized keying authority.
Some of KINK requirements are: use the Kerberos to create session keys securely, ability to be integrated into IPSec security architecture, must allow for IPSec SA s to be initiated by both servers and clients, thus preserving IPSec's peer to peer nature, must support authentication with secret key or with public key, must be able to setup both transport and tunnels for AH and ESP security associations.
This protocol is a hybrid protocol of Kerberos and IKE. Due to its flexible requirements it would be a good alternative of the current implementations [5].
As many of the most important elements (CMS, OSS servers, Gateway servers) are located in the operator premises, and the message exchange between elements can be done on a ``private'' separated network without traversing public networks, IKE is a better solution than Kerberos (no need to implement a new sever - as required by Kerberos).
It is not also feasible to load the multimedia traffic with extremely sophisticated security protocols, since the signaling would load the network against the data traffic. That's also why RTP interface uses CMS based Key management and RC4 encryption transform, and for the signaling traffic RTCP is still used IKE. IKE is used due to its ability to have direct peer-to-peer functionality.
Regarding the CMTS and HFC Security. On HFC the security system BPI+ is handling Datalink Layer security. But it can't secure the IP layer. So, a security for IP layer for the IP packets on the HFC network is required.
Normal internet traffic can be also provided. We can use (connect) one or more of managed IP network routers to the internet. If extra security is required, a firewall can be configured in those routers. Of course, the charging servers must be configured to support internet traffic.
Concerning the VoIP protocols, there are several numbers of protocols that might be used: RTP, SIP (evolved as an alternate to H323), RTSP, Codecs. Each protocol usage requires its own specific implementations. In this paper only the RTP specific implementations were discussed.
The paper described the security protocols and the key management associated. VoIP over PacketCable infrastructure takes the advantage of the ready CATV HFC infrastructure to bring services that do not have (or even can not be implemented) over the normal PSTN networks. As remarked, it is still kept into use the compatibility with normal PSTN lines. Extra services to VoIP can be successfully implemented over PacketCable Networks.
This document was generated using the LaTeX2HTML translator Version 98.1p1 release (March 2nd, 1998)
Copyright © 1993, 1994, 1995, 1996, 1997, Nikos Drakos, Computer Based Learning Unit, University of Leeds.
The command line arguments were:
latex2html -split 0 -local_icons -address burlacum@cc.hut.fi
packetcable.
The translation was initiated by Mihai Burlacu on 2000-11-26
