Another solution is to define a prefix that has to be dialled to reach an IP telephone.
As mentioned before, prefix-routing is the easiest option to configure. An IP Telephony prefix would also allow a user to change from a legacy phone to an IP Telephony phone but keep his number modified in a way that is easy to remember (e.g., if the internal number was 2972 and the prefix for VoIP is 99 than the new number is 992972, which applies for all numbers).
On the other hand, there must be a way to decide if a call that originates on the IP-side has an IP
Telephony target or a phone on the PBX. Again, this can be realised with a service prefix for legacy phones or by making the PBX the default route for targets that are not registered at the same server.This must be carefully considered to avoid the situation that a call from an IP phone to another IP phone target that is not currently registered is routed back and forth between IP
Telephony server and PBX.
The problem with this solution is that you have to know if the person you want to call has an IP
phone or not and this constitutes a number change which still requires all business cards to be reprinted.
To avoid this number change being ‘visible’, the PBX might set up a mapping table that maps outdated old addresses to the new addresses, so the PBX maps the dialled 2972 to 992972 and routes the call to the IP world.
P.73
[IP Telephony Cookbook] / Setting Up Basic Services
3.Per-number routing
The cleanest way to handle call routing is to perform routing decisions on the individual number (see Section 4.1.1.1.2).Whether a number belongs to an IP phone or PBX phone is fully transparent to the user and no error-prone default routes are required. It is also the solution that has the highest configuration and administration effort because there are, most probably, at least two databases that must be kept consistent.
4.Protocol- and number-based routing
The call routing problem gets worse as soon as multiple call-signalling protocols are deployed in the IP world and there is no single server supporting all of them at once (see Figure 4.5). Every IP Telephony server must be aware that a number that belongs to another server must be routed to the gateway, or otherwise the gateway must be the default route for unknown targets. In any case, calls for unknown targets land on a gateway.The gateway needs to decide where to route a call. Because it is desirable that gateways are dumb (to prevent having yet another place to configure routing details), the gateway will hand the call to the PBX which makes the final routing decision, which eventually means to hand the call to another gateway (or back to the originating server if there is only one multi-protocol gateway).
All of the problems and solutions mentioned above are very dependent on specific products and the features they support, so, unfortunately, there can be no general advice on how to implement dial plan migration.
~ 4.3 Authentication
To charge individuals for used services, it is necessary to have means of authentication for registration and call signalling.This section gives an overview of the mechanisms used for this purpose in H.323 and SIP.
~ 4.3.1 Authentication in H.323
The H.323 protocol framework uses H.235 Security and Encryption for H-series (H.323 and other H.245-based) multimedia terminals for optional security features.This recommendation describes how to incorporate authentication, integrity and confidentiality for H.323
communication and what kind of security infrastructure and techniques are supported.
~ 4.3.1.1 Areas of application
H.235 can be applied to all aspects of H.323 communication, which can be broken into two basic categories: Security for signalling messages and Security for media streams.
Security for signalling messages includes the RAS channel (see Section 2.2.1.3) that is used for registration of endpoints, admission and status of calls, as well as the call signalling channel (H.225) that is used for call establishment and the media control channel (H.245).
Security for media streams is used to provide confidentiality for transmitted audio and video data.
P.74
[IP Telephony Cookbook] / Setting Up Basic Services
~ 4.3.1.2 User Authentication
User authentication is the process by which a user performing an action proves his identity to the server entity. Basically, three different approaches can be classified: passwords with symmetric encryption, passwords with hashing and public-key mechanisms.
1.Passwords with symmetric encryption: This approach is based on the idea that both communicating entities share a secret, e.g., a password and that each endpoint has a unique generalID that has been configured before by some means outside the protocol and that is known to both endpoints.
The endpoint that wishes to be authenticated generates a CryptoToken which consists of the sender's generalID, the receivers generalID, a timestamp and a random number (that is monotonically increasing, making messages with the same timestamp unique) encoded with the secret key (derived from the shared password).
Encryption can be done by a selection of mechanisms such as DES, 3-DES or any other algorithm that is registered in ISO/IEC 9979. It is also possible that a manufacturer can use other algorithms although this will not be interoperable.
2.Passwords with hashing: this is a similar approach, where CryptoHashedToken is computed using the generalID and a timestamp to be passed through a hashing function like HMAC-MD5 or algorithms defined in ISO/IEC 97972.
3.Public-key mechanisms: this approach also generates a CryptoToken but uses asymmetric encryption.This enables the use of signature cards and certificates.
~ 4.3.1.3 Integrity
Integrity refers to message integrity and ensures that a received message is identical to that which was transmitted by the sender and has not been modified.
H.235 supports two mechanisms to achieve integrity: the use of CryptoTokens and the IntegrityCheckValue.
1.CryptoTokens are already described in Section 4.3.1.2.To allow an integrity check, the whole message is used to compute a MAC/digital signature, instead of just a small subset required for authentication.
This mechanism can be used for any signalling channel (RAS/H.225.0/H.245).
2.IntegrityCheckValue refers to an element that occurs in RAS messages. Again, the hash-value of the message (without the hash-value) is transmitted.
This second mechanism was introduced before the adoption of H.235, because it was deemed critical that there was not a data-integrity mechanism for the unreliable RAS channel. Since the adoption of H.235, the CryptoToken method is the preferred way to check integrity.
2. An unofficial list can be found at: <http://www.isg.rhul.ac.uk/~cjm/ISO-register/> P.75
[IP Telephony Cookbook] / Setting Up Basic Services
~ 4.3.1.4 Confidentiality
Confidentiality ranges from secured H.225.0 signalling channels to secured media streams.The H.323/H.235 suite of protocols does not specify a way to secure the signalling channels, because they are used first in every call but have to be secured from the very beginning. Instead,Transport Layer Security (TLS) or IPSEC is be used to secure the H.225.0 channel. An endpoint supporting such a mechanism must listen on a well-known port (e.g., 1300 for TLS) to receive secured connections.
Within H.225.0, the security capabilities for the H.245 media control channel can be exchanged.
The H.245 channel itself can be used to negotiate media encryption.
~ 4.3.1.5 Security profiles
H.235 defines three security profiles, - the ‘Baseline security profile’, the ‘Signature security profile’ and the ‘Voice encryption security profile’. Each profile defines a collection of H.235
mechanisms that must be supported by an endpoint.
The Baseline security profile is the simplest profile and is suitable for providing authentication and integrity in password-based environments. Most endpoints that claim H.235 support implement (only) this profile.
The Signature security profile is the same as the Baseline security profile but uses digital signatures instead of passwords.
The Voice encryption security profile defines mechanisms to achieve confidentiality for the media streams. It can be used along with one of the other security profiles that achieve authentication.
~ 4.3.1.6 H.235 and the real world
While H.235 has existed for some years, there are not many H.323 products that support it. Some products only use H.235 (baseline security) for the communication between gatekeeper and gateway and not for communication with the endpoint. And even in cases where endpoint communication uses H.235, it is often not interoperable between different vendor products because H.235 does not mandate a minimum set of algorithms that can be used, or which elements, the generated tokens must consist of. So, when interested in H.235 in your IP
Telephony network, ask your IP Telephony vendor for a list of compatible equipment.
~ 4.3.2 Authentication in SIP
This section describes authentication mechanisms used in SIP-based networks. First the basics of digest authentication are described, while in following sections a brief overview is given of how digest authentication applies to SIP messages, when it should be used and when it should not.
P.76
[IP Telephony Cookbook] / Setting Up Basic Services
~ 4.3.2.1 Overview of Digest Authentication
Digest authentication is a simple authentication mechanism developed originally for HTTP (it is often called HTTP digest) and it is described in RFC2671.The authentication mechanism is very simple. It is based on cryptographic hashes to prevent the transferring of the user's password in clear-text.
Digest authentication verifies that both parties that communicate know a shared secret (a password).
When a server wants to authenticate a user, it generates digest challenge and sends it to the user.
A typical digest challenge looks like this:
Digest realm="iptel.org", qop="auth,auth-int", nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", opaque="", algorithm=MD5
It consists of a set of parameters that are sent to the user.The user then uses the parameters to generate the proper digest reply and send it back to the server.The meaning of the parameters in the digest challenge is as follows:
- realm:The realm parameter is mandatory and must be present in all challenges. Its purpose is to identify credentials within a SIP message. In the case of SIP, it is usually set to the domain that the proxy server is responsible for.
SIP user agents are supposed to display the contents of the parameter to the user when they prompt him for username and password so that he uses the appropriate username and password (for this server);
- nonce: this is a server-specified data string which is uniquely generated each time a server generates a digest challenge. Nonce is usually constructed as the MD5 hash of some data.The data usually includes time-stamp and a secret phrase of the generating server.That ensures that each nonce has a limited lifetime (i.e., expires after some time and can not be used later) and also is unique (i.e., no other server will be able to generate the same nonce).
Clients use the nonce to generate a digest response and thus the server will receive the contents of the nonce back in a digest response. It usually checks the validity of the nonce before it checks the rest of the digest response.
So, basically, nonce is a sort of an identifier that ensures that received digest credentials have really been generated for a particular digest challenge, and also limits the lifetime of the digest response, preventing replay attacks in the future;
- opaque: this is an opaque data string passed to the user in a challenge.The user will pass the data string back to the server in a digest response.That allows servers to be stateless. If there is any state they need to maintain between challenge and response, they can pass it to the client using this parameter and read it again later when a digest response comes.
- algorithm: the algorithm used to calculate hashes. Currently only MD5 is supported;
- qop: the quality of protection.The parameter specifies what protection schemes the server supports. A client will pick one from the list.The value ‘auth’ indicates just authentication.
P.77
[IP Telephony Cookbook] / Setting Up Basic Services
The value ‘auth-int’ indicates authentication with some integrity protection. For a more detailed description, see RFC2617.
After receiving the digest challenge, a user agent will prompt the user for username and password (if not preconfigured), generate a digest response and send the response to the server. A digest response might look like this:
Digest username="jan", realm="iptel.org",
nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", uri="sip:iptel.org", qop=auth, nc=00000001, cnonce="0a4f113b",
response="6629fae49393a05397450978507c4ef1", opaque=""
The digest response is similar to the digest challenge.Those parameters that are the same have the same meaning as in the digest challenge. Below is a brief description of only the new parameters:
- uri: the parameter contains URI the clients wants to access;
- qop: the level of protection chosen by the client;
- nc: (nonce count) the value is the hexadecimal count of the number of requests (including the current request) that the client has sent with the nonce value in this request. For example, in the first request, sent in response to a given nonce value, the client sends nc=00000001.The purpose of this directive is to allow the server to detect request replays by maintaining its own copy of this count. If the same value is seen twice, then the request is a replay;
- cnonce: the value is an opaque quoted string value provided by the client and used by both client and server to avoid chosen plain-text attacks, to provide mutual authentication and to provide some message integrity protection;
- response: a string computed by the user agent which proves that the user knows a password.
Upon reception of a digest response, the server recalculates the value of the response parameter for comparison purposes, using attributes provided by the client and the password stored on the server. If the result is identical to the response received from the client, then the client has proven knowledge of the password and he is authenticated.
~ 4.3.2.2 Digest Authentication and SIP
The appearance of digest challenge and response has been described, but not yet how they are applied to SIP messages. Since the authentication mechanism was originally developed for the HTTP protocol, and SIP is very similar to that protocol, mapping of digest challenge and response to SIP messages is easy and straightforward. It is described in RFC3261.
When a SIP server receives a SIP request and wants to verify the authenticity of the user before processing the requests, it looks to see if the request contains digest credentials. If there are no credentials in the SIP request, it will generate a negative final response and include digest challenge into the response.
When a client receives the response (containing digest challenge), it is supposed to calculate proper digest response and send the request again, this time including the calculated digest credentials.
P.78
[IP Telephony Cookbook] / Setting Up Basic Services
The server then verifies the digest response and processes the request if the verification was successful.
Proxy servers use the Proxy Authentication Required response and include the digest challenge into the Proxy-Authenticate header field. An example of such a challenge might look like: SIP/2.0 407 Proxy Authentication Required.
Via: SIP/2.0/UDP 195.37.78.121:5060.
From: sip:jan@iptel.org;tag=3944790419.
To:<sip:5060@iptel.org;user=phone>;tag=794fe65c16edfdf45da4fc39a5d2867
Call-ID: 3541699089@195.37.78.121.
CSeq: 1 INVITE.
Proxy-Authenticate: Digest realm="iptel.org", \
nonce="3f9fc19cf91f65958f664122c1310d4c28cc61a2".
Content-Length: 0.
SIP user agents (including registrars and back-to-back user agents) use the 401 Unauthorised response for the digest challenge. An example of such a challenge might be: SIP/2.0 401 Unauthorised.
Via: SIP/2.0/UDP 218.79.100.193:65030;branch=z9hG4bK1ce21dab.
To: "IPTel844978" <sip:844978@iptel.org>;tag=794fe65c16edfdf45da4fc39
From: "IPTel844978" <sip:844978@iptel.org>;tag=1fd6218e.
Call-ID: 2d471abf-c0fbee95-bee93355-fea1736b@218.79.100.193.
CSeq: 88608141 REGISTER.
WWW-Authenticate: Digest realm="iptel.org", \
nonce="3f9fc19cf91f65958f664122c1310d4c28cc61a2".
Content-Length: 0.
407 responses are used by SIP elements (mostly SIP Proxy Servers) that are not the final destination for the request, and after authentication, will forward the requests further. 401
responses are used by SIP elements that are the final destination for the request and after authentication will generate a final reply.
When including the digest response clients add an Authorisation or a Proxy-Authorisation header field that contains the digest response.The following example shows a REGISTER message containing digest credentials.
REGISTER sip:iptel.org SIP/2.0.
Via: SIP/2.0/UDP 195.37.78.121:5060.
From: sip:jan@iptel.org.
To: sip:jan@iptel.org.
Call-ID: 003094c3-bcfea44f-40bdf830-2a557714@195.37.78.121.
CSeq: 102 REGISTER.
User-Agent: CSCO/4.
Contact: <sip:jan@195.37.78.121:5060>.
Authorisation: Digest username="jan",realm="iptel.org", P.79
[IP Telephony Cookbook] / Setting Up Basic Services
uri="sip:iptel.org",response="dab81127b9a7169ed57aa4a6ca146184", nonce="3f9fc0f9619dd1a712b27723398303ea436e839a",algorithm=md5.
Content-Length: 0.
Expires: 10.
~ 4.3.2.3 Basic Scenarios
Above is a description of what digest authentication looks like and how digest challenges and responses are carried in SIP messages.This chapter looks at which SIP messages can be challenged and which cannot. It also describes the two most common situations in which digest authentication is used.
When a SIP user agent receives a digest challenge, it is supposed to re-send the same request again, but this time with proper digest credentials.That also means that the user agent must increase the CSeq number in the request in order to avoid treatment the new request as a retransmission by the server.
Because challenging a request means that the request will be sent again with higher CSeq. It is not possible to challenge ACK and CANCEL requests. Both the requests must have the same CSeq as the original request and thus can not be challenged.
All other requests can be challenged, although from time-to-time there appear implementations that seem to have problems with the challenging of the not-so-common SIP requests.
There are two cases which are deployed most often and deserve further description: authentication of REGISTER messages and authentication of INVITE messages.These are described in separate sections.
4.3.2.3.1 Registration authentication
Authentication of REGISTER messages is very important and should be done by every SIP
Proxy Server. By REGISTER messages, SIP user agents are informing the server of their current location so the server knows where to send further requests.
If a server does not authenticate REGISTER requests then anyone can register any contact for any user, thus hijacking calls to that person.This is obviously extremely important to protect against, and therefore authentication of REGISTER messages should always be enabled.
Figure 4.9 shows the call flow of a typical SIP registration including digest authentication.
P.80
[IP Telephony Cookbook] / Setting Up Basic Services
User Agent
Registrar