Authentication and TLS
You can require authentication from SIP users when they perform various SIP functions (register a user, start a call, hang up a call, send a message etc). Here you configure if authentication is required, and which functions should require authentication of the user.
To require authentication for registration is a good way of ensuring that no one claims to be another user. However, you should not always use authentication; if you do, people from outside can't call you or send messages via SIP without knowing the password.
To increase security, you can also require that SIP users use TLS, which encrypts the connection. This makes it hard for eavesdroppers to read the SIP signaling.
Authentication settings
SIP authentication status
Decide whether SIP authentication should be On or Off. If Off, no authentication is required for any SIP method, regardless of what settings you have made below.
N.B.: If SIP authentication is active, all SIP methods entered in the Local SIP user database table will always require authentication for the specified domains (local/other). SIP methods which are not in the table are allowed without authentication.
Realm
When authentication is required for a method, the SIP client will ask for a password. The Realm is what the client will present on your screen when asking for a password. If you, for example, use sip.ingate.com as your Realm, the client will ask for password with a text which looks like this:
Enter the password for sip.ingate.com
SIP groups
Here you define the groups that are used when defining Local SIP user database and RADIUS users SIP group.
You can form a group of several methods by adding more rows to one group.
Name
The name of the SIP group. This name is used in the Local SIP user database table and for RADIUS users SIP group.
Subgroup
An already defined group can be used as a subgroup to new groups. Select the old group here and select '-' as Method and Traffic to. If you don't want to use a subgroup, select '-' here.
Method
Select a SIP method which this SIP user group can use with authentication.
Once a method is used, it will always require authentication for all users. Methods that are not selected in this table will not require authentication.
Example: Two SIP groups are created: Local containing the methods REGISTER and INVITE, and Other containing the method INVITE. Both these methods will now require authentication for all users, and users of the Other group will not be able to use REGISTER, as they are not allowed to use it with authentication.
Traffic to
Here, you select the direction of the authenticated traffic. Local domains means that traffic to Locally handled domains of this firewall is authenticated through this method. Other domains means that traffic to all domains which are not Locally handled domains of this firewall is authenticated through this method. Both means that this SIP method is authenticated regardless of where the traffic is bound.
Delete row
If you select this box, the row is deleted when you click on Add new rows or Save.
Add new rows
Enter the number of new groups and rows you want to add to the table, and then click on Add new rows.
SIP Methods
Enter the SIP methods available for SIP authentication. Common methods are predefined (from RFC 3261). Note that the standard methods ACK and CANCEL can't be authenticated.
Method
Enter the name of the SIP method.
Delete row
If you select this box, the row is deleted when you click on Add new rows or Save.
Add new rows
Enter the number of new rows you want to add to the table, and then click on Add new rows.
Local TLS settings
To make sure that no one can eavesdrop on the SIP signaling between your Ingate Firewall and its SIP peers, you can use encrypted SIP connections. In Ingate Firewall this is managed by the TLS transport protocol.
Here, you select whether to accept unencrypted or encrypted SIP signaling. Read more about TLS in RFC 2246.
Currently, TLS encryption is only available for one SIP domain on the firewall. SIP signaling for other SIP domains will be sent unencrypted. The TLS domain is the same domain as the CN (Common Name) of the selected X.509 certificate for TLS.
To use TLS, the firewall must have an X.509 certificate, which works as an ID card, identifying the firewall to your SIP peer. This will ensure that they are really communicating with your firewall and not somebody else's computer. TLS uses an encryption method using two keys, one secret and one public. The secret key is kept in the firewall and the public key is used in the certificate. If any of the keys is changed, the TLS connection won't work.
Accepted transport for incoming requests
Here, you select whether the firewall should accept all SIP signaling regardless of transport (Any), only unencrypted signaling (UDP or TCP), or only encrypted signaling (TLS).
Use this certificate for TLS
Here you select what certificate to use. The same certificate is used for all TLS peers. All local certificates for the firewall are created on the Certificates page under Basic Configuration.
TLS CA certificates
To authenticate peers for TLS connections, the firewall needs certificates for the CAs used for signing the peer certificates.
CA
Select a CA from which the firewall should accept connections. The CA certificates are imported on the Certificates page.
Delete row
If you select this box, the row is deleted when you click on Add new rows or Save.
Add new rows
Enter the number of new rows you want to add to the table, and then click on Add new rows.
Save
Saves the Authentication and TLS configuration to the preliminary configuration.
Undo
Reverts all of the above fields to their previous configuration.