To charge individuals for used services it is necessary to have means of authentication for registration and call signaling. This section gives an overview on the mechanisms used for this purpose in H.323 and SIP.
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.
H.235 can be applied to all aspects of H.323 communication which can be broken into two basic categories: Security for signaling messages and Security for media streams.
Security for signaling 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 signaling 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.
User authentication is the process by which a user performing an action proofs his identity to the server entity. Basically three different approaches can be classified: passwords with symmetric encryption, passwords with hashing and public-key mechanisms.
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 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[2]. It is also possible that a manufacturer can use other algorithms although this will not be interoperable.
- 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 9797.
- Public-key mechanisms: this approach also generates a CryptoToken but uses asymmetric encryption. This enables the use of signature cards and certificates.
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.
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 signaling channel (RAS/H.225.0/H.245).
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.
Confidentiality ranges from secured H.225.0 signaling channels to secured media streams. The H.323/H.235 suite of protocols does not specify a way to secure the signaling 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 shall 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.
H.235 defines three security profiles - the "“Baseline security profile”", the "“Signature Security Profile”" and the "“Voice encryption security profile”". Each profiles 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.
While H.235 exists for some years now 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 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.
In this section we describe authentication mechanisms used in SIP based networks. First we describe basics of digest authentication, while in following sections we give a brief overview of how digest authentication applies to SIP messages, when it should be used and when it should not.
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 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 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 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 case of SIP, it is usually set to the domain 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 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 does the server support. A client will pick one from the list. The value “auth” indicates just authentication, the value “auth-int” indicates authentication with some integrity protection. For 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=""
As we can see, the digest response is similar to the digest challenge. Those parameters that are the same have the same meaning as in the digest challenge. We will briefly describe only 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.
We have described what digest challenge and response looks like, but we have not described 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 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.
The server then verifies the digest response and processes the request is the verification was successful.
Proxy servers use “407 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 Unauthorized” response for the digest challenge. An example of such a challenge might be:
SIP/2.0 401 Unauthorized. 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 “Authorization” or “Proxy-Authorization” 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>. Authorization: Digest username="jan",realm="iptel.org", uri="sip:iptel.org",response="dab81127b9a7169ed57aa4a6ca146184", nonce="3f9fc0f9619dd1a712b27723398303ea436e839a",algorithm=md5. Content-Length: 0. Expires: 10.
We have described what digest authentication looks like and how digest challenges and responses are carried in SIP messages. In this chapter we will look at which SIP messages can be challenged and which can not. We will also describe 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. We will describe them in separate chapters.
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 call flow of a typical SIP registration including digest authentication.
Authentication of INVITE requests is not really required, but it is a good practice to do so. A SIP proxy server can only challenge requests that are coming from users belonging to an administrative domain the proxy server is responsible for. This means that a proxy responsible for e.g. the iptel.org domain can challenge only requests that have iptel.org in the “From” header field.
Requests coming from foreign users can not be challenged because foreign users usually do not have a username and password registered at this server. Requiring authentication would make incoming calls from foreign users impossible.
Figure 4.10 is a call flow of challenged INVITE.
